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

[Ballot discuss]
Substantive:

>    At the initialization of the association, the sender of the INIT or
>    INIT ACK chunk shall include this OPTIONAL parameter to inform its
>    peer that it is able to support the Forward TSN chunk. The format of
>    this parameter is defined as follows:

Could be more clear. Is the INIT required to include it? Does the INIT
ACK only include it if the INIT did? I.e, Don't both sides need to
explicitly signal this capability before either side can use it?

Actually, this is made more clear later:

>    When an endpoint that supports the FORWARD TSN chunk receives an INIT
>    that does not contain the Forward-TSN-Supported Parameter, that
>    endpoint:
>
>    o  MAY include the Forward-TSN-Supported parameter in the INIT-ACK,
>
>    o  SHOULD record the fact that the peer does not support the FORWARD
>      TSN chunk,
>
>    o  MUST NOT send a FORWARD TSN chunk at any time during the
>      associations life,
>
>    o  SHOULD inform the upper layer, if the upper layer has requested
>      such notification.

But these rules seem odd (to me). Why would the ACK include the
Forward-TSN-supported if the INIT doesn't? Seems completely useless.
Second should is rather obvious. You need to record whether the other
side implements (if you do), so you know if you can send or not.

then...

> 7. Security Considerations
>
>    This document does not introduce any new security concerns to SCTP
>    other than the ones already documented in RFC2960 [3]. In particular
>    this document shares the same security issues as unordered data
>    within RFC2960 [3] identified by RFC3436 [5]. An application using
>    the PR-SCTP extension should not use transport layer security;
>    further details can be found in RFC3436 [5].

This option provides new way for a MITM (or other intruder) to
interfere with the packet flow. But this is the case in general
already, so the question is whether this makes things any worse than
things alread are.

I wonder about the following. If the sender SCTP indicates the
capability of supporting the new mode, and the receiver acknowledges
that it also supports the mode, _but_ neither the sender nor receiving
application (or maybe not both of them) requested the service, could
an intruder introduce messages that cause individual chunks to be
"abandoned" without either side noticing? This may not be a big attack
to worry about (compared to other types of attack), but it may be
preventable if:

  - it is only permitted if both SCTP endpoints negotiated the option

  - SCTP  only negotiates usage if the upper layer protocol has
    requested it do so.

Suggestion: make the following rules clear:

- INIT includes Forward-TSN-Supported only if application indicates
  it wants this feature
 
- INIT-ACK only includes Forward-TSN-Supported if it supports it AND
  upper layer application has requested its use, and in response to
  an INIT indicating support for the option.

>        Stream Sequence-N: 16 bit u_int
>
>          This field holds the sequence number associated with the stream
>          that was skipped. The stream sequence field holds the largest stream
>          sequence number in this stream being skipped.  The receiver of
>          the FWD-TSN's can use the Stream-N and Stream Sequence-N fields
>          to enable delivery of any stranded TSN's that remain on the stream
>          re-ordering queues. This field MUST NOT report TSN's corresponding
>          to DATA chunk that are marked as unordered. For ordered DATA
>          chunks this field MUST be filled in.

There seems to be an interesting edge case here. Suppose a data chunk
has been received, but not handed upwards, due to a missing sequence
number. But then a Forward-TSN arrives basically saying "we don't care
about this sequence number anymore". Should the receiver discard it?
(that would be correct behavior semantically -- the sender has
concluded it is no longer timely). Or it should it forward it up the
stack, since it has the data already. This document doesn't seem to
say what to do in this case. Indeed, the wording above might be
confusing as it talks about "enable delivery of stranded TSN".  I
assume this is NOT about the case I just described (but is that clear)
and is really trying to say that if the Forward-TSN moves the sequence
number to X, and chunk X has already been received, it can now be
handed upwards and the received sequence numbers adjusted
accordingly. It might be good to clarify these two points.


>      C3) If, after step C1 and C2, the "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 the
>          "Advanced.Peer.Ack.Point".
>
>          IMPLEMENTATION NOTE: It is an implemenation decision as to
>          which destination address is to be sent to, the only
>          restriction being that the address MUST be one that is
>          CONFIRMED.

Are there any corner cases here like if the a chunk is abandoned less
than one RTT after it was first queued? I.e., the above MUST might
lead to situations where you get several incoming SACKs that cause a
corresponding resent of the Forward-TSN chunk.

Actually, the somewhate MUST is contradicted later by MAYs, i.e.:

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

Maybe tweak the earlier wording with a pointer to the later text?

>    The new OPTIONAL parameter "forward tsn supported" is a boolean flag:
>
>    (0) false [default] indicates that FORWARD TSN is not supported by
>      the peer.
>
>    (1) true indicates that FORWARD TSN is supported by the peer.

