Hi, Gabriel. Many thanks for letting us know about the timeline and for your kind words! We will wait to hear from Marcelo.
Lynne Bartholomew RFC Production Center > On Aug 27, 2025, at 8:43 AM, Gabriel Montenegro <[email protected]> > wrote: > > Hi Lynne, > > Our main editor is Marcelo and he's currently on vacation. He'll return > shortly but then will be very busy for a few more days. He did indicate to me > that he'd respond to you and clarify that once he gets some time he'll work > on the response from our part. > > Thanks a lot for all your efforts improving our draft and preparing it for > RFC-hood! > > Gabriel > >> -----Original Message----- >> From: Lynne Bartholomew <[email protected]> >> Sent: Monday, August 25, 2025 12:46 >> To: [email protected]; [email protected]; >> [email protected]; [email protected] >> Cc: IRSG <[email protected]>; [email protected]; [email protected]; >> auth48archive <[email protected]> >> Subject: Re: AUTH48: RFC-to-be 9840 <draft-irtf-iccrg-rledbat-10> for your >> review >> >> Dear authors, >> >> We do not believe that we have heard from you regarding the questions >> below. Please review the questions, and let us know how this document >> should be updated. >> >> The latest files are posted here: >> >> >> https://www.rfc/ >> - >> editor.org%2Fauthors%2Frfc9840.xml&data=05%7C02%7C%7Cc91c22ce9f184 >> 53a9c5a08dde3f6db3a%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0% >> 7C638917371576472252%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGki >> OnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoy >> fQ%3D%3D%7C0%7C%7C%7C&sdata=jKKHyQ%2FXOF%2B6lylvrUrpkxok%2BK >> dllG8HmbuwK0eWDvk%3D&reserved=0 >> >> https://www.rfc/ >> - >> editor.org%2Fauthors%2Frfc9840.html&data=05%7C02%7C%7Cc91c22ce9f184 >> 53a9c5a08dde3f6db3a%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0% >> 7C638917371576499541%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGki >> OnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoy >> fQ%3D%3D%7C0%7C%7C%7C&sdata=7DB0g5bc89potkfM4PnaKwGH%2FPWk >> lkMDmdEgc6r79cg%3D&reserved=0 >> >> https://www.rfc/ >> - >> editor.org%2Fauthors%2Frfc9840.pdf&data=05%7C02%7C%7Cc91c22ce9f184 >> 53a9c5a08dde3f6db3a%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0% >> 7C638917371576514515%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGki >> OnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoy >> fQ%3D%3D%7C0%7C%7C%7C&sdata=n8goYVkxiGw7SJdybjRK9SqoF9yLxkSDx >> YMdyV0iETA%3D&reserved=0 >> >> https://www.rfc/ >> - >> editor.org%2Fauthors%2Frfc9840.txt&data=05%7C02%7C%7Cc91c22ce9f1845 >> 3a9c5a08dde3f6db3a%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7 >> C638917371576527122%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiO >> nRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyf >> Q%3D%3D%7C0%7C%7C%7C&sdata=Hh09Zu87ccIVPHJSgCgifnpPP8uoqnvFm >> BkejLXdy%2BI%3D&reserved=0 >> >> Diff file of the text: >> >> https://www.rfc/ >> -editor.org%2Fauthors%2Frfc9840- >> diff.html&data=05%7C02%7C%7Cc91c22ce9f18453a9c5a08dde3f6db3a%7C84 >> df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638917371576539712%7CU >> nknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAw >> MCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C >> &sdata=GeDx6IHDKiR958CR5Dbw0050RXrFkCWzEpjAkMndpy8%3D&reserved >> =0 >> >> https://www.rfc/ >> -editor.org%2Fauthors%2Frfc9840- >> rfcdiff.html&data=05%7C02%7C%7Cc91c22ce9f18453a9c5a08dde3f6db3a%7C >> 84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638917371576552218%7 >> CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMD >> AwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C >> %7C&sdata=%2FyGiDMt3B9OQ5%2F%2FNsmuJz674vTT%2FN89rAqo8m89rzk >> w%3D&reserved=0 (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%2Fauthors%2Frfc9840-alt- >> diff.html&data=05%7C02%7C%7Cc91c22ce9f18453a9c5a08dde3f6db3a%7C84 >> df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638917371576564701%7CU >> nknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAw >> MCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C >> &sdata=pqEa1ecfHpn2%2B6K2%2FyJ%2BfunylWzgDvy9Jv82KLM5xK8%3D&res >> erved=0 >> >> Diff of the XML: >> >> https://www.rfc/ >> -editor.org%2Fauthors%2Frfc9840- >> xmldiff1.html&data=05%7C02%7C%7Cc91c22ce9f18453a9c5a08dde3f6db3a% >> 7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638917371576577299 >> %7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAu >> MDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C% >> 7C%7C&sdata=1mh54wpK9OdTpMDZVoBfctAk9CWNkvOLY%2BqHywY3iB4%3 >> D&reserved=0 >> >> Thank you! >> >> Lynne Bartholomew >> RFC Production Center >> >> >>> On Aug 18, 2025, at 1:15 PM, [email protected] wrote: >>> >>> 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 --> >>> >>> >>> 2) <!-- [rfced] Please insert any keywords (beyond those that appear >>> in the >>> title) for use on >>> >> <https://www/. >>> rfc- >> editor.org%2Fsearch&data=05%7C02%7C%7Cc91c22ce9f18453a9c5a08dde3f6 >>> >> db3a%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C6389173715767 >> 78056%7 >>> >> CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMD >> AwMCIsIlA >>> >> iOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata >> =3te6j >>> >> pz%2BAUoggN0HM1JWMGaKAWk1ybO0rD5aHVHhT%2BI%3D&reserved=0>. >> --> >>> >>> >>> 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%2Frfc%2Frfc5743.html%23section- >> 2.1&data=05%7C02%7C%7Cc9 >>> >> 1c22ce9f18453a9c5a08dde3f6db3a%7C84df9e7fe9f640afb435aaaaaaaaaaaa >> %7C1% >>> >> 7C0%7C638917371576792998%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1 >> hcGkiOnRyd >>> >> WUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3 >> D%3 >>> >> D%7C0%7C%7C%7C&sdata=GjY8WVdbDn%2BbE3XuGfAU1R6LiwcdWi1oqFaT >> V0qIFFE%3D& >>> reserved=0>. --> >>> >>> >>> 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. >>> >>> 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). >>> >>> 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). >>> --> >>> >>> >>> 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. >>> --> >>> >>> >>> 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. >>> >>> 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%2Finfo%2Frfc6582&data=05%7C02%7C%7Cc91c22ce9f18453a9c5a >>> >> 08dde3f6db3a%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C63891 >> 7371576 >>> >> 810057%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiI >> wLjAuMDA >>> >> wMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C% >> 7C&sda >>> >> ta=1w8cEIc8r3ZN%2F8UivnFx8qGxSiAhROdL295MtFQqErk%3D&reserved=0>. >> --> >>> >>> >>> 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. >>> >>> 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. >>> ... >>> 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. >>> ... >>> - 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. --> >>> >>> >>> 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. >>> >>> 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. --> >>> >>> >>> 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. >>> >>> >>> b) Does "they only allow to perform" mean "they are only allowed to >>> perform", "they only permit performing", or something else? >>> >>> 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). --> >>> >>> >>> 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. >>> >>> 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. --> >>> >>> >>> 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"? --> >>> >>> >>> 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. --> >>> >>> >>> 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. --> >>> >>> >>> 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. >>> --> >>> >>> >>> 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. --> >>> >>> >>> 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. --> >>> >>> >>> 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]. >>> >>> 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.c/ >> om%2Fnet- >> research%2Frledbat_module&data=05%7C02%7C%7Cc91c22ce9f18453a9c5a >> 08dde3f6db3a%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C63891 >> 7371576826019%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydW >> UsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D% >> 3D%7C0%7C%7C%7C&sdata=1eN8O%2BmvTBvf79%2BuiaCWcb4%2BJEk4cvu >> XgfMYDds%2FK9k%3D&reserved=0. >>> >>> - ns3 implementation, open source, available since 2020 at >>> >> https://github.c/ >> om%2Fmanas11%2Fimplementation-of-rLEDBAT-in-ns- >> 3&data=05%7C02%7C%7Cc91c22ce9f18453a9c5a08dde3f6db3a%7C84df9e7f >> e9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638917371576840026%7CUnkno >> wn%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsI >> lAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdat >> a=fHde8vtCMWawuzxUU%2FqkHyQcERsBvuz4wQliHPsCiCM%3D&reserved=0 >> . >>> >>> 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%2Fnet- >> research%2Frledbat_module&data=05%7C02%7C%7Cc91c22ce9f18453a9c5a >> 08dde3f6db3a%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C63891 >> 7371576852848%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydW >> UsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D% >> 3D%7C0%7C%7C%7C&sdata=yuXVYLZdZFfIFM2qBNDHZk3%2FmCZGf1U7zSv7 >> qZd%2BclQ%3D&reserved=0>. >>> >>> [rLEDBAT-in-ns3] "Implementation-of-rLEDBAT-in-ns-3", commit >>> 2ab34ad, June 2020, >>> >> <https://github/. >> com%2Fmanas11%2F&data=05%7C02%7C%7Cc91c22ce9f18453a9c5a08dde3 >> f6db3a%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C63891737157 >> 6865834%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiO >> iIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C >> 0%7C%7C%7C&sdata=Vnzp%2F%2Flv91Bd3lVrzu9Rl4m6Ilb2JwowC0U05ruED >> 4U%3D&reserved=0 >>> implementation-of-rLEDBAT-in-ns-3>. --> >>> >>> >>> 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 --> >>> >>> >>> 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/ >> %2F10.1016%2Fj.comnet.2022.109036&data=05%7C02%7C%7Cc91c22ce9f18 >> 453a9c5a08dde3f6db3a%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0 >> %7C638917371576878459%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcG >> kiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIj >> oyfQ%3D%3D%7C0%7C%7C%7C&sdata=IISBhqHGHUVCsjXOi%2BrOGegCQ6k >> MB2fGActODKR1rtM%3D&reserved=0>. >>> >>> [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/ >> %2F10.1016%2Fj.comnet.2022.109460&data=05%7C02%7C%7Cc91c22ce9f18 >> 453a9c5a08dde3f6db3a%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0 >> %7C638917371576891218%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcG >> kiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIj >> oyfQ%3D%3D%7C0%7C%7C%7C&sdata=ZBVkh8DbGFQMbT%2FDbJo67V%2Fv >> ewmAMdgzRm9GpuxKgLQ%3D&reserved=0>. >>> >>> [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%2F10.1016%2Fj.comnet.2023.109841&data=05%7C02%7C%7Cc91c22ce9f >> 18453 >>> >> a9c5a08dde3f6db3a%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C >> 6389173 >>> >> 71576903871%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUs >> IlYiOiIwLj >>> >> AuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7 >> C%7C%7 >>> >> C&sdata=udFKH6UgRTXcAfitgKNhQuMbbQWuf0W83tmCiJrrBfs%3D&reserve >> d=0>. >>> --> >>> >>> >>> 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. --> >>> >>> >>> 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%2Frpc%2Fwiki%2Fdoku.php%3Fid%3Dsourcecode- >> types&data=05 >>> %7C02%7C%7Cc91c22ce9f18453a9c5a08dde3f6db3a%7C84df9e7fe9f640afb >> 435aaaa >>> >> aaaaaaaa%7C1%7C0%7C638917371576916922%7CUnknown%7CTWFpbGZsb >> 3d8eyJFbXB0 >>> >> eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpb >> CIsIl >>> >> dUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=DIvMcy6vLAU0Rq3cxzptj2GZvTelx >> ctKG5%2 >>> F2tx%2FAC4Q%3D&reserved=0> >>> for a list of sourcecode types. --> >>> >>> >>> 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) >>> --> >>> >>> >>> 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) >>> --> >>> >>> >>> 28) <!-- [rfced] Please review the "Inclusive Language" portion of the >>> online Style Guide at >>> >> <https://www/. >>> rfc- >> editor.org%2Fstyleguide%2Fpart2%2F%23inclusive_language&data=05%7C >>> >> 02%7C%7Cc91c22ce9f18453a9c5a08dde3f6db3a%7C84df9e7fe9f640afb435aa >> aaaaa >>> >> aaaaa%7C1%7C0%7C638917371576930107%7CUnknown%7CTWFpbGZsb3d8 >> eyJFbXB0eU1 >>> >> hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIl >> dUI >>> >> joyfQ%3D%3D%7C0%7C%7C%7C&sdata=Gn%2BZ7Mmb04EzY4D65XraSPEpsL >> kLB36aT9hIC >>> Q32kIs%3D&reserved=0>, 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. --> >>> >>> >>> 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) >>> >>> RCV-WND (Figure 1) / RCV WND (Section 5) / >>> RCV.WND (per the rest of this document and per published RFCs >>> to date) >>> >>> TSVal / TSval (per published RFCs, including RFC 7323; we could not >>> find "TSVal" in any published RFC) >>> >>> b) The following terms appear to be used inconsistently in this >>> document. Please let us know which form is preferred. >>> >>> a rLEDBAT / an rLEDBAT >>> >>> Receive window / Receive Window / receive window (We see that >>> "congestion window" is used consistently.) >>> >>> sendList / sentList --> >>> >>> >>> Thank you. >>> >>> Lynne Bartholomew and Rebecca VanRheenen RFC Production Center >>> >>> >>> >>> On Aug 18, 2025, at 1:09 PM, [email protected] 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.rf/ >> c- >> editor.org%2Ffaq%2F&data=05%7C02%7C%7Cc91c22ce9f18453a9c5a08dde3f >> 6db3a%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638917371576 >> 942666%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiI >> wLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0 >> %7C%7C%7C&sdata=DQVdHDr6qA62eIVa33FZGCsCxIwTQdVBtf15l46TkLc%3D >> &reserved=0). >>> >>> 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.i/ >> etf.org%2Flicense- >> info&data=05%7C02%7C%7Cc91c22ce9f18453a9c5a08dde3f6db3a%7C84df9e >> 7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638917371576958426%7CUnkn >> own%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCI >> sIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sd >> ata=v0r1bRpXElTxuNsYmVnVysk%2Fx1Qbsz9EKnb3klrUwf8%3D&reserved=0). >>> >>> * 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://author/ >> s.ietf.org%2Frfcxml- >> vocabulary&data=05%7C02%7C%7Cc91c22ce9f18453a9c5a08dde3f6db3a%7 >> C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638917371576972535% >> 7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuM >> DAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7 >> C%7C&sdata=zFjIYpFjudnkcscZyYljC5DXG2wbk483V%2FRo0aR90lY%3D&reserv >> ed=0>. >>> >>> * 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 >>> >>> * [email protected] (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). >>> >>> * [email protected], which is a new archival mailing list >>> to preserve AUTH48 conversations; it is not an active discussion >>> list: >>> >>> * More info: >>> >>> https://maila/ >>> rchive.ietf.org%2Farch%2Fmsg%2Fietf-announce%2Fyb6lpIGh- >> 4Q9l2USxIAe6P8 >>> >> O4Zc&data=05%7C02%7C%7Cc91c22ce9f18453a9c5a08dde3f6db3a%7C84df9 >> e7fe9f6 >>> >> 40afb435aaaaaaaaaaaa%7C1%7C0%7C638917371576987172%7CUnknown% >> 7CTWFpbGZs >>> >> b3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsI >> kFOIj >>> >> oiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=TtDbvZ8UMLvk4N9s >> MvHujlyf >>> Nsvirolb%2FkBBZzrJdRw%3D&reserved=0 >>> >>> * The archive itself: >>> >>> https://maila/ >>> >> rchive.ietf.org%2Farch%2Fbrowse%2Fauth48archive%2F&data=05%7C02%7C >> %7Cc >>> >> 91c22ce9f18453a9c5a08dde3f6db3a%7C84df9e7fe9f640afb435aaaaaaaaaaaa >> %7C1 >>> %7C0%7C638917371576999791%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0 >> eU1hcGkiOnRy >>> >> dWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3 >> D% >>> >> 3D%7C0%7C%7C%7C&sdata=o8rpYeXHY3s1esEkFPWzmIQw5ia8VbxR%2Fz6bz >> WH3f%2F4% >>> 3D&reserved=0 >>> >>> * 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, >>> [email protected] 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.r/ >>> fc- >> editor.org%2Fauthors%2Frfc9840.xml&data=05%7C02%7C%7Cc91c22ce9f184 >> 5 >>> >> 3a9c5a08dde3f6db3a%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7 >> C638917 >>> >> 371577014394%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydW >> UsIlYiOiIwL >>> >> jAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7 >> C%7C% >>> >> 7C&sdata=AVW3ff0nEgGVxj97k5zZ42P6gr5QfL3HDIUE%2BWo6cMw%3D&res >> erved=0 >>> >>> https://www.r/ >>> fc- >> editor.org%2Fauthors%2Frfc9840.html&data=05%7C02%7C%7Cc91c22ce9f184 >>> >> 53a9c5a08dde3f6db3a%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0% >> 7C63891 >>> >> 7371577027531%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydW >> UsIlYiOiIw >>> >> LjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0% >> 7C%7C >>> %7C&sdata=zx6E7y0xvfMJ01vbUAtgQjrziTtHC%2Fwskpl1nPs6xdc%3D&reser >> ved=0 >>> >>> https://www.r/ >>> fc- >> editor.org%2Fauthors%2Frfc9840.pdf&data=05%7C02%7C%7Cc91c22ce9f184 >> 5 >>> >> 3a9c5a08dde3f6db3a%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7 >> C638917 >>> >> 371577040402%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydW >> UsIlYiOiIwL >>> >> jAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7 >> C%7C% >>> >> 7C&sdata=in19%2Fcm8WXDJLecKFNSoDxH1JhIHpUh6pm20QGw5AK4%3D&re >> served=0 >>> >>> https://www.r/ >>> fc- >> editor.org%2Fauthors%2Frfc9840.txt&data=05%7C02%7C%7Cc91c22ce9f1845 >>> >> 3a9c5a08dde3f6db3a%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7 >> C638917 >>> >> 371577053183%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydW >> UsIlYiOiIwL >>> >> jAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7 >> C%7C% >>> >> 7C&sdata=junWbcJcdYgpEeYwM4UGurqfoxhS8knmBk%2F0PcYBP%2Bs%3D&r >> eserved=0 >>> >>> Diff file of the text: >>> >>> https://www.r/ >>> fc-editor.org%2Fauthors%2Frfc9840- >> diff.html&data=05%7C02%7C%7Cc91c22ce >>> >> 9f18453a9c5a08dde3f6db3a%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1% >> 7C0%7C >>> >> 638917371577065957%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOn >> RydWUsIlY >>> >> iOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D% >> 7C0% >>> >> 7C%7C%7C&sdata=eLWtP181fddr23NhKN97JJlmYat%2F9XQjs%2BcnWGOlZOs >> %3D&rese >>> rved=0 >>> >>> https://www.r/ >>> fc-editor.org%2Fauthors%2Frfc9840- >> rfcdiff.html&data=05%7C02%7C%7Cc91c2 >>> >> 2ce9f18453a9c5a08dde3f6db3a%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C >> 1%7C0 >>> %7C638917371577078673%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hc >> GkiOnRydWUs >>> >> IlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D >> %7 >>> >> C0%7C%7C%7C&sdata=A7dfg4bB%2FvJIVVUX9sMUHns24TaR%2FI4XifkFXLnH >> W1g%3D&r >>> eserved=0 (side by side) >>> >>> Alt-diff of the text (allows you to more easily view changes where >>> text has been deleted or moved): >>> >>> https://www.r/ >>> fc-editor.org%2Fauthors%2Frfc9840-alt- >> diff.html&data=05%7C02%7C%7Cc91c >>> >> 22ce9f18453a9c5a08dde3f6db3a%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7 >> C1%7C >>> >> 0%7C638917371577091639%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hc >> GkiOnRydWU >>> >> sIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3 >> D% >>> >> 7C0%7C%7C%7C&sdata=bwLwTQuAhZmOCEqM2OXRf1rbAwgvoDM2AOVDIy1 >> btIg%3D&rese >>> rved=0 >>> >>> Diff of the XML: >>> >>> https://www.r/ >>> fc-editor.org%2Fauthors%2Frfc9840- >> xmldiff1.html&data=05%7C02%7C%7Cc91c >>> >> 22ce9f18453a9c5a08dde3f6db3a%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7 >> C1%7C >>> >> 0%7C638917371577104230%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hc >> GkiOnRydWU >>> >> sIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3 >> D% >>> >> 7C0%7C%7C%7C&sdata=1%2FokDPLockKjCMPeaAk5FrQkC9tHRGNJYKbQpc% >> 2BO%2Fko%3 >>> D&reserved=0 >>> >>> >>> Tracking progress >>> ----------------- >>> >>> The details of the AUTH48 status of your document are here: >>> >>> https://www.r/ >>> fc- >> editor.org%2Fauth48%2Frfc9840&data=05%7C02%7C%7Cc91c22ce9f18453a9c >> 5 >>> >> a08dde3f6db3a%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C6389 >> 1737157 >>> >> 7121173%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiO >> iIwLjAuMD >>> >> AwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C >> %7C&sd >>> >> ata=wFuAJYvNRn1JjEbiShLofwAqSR4TCWx2sC1AgFR%2FtDk%3D&reserved=0 >>> >>> 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 -- [email protected] To unsubscribe send an email to [email protected]
