RFC 3708

Using TCP Duplicate Selective Acknowledgement (DSACKs) and Stream Control Transmission Protocol (SCTP) Duplicate Transmission Sequence Numbers (TSNs) to Detect Spurious Retransmissions

📅 published February 2004, from ietf

Title Block: RFC 3708 🎀

okay bestie, this one is RFC 3708 from the Network Working Group, and it's an Experimental doc, so it's a "let's try this and see" kind of vibe 🧪✨. It's by E. Blanton (Purdue University) and M. Allman (ICIR), dated February 2004. The title is Using TCP Duplicate Selective Acknowledgement (DSACKs) and Stream Control Transmission Protocol (SCTP) Duplicate Transmission Sequence Numbers (TSNs) to Detect Spurious Retransmissions 💅. The header doesn't list any RFCs it obsoletes or updates.

Status of this Memo 📋

okay so this memo defines an Experimental Protocol for the Internet community 🧪. It does NOT specify an Internet standard of any kind, so don't go calling it a standard 🙅‍♀️. They're asking for discussion and suggestions for improvement, and distribution of the memo is unlimited 💌.

Copyright (C) The Internet Society (2004). All Rights Reserved. 🌸

Abstract 🦋

okay so TCP and SCTP both tell you when a duplicate segment has shown up. TCP does it with Duplicate Selective Acknowledgement (DSACKs), and SCTP does it with Duplicate Transmission Sequence Number (TSN) notification 📬. This doc gives you careful, conservative ways to use that info to spot unnecessary retransmissions, for a bunch of different apps 🔍✨.

1. Introduction 🎀

Terminology 📖

TCP [RFC793] and SCTP [RFC2960] give you notification of duplicate segment receipt through duplicate selective acknowledgment (DSACK) [RFC2883] and Duplicate TSN notifications, respectively 💖. With that info, a TCP or SCTP sender can usually figure out when a retransmission was sent by mistake 🙈. This doc has two methods for using duplicate notifications 👯‍♀️. The first one is simple and works for accounting apps 🧾. The second one is a conservative algorithm that tells unnecessary retransmissions apart from real loss events, so you can undo unnecessary congestion control changes 🔄🫶.

This doc is meant to lay out reasonable, safe algorithms for detecting spurious retransmissions and talk through the stuff you need to think about 🧠. It's NOT trying to be the only possible way to get there, though, and the guidelines here should still be considered when you design your own alternate algorithms ✨. Also, this doc does NOT say what a TCP or SCTP sender may do after it detects a spurious retransmission 🤷‍♀️. People have come up with a bunch of proposals already (e.g., [RFC3522], [SK03], [BDA03]), but it isn't clear yet which ones are the right fit 🌈. Plus, they all rely on detecting spurious retransmits, so they can share the algorithm specified in this document 🫱🏻‍🫲🏼.

Last thing: to keep the text simple, most of the discussion is written in terms of TCP DSACKs, even though it applies to both TCP and SCTP 🧚.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] 📚.

2. Counting Duplicate Notifications 🔢

okay so for some apps, a plain count of duplicate notifications is enough 💅. Say a stack just wants to know (for whatever reason) how many segments were retransmitted spuriously. Counting every duplicate notification for retransmitted segments should work really well 🙌. Another way to use this is to monitor and adapt transport algorithms so the transport isn't blasting a ton of spurious data into the network 🚫📡. For example, monitoring duplicate notifications could help the Early Retransmit [AAAB03] algorithm figure out whether fast retransmitting [RFC2581] segments with a lower-than-normal duplicate ACK threshold is working, or whether segment reordering is the thing causing spurious retransmits 🕵️‍♀️.

Now for a more speculative one 👀. Duplicate notification has been proposed as an integral part of estimating TCP's total loss rate [AEO03] 🧮. The goal there is to reduce the impact of corruption-based losses on transport protocol performance 🛠️. [EOA03] proposes changing the transport's congestion response based on the fraction of losses that are actually due to congestion. To do that, the network has to provide the corruption-based loss rate, and the transport sender has to estimate the total loss rate 🌊. Duplicate notifications are a key part of estimating the total loss rate accurately [AEO03] 💜.

