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 <marc...@it.uc3m.es> > Sent: Thursday, September 11, 2025 02:45 > To: Lynne Bartholomew <lbartholo...@staff.rfc-editor.org> > Cc: rfc-edi...@rfc-editor.org; albe...@it.uc3m.es; > g.e.montene...@hotmail.com; pravb.i...@gmail.com; i...@irtf.org; > vidhi_g...@apple.com; auth48archive@rfc-editor.org > 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 <marc...@it.uc3m.es> > wrote: > >> > >> Hi, > >> > >> thanks for the comments, replies below... > >> > >> El 8/9/25 a las 21:22, Lynne Bartholomew escribió: > >>> Hi, Marcelo. Thank you for your replies to our questions! > >>> > >>> A couple follow-up questions for you: > >>> > >>> Regarding our question 8)a) and your reply: > >>> > >>>>> 8) <!-- [rfced] Section 3: > >>>>> > >>>>> a) Will "other documents" be clear to readers? Should one or more > >>>>> specific documents be cited here? > >>>>> > >>>>> Original: > >>>>> The LBE > >>>>> congestion control algorithm executed in the rLEDBAT receiver is > >>>>> defined in other documents. > >>>> by other documents we meant elsewhere (i.e. not in this document), > maybe using elsewhere would be clearer? > >>> As it appears that this topic could be considered beyond the scope of this > document, may we update this sentence as follows? > >>> > >>> Currently: > >>> The LBE > >>> congestion control algorithm executed in the rLEDBAT receiver is > >>> defined in other documents. > >>> > >>> Suggested: > >>> How the LBE > >>> congestion control algorithm is executed in the rLEDBAT receiver is > >>> beyond the scope of this document. > >> mmm, not exactly. > >> > >> I would suggest: > >> > >> The defintion of the actual LBE > >> congestion control algorithm executed in the rLEDBAT receiver is > >> beyond the scope of this document. > >> > >> Regards, marcelo > >> > >>> = = = = = > >>> > >>> Regarding our question 9) and your reply: > >>> > >>>>> 9) <!-- [rfced] Sections 3.1 and 3.1.1: We had trouble following the > >>>>> meaning of "honoring both", "may fall short to honor", "honoring > >>>>> that", and "sufficient to honor the window output" in these > >>>>> sentences. Please clarify. > >>>> There seem a lot of honor in this document! :) > >>>> I thought it was an expression widely used in english > >>>> In general, what I meant was essentially to comply with the restriction > imposed by the RLWND and fcwnd (respecting, adhering to, or not violating > according to chatgpt) > >>>> The value of the window must not be larger than any of these two, so > honoring them meand that the window is not largen than any of them. > >>>> Feel free to rephrase it if you think it is unclear. > >>> Thank you for the explanation. We did not make any changes. > >>> > >>> = = = = = > >>> > >>> The latest files are posted here. Please refresh your browser: > >>> > >>> > https://www.rfc/ > - > editor.org%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 > <marc...@it.uc3m.es> wrote: > >>>> > >>>> Hi, > >>>> > >>>> Thanks for all the work on the document. > >>>> I reply online below... > >>>> > >>>> El 18/8/25 a las 22:15, rfc-edi...@rfc-editor.org escribió: > >>>>> Authors, > >>>>> > >>>>> While reviewing this document during AUTH48, please resolve (as > necessary) the following questions, which are also in the XML file. > >>>>> > >>>>> > >>>>> 1) <!-- [rfced] Alberto, would you prefer that we use accented letters > >>>>> in your name in this and subsequent RFCs? We ask because we see > >>>>> "García-Martínez" in [COMNET1], [COMNET2], and [COMNET3]. We > are > >>>>> fine either way, but we ask because some authors prefer that the > >>>>> accents be used. If you prefer that we use the accented letters > >>>>> going forward, we will note your preference for future reference. > >>>>> > >>>>> Original: > >>>>> A. Garcia-Martinez > >>>>> ... > >>>>> Alberto Garcia-Martinez --> > >>>>> > >>>> Accents would be great, thanks! > >>>> > >>>>> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in > the > >>>>> title) for use on > <https://www.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, rfc-edi...@rfc-editor.org wrote: > >>>>> > >>>>> *****IMPORTANT***** > >>>>> > >>>>> Updated 2025/08/18 > >>>>> > >>>>> RFC Author(s): > >>>>> -------------- > >>>>> > >>>>> Instructions for Completing AUTH48 > >>>>> > >>>>> Your document has now entered AUTH48. Once it has been reviewed > and > >>>>> approved by you and all coauthors, it will be published as an RFC. > >>>>> If an author is no longer available, there are several remedies > >>>>> available as listed in the FAQ > (https://www.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 > >>>>> > >>>>> * rfc-edi...@rfc-editor.org (the RPC team) > >>>>> > >>>>> * other document participants, depending on the stream (e.g., > >>>>> IETF Stream participants are your working group chairs, the > >>>>> responsible ADs, and the document shepherd). > >>>>> > >>>>> * auth48archive@rfc-editor.org, which is a new archival mailing list > >>>>> to preserve AUTH48 conversations; it is not an active discussion > >>>>> list: > >>>>> > >>>>> * More info: > >>>>> > https://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, > >>>>> auth48archive@rfc-editor.org will be re-added to the CC list and > >>>>> its addition will be noted at the top of the message. > >>>>> > >>>>> You may submit your changes in one of two ways: > >>>>> > >>>>> An update to the provided XML file > >>>>> — OR — > >>>>> An explicit list of changes in this format > >>>>> > >>>>> Section # (or indicate Global) > >>>>> > >>>>> OLD: > >>>>> old text > >>>>> > >>>>> NEW: > >>>>> new text > >>>>> > >>>>> You do not need to reply with both an updated XML file and an explicit > >>>>> list of changes, as either form is sufficient. > >>>>> > >>>>> We will ask a stream manager to review and approve any changes that > seem > >>>>> beyond editorial in nature, e.g., addition of new text, deletion of > >>>>> text, > >>>>> and technical changes. Information about stream managers can be > found in > >>>>> the FAQ. Editorial changes do not require approval from a stream > manager. > >>>>> > >>>>> > >>>>> Approving for publication > >>>>> -------------------------- > >>>>> > >>>>> To approve your RFC for publication, please reply to this email stating > >>>>> that you approve this RFC for publication. Please use ‘REPLY ALL’, > >>>>> as all the parties CCed on this message need to see your approval. > >>>>> > >>>>> > >>>>> Files > >>>>> ----- > >>>>> > >>>>> The files are available here: > >>>>> > https://www.rfc/ > - > editor.org%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 -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
