Hi, Praveen. We have noted your approval on the AUTH48 status page:
https://www.rfc-editor.org/auth48/rfc9840 As we now have all approvals, we will prepare this document for publication shortly. Thank you! Lynne Bartholomew RFC Production Center > On Sep 13, 2025, at 9:47 AM, Praveen Balasubramanian <[email protected]> > wrote: > > Hi Lynne, > > Looks good to me. I approve this RFC for publication. > > Thanks Lynne and Marcelo! > > > On Thu, Sep 11, 2025 at 9:30 AM Lynne Bartholomew > <[email protected]> wrote: > Hi, Alberto. So noted: > > https://www.rfc-editor.org/auth48/rfc9840 > > After we receive approval for publication from Praveen, we will move this > document forward for publication. > > Thank you! > > Lynne Bartholomew > RFC Production Center > > > On Sep 11, 2025, at 9:19 AM, ALBERTO GARCIA MARTINEZ > > <[email protected]> wrote: > > > > Hi, > > Same for me, I also approve this RFC for publication. > > > > Thanks Lynne and Marcelo for all the work! > > Alberto > > > > > >> On Sep 11, 2025, at 9:16 AM, Lynne Bartholomew > >> <[email protected]> wrote: > >> > >> Hi, Marcelo and Gabriel. > >> > >> Gabriel, we have noted your approval on the AUTH48 status page: > >> > >> https://www.rfc-editor.org/auth48/rfc9840 > >> > >> Marcelo, as it appears that you also approve this document for publication > >> in its current form, we have noted your approval as well. Please let us > >> know if we misunderstood your note, and we will change your approval > >> status back to "No". > >> > >> Thank you! > >> > >> Lynne Bartholomew > >> RFC Production Center > >> > >> El jue, 11 sept 2025 a las 13:41, Gabriel Montenegro > >> (<[email protected]>) escribió: > >> Hi Lynne, > >> > >> Looks good to me too! I believe we're supposed to send the formal approval > >> on our part, so here goes: > >> > >> I approve this RFC for publication. > >> > >> Thanks Lynne and Marcelo, > >> > >> Gabriel > >> > >> > -----Original Message----- > >> > From: marcelo bagnulo braun <[email protected]> > >> > Sent: Thursday, September 11, 2025 02:45 > >> > To: Lynne Bartholomew <[email protected]> > >> > Cc: [email protected]; [email protected]; > >> > [email protected]; [email protected]; [email protected]; > >> > [email protected]; [email protected] > >> > Subject: Re: AUTH48: RFC-to-be 9840 <draft-irtf-iccrg-rledbat-10> for > >> > your > >> > review > >> > > >> > Looks good to me, thanks! > >> > > >> > > >> > El 9/9/25 a las 21:49, Lynne Bartholomew escribió: > >> > > 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%2Fauthors%2Frfc9840.txt&data=05%7C02%7C%7C60df6ff86cf14cb > >> > ef20408ddf0feb5ad%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C6 > >> > 38931698950795522%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOn > >> > RydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ > >> > %3D%3D%7C0%7C%7C%7C&sdata=FTVZc0kICLPnaN9rIJG5nhr9BS7Ux3BOLHG > >> > bIle0A0o%3D&reserved=0 > >> > > > >> > https://www.rfc/ > >> > - > >> > editor.org%2Fauthors%2Frfc9840.pdf&data=05%7C02%7C%7C60df6ff86cf14c > >> > bef20408ddf0feb5ad%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C > >> > 638931698950813902%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOn > >> > RydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ > >> > %3D%3D%7C0%7C%7C%7C&sdata=7Il0CpeyTT%2F9ekpjiQnLvTSLpWIv%2FoZ > >> > 33qPcRmliqlw%3D&reserved=0 > >> > > > >> > https://www.rfc/ > >> > - > >> > editor.org%2Fauthors%2Frfc9840.html&data=05%7C02%7C%7C60df6ff86cf14 > >> > cbef20408ddf0feb5ad%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7 > >> > C638931698950826863%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiO > >> > nRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyf > >> > Q%3D%3D%7C0%7C%7C%7C&sdata=zdrffVstGf9yuRCPB5dN8GYo9DD2uG%2 > >> > B7v%2B65IQOsOrQ%3D&reserved=0 > >> > > > >> > https://www.rfc/ > >> > - > >> > editor.org%2Fauthors%2Frfc9840.xml&data=05%7C02%7C%7C60df6ff86cf14c > >> > bef20408ddf0feb5ad%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C > >> > 638931698950840045%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOn > >> > RydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ > >> > %3D%3D%7C0%7C%7C%7C&sdata=Am5TT%2BcojLI%2FVcjQ%2F6rDQyVcivZU > >> > Xaq%2FS719%2FrZI2uU%3D&reserved=0 > >> > > > >> > https://www.rfc/ > >> > -editor.org%2Fauthors%2Frfc9840- > >> > diff.html&data=05%7C02%7C%7C60df6ff86cf14cbef20408ddf0feb5ad%7C84d > >> > f9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638931698950854840%7CUn > >> > known%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAw > >> > MCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C > >> > &sdata=b76%2FSyyjtAAFm5n0nTwvjId0pYnI9mj3F6FVgaTXBZM%3D&reserved > >> > =0 > >> > > > >> > https://www.rfc/ > >> > -editor.org%2Fauthors%2Frfc9840- > >> > rfcdiff.html&data=05%7C02%7C%7C60df6ff86cf14cbef20408ddf0feb5ad%7C8 > >> > 4df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638931698950869874%7C > >> > Unknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDA > >> > wMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C% > >> > 7C&sdata=jzke9DB8g8Ci9Ni8QnhxCOmhQKLDSrmkI2WgLPvfvJ8%3D&reserved > >> > =0 (side by side) > >> > > > >> > https://www.rfc/ > >> > -editor.org%2Fauthors%2Frfc9840- > >> > auth48diff.html&data=05%7C02%7C%7C60df6ff86cf14cbef20408ddf0feb5ad > >> > %7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C63893169895088622 > >> > 7%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAu > >> > MDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C% > >> > 7C%7C&sdata=hum5sSB%2FIeoRHE5KeDJ2boRzH08QL1Etd7nOMJxz3ek%3D& > >> > reserved=0 > >> > > > >> > https://www.rfc/ > >> > -editor.org%2Fauthors%2Frfc9840- > >> > auth48rfcdiff.html&data=05%7C02%7C%7C60df6ff86cf14cbef20408ddf0feb5a > >> > d%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C6389316989508997 > >> > 55%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjA > >> > uMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C > >> > %7C%7C&sdata=55sH9WgjPwtBrOGDSaLgLtklo9AQA9L8mt0UP1%2FHiMc%3D > >> > &reserved=0 (side by side) > >> > > > >> > https://www.rfc/ > >> > -editor.org%2Fauthors%2Frfc9840- > >> > lastdiff.html&data=05%7C02%7C%7C60df6ff86cf14cbef20408ddf0feb5ad%7C > >> > 84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638931698950917044%7 > >> > CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMD > >> > AwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C > >> > %7C&sdata=eBktsc2cgmyGirAUTwoeYx72ER2m1IQ8RNMNFJU7qdk%3D&reser > >> > ved=0 > >> > > > >> > https://www.rfc/ > >> > -editor.org%2Fauthors%2Frfc9840- > >> > lastrfcdiff.html&data=05%7C02%7C%7C60df6ff86cf14cbef20408ddf0feb5ad% > >> > 7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638931698950934425 > >> > %7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAu > >> > MDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C% > >> > 7C%7C&sdata=o7nYrvNTimgTY1ELqau9qjQXReO7hdCQTBn7zlu8SfE%3D&rese > >> > rved=0 (side by side) > >> > > > >> > > > >> > https://www.rfc/ > >> > -editor.org%2Fauthors%2Frfc9840- > >> > xmldiff1.html&data=05%7C02%7C%7C60df6ff86cf14cbef20408ddf0feb5ad%7 > >> > C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638931698950953072% > >> > 7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuM > >> > DAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7 > >> > C%7C&sdata=isWVnqpc7lpZ0iDlCzdyLBFns3wiLYzKVTDlbe%2FBPU4%3D&reser > >> > ved=0 > >> > > > >> > https://www.rfc/ > >> > -editor.org%2Fauthors%2Frfc9840- > >> > xmldiff2.html&data=05%7C02%7C%7C60df6ff86cf14cbef20408ddf0feb5ad%7 > >> > C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638931698950973012% > >> > 7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuM > >> > DAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7 > >> > C%7C&sdata=RvEso6lliVNMGR2lMn2Qnq6S44We6mwL%2Fpg90aRDnh0%3D > >> > &reserved=0 > >> > > > >> > https://www.rfc/ > >> > -editor.org%2Fauthors%2Frfc9840-alt- > >> > diff.html&data=05%7C02%7C%7C60df6ff86cf14cbef20408ddf0feb5ad%7C84d > >> > f9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638931698950992812%7CUn > >> > known%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAw > >> > MCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C > >> > &sdata=stMLuBwew8y12CMyTtM6wFPcoIucxlA0iIKf8Rjxac8%3D&reserved=0 > >> > > > >> > > Thank you! > >> > > > >> > > Lynne Bartholomew > >> > > RFC Production Center > >> > > > >> > >> On Sep 9, 2025, at 1:08 AM, marcelo bagnulo braun <[email protected]> > >> > 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%2Fauthors%2Frfc9840.txt&data=05%7C02%7C%7C60df6ff86cf14cb > >> > ef20408ddf0feb5ad%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C6 > >> > 38931698951012908%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOn > >> > RydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ > >> > %3D%3D%7C0%7C%7C%7C&sdata=402A26XAvnY2H0rPRjJDf0NWmOt8HrlaFs > >> > w4ITVLwkk%3D&reserved=0 > >> > >>> > >> > https://www.rfc/ > >> > - > >> > editor.org%2Fauthors%2Frfc9840.pdf&data=05%7C02%7C%7C60df6ff86cf14c > >> > bef20408ddf0feb5ad%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C > >> > 638931698951033190%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOn > >> > RydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ > >> > %3D%3D%7C0%7C%7C%7C&sdata=7t86Fcj%2FOBSlW%2BF%2Fr9wbX42QR4Y > >> > 5ncwb5ubjrofnLxc%3D&reserved=0 > >> > >>> > >> > https://www.rfc/ > >> > - > >> > editor.org%2Fauthors%2Frfc9840.html&data=05%7C02%7C%7C60df6ff86cf14 > >> > cbef20408ddf0feb5ad%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7 > >> > C638931698951052611%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiO > >> > nRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyf > >> > Q%3D%3D%7C0%7C%7C%7C&sdata=ztlEQlc26oOlRvMkxmt%2FysGIvUwUnFG > >> > QootxvkdsJgo%3D&reserved=0 > >> > >>> > >> > https://www.rfc/ > >> > - > >> > editor.org%2Fauthors%2Frfc9840.xml&data=05%7C02%7C%7C60df6ff86cf14c > >> > bef20408ddf0feb5ad%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C > >> > 638931698951068442%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOn > >> > RydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ > >> > %3D%3D%7C0%7C%7C%7C&sdata=RGur6TxSJtASy42iyFLRNzC3Z6jQO3HPCij1 > >> > HyWj7w0%3D&reserved=0 > >> > >>> > >> > https://www.rfc/ > >> > -editor.org%2Fauthors%2Frfc9840- > >> > diff.html&data=05%7C02%7C%7C60df6ff86cf14cbef20408ddf0feb5ad%7C84d > >> > f9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638931698951087282%7CUn > >> > known%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAw > >> > MCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C > >> > &sdata=0wgmhaG1hsYbnubcvICLtSohQyzF5LuUAm7EMJofcck%3D&reserved > >> > =0 > >> > >>> > >> > https://www.rfc/ > >> > -editor.org%2Fauthors%2Frfc9840- > >> > rfcdiff.html&data=05%7C02%7C%7C60df6ff86cf14cbef20408ddf0feb5ad%7C8 > >> > 4df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638931698951106143%7C > >> > Unknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDA > >> > wMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C% > >> > 7C&sdata=iTaYH9Wsxp06thq48DZq%2Bpvv0mQB3BAlFQxwR8zUK6Q%3D&res > >> > erved=0 (side by side) > >> > >>> > >> > https://www.rfc/ > >> > -editor.org%2Fauthors%2Frfc9840- > >> > auth48diff.html&data=05%7C02%7C%7C60df6ff86cf14cbef20408ddf0feb5ad > >> > %7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C63893169895112573 > >> > 5%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAu > >> > MDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C% > >> > 7C%7C&sdata=gE0mRugcz7Ph60jbHXMs%2F52P4wZcfhR1fsJzAxlUk%2F8%3D > >> > &reserved=0 > >> > >>> > >> > https://www.rfc/ > >> > -editor.org%2Fauthors%2Frfc9840- > >> > auth48rfcdiff.html&data=05%7C02%7C%7C60df6ff86cf14cbef20408ddf0feb5a > >> > d%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C6389316989511453 > >> > 14%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjA > >> > uMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C > >> > %7C%7C&sdata=Uy8y614RSHGUiey5kWPCilO9RUvR98WcYnHmyRnNlAA%3D > >> > &reserved=0 (side by side) > >> > >>> > >> > >>> > >> > https://www.rfc/ > >> > -editor.org%2Fauthors%2Frfc9840-alt- > >> > diff.html&data=05%7C02%7C%7C60df6ff86cf14cbef20408ddf0feb5ad%7C84d > >> > f9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638931698951164584%7CUn > >> > known%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAw > >> > MCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C > >> > &sdata=nwpon2f2xUp5F7uAkETsEVNzjpnQnHJ01D9ku6taE3Y%3D&reserved= > >> > 0 > >> > >>> > >> > https://www.rfc/ > >> > -editor.org%2Fauthors%2Frfc9840- > >> > xmldiff1.html&data=05%7C02%7C%7C60df6ff86cf14cbef20408ddf0feb5ad%7 > >> > C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638931698951184759% > >> > 7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuM > >> > DAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7 > >> > C%7C&sdata=4v%2FGD5JE%2FXcwEMUBjnZmbkTO4mmRYk2rC0t%2FN5KJv1s > >> > %3D&reserved=0 > >> > >>> > >> > https://www.rfc/ > >> > -editor.org%2Fauthors%2Frfc9840- > >> > xmldiff2.html&data=05%7C02%7C%7C60df6ff86cf14cbef20408ddf0feb5ad%7 > >> > C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638931698951204039% > >> > 7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuM > >> > DAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7 > >> > C%7C&sdata=0XWyJD5xPfHnhSH1n49Hco6LManM9OVqWltZ8drfXXs%3D&res > >> > erved=0 > >> > >>> > >> > https://www.rfc/ > >> > -editor.org%2Fauthors%2Frfc9840-alt- > >> > diff.html&data=05%7C02%7C%7C60df6ff86cf14cbef20408ddf0feb5ad%7C84d > >> > f9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638931698951221481%7CUn > >> > known%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAw > >> > MCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C > >> > &sdata=hfcwAefWpVmCsulEjYRywHOn6lqg%2BBKPpoEleSFN6w4%3D&reserv > >> > ed=0 > >> > >>> > >> > >>> Thanks again! > >> > >>> > >> > >>> Lynne Bartholomew > >> > >>> RFC Production Center > >> > >>> > >> > >>>> On Sep 4, 2025, at 3:21 AM, marcelo bagnulo braun > >> > <[email protected]> wrote: > >> > >>>> > >> > >>>> Hi, > >> > >>>> > >> > >>>> Thanks for all the work on the document. > >> > >>>> I reply online below... > >> > >>>> > >> > >>>> El 18/8/25 a las 22:15, [email protected] 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.r/ > >> > fc- > >> > editor.org%2Fsearch&data=05%7C02%7C%7C60df6ff86cf14cbef20408ddf0feb > >> > 5ad%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C63893169895123 > >> > 5042%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwL > >> > jAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7 > >> > C%7C%7C&sdata=3lIgWqdCwaIEP8XB9yWGuZeQdQX2SAIfq519kn3stUg%3D& > >> > reserved=0>. --> > >> > >>>>> > >> > >>>> 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.r/ > >> > fc-editor.org%2Frfc%2Frfc5743.html%23section- > >> > 2.1&data=05%7C02%7C%7C60df6ff86cf14cbef20408ddf0feb5ad%7C84df9e7f > >> > e9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638931698951248655%7CUnkno > >> > wn%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsI > >> > lAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdat > >> > a=yPzoqsFBrpaGkgL1uZCBForo2EGE9Gru2Gm06JNaZLg%3D&reserved=0>. --> > >> > >>>>> > >> > >>>> 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.r/ > >> > fc- > >> > editor.org%2Finfo%2Frfc6582&data=05%7C02%7C%7C60df6ff86cf14cbef2040 > >> > 8ddf0feb5ad%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638931 > >> > 698951263122%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydW > >> > UsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D% > >> > 3D%7C0%7C%7C%7C&sdata=b9bhuvCKE0eaItNuBF8H9LyFh5z%2F%2Foq1u7lI > >> > Sq4%2BHag%3D&reserved=0>. --> > >> > >>>> 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.c/ > >> > om%2Fnet- > >> > research%2Frledbat_module&data=05%7C02%7C%7C60df6ff86cf14cbef2040 > >> > 8ddf0feb5ad%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638931 > >> > 698951277810%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydW > >> > UsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D% > >> > 3D%7C0%7C%7C%7C&sdata=S72lNBbP2S4NcJOn%2BMwdx85WF8fswCc0wl3 > >> > Ko8kKZOs%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%7C60df6ff86cf14cbef20408ddf0feb5ad%7C84df9e7fe9 > >> > f640afb435aaaaaaaaaaaa%7C1%7C0%7C638931698951290829%7CUnknown > >> > %7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAi > >> > OiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata= > >> > sxfLj3rD77MNxbTMNuhTDaURcUY6hCUj%2BZfvzLKo%2Frc%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%7C60df6ff86cf14cbef2040 > >> > 8ddf0feb5ad%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638931 > >> > 698951303371%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydW > >> > UsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D% > >> > 3D%7C0%7C%7C%7C&sdata=E0522vp3AICFzNHjoNZZtck3IFZ%2FWBq8KphdN > >> > pa7q5k%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%7C60df6ff86cf14cbef20408ddf0fe > >> > b5ad%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C6389316989513 > >> > 15879%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiI > >> > wLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0 > >> > %7C%7C%7C&sdata=8a3f267L9J1KUbn6%2BnsTEHudN4kAoLqR3Q0QQaS6nYs > >> > %3D&reserved=0 > >> > >>>>> 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/ > >> > %2F10.1016%2Fj.comnet.2022.109036&data=05%7C02%7C%7C60df6ff86cf14 > >> > cbef20408ddf0feb5ad%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7 > >> > C638931698951329255%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiO > >> > nRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyf > >> > Q%3D%3D%7C0%7C%7C%7C&sdata=o5twGjLFuUaBhcH6ar13UeahLWjUDWr > >> > Hlz%2FIuow1Lfw%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%7C60df6ff86cf14 > >> > cbef20408ddf0feb5ad%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7 > >> > C638931698951345187%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiO > >> > nRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyf > >> > Q%3D%3D%7C0%7C%7C%7C&sdata=%2BqmHG9zYdYkK45z9qcDJBX0Hut%2F > >> > U9Dcfv6ceBXtzKGU%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%7C60df6ff86cf14 > >> > cbef20408ddf0feb5ad%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7 > >> > C638931698951358623%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiO > >> > nRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyf > >> > Q%3D%3D%7C0%7C%7C%7C&sdata=qbnwNrvLqqH2AbpxoHhStDVGW1%2FE > >> > Smv%2FMmJjNAwaTz4%3D&reserved=0>. --> > >> > >>>>> > >> > >>>>> > >> > >>>> 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.r/ > >> > fc-editor.org%2Frpc%2Fwiki%2Fdoku.php%3Fid%3Dsourcecode- > >> > types&data=05%7C02%7C%7C60df6ff86cf14cbef20408ddf0feb5ad%7C84df9e > >> > 7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638931698951371232%7CUnkn > >> > own%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCI > >> > sIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sd > >> > ata=Qrun8uO8H%2BardLiyIJTCMhYtNJwu9UrF8mqKpyzM%2B0I%3D&reserve > >> > d=0> > >> > >>>>> 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.r/ > >> > fc- > >> > editor.org%2Fstyleguide%2Fpart2%2F%23inclusive_language&data=05%7C02 > >> > %7C%7C60df6ff86cf14cbef20408ddf0feb5ad%7C84df9e7fe9f640afb435aaaaa > >> > aaaaaaa%7C1%7C0%7C638931698951384152%7CUnknown%7CTWFpbGZsb3 > >> > d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkF > >> > OIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=dc8hZdY58gB1P9 > >> > C%2BlqNq4bSwklZ8uJn8Yn%2FAcJBuF0E%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. --> > >> > >>>>> > >> > >>>> 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, [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%7C60df6ff86cf14cbef20408ddf0fe > >> > b5ad%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C6389316989513 > >> > 98287%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiI > >> > wLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0 > >> > %7C%7C%7C&sdata=XAznkhacI5ouBP2NGfuyCMz138NmCOupC1NmrdUIvIY% > >> > 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%7C60df6ff86cf14cbef20408ddf0feb5ad%7C84df9e7f > >> > e9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638931698951411651%7CUnkno > >> > wn%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsI > >> > lAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdat > >> > a=X4bVtBhZoaSZ32Yet0FfsrH9Bnp2BPEry23wMHyhzyU%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%7C60df6ff86cf14cbef20408ddf0feb5ad%7C8 > >> > 4df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638931698951424114%7C > >> > Unknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDA > >> > wMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C% > >> > 7C&sdata=YSKCk9AJTB1RAflgI%2B7K%2B89jvxFRtxRsTBf1vJqh8us%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://mailarc/ > >> > hive.ietf.org%2Farch%2Fmsg%2Fietf-announce%2Fyb6lpIGh- > >> > 4Q9l2USxIAe6P8O4Zc&data=05%7C02%7C%7C60df6ff86cf14cbef20408ddf0fe > >> > b5ad%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C6389316989514 > >> > 37246%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiI > >> > wLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0 > >> > %7C%7C%7C&sdata=1z20TvruqMEwK0QNtI2lrpjQzR2ApClTvNZ4JBus04I%3D& > >> > reserved=0 > >> > >>>>> > >> > >>>>> * The archive itself: > >> > >>>>> > >> > https://mailarc/ > >> > hive.ietf.org%2Farch%2Fbrowse%2Fauth48archive%2F&data=05%7C02%7C%7 > >> > C60df6ff86cf14cbef20408ddf0feb5ad%7C84df9e7fe9f640afb435aaaaaaaaaaa > >> > a%7C1%7C0%7C638931698951453203%7CUnknown%7CTWFpbGZsb3d8eyJF > >> > bXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiT > >> > WFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=s%2FjXAVMije%2FP3Ch > >> > dsnljL3GoQv6uQts0n%2BELn8NYLKQ%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.rfc/ > >> > - > >> > editor.org%2Fauthors%2Frfc9840.xml&data=05%7C02%7C%7C60df6ff86cf14c > >> > bef20408ddf0feb5ad%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C > >> > 638931698951651775%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOn > >> > RydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ > >> > %3D%3D%7C0%7C%7C%7C&sdata=b4j%2Bhs%2Bx2Nsy2ioVqI8cwgT1iPJSftez > >> > 1woYwo8zRZA%3D&reserved=0 > >> > >>>>> > >> > https://www.rfc/ > >> > - > >> > editor.org%2Fauthors%2Frfc9840.html&data=05%7C02%7C%7C60df6ff86cf14 > >> > cbef20408ddf0feb5ad%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7 > >> > C638931698951682490%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiO > >> > nRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyf > >> > Q%3D%3D%7C0%7C%7C%7C&sdata=dFRatTqTk65esIeS8KSYNFn8ClscSkGwv% > >> > 2Fa52zfyDsM%3D&reserved=0 > >> > >>>>> > >> > https://www.rfc/ > >> > - > >> > editor.org%2Fauthors%2Frfc9840.pdf&data=05%7C02%7C%7C60df6ff86cf14c > >> > bef20408ddf0feb5ad%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C > >> > 638931698951698175%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOn > >> > RydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ > >> > %3D%3D%7C0%7C%7C%7C&sdata=W%2FIwticR6M2R2sb73CMol%2BR3puM > >> > ftatKALgXZECpb3w%3D&reserved=0 > >> > >>>>> > >> > https://www.rfc/ > >> > - > >> > editor.org%2Fauthors%2Frfc9840.txt&data=05%7C02%7C%7C60df6ff86cf14cb > >> > ef20408ddf0feb5ad%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C6 > >> > 38931698951711090%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOn > >> > RydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ > >> > %3D%3D%7C0%7C%7C%7C&sdata=NyzMtVsp2y%2FAkm2qB3ENkGgy%2Bl34 > >> > p4eFcLsdffIP7oA%3D&reserved=0 > >> > >>>>> > >> > >>>>> Diff file of the text: > >> > >>>>> > >> > https://www.rfc/ > >> > -editor.org%2Fauthors%2Frfc9840- > >> > diff.html&data=05%7C02%7C%7C60df6ff86cf14cbef20408ddf0feb5ad%7C84d > >> > f9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638931698951724425%7CUn > >> > known%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAw > >> > MCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C > >> > &sdata=UdKkbC7qDOd5yv6i4VVFvQmP2CEYgERjCr8DUP9kqXg%3D&reserved > >> > =0 > >> > >>>>> > >> > https://www.rfc/ > >> > -editor.org%2Fauthors%2Frfc9840- > >> > rfcdiff.html&data=05%7C02%7C%7C60df6ff86cf14cbef20408ddf0feb5ad%7C8 > >> > 4df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638931698951737573%7C > >> > Unknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDA > >> > wMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C% > >> > 7C&sdata=hRzOCkuUgK9gnKF%2FtPPF9qEx4S1%2B5PZV5xqc5yoLAt4%3D&res > >> > erved=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%7C60df6ff86cf14cbef20408ddf0feb5ad%7C84d > >> > f9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638931698951750239%7CUn > >> > known%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAw > >> > MCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C > >> > &sdata=quCPiSOwVbyYzUkrBk5PiAIG2sDjuSkpp7Ut27b5OuQ%3D&reserved=0 > >> > >>>>> > >> > >>>>> Diff of the XML: > >> > >>>>> > >> > https://www.rfc/ > >> > -editor.org%2Fauthors%2Frfc9840- > >> > xmldiff1.html&data=05%7C02%7C%7C60df6ff86cf14cbef20408ddf0feb5ad%7 > >> > C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638931698951763072% > >> > 7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuM > >> > DAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7 > >> > C%7C&sdata=fEodxuUClEfwH7WyAAeKF6VDOIHVc72Tz%2FiA1oGpOaE%3D&r > >> > eserved=0 > >> > >>>>> > >> > >>>>> > >> > >>>>> Tracking progress > >> > >>>>> ----------------- > >> > >>>>> > >> > >>>>> The details of the AUTH48 status of your document are here: > >> > >>>>> > >> > https://www.rfc/ > >> > - > >> > editor.org%2Fauth48%2Frfc9840&data=05%7C02%7C%7C60df6ff86cf14cbef20 > >> > 408ddf0feb5ad%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C6389 > >> > 31698951775630%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRyd > >> > WUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3 > >> > D%3D%7C0%7C%7C%7C&sdata=E3a9QT12HFTVrtbj%2BaZYmTMhDnxGsUx69 > >> > LjX7IVG660%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]
