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 --> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on <https://www.rfc-editor.org/search>. --> 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>. --> 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. 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). 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). --> 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. --> 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. 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>. --> 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. 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. ... 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. ... - 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. --> 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. 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. --> 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. b) Does "they only allow to perform" mean "they are only allowed to perform", "they only permit performing", or something else? 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). --> 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. 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. --> 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"? --> 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. --> 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. --> 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. --> 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. --> 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. --> 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]. 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>. --> 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 --> 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>. --> 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. --> 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. --> 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) --> 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) --> 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. --> 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) RCV-WND (Figure 1) / RCV WND (Section 5) / RCV.WND (per the rest of this document and per published RFCs to date) TSVal / TSval (per published RFCs, including RFC 7323; we could not find "TSVal" in any published RFC) b) The following terms appear to be used inconsistently in this document. Please let us know which form is preferred. a rLEDBAT / an rLEDBAT Receive window / Receive Window / receive window (We see that "congestion window" is used consistently.) sendList / sentList --> 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) : -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
