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.
	skipping to change at line 798 ¶		skipping to change at line 798 ¶
	Balasubramanian, P., Havey, D., and G. Montenegro,		Balasubramanian, P., Havey, D., and G. Montenegro,
	"Design, implementation and validation of a receiver-		"Design, implementation and validation of a receiver-
	driven less-than-best-effort transport", Computer		driven less-than-best-effort transport", Computer
	Networks, vol. 233, DOI 10.1016/j.comnet.2023.109841,		Networks, vol. 233, DOI 10.1016/j.comnet.2023.109841,
	September 2023,		September 2023,
	<https://doi.org/10.1016/j.comnet.2023.109841>.		<https://doi.org/10.1016/j.comnet.2023.109841>.
	[LEDBAT++] Balasubramanian, P., Ertugay, O., Havey, D., and M.		[LEDBAT++] Balasubramanian, P., Ertugay, O., Havey, D., and M.
	Bagnulo, "LEDBAT++: Congestion Control for Background		Bagnulo, "LEDBAT++: Congestion Control for Background
	Traffic", Work in Progress, Internet-Draft, draft-irtf-		Traffic", Work in Progress, Internet-Draft, draft-irtf-
	iccrg-ledbat-plus-plus-02, 13 February 2025,		iccrg-ledbat-plus-plus-03, 9 September 2025,
	<https://datatracker.ietf.org/doc/html/draft-irtf-iccrg-		<https://datatracker.ietf.org/doc/html/draft-irtf-iccrg-
	ledbat-plus-plus-02>.		ledbat-plus-plus-03>.
	[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion		[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
	Control", RFC 5681, DOI 10.17487/RFC5681, September 2009,		Control", RFC 5681, DOI 10.17487/RFC5681, September 2009,
	<https://www.rfc-editor.org/info/rfc5681>.		<https://www.rfc-editor.org/info/rfc5681>.
	[RFC6582] Henderson, T., Floyd, S., Gurtov, A., and Y. Nishida, "The		[RFC6582] Henderson, T., Floyd, S., Gurtov, A., and Y. Nishida, "The
	NewReno Modification to TCP's Fast Recovery Algorithm",		NewReno Modification to TCP's Fast Recovery Algorithm",
	RFC 6582, DOI 10.17487/RFC6582, April 2012,		RFC 6582, DOI 10.17487/RFC6582, April 2012,
	<https://www.rfc-editor.org/info/rfc6582>.		<https://www.rfc-editor.org/info/rfc6582>.
End of changes. 3 change blocks.
	22 lines changed or deleted		22 lines changed or added
This html diff was produced by rfcdiff 1.48.