RFC 3758

Stream Control Transmission Protocol (SCTP) Partial Reliability Extension

📅 published May 2004, from ietf

RFC 3758 💖 Stream Control Transmission Protocol (SCTP) Partial Reliability Extension

okay bestie, this is the RFC that gives SCTP a partial reliability upgrade 🦋 Let's start with the title block so you know who made it and when ✨

  • Network Working Group 🌸
  • Request for Comments: 3758
  • Category: Standards Track
  • Date: May 2004
  • Authors: R. Stewart (Cisco Systems, Inc.), M. Ramalho (Cisco Systems, Inc.), Q. Xie (Motorola, Inc.), M. Tuexen (Univ. of Applied Sciences Muenster), P. Conrad (University of Delaware) 👑
  • Obsoletes / Updates: the title block in this copy doesn't list either one 🙈

Status of this Memo ✨

okay so this section tells you what kind of document this is. It's an Internet standards track protocol spec for the Internet community, and it's asking for discussion and suggestions for improvements 💅 If you want the current standardization state and status of this protocol, go check the current edition of the "Internet Official Protocol Standards" (STD 1) 🔥 Distribution of this memo is unlimited, so share it with everyone 🫶

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

Abstract 🦋

this memo is all about extending SCTP so that an endpoint can tell its peer to move the cumulative ack point forward 👀 When both sides of an association support the extension, SCTP can give an upper layer protocol partially reliable data transmission service 🔥 The doc covers the protocol extensions, which are a new parameter for INIT and INIT ACK plus a brand new FORWARD TSN chunk type, and it gives one example of a partially reliable service you can offer the upper layer through this mechanism ✨

Table of Contents 🌈

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
       1.1.  Overview of Protocol Extensions. . . . . . . . . . . . .  2
       1.2.  Overview of New Services Provided to the Upper Layer . .  3
       1.3.  Benefits of PR-SCTP  . . . . . . . . . . . . . . . . . .  4
   2.  Conventions. . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Protocol Changes to support PR-SCTP .  . . . . . . . . . . . .  5
       3.1.  Forward-TSN-Supported Parameter For INIT and INIT ACK. .  5
       3.2.  Forward Cumulative TSN Chunk Definition (FORWARD TSN). .  5
       3.3.  Negotiation of Forward-TSN-Supported parameter . . . . .  7
             3.3.1. Sending Forward-TSN-Supported param in INIT . . .  7
             3.3.2. Receipt of Forward-TSN-Supported parameter in
                    INIT or INIT-ACK. . . . . . . . . . . . . . . . .  7
             3.3.3. Receipt of Op. Error for Forward-TSN-Supported
                    Param . . . . . . . . . . . . . . . . . . . . . .  8
       3.4.  Definition of "abandoned" in the context of PR-SCTP. . .  8
       3.5.  Sender Side Implementation of PR-SCTP. . . . . . . . . .  9
       3.6.  Receiver Side Implementation of PR-SCTP. . . . . . . . . 12
   4.  Services provided by PR-SCTP to the upper layer. . . . . . . . 14
       4.1.  PR-SCTP Service Definition for "timed reliability" . . . 15
       4.2.  PR-SCTP Association Establishment. . . . . . . . . . . . 16
       4.3.  Guidelines for defining other PR-SCTP Services . . . . . 17
       4.4.  Usage Notes. . . . . . . . . . . . . . . . . . . . . . . 19
   5.  Variables. . . . . . . . . . . . . . . . . . . . . . . . . . . 19
   6.  Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 19
   7.  Security Considerations. . . . . . . . . . . . . . . . . . . . 19
   8.  IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 20
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
       9.1.  Normative References . . . . . . . . . . . . . . . . . . 20
       9.2.  Informative References . . . . . . . . . . . . . . . . . 20
   10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20
   11. Full Copyright Statement . . . . . . . . . . . . . . . . . . .

1. Introduction 🧚

this memo extends SCTP, as described in RFC 2960 [2], so that an SCTP sender can tell its peer it should no longer expect to receive one or more DATA chunks 💅

1.1. Overview of Protocol Extensions 🌸

the extension has two new pieces ✨

  1. a single new parameter in the INIT/INIT-ACK exchange that shows whether the endpoint supports the extension 🎀
  2. a single new chunk type, FORWARD TSN, which tells the receiver to move its cumulative ack point forward. This can skip past one or more DATA chunks that may not have been received and/or acknowledged yet 🦋

1.2. Overview of New Services Provided to the Upper Layer 👑

when both sides of an SCTP association support this extension, it can be used to give partially reliable transport service over the association 🔥 Partially reliable transport service is a service where the user can set, per message, the rules for how persistent the transport service should be when it tries to send that message to the receiver 💖