Maybe a minor point, but shouldn't the semantics of this be "supported
by both sender and receiver"? That's what you care about, and if the
sender doesn't support this, it matters not if the peer does. Or, is
there some other way the sender determines whether the sending SCTP
supports this and  it is only allowed to request the feature if it
already knows its supported on the sender?

>    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 is expired, the SCTP
>      sender MUST "abandon" the message, as per the rules specified in
>      Section 3.5 marking that TSN as eligible for forward TSN. Note
>      that this meets the requirement G1 defined in Section 4.3

I think TR4 should be split into two cases. In the case that a message
has not been transmitted yet, there is no need for "abandoning" the
messages as per this document. It can be handled using the previous
technique. This is important, because it means no messages go out on
the wire. Its only if the message has been transmitted once that one
needs to abandon...

Also, I think there should be some text/rules that say how to handle
the case of transmitting a DATA chunk (for the first time) it if is
clear that it would be scheduled for abandonment _before_ the RTT will
expire. I.e., its guaranteed to be "old" before the ACK comes
back. Naive implementations that don't think about this might do dumb
things. I don't think much text is needed, but it woudl be good to
notify implementors of the issue and what they should do about it.

[Ballot comment]
Nits:

>    Hereafter, we use the notation "PR-SCTP" to refer to the SCTP
>    protocol extended as defined in this document.

Spell out "partially reliable" above so folk make the connection with
PR.

>    Comparisons and arithmetic on TSNs are governed by the rules in
>    Section 1.6 of RFC2960 [3].

expand TSN on first usage.

>  services as required.  Each such service may be proposed as a
>  separate new informational RFC.

Better to drop "informational". Point is to publish each one as
separate document. The exact type of document doesn't need to be
specified here, though I suspect info will be the normal case. But it
isn't a requirement.

same comment applies elsewhere in document.


>    Rodriguez, Ian Rytina, Chip Sharp, and others for their comment.s

s/.s/s./

>    When a receiver of an INIT detects a Forward-TSN-Supported parameter,
>    and does not support the Forward-TSN chunk type, the receiver SHOULD
>    treat this parameter as an invalid or unrecognized parameter and
>    respond to the data sender with an unrecognized parameter in the
>    INIT-ACK, following the rules defined in Section 3.3.3 of RFC2960
>    [3].
>
>    When a receiver of an INIT-ACK detects a Forward-TSN-Supported
>    parameter, and does not support the Forward-TSN chunk type, the
>    receiver SHOULD treat this parameter as an invalid or unrecognized
>    parameter and respond to the data sender with an unrecognized
>    parameter error, following the rules defined in Section 3.3.3 of
>    RFC2960 [3]. This error SHOULD be reported in an ERROR chunk bundled
>    with the COOKIE-ECHO.

Seems odd for this document to seem to be saying what to do if you
don't understand the new extensions (that is what I intepret when I
see MUST langague like the above). I suspect the text that is here is
just being copied verbatim from the base SCTP spec. It would be better
to make to make it clear that this is already the required behavior
per 2960, and either quote the text (for info) or just point to the
other document.

[Ballot discuss]
Substantive:

>    At the initialization of the association, the sender of the INIT or
>    INIT ACK chunk shall include this OPTIONAL parameter to inform its
>    peer that it is able to support the Forward TSN chunk. The format of
>    this parameter is defined as follows:

Could be more clear. Is the INIT required to include it? Does the INIT
ACK only include it if the INIT did? I.e, Don't both sides need to
explicitly signal this capability before either side can use it?

Actually, this is made more clear later:

>    When an endpoint that supports the FORWARD TSN chunk receives an INIT
>    that does not contain the Forward-TSN-Supported Parameter, that
>    endpoint:
>
>    o  MAY include the Forward-TSN-Supported parameter in the INIT-ACK,
>
>    o  SHOULD record the fact that the peer does not support the FORWARD
>      TSN chunk,
>
>    o  MUST NOT send a FORWARD TSN chunk at any time during the
>      associations life,
>
>    o  SHOULD inform the upper layer, if the upper layer has requested
>      such notification.

But these rules seem odd (to me). Why would the ACK include the
Forward-TSN-supported if the INIT doesn't? Seems completely useless.
Second should is rather obvious. You need to record whether the other
side implements (if you do), so you know if you can send or not.

then...

> 7. Security Considerations
>
>    This document does not introduce any new security concerns to SCTP
>    other than the ones already documented in RFC2960 [3]. In particular
>    this document shares the same security issues as unordered data
>    within RFC2960 [3] identified by RFC3436 [5]. An application using
>    the PR-SCTP extension should not use transport layer security;
>    further details can be found in RFC3436 [5].

This option provides new way for a MITM (or other intruder) to
interfere with the packet flow. But this is the case in general
already, so the question is whether this makes things any worse than
things alread are.

