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.rfc-editor.org/search>. -->
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.rfc-editor.org/rfc/rfc5743.html#section-2.1>. -->
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.rfc-editor.org/info/rfc6582>. -->
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.com/net-research/rledbat_module.
- ns3 implementation, open source, available since 2020 at
https://github.com/manas11/implementation-of-rLEDBAT-in-ns-3.
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/net-research/rledbat_module>.
[rLEDBAT-in-ns3] "Implementation-of-rLEDBAT-in-ns-3", commit
2ab34ad, June 2020,
<https://github.com/manas11/
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/10.1016/j.comnet.2022.109036>.
[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/10.1016/j.comnet.2022.109460>.
[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/10.1016/j.comnet.2023.109841>. -->
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.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types>
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.rfc-editor.org/styleguide/part2/#inclusive_language>,
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.rfc-editor.org/faq/).
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.ietf.org/license-info).
* 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://authors.ietf.org/rfcxml-vocabulary>.
* 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://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
* The archive itself:
https://mailarchive.ietf.org/arch/browse/auth48archive/
* 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/authors/rfc9840.xml
https://www.rfc-editor.org/authors/rfc9840.html
https://www.rfc-editor.org/authors/rfc9840.pdf
https://www.rfc-editor.org/authors/rfc9840.txt
Diff file of the text:
https://www.rfc-editor.org/authors/rfc9840-diff.html
https://www.rfc-editor.org/authors/rfc9840-rfcdiff.html (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/authors/rfc9840-alt-diff.html
Diff of the XML:
https://www.rfc-editor.org/authors/rfc9840-xmldiff1.html
Tracking progress
-----------------
The details of the AUTH48 status of your document are here:
https://www.rfc-editor.org/auth48/rfc9840
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) :
