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 > On Sep 11, 2025, at 4:41 AM, Gabriel Montenegro <[email protected]> > wrote: > > 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]