3. Congestion/Duplicate Disambiguation Algorithm 🕵️‍♀️💖

okay so when the goal of detecting spurious retransmissions is to "undo" unnecessary changes to the congestion control state (like suggested in [RFC2883]) 🔙, the data sender ideally needs to figure out two things 🧩:

(a) Whether spurious retransmissions in a particular window of data are masking real segment loss (congestion) 🚨.

Here's an example to picture it 🎬. Say segments N and N+1 both get retransmitted, even though the network only dropped segment N (so segment N+1 was retransmitted for no reason 😭). When the sender gets the notification that segment N+1 arrived more than once, it can conclude that N+1 was needlessly resent 🙃. But it still can't conclude that it's okay to revert the congestion control state, because the window of data had at least one valid congestion indication (segment N was lost) 🥲.

(b) Whether network duplication is the reason for the duplicate notification 🌀.

Honestly, figuring out whether a duplicate notification came from the network duplicating a packet or from a spurious retransmit is a nearly impossible task in theory 🤯. Since [Pax97] shows that packet duplication by the network is rare, the algorithm in this section just stops working when network duplication is detected (that's when you get a duplication notification for a segment the sender did NOT retransmit) 🛑.

The algorithm below gives reasonable, but not complete, protection against both of these cases 🫶.

We assume the TCP sender has a data structure to hold selective acknowledgment information (e.g., as outlined in [RFC3517]) 🗂️. The steps below need that "scoreboard" to be extended so it keeps a slightly longer history of retransmissions than what [RFC3517] calls for ✨. The rest of the algorithm picks up in the next part, bestie 💅🧚.

okay so this section is basically a tour of everyone else who tried to figure out "was that retransmit actually needed?" 🕵️‍♀️ and honestly the list is iconic 💅

[BA02] took the algorithm from this document and used it as the starting point to test a bunch of ways to make TCP more robust to reordered packets 🌀 main character energy for sure 🎀

The Eifel detection algorithm [RFC3522] uses the TCP timestamp option [RFC1323] to figure out whether the ACK for a retransmit is for the original transmission or for the retransmission itself 🧚 more generally, [LK00] explains why it's worth detecting spurious retransmits and undoing needless congestion control changes, using either the timestamp-based scheme or a "retransmit bit" that flags retransmits (and ACKs of retransmits) 🦋 Eifel can catch spurious retransmits faster than a DSACK-based scheme, ngl that's so good 🔥 but the tradeoff is that the 12-byte timestamp option has to be sent in every packet for Eifel to work 🙈

F-RTO [SK03] is lowkey clever: it slightly changes how TCP sends right after a retransmission timeout, then watches the pattern of ACKs that come back 🌸 that pattern can tell you whether the retransmitted segment was needed 💖 the best part is that it only needs to be implemented on the sender side, and nothing extra has to cross the network (no DSACKs, no timestamps, no special flags, none of that) 💅 the catch is that it's a heuristic, so network pathologies like duplication or reordering of key packets can confuse it 😭 also, F-RTO only works for spurious retransmits triggered by the transport's retransmission timer ⏰

And last but not least, [AP99] briefly looked at timing the gap between retransmitting a segment after a retransmission timeout and the arrival of the next ACK 🕰️ if that gap is less than f times the minimum RTT seen so far on the connection, the retransmit gets labeled spurious 🫶 with f=1/2, the algorithm catches roughly 59% of the needless retransmission timeouts, but it also flags needed retransmits about 2.5% of the time 🙈 just like F-RTO, this only detects spurious retransmits sent by the transport's retransmission timer 🧚

5. Security Considerations 🔐

okay bestie, this section is SERIOUS and I need you to read it all 🚨

It's possible for the receiver to falsely report spurious retransmissions when there was actually a loss 😱 that could trick a TCP or SCTP sender into wrongly concluding that no loss happened, and maybe cause inappropriate changes to the sender's congestion control state 💀

Here's a scenario that's giving chaos: a receiver watches every segment or chunk that arrives, and any segment that shows up out of order by more than some threshold gets acknowledged as a duplicate, on the assumption that it's a retransmission 🙃 a sender using the algorithm above will then assume that retransmission was spurious 💀

The ECN nonce sum proposal [RFC3540] could possibly help stop a receiver from hiding real losses from the sender, with a modest extension ✨ in the common case, where the receiver gets an original transmission and a spurious retransmit, the receiver has the nonce from the original transmission, so it can "prove" to the sender that the duplication notification is valid 🫶 but if the receiver never got the original and is trying to push the sender into transmitting at an inappropriately high rate, it won't know the ECN nonce from the original segment, so it probabilistically won't be able to fool the sender for long 🎀 [RFC3540] says to disable nonce sums on duplicate ACKs, which means the nonce sum isn't directly suitable for fixing the problem of receivers lying about DSACK information 😤 still, future efforts might use [RFC3540] as a starting point for building protection if it's ever needed 🔮

6. Acknowledgments 💜

Sourabh Ladha and Reiner Ludwig gave several useful comments on an earlier version of this document 🙌 the second author thanks BBN Technologies and NASA's Glenn Research Center for supporting this work 🚀

7. References 📚

7.1. Normative References 🧾

[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2883] Floyd, S., Mahdavi, J., Mathis, M. and M. Podolsky, "An Extension to the Selective Acknowledgement (SACK) Option for TCP", RFC 2883, July 2000.

[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000.

7.2. Informative References 🌈

[AAAB03] Allman, M., Avrachenkov, K., Ayesta, U. and J. Blanton, "Early Retransmit for TCP", Work in Progress, June 2003.

[AEO03] Allman, M., Eddy, E. and S. Ostermann, "Estimating Loss Rates With TCP", Work in Progress, August 2003.

[AP99] Allman, M. and V. Paxson, "On Estimating End-to-End Network Path Properties", SIGCOMM 99.

[BA02] Blanton, E. and M. Allman. On Making TCP More Robust to Packet Reordering. ACM Computer Communication Review, 32(1), January 2002.

[BDA03] Blanton, E., Dimond, R. and M. Allman, "Practices for TCP Senders in the Face of Segment Reordering", Work in Progress, February 2003.

[EOA03] Eddy, W., Ostermann, S. and M. Allman, "New Techniques for Making Transport Protocols Robust to Corruption-Based Loss", Work in Progress, July 2003.

[LK00] R. Ludwig, R. H. Katz. The Eifel Algorithm: Making TCP Robust Against Spurious Retransmissions. ACM Computer Communication Review, 30(1), January 2000.

[Pax97] V. Paxson. End-to-End Internet Packet Dynamics. In ACM SIGCOMM, September 1997.

[RFC1323] Jacobson, V., Braden, R. and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.

[RFC3517] Blanton, E., Allman, M., Fall, K. and L. Wang, "A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP", RFC 3517, April 2003.

[RFC3522] Ludwig, R. and M. Meyer, "The Eifel Detection Algorithm for TCP," RFC 3522, April 2003.

[RFC3540] Spring, N., Wetherall, D. and D. Ely, "Robust Explicit Congestion Notification (ECN) Signaling with Nonces", RFC 3540, June 2003.

[SK03] Sarolahti, P. and M. Kojo, "F-RTO: An Algorithm for Detecting Spurious Retransmission Timeouts with TCP and SCTP", Work in Progress, June 2003.

8. Authors' Addresses 📬

Ethan Blanton Purdue University Computer Sciences 1398 Computer Science Building West Lafayette, IN 47907

EMail: eblanton@cs.purdue.edu

Mark Allman ICSI Center for Internet Research 1947 Center Street, Suite 600 Berkeley, CA 94704-1198 Phone: 216-243-7361

EMail: mallman@icir.org http://www.icir.org/mallman/

Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78 and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 🪪

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Acknowledgement 🙏

Funding for the RFC Editor function is currently provided by the Internet Society. 💖

📦 where this page comes from