Hi, Marcelo. We updated the third paragraph of Section 4 per your note below.
The latest files are posted here. Please refresh your browser: https://www.rfc-editor.org/authors/rfc9840.txt https://www.rfc-editor.org/authors/rfc9840.pdf https://www.rfc-editor.org/authors/rfc9840.html https://www.rfc-editor.org/authors/rfc9840.xml https://www.rfc-editor.org/authors/rfc9840-diff.html https://www.rfc-editor.org/authors/rfc9840-rfcdiff.html (side by side) https://www.rfc-editor.org/authors/rfc9840-auth48diff.html https://www.rfc-editor.org/authors/rfc9840-auth48rfcdiff.html (side by side) https://www.rfc-editor.org/authors/rfc9840-lastdiff.html https://www.rfc-editor.org/authors/rfc9840-lastrfcdiff.html (side by side) https://www.rfc-editor.org/authors/rfc9840-xmldiff1.html https://www.rfc-editor.org/authors/rfc9840-xmldiff2.html https://www.rfc-editor.org/authors/rfc9840-alt-diff.html Thank you! Lynne Bartholomew RFC Production Center > On Sep 9, 2025, at 1:08 AM, marcelo bagnulo braun <marc...@it.uc3m.es> wrote: > > Hi, > > thanks for the comments, replies below... > > El 8/9/25 a las 21:22, Lynne Bartholomew escribió: >> Hi, Marcelo. Thank you for your replies to our questions! >> >> A couple follow-up questions for you: >> >> Regarding our question 8)a) and your reply: >> >>>> 8) <!-- [rfced] Section 3: >>>> >>>> a) Will "other documents" be clear to readers? Should one or more >>>> specific documents be cited here? >>>> >>>> Original: >>>> The LBE >>>> congestion control algorithm executed in the rLEDBAT receiver is >>>> defined in other documents. >>> by other documents we meant elsewhere (i.e. not in this document), maybe >>> using elsewhere would be clearer? >> >> As it appears that this topic could be considered beyond the scope of this >> document, may we update this sentence as follows? >> >> Currently: >> The LBE >> congestion control algorithm executed in the rLEDBAT receiver is >> defined in other documents. >> >> Suggested: >> How the LBE >> congestion control algorithm is executed in the rLEDBAT receiver is >> beyond the scope of this document. > > mmm, not exactly. > > I would suggest: > > The defintion of the actual LBE > congestion control algorithm executed in the rLEDBAT receiver is > beyond the scope of this document. > > Regards, marcelo > >> = = = = = >> >> Regarding our question 9) and your reply: >> >>>> 9) <!-- [rfced] Sections 3.1 and 3.1.1: We had trouble following the >>>> meaning of "honoring both", "may fall short to honor", "honoring >>>> that", and "sufficient to honor the window output" in these >>>> sentences. Please clarify. >>> There seem a lot of honor in this document! :) >>> I thought it was an expression widely used in english >>> In general, what I meant was essentially to comply with the restriction >>> imposed by the RLWND and fcwnd (respecting, adhering to, or not violating >>> according to chatgpt) >>> The value of the window must not be larger than any of these two, so >>> honoring them meand that the window is not largen than any of them. >>> Feel free to rephrase it if you think it is unclear. >> >> Thank you for the explanation. We did not make any changes. >> >> = = = = = >> >> The latest files are posted here. Please refresh your browser: >> >> https://www.rfc-editor.org/authors/rfc9840.txt >> https://www.rfc-editor.org/authors/rfc9840.pdf >> https://www.rfc-editor.org/authors/rfc9840.html >> https://www.rfc-editor.org/authors/rfc9840.xml >> https://www.rfc-editor.org/authors/rfc9840-diff.html >> https://www.rfc-editor.org/authors/rfc9840-rfcdiff.html (side by side) >> https://www.rfc-editor.org/authors/rfc9840-auth48diff.html >> https://www.rfc-editor.org/authors/rfc9840-auth48rfcdiff.html (side by >> side) >> >> https://www.rfc-editor.org/authors/rfc9840-alt-diff.html >> https://www.rfc-editor.org/authors/rfc9840-xmldiff1.html >> https://www.rfc-editor.org/authors/rfc9840-xmldiff2.html >> https://www.rfc-editor.org/authors/rfc9840-alt-diff.html >> >> Thanks again! >> >> Lynne Bartholomew >> RFC Production Center >> >>> On Sep 4, 2025, at 3:21 AM, marcelo bagnulo braun <marc...@it.uc3m.es> >>> wrote: >>> >>> Hi, >>> >>> Thanks for all the work on the document. >>> I reply online below... >>> >>> El 18/8/25 a las 22:15, rfc-edi...@rfc-editor.org escribió: >>>> Authors, >>>> >>>> While reviewing this document during AUTH48, please resolve (as necessary) >>>> the following questions, which are also in the XML file. >>>> >>>> >>>> 1) <!-- [rfced] Alberto, would you prefer that we use accented letters >>>> in your name in this and subsequent RFCs? We ask because we see >>>> "García-Martínez" in [COMNET1], [COMNET2], and [COMNET3]. We are >>>> fine either way, but we ask because some authors prefer that the >>>> accents be used. If you prefer that we use the accented letters >>>> going forward, we will note your preference for future reference. >>>> >>>> Original: >>>> A. Garcia-Martinez >>>> ... >>>> Alberto Garcia-Martinez --> >>>> >>> Accents would be great, thanks! >>> >>>> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in the >>>> title) for use on <https://www.rfc-editor.org/search>. --> >>>> >>> Congestion control, scavenger/less-than-best-effort traffic >>> >>>> 3) <!-- [rfced] Please ensure that the guidelines listed in Section 2.1 >>>> of RFC 5743 have been adhered to in this document. See >>>> <https://www.rfc-editor.org/rfc/rfc5743.html#section-2.1>. --> >>>> >>> These have been addressed during shepherd review. >>> >>>> 4) <!-- [rfced] Section 1: Is there a distinction between >>>> "standard-TCP" and "standard TCP" (e.g., "standard TCP sender", >>>> "standard-TCP flow") as used in this document, or do they mean the >>>> same thing? We ask because we see "hereafter referred (to) as >>>> standard-TCP for short" in the second paragraph of Section 1. >>>> If "standard-TCP" and "standard TCP" mean the same thing, we suggest >>>> removing the hyphen*. >>>> >>>> * Please note that we also see "standard TCP" but not "standard-TCP" >>>> in RFC 6817, and the only published RFC to date that uses >>>> "standard-TCP" appears to be RFC 1687 ("A Large Corporate User's View >>>> of IPng"), published in August 1994. >>> I suggest we use standard-TCP throughout the document. >>> >>>> Original: >>>> When LEDBAT traffic shares a bottleneck with other traffic using >>>> standard congestion control algorithms (for example, TCP traffic >>>> using Cubic[RFC9438], hereafter referred as standard-TCP for short), >>>> it reduces its sending rate earlier and more aggressively than >>>> standard-TCP congestion control, allowing other non-background >>>> traffic to use more of the available capacity. >>>> ... >>>> rLEDBAT assumes that the sender is a standard TCP sender. >>>> ... >>>> This guarantees >>>> that the rLEDBAT flow will never transmit more aggressively than a >>>> standard-TCP flow, as the sender's congestion window limits the >>>> sending rate. --> >>>> >>>> >>>> 5) <!-- [rfced] Appendix A (moved to Section 2, as noted below): >>>> >>>> a) Please note the following: >>>> >>>> * Because we found "RFC 2119 key words" (e.g., "MUST", "SHOULD") in >>>> this document, per our standard process we added the appropriate >>>> boilerplate text and Normative Reference listings. >>>> >>>> * We moved the contents of Appendix A to a new Section 2, so that >>>> readers can read the definitions of the terms before they are used >>>> in this document (e.g., "RCV.WND" in Section 4.1). >>> ok >>> >>>> b) We had trouble following the meaning of "(which computation is >>>> modified by this specification)". Does "which computation" mean >>>> "the computation of which", and does "this specification" refer to >>>> this document or the specification of the value? If the suggested >>>> text is not correct, please clarify. >>>> >>>> Original: >>>> RCV.WND: the value included in the Receive Window field of the TCP >>>> header (which computation is modified by this specification) >>>> >>>> Suggested: >>>> RCV.WND: The value included in the Receive Window field of the TCP >>>> header (the computation of which is modified by its specification). --> >>>> >>>> >>> Agree with the proposed modification >>> >>>> 6) <!-- [rfced] Appendix A and Section 3.1: Regarding "RFC793bis (TCP) >>>> receiver": Should RFC 9293 ("Transmission Control Protocol (TCP)"), >>>> which obsoletes RFC 793, be cited in the text as suggested below? >>>> >>>> Original: >>>> fcwnd: the value that a standard RFC793bis TCP receiver calculates >>>> to set in the receive window for flow control purposes. >>>> ... >>>> In order to avoid confusion, we >>>> will call fcwnd the value that a standard RFC793bis TCP receiver >>>> calculates to set in the receive window for flow control purposes. >>>> We call RLWND the window value calculated by rLEDBAT algorithm and we >>>> call RCV.WND the value actually included in the Receive Window field >>>> of the TCP header. For a RFC793bis receiver, RCV.WND == fcwnd. >>>> >>>> Suggested: >>>> fcwnd: The value that a standard TCP receiver compliant with >>>> [RFC9293] calculates to set in the receive window for flow >>>> control purposes. >>>> ... >>>> In order to avoid confusion, we will call >>>> fcwnd the value that a standard TCP receiver compliant with >>>> [RFC9293] calculates to set in the receive window for flow control >>>> purposes. We call RLWND the window value calculated by the rLEDBAT >>>> algorithm, and we call RCV.WND the value actually included in the >>>> Receive Window field of the TCP header. For a receiver compliant >>>> with [RFC9293], RCV.WND == fcwnd. --> >>>> >>> Agree >>> >>>> 7) <!-- [rfced] Sections 3, 3.2.1, and 3.2.2: >>>> >>>> a) We changed "Time Stamp Option", "Time Stamp (TS) option", and >>>> "TimeStamp option" to "TCP Timestamps option" or "TS option", per >>>> RFC 7323 and "TS option generation rules [RFC7323]" used elsewhere in >>>> this document. Please let us know any concerns. >>>> >>>> Original: >>>> In particular, the sender MUST >>>> implement [RFC9293] and it also MUST implement the Time Stamp Option >>>> as defined in [RFC7323]. >>>> ... >>>> In order to measure RTT, the rLEDBAT client MUST enable the Time >>>> Stamp (TS) option [RFC7323]. >>>> ... >>>> In the case of TCP, the receiver can use the TimeStamp option to >>>> measure the one way delay by subtracting the timestamp contained in >>>> the incoming packet from the local time at which the packet has >>>> arrived. >>>> >>>> Currently: >>>> In particular, the sender MUST >>>> implement [RFC9293] and also MUST implement the TCP Timestamps (TS) >>>> option as defined in [RFC7323]. >>>> ... >>>> In order to measure RTT, the rLEDBAT client MUST enable the TS >>>> option [RFC7323]. >>>> ... >>>> In the case of TCP, the receiver can use the TS option to measure the >>>> one-way delay by subtracting the timestamp contained in the incoming >>>> packet from the local time at which the packet has arrived. >>> ok >>> >>>> b) We do not see "New Reno", "NewReno", or "Reno" mentioned anywhere >>>> in RFC 5681. May we also cite RFC 6582 ("The NewReno Modification to >>>> TCP's Fast Recovery Algorithm"), which obsoletes RFC 3782 (which we >>>> see mentioned in RFC 5681), for ease of the reader? >>>> >>>> Original: >>>> Also, the sender should implement some of >>>> the standard congestion control mechanisms, such as Cubic [RFC9438] >>>> or New Reno [RFC5681]. >>>> >>>> Suggested: >>>> Also, the sender should implement >>>> some of the standard congestion control mechanisms, such as CUBIC >>>> [RFC9438] or NewReno [RFC5681] [RFC6582]. >>>> ... >>>> [RFC6582] Henderson, T., Floyd, S., Gurtov, A., and Y. Nishida, "The >>>> NewReno Modification to TCP's Fast Recovery Algorithm", >>>> RFC 6582, DOI 10.17487/RFC6582, April 2012, >>>> <https://www.rfc-editor.org/info/rfc6582>. --> >>> ok >>> >>>> >>>> 8) <!-- [rfced] Section 3: >>>> >>>> a) Will "other documents" be clear to readers? Should one or more >>>> specific documents be cited here? >>>> >>>> Original: >>>> The LBE >>>> congestion control algorithm executed in the rLEDBAT receiver is >>>> defined in other documents. >>> by other documents we meant elsewhere (i.e. not in this document), maybe >>> using elsewhere would be clearer? >>> >>>> b) Does "The rLEDBAT MAY use other LBE congestion control algorithms >>>> defined elsewhere" mean "The rLEDBAT receiver MAY use other LBE >>>> congestion control algorithms defined elsewhere" or something else? >>>> We ask because we see "the rLEDBAT node", "the rLEDBAT receiver", >>>> "the rLEDBAT host", etc. >>>> >>>> We have the same question re. "the rLEDBAT in host A" >>>> (Section 3.2.1.1) and "How the rLEDBAT should resume" (Section 4). >>>> >>>> Original: >>>> The rLEDBAT MAY >>>> use other LBE congestion control algorithms defined elsewhere. >>> I would suggest simply removing the "The" and say: >>> rLEDBAT MAY use other LBE congestion control algorithms defined elsewhere. >>> >>>> ... >>>> This limitation of the sender's window can come either from the TCP >>>> congestion window in host B or from the announced receive window from >>>> the rLEDBAT in host A. >>> Similarly, remove the "The" and say >>> This limitation of the sender's window can come either from the TCP >>> congestion window in host B or from the announced receive window from >>> rLEDBAT in host A. >>> >>>> ... >>>> - How the rLEDBAT should resume after a period during which there >>>> was no incoming traffic and the information about the rLEDBAT >>>> state information is potentially dated. --> >>> Same again, remove the "the" and keep >>> How rLEDBAT should resume after a period during which there >>> was no incoming traffic and the information about the rLEDBAT >>> state information is potentially dated. >>>> >>>> 9) <!-- [rfced] Sections 3.1 and 3.1.1: We had trouble following the >>>> meaning of "honoring both", "may fall short to honor", "honoring >>>> that", and "sufficient to honor the window output" in these >>>> sentences. Please clarify. >>> There seem a lot of honor in this document! :) >>> I thought it was an expression widely used in english >>> In general, what I meant was essentially to comply with the restriction >>> imposed by the RLWND and fcwnd (respecting, adhering to, or not violating >>> according to chatgpt) >>> The value of the window must not be larger than any of these two, so >>> honoring them meand that the window is not largen than any of them. >>> Feel free to rephrase it if you think it is unclear. >>>> Original: >>>> This >>>> may fall short to honor the new calculated value of the RLWND >>>> immediately. However, the receiver SHOULD progressively reduce the >>>> advertised RCV.WND, always honoring that the reduction is less or >>>> equal than the received bytes, until the target window determined by >>>> the rLEDBAT algorithm is reached. >>>> ... >>>> In the case of rLEDBAT receiver, the rLEDBAT receiver MUST NOT set >>>> the RCV.WND to a value larger than fcwnd and it SHOULD set the >>>> RCV.WND to the minimum of RLWND and fcwnd, honoring both. >>>> ... >>>> In order to avoid window shrinking, the receiver MUST only reduce >>>> RCV.WND by the number of bytes upon of a received data packet. This >>>> may fall short to honor the new calculated value of the RLWND >>>> immediately. However, the receiver SHOULD progressively reduce the >>>> advertised RCV.WND, always honoring that the reduction is less or >>>> equal than the received bytes, until the target window determined by >>>> the rLEDBAT algorithm is reached. This implies that it may take up >>>> to one RTT for the rLEDBAT receiver to drain enough in-flight bytes >>>> to completely close its receive window without shrinking it. This is >>>> sufficient to honor the window output from the LEDBAT/LEDBAT++ >>>> algorithms since they only allow to perform at most one >>>> multiplicative decrease per RTT. --> >>>> >>>> >>>> 10) <!-- [rfced] Section 3.1: We had trouble parsing this sentence. >>>> We updated it as follows. If this is incorrect, please clarify the >>>> text. >>>> >>>> Original: >>>> One exception to this >>>> is at the beginning of the connection, when there is no information >>>> to set RLWND, then, RLWND is set to its maximum value, so that the >>>> sending rate of the sender is governed by the flow control algorithm >>>> of the receiver and the TCP slow start mechanism of the sender. >>>> >>>> Currently: >>>> One exception to >>>> this scenario is that at the beginning of the connection, when there >>>> is no information to set RLWND, RLWND is set to its maximum value, >>>> so that the sending rate of the sender is governed by the flow >>>> control algorithm of the receiver and the TCP slow start mechanism >>>> of the sender. --> >>> looks good to me >>> >>>> >>>> 11) <!-- [rfced] Section 3.1.1: >>>> >>>> a) Please clarify "upon of" in this sentence. Are some words >>>> missing, or should either "upon" or "of" be removed? >>>> >>>> Original: >>>> In order to avoid window shrinking, the receiver MUST only reduce >>>> RCV.WND by the number of bytes upon of a received data packet. >>> Like this is better?: >>> In order to avoid window shrinking, the receiver MUST only reduce >>> RCV.WND by the number of bytes contained in a received data packet. >>> Or, if you preffer the chatgpt version: >>> “To prevent window shrinking, the receiver may only decrease RCV.WND in >>> increments equal to the size of data just received in a packet.” >>> >>>> >>>> b) Does "they only allow to perform" mean "they are only allowed to >>>> perform", "they only permit performing", or something else? >>>> >>> the former, so it should write: >>> This is >>> sufficient to honor the window output from the LEDBAT/LEDBAT++ >>> algorithms since they are only allow to perform at most one >>> multiplicative decrease per RTT. >>> >>>> Original: >>>> This is >>>> sufficient to honor the window output from the LEDBAT/LEDBAT++ >>>> algorithms since they only allow to perform at most one >>>> multiplicative decrease per RTT. --> >>> >>>> >>>> 12) <!-- [rfced] Section 3.1.2: We changed "with WS of 14" to "with a WS >>>> option value of 14" here, to indicate the option value as opposed to >>>> the concept of window scale. If this is incorrect, please clarify. >>>> >>>> Original: >>>> WS option values higher than 11 can affect the dynamics of rLEDBAT, >>>> since control may become too coarse (e.g., with WS of 14, a change in >>>> one unit of the receive window implies a change of 10 MSS in the >>>> effective window). >>>> >>>> Currently: >>>> WS option values higher than 11 can affect the dynamics of rLEDBAT, >>>> since control may become too coarse (e.g., with a WS option value of >>>> 14, a change in one unit of the receive window implies a change of 10 >>>> MSS in the effective window). --> >>>> >>> ok with the change >>> >>>> 13) <!-- [rfced] Section 3.2.1: Please confirm that "error" is the >>>> correct word here. The approach discussed in this section does not >>>> seem to otherwise be considered an error - only an approach with a >>>> limitation (per the previous sentence). Please confirm that calling >>>> this approach an error will be clear to readers. >>>> >>>> Original (the previous sentence is included for context): >>>> This is a fundamental limitation of this >>>> approach. The impact of this error is that the rLEDBAT controller >>>> will also react to congestion in the reverse path direction which >>>> results in an even more conservative mechanism. >>>> >>>> Perhaps ("this limitation"): >>>> This is a fundamental limitation of this >>>> approach. The impact of this limitation is that the rLEDBAT >>>> controller will also react to congestion in the reverse path >>>> direction, resulting in an even more conservative mechanism. >>>> >>> Let's use limitation. >>> >>>> Or possibly ("this issue"): >>>> This is a fundamental limitation of this >>>> approach. The impact of this issue is that the rLEDBAT controller >>>> will also react to congestion in the reverse path direction, >>>> resulting in an even more conservative mechanism. --> >>>> >>>> >>>> 14) <!-- [rfced] Section 3.2.1: Does "as it is usually done in TCP" >>>> indicate a comparison or a contrast? If the suggested text is not >>>> correct, please clarify. >>>> >>>> Original: >>>> In a pure >>>> receiver there is no data flowing from the rLEDBAT receiver to the >>>> sender, making impossible to match data packets with acknowledgements >>>> packets to measure RTT, as it is usually done in TCP for other >>>> purposes. >>>> >>>> Suggested (guessing a contrast): >>>> In a pure >>>> receiver, there is no data flowing from the rLEDBAT receiver to the >>>> sender, making it impossible to match data packets with >>>> Acknowledgment packets to measure RTT, in contrast to what is >>>> usually done in TCP for other purposes. --> >>>> >>> Agree with the suggestion >>> >>>> 15) <!-- [rfced] Sections 3.2.1 and subsequent: Because "TSval" stands >>>> for "Timestamp Value" per RFC 7323, may we change the instances of >>>> "TSval value" to "TSval", to avoid the appearance of "Timestamp Value >>>> value"? --> >>> Agree with the proposed change >>> >>>> >>>> 16) <!-- [rfced] Sections 3.2.1.1 and 3.2.1.2: For ease of the reader, >>>> we changed "min filter" to "MIN filter" and cited RFC 6817 here >>>> (where "MIN filter" is first used). Please let us know any concerns. >>>> >>>> Original: >>>> To address this >>>> situation, the filter used by the congestion control algorithm >>>> executed in the receiver SHOULD discard outliers (e.g. a min filter >>>> would achieve this) when measuring RTT using pure ACK packets. >>>> ... >>>> Also, applying a filter that >>>> discards outliers would also address this issue (e.g. a min filter). >>>> >>>> Currently: >>>> To address this >>>> situation, the filter used by the congestion control algorithm >>>> executed in the receiver SHOULD discard outliers (e.g., a MIN filter >>>> [RFC6817] would achieve this) when measuring RTT using pure ACK >>>> packets. >>>> ... >>>> Applying a filter (e.g., a MIN >>>> filter) that discards outliers would also address this issue. --> >>>> >>> Agree with the proposed change >>> >>>> 17) <!-- [rfced] Section 3.2.2: We changed 'effectively canceling the >>>> clock offset error' to 'effectively "canceling out" the clock offset >>>> error' per Appendix A.1 of RFC 6817 (which says 'the offsets cancel >>>> each other out in the queuing delay estimate'). Please let us know >>>> any objections. >>>> >>>> Original: >>>> As noted in [RFC6817] the clock offset between the clock of >>>> the sender and the clock in the receiver does not affect the LEDBAT >>>> operation, since LEDBAT uses the difference between the base one way >>>> delay and the current one way delay to estimate the queuing delay, >>>> effectively canceling the clock offset error in the queueing delay >>>> estimation. >>>> >>>> Currently: >>>> As noted >>>> in [RFC6817], the clock offset between the sender's clock and the >>>> receiver's clock does not affect the LEDBAT operation, since LEDBAT >>>> uses the difference between the base one-way delay and the current >>>> one-way delay to estimate the queuing delay, effectively "canceling >>>> out" the clock offset error in the queuing delay estimation. --> >>>> >>> Agree with the proposed change >>> >>>> 18) <!-- [rfced] Section 3.2.2: We had trouble parsing these sentences. >>>> If the suggested text is not correct, please clarify the meaning of >>>> "the receiver is unaware if the sender is injecting traffic" and >>>> "reducing the announced receive window to a few packets and perform". >>>> >>>> Original: >>>> The problem is that the receiver is unaware if the >>>> sender is injecting traffic at any point in time, and so, it is >>>> unable to use these quiet intervals to perform measurements. The >>>> receiver can however, force periodic slowdowns, reducing the >>>> announced receive window to a few packets and perform the >>>> measurements then. >>>> >>>> Suggested: >>>> The problem is that the receiver is unaware of whether the >>>> sender is injecting traffic at any point in time; it is therefore >>>> unable to use these quiet intervals to perform measurements. The >>>> receiver can, however, force periodic slowdowns, reducing the >>>> announced receive window to a few packets and performing the >>>> measurements at that time. --> >>>> >>>> >>> ok with the proposed change >>> >>>> 19) <!-- [rfced] Section 3.3: This sentence does not parse. If the >>>> suggested text is not correct, please clarify "reducing its window to >>>> 1MSS and take over the control". >>>> >>>> Original (the previous sentence is included for context): >>>> If all packets in the tail >>>> of the window are lost, the receiver will not be able to detect a >>>> mismatch between the sequence numbers of the packets and the order of >>>> the timestamps. In this case, rLEDBAT will not react to losses but >>>> the TCP congestion controller at the sender will, most likely >>>> reducing its window to 1MSS and take over the control of the sending >>>> rate, until slow start ramps up and catches the current value of the >>>> rLEDBAT window. >>>> >>>> Suggested (the missing space in "1MSS" has been added): >>>> In this case, rLEDBAT will not react to losses; however, >>>> the TCP congestion controller at the sender will, most likely >>>> reducing its window to 1 MSS and taking over the control of the >>>> sending rate until slow start ramps up and catches the current >>>> value of the rLEDBAT window. --> >>> agree with the proposed change >>> >>>> >>>> 20) <!-- [rfced] Section 4: We (1) changed "the sender and the receiver >>>> Congestion control algorithms" to "the sender's and receiver's >>>> congestion control algorithms" per the next sentence and >>>> (2) clarified that "these two" means "these two algorithms". >>>> Please let us know if anything is incorrect. >>>> >>>> Original (the next sentence is included for context): >>>> - Interaction between the sender and the receiver Congestion >>>> control algorithms. rLEDBAT posits that because the rLEDBAT >>>> receiver is using a less-than-best-effort congestion control >>>> algorithm, the receiver congestion control algorithm will expose a >>>> smaller congestion window (conveyed though the Receive Window) >>>> than the one resulting from the congestion control algorithm >>>> executed at the sender. One of the purposes of the experiment is >>>> learn how these two interact and if the assumption that the >>>> receiver side is always controlling the sender's rate (and making >>>> rLEDBAT effective) holds. >>>> >>>> Currently ("conveyed though the" has also been corrected): >>>> * Interaction between the sender's and receiver's congestion control >>>> algorithms. rLEDBAT posits that because the rLEDBAT receiver is >>>> using a less-than-best-effort congestion control algorithm, the >>>> receiver's congestion control algorithm will expose a smaller >>>> congestion window (conveyed through the Receive Window) than the >>>> one resulting from the congestion control algorithm executed at >>>> the sender. One of the purposes of the experiment is to learn how >>>> these two algorithms interact and if the assumption that the >>>> receiver side is always controlling the sender's rate (and making >>>> rLEDBAT effective) holds. --> >>>> >>> agree with the proposed change >>> >>>> 21) <!-- [rfced] Section 4.1: >>>> >>>> a) Because the latest version of [Windows11] is dated October 2024 >>>> and "2023" is not mentioned on the page, we cannot verify "since >>>> October 2023". A Google search for "Windows 11 22H2 ledbat 2023" >>>> does not provide any information. Will "October 2023" be clear to >>>> readers, or should this item be rephrased? If you would like to >>>> rephrase, please provide clarifying text. >>>> >>>> Original: >>>> - Windows 11. rLEDBAT is available in Microsoft's Windows 11 22H2 >>>> since October 2023 [Windows11]. >>> Let's keep it the way it is. >>> >>>> b) Would you like us to cite these GitHub pages and list them in the >>>> Informative References section, as suggested below? >>>> >>>> Original: >>>> - Linux implementation, open source, available since 2022 at >>>> https://github.com/net-research/rledbat_module. >>>> >>>> - ns3 implementation, open source, available since 2020 at >>>> https://github.com/manas11/implementation-of-rLEDBAT-in-ns-3. >>>> >>>> Suggested: >>>> * Linux implementation, open source, available since 2022 >>>> [rledbat_module]. >>>> >>>> * ns3 implementation, open source, available since 2020 >>>> [rLEDBAT-in-ns3]. >>>> ... >>>> [rledbat_module] "rledbat_module", commit d82ff20, September 2022, >>>> <https://github.com/net-research/rledbat_module>. >>>> >>>> [rLEDBAT-in-ns3] "Implementation-of-rLEDBAT-in-ns-3", commit >>>> 2ab34ad, June 2020, >>>> <https://github.com/manas11/ >>>> implementation-of-rLEDBAT-in-ns-3>. --> >>>> >>> Agree with the proposed change >>> >>>> 22) <!-- [rfced] Section 4.1: Do the "#" symbols mean "number" in these >>>> items or something else? Will the text be clear "as is" to readers? >>>> If not, please clarify. >>>> >>>> Original: >>>> - Windows update # using DO >>>> >>>> - Windows Store # using DO >>>> ... >>>> - Windows Error Reporting # wermgr.exe; werfault.exe >>>> ... >>>> - Xbox (download games) # using DO --> >>> You can replace the # by a : >>> >>>> >>>> 23) <!-- [rfced] References: We found and added DOIs for [COMNET1], >>>> [COMNET2], and [COMNET3]. The DOIs lead to open-access versions of >>>> those references. Please review our updates and the new links, and >>>> let us know if anything is incorrect. >>>> >>>> Original: >>>> [COMNET1] Bagnulo, M.B. and A.G. Garcia-Martinez, "An experimental >>>> evaluation of LEDBAT++", Computer Networks Volume 212, >>>> 2022. >>>> >>>> [COMNET2] Bagnulo, M.B. and A.G. Garcia-Martinez, "When less is >>>> more: BBR versus LEDBAT++", Computer Networks Volume 219, >>>> 2022. >>>> >>>> [COMNET3] Bagnulo, M.B., Garcia-Martinez, A.G., Mandalari, A.M., >>>> Balasubramanian, P.B,., Havey, D.H., and G.M. Montenegro, >>>> "Design, implementation and validation of a receiver- >>>> driven less-than-best-effort transport", Computer >>>> Networks Volume 233, 2022. >>>> >>>> Currently: >>>> [COMNET1] Bagnulo, M. and A. García-Martínez, "An experimental >>>> evaluation of LEDBAT++", Computer Networks, vol. 212, >>>> DOI 10.1016/j.comnet.2022.109036, July 2022, >>>> <https://doi.org/10.1016/j.comnet.2022.109036>. >>>> >>>> [COMNET2] Bagnulo, M. and A. García-Martínez, "When less is more: >>>> BBR versus LEDBAT++", Computer Networks, vol. 219, >>>> DOI 10.1016/j.comnet.2022.109460, December 2022, >>>> <https://doi.org/10.1016/j.comnet.2022.109460>. >>>> >>>> [COMNET3] Bagnulo, M., García-Martínez, A., Mandalari, A.M., >>>> Balasubramanian, P., Havey, D., and G. Montenegro, >>>> "Design, implementation and validation of a receiver- >>>> driven less-than-best-effort transport", Computer >>>> Networks, vol. 233, DOI 10.1016/j.comnet.2023.109841, >>>> September 2023, >>>> <https://doi.org/10.1016/j.comnet.2023.109841>. --> >>>> >>>> >>> ok >>> >>>> 24) <!-- [rfced] Appendix B: As it appears that "TSecr field" should >>>> remain singular (i.e., not be "TSecr fields") and "TSecr field" is >>>> the subject of this sentence, we changed "are" to "is". Please let >>>> us know if "TSecr field" should be "TSecr fields" instead. >>>> >>>> Original: >>>> The TSecr field of >>>> the packets received by the rLEDBAT-enabled endpoint are matched with >>>> the sendList to compute the RTT. >>>> >>>> Currently: >>>> The TSecr field of >>>> the packets received by the rLEDBAT-enabled endpoint is matched with >>>> the sendList to compute the RTT. --> >>>> >>>> >>> Agree with the proposed change >>> >>>> 25) <!-- [rfced] Figures 2 and 3: Per the contents of the figures and >>>> the title of Appendix B, we set the sourcecode type to "pseudocode". >>>> Please let us know any concerns. >>>> >>>> Please see >>>> <https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types> >>>> for a list of sourcecode types. --> >>>> >>> ok >>>> 26) <!-- [rfced] Figure 3: Should "RWND" be "RLWND" here? We ask >>>> because we do not see "RWND" used elsewhere in this document. >>>> >>>> Original: >>>> //Compute the RWND to include in the packet >>>> RLWND = min(RLWND, fcwnd) --> >>> Yes, use RLWND >>> >>>> >>>> 27) <!-- [rfced] FYI - We have added expansions for the following >>>> abbreviations >>>> per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each >>>> expansion in the document carefully to ensure correctness. >>>> >>>> Controlled Delay (CoDel) >>>> Proportional Integral controller Enhanced (PIE) >>>> Low Latency, Low Loss, and Scalable Throughput (L4S) >>>> Maximum Segment Size (MSS) >>>> Bottleneck Bandwidth and Round-trip propagation time (BBR) >>>> --> >>>> >>> OK >>>> 28) <!-- [rfced] Please review the "Inclusive Language" portion of the >>>> online Style Guide at >>>> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>, >>>> and let us know if any changes are needed. Updates of this nature >>>> typically result in more precise language, which is helpful for >>>> readers. >>>> >>>> Note that our script did not flag any words in particular, but this >>>> should still be reviewed as a best practice. --> >>>> >>> ok, done >>> >>>> 29) <!-- [rfced] Please let us know if any changes are needed for the >>>> following: >>>> >>>> a) The following terms were used inconsistently in this document. >>>> We chose to use the latter forms. Please let us know any objections. >>>> >>>> Congestion control (1 instance) / congestion control (46 instances) >>> ok, let's use congestion control everywhere >>> >>>> RCV-WND (Figure 1) / RCV WND (Section 5) / >>>> RCV.WND (per the rest of this document and per published RFCs >>>> to date) >>> Ok, let's use RCV.WND everywhere >>>> TSVal / TSval (per published RFCs, including RFC 7323; we could not >>>> find "TSVal" in any published RFC) >>> Ok, let's use TSval everywhere >>>> b) The following terms appear to be used inconsistently in this >>>> document. Please let us know which form is preferred. >>>> >>>> a rLEDBAT / an rLEDBAT >>> mmm, whathever you think it is best (i dont have an opinion) >>> >>>> Receive window / Receive Window / receive window >>>> (We see that "congestion window" is used consistently.) >>>> >>> Let's use receive window >>> >>>> sendList / sentList --> >>>> >>> Let's use sendList >>> >>> Regards, marcelo >>> >>>> Thank you. >>>> >>>> Lynne Bartholomew and Rebecca VanRheenen >>>> RFC Production Center >>>> >>>> >>>> >>>> On Aug 18, 2025, at 1:09 PM, rfc-edi...@rfc-editor.org wrote: >>>> >>>> *****IMPORTANT***** >>>> >>>> Updated 2025/08/18 >>>> >>>> RFC Author(s): >>>> -------------- >>>> >>>> Instructions for Completing AUTH48 >>>> >>>> Your document has now entered AUTH48. Once it has been reviewed and >>>> approved by you and all coauthors, it will be published as an RFC. >>>> If an author is no longer available, there are several remedies >>>> available as listed in the FAQ (https://www.rfc-editor.org/faq/). >>>> >>>> You and you coauthors are responsible for engaging other parties >>>> (e.g., Contributors or Working Group) as necessary before providing >>>> your approval. >>>> >>>> Planning your review >>>> --------------------- >>>> >>>> Please review the following aspects of your document: >>>> >>>> * RFC Editor questions >>>> >>>> Please review and resolve any questions raised by the RFC Editor >>>> that have been included in the XML file as comments marked as >>>> follows: >>>> >>>> <!-- [rfced] ... --> >>>> >>>> These questions will also be sent in a subsequent email. >>>> >>>> * Changes submitted by coauthors >>>> >>>> Please ensure that you review any changes submitted by your >>>> coauthors. We assume that if you do not speak up that you >>>> agree to changes submitted by your coauthors. >>>> >>>> * Content >>>> >>>> Please review the full content of the document, as this cannot >>>> change once the RFC is published. Please pay particular attention to: >>>> - IANA considerations updates (if applicable) >>>> - contact information >>>> - references >>>> >>>> * Copyright notices and legends >>>> >>>> Please review the copyright notice and legends as defined in >>>> RFC 5378 and the Trust Legal Provisions >>>> (TLP – https://trustee.ietf.org/license-info). >>>> >>>> * Semantic markup >>>> >>>> Please review the markup in the XML file to ensure that elements of >>>> content are correctly tagged. For example, ensure that <sourcecode> >>>> and <artwork> are set correctly. See details at >>>> <https://authors.ietf.org/rfcxml-vocabulary>. >>>> >>>> * Formatted output >>>> >>>> Please review the PDF, HTML, and TXT files to ensure that the >>>> formatted output, as generated from the markup in the XML file, is >>>> reasonable. Please note that the TXT will have formatting >>>> limitations compared to the PDF and HTML. >>>> >>>> >>>> Submitting changes >>>> ------------------ >>>> >>>> To submit changes, please reply to this email using ‘REPLY ALL’ as all >>>> the parties CCed on this message need to see your changes. The parties >>>> include: >>>> >>>> * your coauthors >>>> >>>> * rfc-edi...@rfc-editor.org (the RPC team) >>>> >>>> * other document participants, depending on the stream (e.g., >>>> IETF Stream participants are your working group chairs, the >>>> responsible ADs, and the document shepherd). >>>> >>>> * auth48archive@rfc-editor.org, which is a new archival mailing list >>>> to preserve AUTH48 conversations; it is not an active discussion >>>> list: >>>> >>>> * More info: >>>> https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc >>>> >>>> * The archive itself: >>>> https://mailarchive.ietf.org/arch/browse/auth48archive/ >>>> >>>> * Note: If only absolutely necessary, you may temporarily opt out >>>> of the archiving of messages (e.g., to discuss a sensitive matter). >>>> If needed, please add a note at the top of the message that you >>>> have dropped the address. When the discussion is concluded, >>>> auth48archive@rfc-editor.org will be re-added to the CC list and >>>> its addition will be noted at the top of the message. >>>> >>>> You may submit your changes in one of two ways: >>>> >>>> An update to the provided XML file >>>> — OR — >>>> An explicit list of changes in this format >>>> >>>> Section # (or indicate Global) >>>> >>>> OLD: >>>> old text >>>> >>>> NEW: >>>> new text >>>> >>>> You do not need to reply with both an updated XML file and an explicit >>>> list of changes, as either form is sufficient. >>>> >>>> We will ask a stream manager to review and approve any changes that seem >>>> beyond editorial in nature, e.g., addition of new text, deletion of text, >>>> and technical changes. Information about stream managers can be found in >>>> the FAQ. Editorial changes do not require approval from a stream manager. >>>> >>>> >>>> Approving for publication >>>> -------------------------- >>>> >>>> To approve your RFC for publication, please reply to this email stating >>>> that you approve this RFC for publication. Please use ‘REPLY ALL’, >>>> as all the parties CCed on this message need to see your approval. >>>> >>>> >>>> Files >>>> ----- >>>> >>>> The files are available here: >>>> https://www.rfc-editor.org/authors/rfc9840.xml >>>> https://www.rfc-editor.org/authors/rfc9840.html >>>> https://www.rfc-editor.org/authors/rfc9840.pdf >>>> https://www.rfc-editor.org/authors/rfc9840.txt >>>> >>>> Diff file of the text: >>>> https://www.rfc-editor.org/authors/rfc9840-diff.html >>>> https://www.rfc-editor.org/authors/rfc9840-rfcdiff.html (side by side) >>>> >>>> Alt-diff of the text (allows you to more easily view changes >>>> where text has been deleted or moved): >>>> https://www.rfc-editor.org/authors/rfc9840-alt-diff.html >>>> >>>> Diff of the XML: >>>> https://www.rfc-editor.org/authors/rfc9840-xmldiff1.html >>>> >>>> >>>> Tracking progress >>>> ----------------- >>>> >>>> The details of the AUTH48 status of your document are here: >>>> https://www.rfc-editor.org/auth48/rfc9840 >>>> >>>> Please let us know if you have any questions. >>>> >>>> Thank you for your cooperation, >>>> >>>> RFC Editor >>>> >>>> -------------------------------------- >>>> RFC9840 (draft-irtf-iccrg-rledbat-10) >>>> >>>> Title : rLEDBAT: receiver-driven Low Extra Delay Background Transport for >>>> TCP >>>> Author(s) : M. Bagnulo, A. Garcia-Martinez, G. Montenegro, P. >>>> Balasubramanian >>>> WG Chair(s) : >>>> Area Director(s) : >>>> >>>> > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
