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]
