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. |