| rfc9840v2.txt | rfc9840.txt | |||
|---|---|---|---|---|
| skipping to change at line 246 ¶ | skipping to change at line 246 ¶ | |||
| rLEDBAT assumes that the sender is a standard-TCP sender. rLEDBAT | rLEDBAT assumes that the sender is a standard-TCP sender. rLEDBAT | |||
| does not require any rLEDBAT-specific modifications to the TCP | does not require any rLEDBAT-specific modifications to the TCP | |||
| sender. The envisioned deployment model for rLEDBAT is that the | sender. The envisioned deployment model for rLEDBAT is that the | |||
| clients implement rLEDBAT and this enables rLEDBAT in communications | clients implement rLEDBAT and this enables rLEDBAT in communications | |||
| with existing standard-TCP senders. In particular, the sender MUST | with existing standard-TCP senders. In particular, the sender MUST | |||
| implement [RFC9293] and also MUST implement the TCP Timestamps (TS) | implement [RFC9293] and also MUST implement the TCP Timestamps (TS) | |||
| option as defined in [RFC7323]. Also, the sender should implement | option as defined in [RFC7323]. Also, the sender should implement | |||
| some of the standard congestion control mechanisms, such as CUBIC | some of the standard congestion control mechanisms, such as CUBIC | |||
| [RFC9438] or NewReno [RFC5681] [RFC6582]. | [RFC9438] or NewReno [RFC5681] [RFC6582]. | |||
| rLEDBAT does not define a new congestion control algorithm. The LBE | rLEDBAT does not define a new congestion control algorithm. The | |||
| congestion control algorithm executed in the rLEDBAT receiver is | definition of the actual LBE congestion control algorithm executed in | |||
| defined in other documents. The rLEDBAT receiver MUST use an LBE | the rLEDBAT receiver is beyond the scope of this document. The | |||
| congestion control algorithm. Because rLEDBAT assumes a standard-TCP | rLEDBAT receiver MUST use an LBE congestion control algorithm. | |||
| sender, the sender will be using a "best effort" congestion control | Because rLEDBAT assumes a standard-TCP sender, the sender will be | |||
| algorithm (such as CUBIC or NewReno). Since rLEDBAT uses the receive | using a "best effort" congestion control algorithm (such as CUBIC or | |||
| window to control the sender's rate and the sender calculates the | NewReno). Since rLEDBAT uses the receive window to control the | |||
| sender's window as the minimum of the receive window and the | sender's rate and the sender calculates the sender's window as the | |||
| congestion window, rLEDBAT will only be effective as long as the | minimum of the receive window and the congestion window, rLEDBAT will | |||
| congestion control algorithm executed in the receiver yields a | only be effective as long as the congestion control algorithm | |||
| smaller window than the one calculated by the sender. This is | executed in the receiver yields a smaller window than the one | |||
| normally the case when the receiver is using an LBE congestion | calculated by the sender. This is normally the case when the | |||
| control algorithm. The rLEDBAT receiver SHOULD use the LEDBAT | receiver is using an LBE congestion control algorithm. The rLEDBAT | |||
| congestion control algorithm [RFC6817] or the LEDBAT++ congestion | receiver SHOULD use the LEDBAT congestion control algorithm [RFC6817] | |||
| control algorithm [LEDBAT++]. rLEDBAT MAY use other LBE congestion | or the LEDBAT++ congestion control algorithm [LEDBAT++]. rLEDBAT MAY | |||
| control algorithms defined elsewhere. Irrespective of which | use other LBE congestion control algorithms defined elsewhere. | |||
| congestion control algorithm is executed in the receiver, a rLEDBAT | Irrespective of which congestion control algorithm is executed in the | |||
| connection will never be more aggressive than standard-TCP, since it | receiver, a rLEDBAT connection will never be more aggressive than | |||
| is always bounded by the congestion control algorithm executed at the | standard-TCP, since it is always bounded by the congestion control | |||
| sender. | algorithm executed at the sender. | |||
| rLEDBAT is essentially composed of three types of mechanisms, namely | rLEDBAT is essentially composed of three types of mechanisms, namely | |||
| those that provide the means to measure the packet delay (either the | those that provide the means to measure the packet delay (either the | |||
| RTT or the one-way delay, depending on the selected algorithm), | RTT or the one-way delay, depending on the selected algorithm), | |||
| mechanisms to detect packet loss, and the means to manipulate the | mechanisms to detect packet loss, and the means to manipulate the | |||
| receive window to control the sender's rate. The first two provide | receive window to control the sender's rate. The first two provide | |||
| input to the LBE congestion control algorithm, while the third uses | input to the LBE congestion control algorithm, while the third uses | |||
| the congestion window computed by the LBE congestion control | the congestion window computed by the LBE congestion control | |||
| algorithm to manipulate the receive window, as depicted in Figure 1. | algorithm to manipulate the receive window, as depicted in Figure 1. | |||
| End of changes. 1 change blocks. | ||||
| 20 lines changed or deleted | 20 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. | ||||