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