one example of partially reliable service is defined in this document, called "timed reliability" ⏳ This service lets the service user set a limit on how long the sender should keep trying to transmit or retransmit the message. It's a natural extension of the "lifetime" parameter that's already in the base protocol 🫶

on top of that example, defining a partially reliable service takes two elements 🧠

  1. how the service user says how reliable a particular message needs to be, and
  2. how the sender side implementation uses that reliability level to decide when to stop retransmitting that message 💅

Note that, apart from the fact that the FORWARD-TSN chunk is required, neither of these two elements changes the on-the-wire protocol 🌈 Only the API and the sender side implementation are affected by how the service gets defined to the upper layer. So, in principle, you can implement lots of different partially reliable services in one SCTP implementation without changing the on-the-wire protocol 🦋 The SCTP receiver also doesn't necessarily need to know which partially reliable semantics the sender is using, because its only job is to correctly interpret FORWARD TSN chunks and skip past the messages the sender has decided not to transmit (or retransmit) anymore 🙈

that said, it is recommended that a limited number of standard partially reliable service definitions get standardized by the IETF. That way, designers of IETF application layer protocols can match what their upper layer protocols need to standard service definitions that a given SCTP implementation provides 🍓 One such definition, "timed reliability," is included in this document. Given the extensions in this document, other definitions can be standardized when the need comes up, without more changes to the on-the-wire protocol ✨

1.3. Benefits of PR-SCTP 💜

in this document, "Partial Reliable Stream Control Transmission Protocol (PR-SCTP)" is the name for SCTP as extended by this document 🎀

here are some of the perks of putting partially reliable data service into SCTP, aka the benefits of PR-SCTP 😭

  1. some application layer protocols can benefit from using one SCTP association to carry both reliable content (like text pages, billing and accounting information, and setup signaling) and unreliable content (like state that's very sensitive to timeliness, where sending a new packet beats re-sending an old one) 🌸 The unreliable side is described in [3].
  2. Partially reliable data traffic on PR-SCTP gets the same communication failure detection and protection as normal reliable SCTP data traffic 🛡️ That includes quickly detecting a failed destination address, failing over to an alternate destination address, and getting notified if the data receiver becomes unreachable 🔥
  3. Besides unordered, unreliable data transfer like UDP gives you, PR-SCTP can also do ordered, unreliable data transfer service 🦋
  4. PR-SCTP uses the same congestion control and congestion avoidance for all data traffic, whether reliable or partially reliable. This is super desirable since SCTP enforces TCP-friendliness (unlike UDP) 👑
  5. Thanks to SCTP's chunk bundling function, reliable and unreliable messages can be multiplexed over a single PR-SCTP association 🧚 That means fewer IP datagrams (and less network overhead) than sending these different types of data with separate protocols. Multiplexing also saves ports compared to using different ports for reliable and unreliable connections 🌈

2. Conventions 🎀

The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in BCP 14, RFC 2119 [1]. 📖

Comparisons and arithmetic on Transport Sequence Numbers (TSNs) are governed by the rules in Section 1.6 of RFC 2960 [2]. 🔢

3. Protocol Changes to support PR-SCTP 🔧

3.1. Forward-TSN-Supported Parameter For INIT and INIT ACK 🦋

the following new OPTIONAL parameter gets added to the INIT and INIT ACK chunks ✨

   Parameter Name                       Status     Type Value
   -------------------------------------------------------------
   Forward-TSN-Supported               OPTIONAL    49152 (0xC000)

at association initialization, the sender of the INIT or INIT ACK chunk MAY include this OPTIONAL parameter to tell its peer that it can support the Forward TSN chunk (see Section 3.3 for more details). The format of the parameter is below 💜

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Parameter Type = 49152     |  Parameter Length = 4         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  • Type: 16 bit u_int
    • 49152, indicating Forward-TSN-Supported parameter 🌟
  • Length: 16 bit u_int
    • Indicates the size of the parameter, i.e., 4 🎀

3.2. Forward Cumulative TSN Chunk Definition (FORWARD TSN) 🎀

okay bestie, here's the brand-new chunk type 🦋 It's giving "new feature unlocked" ✨

Chunk Type    Chunk Name
------------------------------------------------------
192 (0xC0)    Forward Cumulative TSN (FORWARD TSN)

This chunk is how the data sender tells the data receiver to move its cumulative received TSN point forward, because some of the missing TSNs belong to data chunks that SHOULD NOT be transmitted or retransmitted by the sender. 💅

The Forward Cumulative TSN chunk looks like this:

 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 = 192  |  Flags = 0x00 |        Length = Variable      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      New Cumulative TSN                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Stream-1              |       Stream Sequence-1       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\                                                               /
/                                                               \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Stream-N              |       Stream Sequence-N       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Chunk Flags: set to all zeros on transmit and ignored on receipt. Easy peasy 🌸

New Cumulative TSN: 32 bit u_int 🍓 This tells the data receiver the new cumulative TSN. When the receiver gets this value, it MUST consider any missing TSNs earlier than or equal to this value as received, and it MUST stop reporting them as gaps in any subsequent SACKs. no more fake gaps, bestie 🙈

Stream-N: 16 bit u_int 🧚 This field holds a stream number that was skipped by this FWD-TSN.

Stream Sequence-N: 16 bit u_int 💜 This field holds the sequence number for the stream that was skipped. It holds the largest stream sequence number in that skipped stream. The receiver of the FWD-TSN's can use the Stream-N and Stream Sequence-N fields to deliver any stranded TSN's that are still sitting on the stream re-ordering queues, which is so clever ✨ This field MUST NOT report TSN's corresponding to DATA chunks that are marked as unordered. For ordered DATA chunks this field MUST be filled in. 👑

3.3. Negotiation of Forward-TSN-Supported parameter 🫶

3.3.1. Sending Forward-TSN-Supported param in INIT

If an SCTP endpoint supports the FORWARD TSN chunk, then any time it sends an INIT during association establishment, it MAY include the Forward-TSN-supported parameter in the INIT chunk to tell its peer about it. 🦋

Here's the tea: if the endpoint chooses NOT to include the parameter, then it can never send or process a FORWARD TSN for the whole life of the association 🙅‍♀️ It MUST instead act as if it does NOT support the FORWARD TSN chunk, and it returns an ERROR to the peer whenever it gets a FORWARD TSN. 💀

3.3.2. Receipt of Forward-TSN-Supported parameter in INIT or INIT-ACK

When a receiver of an INIT spots a Forward-TSN-Supported parameter but doesn't support the Forward-TSN chunk type, it MUST follow the rules in Section 3.3.3 of RFC 2960 [2]. 🌈

When a receiver of an INIT-ACK spots a Forward-TSN-Supported parameter and it doesn't support the Forward-TSN chunk type, it MUST follow the rules in Section 3.3.3 of RFC 2960 [2]. 🌈

When a receiver of an INIT spots a Forward-TSN-Supported parameter and it does support the Forward-TSN chunk type, it MAY respond with a Forward-TSN-supported parameter in the INIT-ACK chunk. ⭐

Again, the same rule applies: if the endpoint chooses NOT to include the parameter, then it can never send or process a FORWARD TSN during the life of the association. It MUST instead act as if it does NOT support the FORWARD TSN chunk, returning an ERROR to the peer upon receipt of any FORWARD TSN. 🎀

When an endpoint that supports the FORWARD TSN chunk receives an INIT without the Forward-TSN-Supported Parameter, that endpoint:

  • MAY include the Forward-TSN-Supported parameter in the INIT-ACK,
  • SHOULD record the fact that the peer doesn't support the FORWARD TSN chunk,
  • MUST NOT send a FORWARD TSN chunk at any time during the association's life,
  • SHOULD inform the upper layer if the upper layer has asked for that notification. 🔥

3.3.3. Receipt of Op. Error for Forward-TSN-Supported Param

When an SCTP endpoint that wants to use the FORWARD TSN chunk feature for partially reliable data transfer gets an operational error from the remote endpoint (either bundled with the COOKIE or as an unrecognized parameter in the INIT-ACK), and that error says the remote endpoint doesn't recognize the Forward-TSN-Supported parameter, the local endpoint SHOULD inform its upper layer that the remote endpoint can't support partially reliable data transfer. 😭

The local endpoint may then choose one of these:

  1. End the initiation process. (If the initiation process has already ended, the endpoint may need to send an ABORT.) It does this because the peer can't supply the requested features for the new association.
  2. Continue the initiation process, but with the understanding that partially reliable data transmission is not supported. (If the initiation process has already completed, the endpoint MUST just mark the association as not supporting partial reliability.) In this case, the endpoint that received the operational error SHOULD note that the FORWARD TSN chunk is not supported, and it MUST NOT transmit a FORWARD TSN chunk at any time during the life of the association. 🧚

3.4. Definition of "abandoned" in the context of PR-SCTP 🍓

At some point, a sending PR-SCTP implementation MAY decide that a particular data chunk SHOULD NOT be transmitted or retransmitted any further. That decision follows the rules of some specific PR-SCTP service definition, like the "timed reliability" one in Section 4.1. 🕰️ For this document, we define "abandoned" to mean any data chunk the SCTP sender has made this call on. 💖

Each PR-SCTP service defines the rules for deciding when a TSN is "abandoned," so the rules for how, whether, and when to "abandon" a TSN may vary from one service definition to another. Still, the rules for what happens once a TSN is "abandoned" do NOT vary between service definitions, and those rules live in Section 3.5. 💜

3.5. Sender Side Implementation of PR-SCTP ✨

okay so bestie, the sender side of PR-SCTP is basically the same as base SCTP 💅 except for three things:

  • what a sending PR-SCTP implementation has to do when a TSN gets "abandoned" (depending on whatever PR-SCTP service definition is in effect)
  • special moves it has to make when a SACK shows up
  • the rules for generating FORWARD TSN chunks

let's go through them 🦋

A1) The sender keeps an Advanced.Peer.Ack.Point for each peer, which is a theoretical cumulative TSN point for that peer 🧚 Note that this is a new protocol variable, and its value is NOT necessarily the same as the SCTP "Cumulative TSN Ack Point" from Section 1.4 of RFC 2960 [2] (and all the places that doc talks about it) 🙈

A2) From time to time, depending on the rules of a particular PR-SCTP service definition (see Section 4) 💅, the SCTP data sender may decide that a data chunk which has already been assigned a TSN SHOULD be "abandoned".

When a data chunk is "abandoned", the sender MUST treat it as finally acked and no longer outstanding 😭

The sender MUST NOT credit an "abandoned" data chunk to the partial_bytes_acked (as defined in Section 7.2.2 of RFC 2960 [2]), and it MUST NOT advance the cwnd based on this "abandoned" data chunk. no free growth from the ghosted ones, periodt 💀

A3) When a TSN is "abandoned" and it's part of a fragmented message, all other TSN's within that fragmented message MUST be abandoned at the same time 🫶

A4) Whenever the data sender receives a SACK from the data receiver, it MUST first process the SACK using the normal procedures in Section 6.2.1 of RFC 2960 [2] 🔥

The data sender MUST then do these extra steps:

C1) Let SackCumAck be the Cumulative TSN ACK carried in the received SACK. If (Advanced.Peer.Ack.Point < SackCumAck), then update Advanced.Peer.Ack.Point to be equal to SackCumAck. ✨

C2) Now try to push Advanced.Peer.Ack.Point further forward locally. Basically, keep moving it up as long as the chunk next in the out-queue space is marked "abandoned" 🏃‍♀️ Here's the example:

Assuming a SACK arrived with the Cumulative TSN ACK = 102, and Advanced.Peer.Ack.Point gets updated to that value:

out-queue at the end of  ==>   out-queue after Adv.Ack.Point
normal SACK processing         local advancement

             ...                            ...
Adv.Ack.Pt-> 102 acked                      102 acked
             103 abandoned                    103 abandoned
             104 abandoned        Adv.Ack.P-> 104 abandoned
             105                            105
             106 acked                      106 acked
             ...                            ...

so in this example, the data sender successfully moved Advanced.Peer.Ack.Point from 102 up to 104 locally 🌈

C3) If, after C1 and C2, Advanced.Peer.Ack.Point is greater than the Cumulative TSN ACK carried in the received SACK, the data sender MUST send the data receiver a FORWARD TSN chunk containing the latest value of Advanced.Peer.Ack.Point. Note that the sender MAY delay sending a FORWARD TSN, as defined in rule F2 below 🧁

IMPLEMENTATION NOTE: It's an implementation decision which destination address it gets sent to. The only restriction is that the address MUST be one that is CONFIRMED 🎀

C4) For each "abandoned" TSN, the sender of the FORWARD TSN MUST determine whether the chunk has a valid stream and sequence number (i.e., whether it was ordered). If the chunk does have a valid stream and sequence number, the sender MUST include that stream and sequence number in the FORWARD TSN. This info lets the receiver easily find any stranded TSN's waiting on stream reorder queues, which is so helpful 🧚

Each stream SHOULD only be reported once. So if multiple abandoned messages show up in the same stream, only the highest abandoned stream sequence number gets reported 💅

If the total size of the FORWARD TSN does NOT fit in a single MTU, the sender of the FORWARD TSN SHOULD lower Advanced.Peer.Ack.Point to the last TSN that will fit in a single MTU 📦

C5) If a FORWARD TSN is sent, the sender MUST assure that at least one T3-rtx timer is running 💜

IMPLEMENTATION NOTE: Any destination's timer may be used for the purposes of rule C5 ⏰

A5) Any time the T3-rtx timer expires, on any destination, the sender SHOULD try to advance Advanced.Peer.Ack.Point by following the procedures outlined in C2 - C5 🔁

The following additional rules govern how FORWARD TSN chunks get generated 🎀

F1) An endpoint MUST NOT use the FORWARD TSN for any purposes other than the circumstances described in this document 🙅‍♀️

F2) The data sender SHOULD always attempt to bundle an outgoing FORWARD TSN with outbound DATA chunks, for efficiency 🍓

A sender MAY even choose to delay sending the FORWARD TSN in the hope of bundling it with an outbound DATA chunk 🤞

IMPLEMENTATION NOTE: An implementation may wish to limit the number of duplicate FORWARD TSN chunks it sends, either by only sending a duplicate FORWARD TSN every other SACK, or by waiting a full RTT before sending a duplicate FORWARD TSN 🌸

IMPLEMENTATION NOTE: An implementation may allow the maximum delay for generating a FORWARD TSN to be configured either statically or dynamically, so it can meet the specific timing requirements of the protocol being carried. But see the next rule 👀

F3) Any delay applied to sending a FORWARD TSN chunk SHOULD NOT exceed 200ms and MUST NOT exceed 500ms. In other words, an implementation MAY lower this value below 500ms, but it MUST NOT raise it above 500ms ⏱️

NOTE: Delaying the sending of FORWARD TSN chunks may cause delays in the receiver's ability to deliver other data being held at the receiver for re-ordering. The values of 200ms and 500ms match the required values for the delayed acknowledgement in RFC 2960 [2], since delaying a FORWARD TSN has the same consequences, just in the reverse direction 🔄

F4) The detection criterion for out-of-order SACKs MUST remain the same as stated in RFC 2960. That is, a SACK is only considered out-of-order if the Cumulative TSN ACK carried in the SACK is earlier than that of the previous received SACK (i.e., the comparison MUST NOT be made against Advanced.Peer.Ack.Point) 🧐

F5) If the decision to "abandon" a chunk is made, no matter how that decision was reached, the appropriate congestion adjustment MUST be made as specified in RFC 2960 if the chunk would have been marked for retransmission later (e.g., either by T3-Timeout or by Fast Retransmit). this one's a lowkey big deal for keeping the network happy 🌙

3.6. Receiver Side Implementation of PR-SCTP 🎀

okay so the receiver side at endpoint A can handle any PR-SCTP service definition that the sender at endpoint B uses, even if host A's own sending side doesn't support that service 🫶 the receiver just has to handle the Forward-TSN-Supported parameter (see Section 3.3) and handle incoming FORWARD TSN chunks the way described below. that's literally it, no cap ✨

DATA chunk arrival at a PR-SCTP receiver works exactly like it does at a base protocol SCTP receiver. the receiver MUST do the same TSN handling, including duplicate detection, gap detection, SACK generation, cumulative TSN advancement, and so on, as defined in RFC 2960 [2], with the following exceptions and additions 💅

When a FORWARD TSN chunk shows up, the data receiver MUST first bump its cumulative TSN point to the value carried in the chunk, and then MUST further advance its cumulative TSN point locally if it can. here's an example, bestie 🦋

Assuming that the new cumulative TSN carried in the arrived FORWARD TSN is 103:

       in-queue before processing      in-queue after processing
            the FORWARD TSN      ==>   the FORWARD TSN and further
                                                advancement

       cum.TSN.Pt-> 102 received                   102 --
                    103 missing                    103 --
                    104 received                   104 --
                    105 received      cum.TSN.Pt-> 105 received
                    106 missing                    106 missing
                    107 received                   107 received
                    ...                            ...

In this example, the receiver's cumulative TSN point is first updated to 103 and then further advanced to 105. the way it just skipped right past the gap 🌸

After all that processing, the data receiver MUST stop reporting any missing TSNs earlier than or equal to the new cumulative TSN point. no more nagging about stuff that's already been skipped 🙈

Note, if the "New Cumulative TSN" value carried in the arrived FORWARD TSN chunk turns out to be behind or at the current cumulative TSN point, the data receiver MUST treat this FORWARD TSN as out-of-date and MUST NOT update its Cumulative TSN. the receiver SHOULD send a SACK to its peer (the sender of the FORWARD TSN), because a repeat like this might mean the previous SACK got lost in the network 💜

Any time a FORWARD TSN chunk arrives, the receiver MUST follow the same rules it would follow if a DATA chunk had arrived, for the purposes of sending a SACK. so it follows the delayed SACK rules in RFC 2960 [2] section 6.2 🍓

Whenever a DATA chunk arrives with the 'U' bit set to '0' (indicating ordered delivery) and it's out of order, the receiver must hold the chunk for reordering. here's the tricky part: with PR-SCTP, a DATA chunk that everybody's waiting on might never get retransmitted, so a FORWARD TSN needs some extra special handling 😭

In particular, while processing a FORWARD TSN, the receiver MUST use the stream sequence information to check all of the listed stream reordering queues, and immediately make available for delivery any stream sequence numbers earlier than or equal to the stream sequence number listed inside the FORWARD TSN. any stranded data SHOULD be made available to the upper layer application right away, so nothing just sits there rotting 🧚

An application using PR-SCTP to receive data should be aware that messages might be missing. the stream sequence number can be used to figure out that an intervening message got skipped. when messages are missing, it's up to the application to decide whether to process what it has or take some other corrective action 🌈

After receiving and processing a FORWARD TSN, the data receiver MUST be careful when it updates its re-assembly queue. the receiver MUST remove any partially reassembled message that's still missing one or more TSNs earlier than or equal to the new cumulative TSN point. if the receiver has used the partial delivery API, a notification SHOULD also be generated to tell the upper layer API that the partially delivered message will NOT be completed 🥺

Note that after receiving a FORWARD TSN and moving the cumulative acknowledgement point forward, a TSN that got skipped might still show up later (because of network reordering). in that case the receiver follows the normal RFC 2960 [2] rules for duplicate data. that means it drops the chunk and reports it as a duplicate in the next outbound SACK chunk 🫠

4. Services provided by PR-SCTP to the upper layer ✨

As described in Section 1.2, you can build a bunch of different partially reliable transport services using the new protocol mechanisms from Section 3. introducing these new services only requires changes at the sending side API and the sending side protocol implementation 🔥 so there may be a temptation to standardize only the protocol and leave the service definition as "implementation specific" or leave it to "informational" documents, you know? 👀

However, for people who want to write IETF standards for upper layer protocols running over PR-SCTP, it's important to be able to point at a standard definition of the services provided. so this section gives an example definition of one such service, plus guidelines for defining additional services as needed. each of those services may be proposed as a separate new RFC 💖

Section 4 is organized as follows:

  • Section 4.1 provides the definition of one specific PR-SCTP service: timed reliability.
  • Section 4.2 describes how a particular PR-SCTP service definition is requested by the upper layer during association establishment, and how the upper layer is notified if that request cannot be satisfied.
  • Section 4.3 then provides guidelines for the specification of PR-SCTP services other then the one defined in this memo.
  • Finally, Section 4.4 describes some additional usage notes that upper layer protocol designers and implementors may find helpful.

4.1. PR-SCTP Service Definition for "timed reliability" 🦋

The "timed reliability" service is a natural extension of the "lifetime" concept that's already in the base SCTP protocol. it's giving continuity 💅

When this service is requested for an SCTP association, it changes the meaning of the lifetime parameter specified in the SEND primitive (see Section 10.1, part (E) of RFC 2960 [2]; note that the parameter is spelled "life time" in that document) 🎀

In the base SCTP protocol, the lifetime parameter is used to avoid sending stale data. when a lifetime value is set for a particular message and that lifetime expires, SCTP cancels sending the message and notifies the ULP if the first transmission never happened (because of rwnd or cwnd limitations, or for any other reason). however, in the base protocol, if SCTP already sent the first transmission before the lifetime expired, then the message MUST be sent as a normal reliable message. during congestion this is really unfortunate, because retransmitting wastes bandwidth that could have gone to other messages whose lifetime hasn't expired 😩

When the "timed reliability" service is invoked, that last restriction goes away. specifically, when "timed reliability" is in effect, the following rules govern all messages that are sent with a lifetime parameter 🌸

TR1) If the lifetime parameter of a message is SCTP_LIFETIME_RELIABLE (or unspecified see Section 5), that message is treated as a normal reliable SCTP message, just like in the base SCTP protocol. ✨

TR2) If the lifetime parameter is not SCTP_LIFETIME_RELIABLE (see Section 5), then the SCTP sender MUST treat the message just as if it were a normal reliable SCTP message, as long as the lifetime has not yet expired. 💜

TR3) Before assigning a TSN to any message, the SCTP sender MUST evaluate the lifetime of that message. if it's expired, the SCTP sender MUST NOT assign a TSN to that message, but instead, SHOULD issue a notification to the upper layer and abandon the message. 🙈

TR4) Before transmitting or retransmitting a message for which a TSN is already assigned, the SCTP sender MUST evaluate the lifetime of the message. if the lifetime of the message has expired, the SCTP sender MUST "abandon" the message, as per the rules in Section 3.5, marking that TSN as eligible for forward TSN. this meets requirement G1 from Section 4.3. IMPLEMENTATION NOTE: An implementation SHOULD delay TSN assignment as mentioned in RFC 2960 [2] Section 10.1. in that case, the lifetime parameter should be checked BEFORE assigning a TSN, so a message can be abandoned without needing to send a FORWARD TSN 🧚

TR5) The sending SCTP MAY evaluate the lifetime of messages at anytime. expired messages that have not been assigned a TSN MAY be handled as per rule TR3. expired messages that HAVE been assigned a TSN MAY be handled as per rule TR4. 🌈

TR6) The sending application MUST NOT change the lifetime parameter once the message is passed to the sending SCTP. 🫶

Implementation Note: Rules TR1 through TR4 are designed so the implementer doesn't have to keep a separate timer for each message. instead, the lifetime only needs to be checked at points in the message's life where actions are already happening, like TSN assignment, transmission, or a retransmission timeout expiring. Rule TR5 gives the SCTP implementor flexibility to check lifetime at any other convenient moment, WITHOUT requiring that lifetime be checked right at the instant it expires 🥹

4.2. PR-SCTP Association Establishment 💖

okay so, a ULP (upper layer protocol) that uses PR-SCTP may need to know whether PR-SCTP can even work on a given association 🧐 which means the ULP needs some sign of whether its peer supports the FORWARD-TSN chunk. no cap, this matters!!

Section 10.1 of RFC 2960 [2] describes abstract primitives for the ULP-to-SCTP interface, and it notes that "individual implementations must define their own exact format, and may provide combinations or subsets of the basic functions in single calls." ✨

In this section we add one extra return value to the ASSOCIATE primitive so an SCTP service user can tell whether its peer supports the FORWARD-TSN chunk. it's giving clean API design 🎀

RFC 2960 says that the ASSOCIATE primitive "allows the upper layer to initiate an association to a specific peer endpoint". Its format looks like this:

Format: ASSOCIATE(local SCTP instance name, destination transport
      addr, outbound stream count)
-> association id [,destination transport addr list]
   [,outbound stream count]

This extension adds one new OPTIONAL return value, so the updated primitive reads:

Format: ASSOCIATE(local SCTP instance name, destination transport
      addr, outbound stream count )
-> association id [,destination transport addr list]
   [,outbound stream count] [,forward tsn supported]
NOTE: As per RFC 2960, if the ASSOCIATE primitive is implemented as a non-blocking call, the new OPTIONAL return value shall be passed with the association parameters using the COMMUNICATION UP notification. 🙈

The new OPTIONAL parameter "forward tsn supported" is a boolean flag, and it has two values:

  • (0) false [default] indicates that FORWARD TSN is not enabled by both endpoints.
  • (1) true indicates that FORWARD TSN is enabled on both endpoints.

We also add a new primitive so the user application can enable or disable the PR-SCTP service on its endpoint before an association is set up. 🦋

Format: ENABLE_PRSCTP(local SCTP instance name, boolean enable)

If the boolean parameter enable is set to true, PR-SCTP gets turned on for future endpoint associations. If it's set to false, the local endpoint stops advertising PR-SCTP support, so the feature is disabled on future associations. It is recommended that this option be disabled by default, so to turn PR-SCTP on, the user has to call this API option with the enable flag set to "true". 💅

4.3. Guidelines for defining other PR-SCTP Services 🧚

other PR-SCTP services can be defined and implemented whenever upper layer protocols need something different. 🌈 If those ULPs are going to be standardized and need a PR-SCTP service other than the one defined in this document (that's "timed reliability"), then those extra services should also be specified and standardized in a new RFC.

any new service definition should be modeled after Section 4.1, and in particular it should provide:

  1. A description of how the service user specifies any parameters tied to a particular message (and/or any other communication between the application and the SCTP transport sender). These give the sender the info it needs to decide when to give up on sending that message.

Preferably, this description should reference the primitives in the abstract API from Section 10 of RFC 2960 [2], and say whether there are any:

  • changes to the interpretation of existing parameters of existing primitives,
  • additional parameters added to existing primitives (these should be OPTIONAL, and default values should be indicated),
  • additional primitives that may be needed.
  1. A description of the rules the sender side implementation uses to decide when to give up on messages that haven't been assigned a TSN yet. It should also say which protocol events trigger the check, and what actions to take (for example, notifications).
  2. A description of the rules the sender side implementation uses to decide when to give up on transmitting or retransmitting messages that already have a TSN, and that may have been sent and possibly retransmitted zero or more times. 🫶

Items (2) and (3) above should also say which protocol events trigger the evaluation, and what actions to take if the sender decides to give up on the message (for example, notifications to the ULP).

Note that in any PR-SCTP service, the following rule MUST be specified to avoid a protocol deadlock: 🔥

  • (G1) When the sender side implementation gives up on transmitting a message that has been assigned a TSN (in other words, when that message is "abandoned", as defined in Section 3.4), the sender side MUST mark that TSN as eligible for forward TSN, and the rules in Section 3.4 regarding the sending of FORWARD TSN chunks MUST be followed.

Last thing: a PR-SCTP service definition should specify a "canonical service name" that uniquely identifies the service and tells it apart from other PR-SCTP services 👑 ULP standards can use that name to say which PR-SCTP service definition they need, and PR-SCTP API docs can use it to show how an upper layer picks which definition applies. The canonical service name for the PR-SCTP service in Section 4.1 is "timed reliability". ⭐

4.4. Usage Notes 📝

detecting missing data in a PR-SCTP stream is super useful for some apps (like Fibre channel or SCSI over IP) 🍓 With PR-SCTP it's now possible: the upper layer just has to look at the stream sequence number of the arrived user messages in that stream to spot any missing data. Heads up, though: this detection only works when all the messages on that stream are sent in order, meaning the U bit is not set. 🙈

5. Variables 🎀

This section defines a variable used throughout this document:

SCTP_LIFETIME_RELIABLE - A user interface indication defined by an implementation and used to indicate when a message is to be considered fully reliable.

6. Acknowledgments 🫶

The authors would like to thank Brian Bidulock, Scott Bradner, Jon Berger, Armando L. Caro Jr., John Loughney, Jon Peterson, Ivan Arias Rodriguez, Ian Rytina, Chip Sharp, and others for their comments. ✨

7. Security Considerations 💀

This document does not introduce any new security concerns to SCTP other than the ones already documented in RFC 2960 [2]. In particular, this document shares the same security issues as unordered data within RFC 2960 [2] identified by RFC 3436 [4]. An application using the PR-SCTP extension should not use transport layer security; further details can be found in RFC 3436 [4].

Note that the ability to cause a message to be skipped (i.e., the FORWARD TSN chunk) does not provide any new attack for a Man-In-the-Middle (MIM), since the MIM is already capable of changing and/or withholding data, thus effectively skipping messages. However, the FORWARD TSN chunk does provide a mechanism to make it easier for a MIM to skip selective messages when the application has this feature enabled, since the MIM would have less state to maintain. 😭 this one is the spicy part, bestie, so pay attention!!

8. IANA Considerations 📋

IANA has assigned 192 as a new chunk type to SCTP. 🌸

IANA has assigned 49152 as a new parameter type code to SCTP. 🌸

9. References 📚

9.1. Normative References

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

[2] 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.

9.2. Informative References

[3] Clark, D. and D. Tennenhouse, "Architectural Considerations for a New Generation of Protocols", SIGCOMM 1990 pp. 200-208, September 1990.

[4] Jungmaier, A., Rescorla, E. and M. Tuexen, "Transport Layer Security over Stream Control Transmission Protocol", RFC 3436, December 2002.

10. Authors' Addresses 🌟

Here are the authors and how to reach them, bestie 💌

Randall R. Stewart:

Randall R. Stewart
Cisco Systems, Inc.
8725 West Higgins Road
Suite 300
Chicago, IL  60631
USA

Phone: +1-815-477-2127
EMail: rrs@cisco.com

Michael A. Ramalho:

Michael A. Ramalho
Cisco Systems, Inc.
1802 Rue de la Porte
Wall Township, NJ  07719-3784
USA

Phone: +1.732.449.5762
EMail: mramalho@cisco.com

Qiaobing Xie:

Qiaobing Xie
Motorola, Inc.
1501 W. Shure Drive, #2309
Arlington Heights, IL  60004
USA

Phone: +1-847-632-3028
EMail: qxie1@email.mot.com

Michael Tuexen:

Michael Tuexen
Univ. of Applied Sciences Muenster
Stegerwaldstr. 39
48565 Steinfurt
Germany

EMail: tuexen@fh-muenster.de

Phillip T. Conrad:

Phillip T. Conrad
University of Delaware
Department of Computer and Information Sciences
Newark, DE  19716
USA

Phone: +1 302 831 8622
EMail: conrad@acm.org
URI:   `http://www.cis.udel.edu/~pconrad`

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