I wonder about the following. If the sender SCTP indicates the
capability of supporting the new mode, and the receiver acknowledges
that it also supports the mode, _but_ neither the sender nor receiving
application (or maybe not both of them) requested the service, could
an intruder introduce messages that cause individual chunks to be
"abandoned" without either side noticing? This may not be a big attack
to worry about (compared to other types of attack), but it may be
preventable if:

  - it is only permitted if both SCTP endpoints negotiated the option

  - SCTP  only negotiates usage if the upper layer protocol has
    requested it do so.

Suggestion: make the following rules clear:

- INIT includes Forward-TSN-Supported only if application indicates
  it wants this feature
 
- INIT-ACK only includes Forward-TSN-Supported if it supports it AND
  upper layer application has requested its use, and in response to
  an INIT indicating support for the option.

>        Stream Sequence-N: 16 bit u_int
>
>          This field holds the sequence number associated with the stream
>          that was skipped. The stream sequence field holds the largest stream
>          sequence number in this stream being skipped.  The receiver of
>          the FWD-TSN's can use the Stream-N and Stream Sequence-N fields
>          to enable delivery of any stranded TSN's that remain on the stream
>          re-ordering queues. This field MUST NOT report TSN's corresponding
>          to DATA chunk that are marked as unordered. For ordered DATA
>          chunks this field MUST be filled in.

There seems to be an interesting edge case here. Suppose a data chunk
has been received, but not handed upwards, due to a missing sequence
number. But then a Forward-TSN arrives basically saying "we don't care
about this sequence number anymore". Should the receiver discard it?
(that would be correct behavior semantically -- the sender has
concluded it is no longer timely). Or it should it forward it up the
stack, since it has the data already. This document doesn't seem to
say what to do in this case. Indeed, the wording above might be
confusing as it talks about "enable delivery of stranded TSN".  I
assume this is NOT about the case I just described (but is that clear)
and is really trying to say that if the Forward-TSN moves the sequence
number to X, and chunk X has already been received, it can now be
handed upwards and the received sequence numbers adjusted
accordingly. It might be good to clarify these two points.


>      C3) If, after step C1 and C2, the "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 the
>          "Advanced.Peer.Ack.Point".
>
>          IMPLEMENTATION NOTE: It is an implemenation decision as to
>          which destination address is to be sent to, the only
>          restriction being that the address MUST be one that is
>          CONFIRMED.

Are there any corner cases here like if the a chunk is abandoned less
than one RTT after it was first queued? I.e., the above MUST might
lead to situations where you get several incoming SACKs that cause a
corresponding resent of the Forward-TSN chunk.

Actually, the somewhate MUST is contradicted later by MAYs, i.e.:

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

Maybe tweak the earlier wording with a pointer to the later text?

>    The new OPTIONAL parameter "forward tsn supported" is a boolean flag:
>
>    (0) false [default] indicates that FORWARD TSN is not supported by
>      the peer.
>
>    (1) true indicates that FORWARD TSN is supported by the peer.

Maybe a minor point, but shouldn't the semantics of this be "supported
by both sender and receiver"? That's what you care about, and if the
sender doesn't support this, it matters not if the peer does. Or, is
there some other way the sender determines whether the sending SCTP
supports this and  it is only allowed to request the feature if it
already knows its supported on the sender?

>    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 is expired, the SCTP
>      sender MUST "abandon" the message, as per the rules specified in
>      Section 3.5 marking that TSN as eligible for forward TSN. Note
>      that this meets the requirement G1 defined in Section 4.3

I think TR4 should be split into two cases. In the case that a message
has not been transmitted yet, there is no need for "abandoning" the
messages as per this document. It can be handled using the previous
technique. This is important, because it means no messages go out on
the wire. Its only if the message has been transmitted once that one
needs to abandon...

Also, I think there should be some text/rules that say how to handle
the case of transmitting a DATA chunk (for the first time) it if is
clear that it would be scheduled for abandonment _before_ the RTT will
expire. I.e., its guaranteed to be "old" before the ACK comes
back. Naive implementations that don't think about this might do dumb
things. I don't think much text is needed, but it woudl be good to
notify implementors of the issue and what they should do about it.


Nits:

>    Hereafter, we use the notation "PR-SCTP" to refer to the SCTP
>    protocol extended as defined in this document.

Spell out "partially reliable" above so folk make the connection with
PR.

>    Comparisons and arithmetic on TSNs are governed by the rules in
>    Section 1.6 of RFC2960 [3].

expand TSN on first usage.

>  services as required.  Each such service may be proposed as a
>  separate new informational RFC.

Better to drop "informational". Point is to publish each one as
separate document. The exact type of document doesn't need to be
specified here, though I suspect info will be the normal case. But it
isn't a requirement.

same comment applies elsewhere in document.


>    Rodriguez, Ian Rytina, Chip Sharp, and others for their comment.s

s/.s/s./

>    When a receiver of an INIT detects a Forward-TSN-Supported parameter,
>    and does not support the Forward-TSN chunk type, the receiver SHOULD
>    treat this parameter as an invalid or unrecognized parameter and
>    respond to the data sender with an unrecognized parameter in the
>    INIT-ACK, following the rules defined in Section 3.3.3 of RFC2960
>    [3].
>
>    When a receiver of an INIT-ACK detects a Forward-TSN-Supported
>    parameter, and does not support the Forward-TSN chunk type, the
>    receiver SHOULD treat this parameter as an invalid or unrecognized
>    parameter and respond to the data sender with an unrecognized
>    parameter error, following the rules defined in Section 3.3.3 of
>    RFC2960 [3]. This error SHOULD be reported in an ERROR chunk bundled
>    with the COOKIE-ECHO.

Seems odd for this document to seem to be saying what to do if you
don't understand the new extensions (that is what I intepret when I
see MUST langague like the above). I suspect the text that is here is
just being copied verbatim from the base SCTP spec. It would be better
to make to make it clear that this is already the required behavior
per 2960, and either quote the text (for info) or just point to the
other document.

[Ballot comment]
From OPS Directorate (Pekka)

Nits
Abstract
  This memo describes an extension to the Stream Control Transmission
  Protocol (SCTP) RFC2960 [3] that allows an SCTP endpoint to signal to

==> remove the refs from the abstract.

  [1]  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
        9, RFC 2026, October 1996.
                                                                                                                                     
==> this can be removed, isn't even being used.

8. IANA Considerations
                                                                                                                                     
  One new chunk type is added to SCTP (192) by this document.
                                                                                                                                     
  One new parameter type code is defined by this document to be added
  to SCTP (49152).

==> well, technically, IANA is registering these codes and types, not
you guys :-).  So these should be reworded to be like: "IANA is
requested to assign a new chunk type to SCTP; using "192" is
recommended".  But I'm not sure if this is really needed :-)

    Rodriguez, Ian Rytina, Chip Sharp, and others for their comment.s
                                                                                                                                     
==> s/.s/s./

[Ballot comment]
Section 3.6 says:

  Whenever a DATA chunk arrives with the 'U' bit set to '0' (indicating
  ordered delivery) and is out of order, the receiver must hold the
  chunk for reordering. Since it is possible with PR-SCTP that a DATA
  chunk being waited upon will not be retransmitted, special actions
  will need to be taken upon the arrival of a FORWARD TSN.

  In particular, during processing of a FORWARD TSN, the receiver MUST
  use the stream sequence information to examine all of the listed
  stream reordering queues, and immediately make available for delivery
  stream sequence numbers earlier than or equal to the stream sequence
  number listed inside the FORWARD TSN.

Does the U bit here have a secondary expectation that when ordering is
requested, eventual delivery will be better than a drop?  If so, is there
any way to indicate that what you want is ordered delivery, but drop
CHUNKS not yet delivered if the FORWARD TSN is received?

In Section 4, can I suggest "standardized in an informational RFC." be replaced
with "documented in an Informational RFC?"  (By the way, would we object
to someone asking for standards track to one that had been specified in
a WG?)

Lastly, the document seems to make the design choice that using something
liked "timed reliability" is something that the sender decides based on
the availability of Forward TSN as a primitive, and that there is no sense in
which the receiver ought to decide whether to support Forward TSN based
on which of these PR-SCTP services it would be used with.  Fair enough, but
if there is motivational text laying about that could describe that design decision
process, it would be valuable to add it.  It's probably not worth the sweat of
cooking up, though, if it is not available already.

[Ballot comment]
Section 3.6 says:

  Whenever a DATA chunk arrives with the 'U' bit set to '0' (indicating
  ordered delivery) and is out of order, the receiver must hold the
  chunk for reordering. Since it is possible with PR-SCTP that a DATA
  chunk being waited upon will not be retransmitted, special actions
  will need to be taken upon the arrival of a FORWARD TSN.

  In particular, during processing of a FORWARD TSN, the receiver MUST
  use the stream sequence information to examine all of the listed
  stream reordering queues, and immediately make available for delivery
  stream sequence numbers earlier than or equal to the stream sequence
  number listed inside the FORWARD TSN.

Does the U bit here have a secondary expectation that when ordering is
requested, eventual delivery will be better than a drop?  If so, is there
any way to indicate that what you want is ordered delivery, but drop
CHUNKS not yet delivered if the FORWARD TSN is received?

[Ballot comment]
I didn't see any discussion about what a receiver should do if an abandoned TSN arrives after the abandonment message.  Is this a problem?