RFC 7053
SACK-IMMEDIATELY Extension for the Stream Control Transmission Protocol
RFC 7053: SACK-IMMEDIATELY Extension for the Stream Control Transmission Protocol 🦋
Okay bestie, this one is an official IETF Standards Track spec (ISSN 2070-1721), published in November 2013. Three people wrote it: Michael Tuexen and Irene Ruengeler from Muenster Univ. of Appl. Sciences, and Randall Stewart from Adara Networks. It updates RFC 4960 and doesn't obsolete anything. 💅
Abstract ✨
So this doc updates RFC 4960 by adding a way for the sender of a DATA chunk to ask for the matching Selective Acknowledgment (SACK) chunk to be sent back right away, not delayed 🫶 The trick is a bit in the DATA chunk header called the (I)mmediate bit, and either the Stream Control Transmission Protocol (SCTP) implementation or the application on top of an SCTP stack can set it 🔥 Unknown flags in chunk headers get ignored by SCTP implementations, so this extension doesn't cause any interoperability problems. It's giving no drama 💖
Status of This Memo ✨
This is an Internet Standards Track document. 🎀
It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check Section 2 of RFC 5741 🌸
For the current status, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc7053 🧚
Copyright Notice ✨
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. 💜
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. Please read these carefully, because they spell out your rights and restrictions for this document. Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License. 🙈
Table of Contents 🍓
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. The (I)mmediate Bit in the DATA Chunk Header . . . . . . . . . 3
4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Triggering at the Application Level . . . . . . . . . . . . 4
4.2. Triggering at the SCTP Level . . . . . . . . . . . . . . . 4
5. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Sender-Side Considerations . . . . . . . . . . . . . . . . 5
5.2. Receiver Side Considerations . . . . . . . . . . . . . . . 5
6. Interoperability Considerations . . . . . . . . . . . . . . . . 5
7. Socket API Considerations . . . . . . . . . . . . . . . . . . . 5
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
9. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
11.1. Normative References . . . . . . . . . . . . . . . . . . . 7
11.2. Informative References . . . . . . . . . . . . . . . . . . 71. Introduction ✨
Okay so according to [RFC4960], the receiver of a DATA chunk should use delayed SACKs. That delay is totally controlled by the receiver of the DATA chunk, and it stays the default behavior 💅
But in some situations, delaying the SACKs makes the protocol perform worse 😭
- If the receiver can detect such a situation, the matching SACK can go out immediately. For example, [RFC4960] recommends sending the SACK right away if the receiver has detected message loss or message duplication 🔥
- But if only the sender of the DATA chunk can detect the situation, [RFC4960] gives no way to avoid the delay in sending the SACK. Examples include situations that need the application to get involved (like applications using the SCTP_SENDER_DRY_EVENT, see Section 4.1) and ones the SCTP stack can spot on its own (like closing the association, hitting window limits, or resetting streams, see Section 4.2) 👑
To fix the limitation in the second case, this document adds a small extension to the SCTP DATA chunk by defining a new flag, the "I bit". When the sender sets this bit, it's saying the corresponding SACK chunk should not be delayed 🦋
2. Conventions 🎀
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 [RFC2119]. 🌈
3. The (I)mmediate Bit in the DATA Chunk Header 🧚
Here's the extended DATA chunk, in Figure 1 🍓
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0 | Res |I|U|B|E| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TSN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Identifier | Stream Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Protocol Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ User Data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Extended DATA chunk formatThe only difference between the DATA chunk in Figure 1 and the DATA chunk defined in [RFC4960] is that the I bit gets added to the flags field of the DATA chunk header. That's the whole glow-up ✨
[RFC4960] defines the Reserved field and says these bits should be set to 0 by the sender and ignored by the receiver 🫶
4. Use Cases 💖
Either the application using SCTP or the SCTP stack itself can trigger the I bit. The next two subsections are a non-exhaustive list of examples of how the I bit may be set 🌸
4.1. Triggering at the Application Level 🍓
One example where it may make sense for an application to trigger the I bit involves the SCTP_SENDER_DRY_EVENT in the SCTP socket API [RFC6458]. Upper layers of SCTP that use the socket API defined in [RFC6458] can subscribe to SCTP_SENDER_DRY_EVENT so they get notified as soon as no user data is outstanding 👑 To avoid an unnecessary delay, the application can ask for the I bit to be set when it sends the last user message before waiting for that event. That sets the I bit on the last DATA chunk of the user message, and it's possible through the socket API extension described in Section 7 💅
4.2. Triggering at the SCTP Level 🧚
There are also times when the SCTP implementation can set the I bit without involving the upper layer 🦋
If the association is in the SHUTDOWN-PENDING state, setting the I bit cuts down the number of simultaneous associations for a busy server handling short-lived associations 😭
Another case is when sending a DATA chunk fills the congestion or receiver window. Setting the I bit in these cases improves the throughput of the transfer 🔥
If an SCTP association supports the SCTP Stream Reconfiguration extension defined in [RFC6525], performance can get a boost by setting the I bit when there are pending reconfiguration requests that need no outstanding DATA chunks at all 🌈
5. Procedures 👑
5.1. Sender-Side Considerations 💅
Whenever the sender of a DATA chunk can benefit from the corresponding SACK chunk coming back without delay, the sender MAY set the I bit in the DATA chunk header. Please note that why the sender set the I bit doesn't matter to the receiver 🙈
Reasons for setting the I bit include, but are not limited to (see Section 4 for the benefits):
- The application requests to set the I bit of the last DATA chunk of a user message when providing the user message to the SCTP implementation (see Section 7). 🎀
- The sender is in the SHUTDOWN-PENDING state. 🌸
- The sending of a DATA chunk fills the congestion or receiver window. 💖
- The sending of an Outgoing SSN Reset Request Parameter or an SSN/TSN Reset Request Parameter is pending, if the association supports the Stream Reconfiguration extension defined in [RFC6525]. 🧚
5.2. Receiver Side Considerations 🫶
Once the receiver gets an SCTP packet with a DATA chunk that has the I bit set, the receiver SHOULD NOT delay sending the corresponding SACK chunk. In other words, the receiver SHOULD immediately respond with the corresponding SACK chunk ✨
6. Interoperability Considerations 🦋
According to [RFC4960], a receiver of a DATA chunk with the I bit set should ignore that bit if it doesn't support the extension described in this document. The sender of the DATA chunk can handle that case, so there's no requirement to negotiate support for this feature 🌈
7. Socket API Considerations 🍓
This section explains how the socket API defined in [RFC6458] gets extended so the application can set the I bit 💜
Please note that this section is informational only. 🙈
A socket API implementation based on [RFC6458] needs an extension so the application can set the I bit of the last DATA chunk when it sends each user message 🔥
You do this by setting a flag called SCTP_SACK_IMMEDIATELY in the snd_flags field of the struct sctp_sndinfo structure when using sctp_sendv() or sendmsg(). If the deprecated struct sctp_sndrcvinfo structure is used instead when calling sctp_send(), sctp_sendx(), or sendmsg(), the SCTP_SACK_IMMEDIATELY flag can be set in the sinfo_flags field. When using the deprecated function sctp_sendmsg(), the SCTP_SACK_IMMEDIATELY flag can go in the flags parameter 👑
8. IANA Considerations ✨
okay so bestie, IANA is the org that keeps the big registries of protocol numbers, and for this one they handed out a brand new bit for the DATA chunk 🦋 Following the chunk flag registration procedure in [RFC6096], they registered the I bit (the I bit, not a new name, the actual bit we've been obsessing over 💅).
The "Chunk Flags" registry for SCTP got updated like this:
DATA Chunk Flags
+------------------+-----------------+-----------+
| Chunk Flag Value | Chunk Flag Name | Reference |
+------------------+-----------------+-----------+
| 0x01 | E bit | [RFC4960] |
| 0x02 | B bit | [RFC4960] |
| 0x04 | U bit | [RFC4960] |
| 0x08 | I bit | [RFC7053] |
| 0x10 | Unassigned | |
| 0x20 | Unassigned | |
| 0x40 | Unassigned | |
| 0x80 | Unassigned | |
+------------------+-----------------+-----------+so the I bit is 0x08 and the rest of the bits are still up for grabs 🌸
9. Security Considerations 💀
okay this section is serious, so let's be serious 🫶 See [RFC4960] for the general SCTP security considerations. On top of that, there's one extra thing to know.
A malicious sender can force its peer to send a SACK chunk for each received packet containing DATA chunks, instead of every other received packet containing DATA chunks. That could hit the network, with more packets flying around, or the peer, because generating and sending packets costs processing. ngl that's a real concern 😭
BUT, the extra packets can only contain the simplest SACK chunk (no gap reports, no duplicate TSNs), because if there's packet drops or reordering, a SACK would get sent immediately anyway. So this doesn't add a big processing cost on the receiver side 💖 And it doesn't create more network traffic either, because a receiver sending a SACK for every packet is already permitted 🎀
10. Acknowledgments 🫶
The authors want to thank Mark Allmann, Brian Bidulock, David Black, Anna Brunstrom, Gorry Fairhurst, Janardhan Iyengar, Kacheong Poon, and Michael Welzl for their invaluable comments. Thank you, queens 👑
11. References 📚
11.1. Normative References
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
- [RFC6096] Tuexen, M. and R. Stewart, "Stream Control Transmission Protocol (SCTP) Chunk Flags Registration", RFC 6096, January 2011.
11.2. Informative References
- [RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. Yasevich, "Sockets API Extensions for the Stream Control Transmission Protocol (SCTP)", RFC 6458, December 2011.
- [RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control Transmission Protocol (SCTP) Stream Reconfiguration", RFC 6525, February 2012.
Authors' Addresses 🦋
Michael Tuexen Muenster University of Applied Sciences Stegerwaldstr. 39 48565 Steinfurt DE
EMail: tuexen@fh-muenster.de
Irene Ruengeler Muenster University of Applied Sciences Stegerwaldstr. 39 48565 Steinfurt DE
EMail: i.ruengeler@fh-muenster.de
Randall R. Stewart Adara Networks Chapin, SC 29036 US
EMail: randall@lakerest.net
📦 where this page comes from
- ietf: rfc7053 2013-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms