draft-ietf-tsvwg-prsctp-00.txt   draft-ietf-tsvwg-prsctp-01.txt 
Network Working Group R. Stewart Network Working Group R. Stewart
Internet-Draft M. Ramalho Internet-Draft M. Ramalho
Expires: December 17, 2003 Cisco Systems, Inc. Expires: February 20, 2004 Cisco Systems, Inc.
Q. Xie Q. Xie
Motorola, Inc. Motorola, Inc.
M. Tuexen M. Tuexen
Univ. of Applied Sciences Muenster Univ. of Applied Sciences Muenster
P. Conrad P. Conrad
Temple University Temple University
June 18, 2003 August 22, 2003
SCTP Partial Reliability Extension SCTP Partial Reliability Extension
draft-ietf-tsvwg-prsctp-00.txt draft-ietf-tsvwg-prsctp-01.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt. www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 17, 2003. This Internet-Draft will expire on February 20, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
This memo describes an extension to the Stream Control Transmission This memo describes an extension to the Stream Control Transmission
Protocol (SCTP) RFC2960 [5] that allows an SCTP endpoint to signal to Protocol (SCTP) RFC2960 [5] that allows an SCTP endpoint to signal to
its peer that it should move the cumulative ack point forward. When its peer that it should move the cumulative ack point forward. When
skipping to change at page 12, line 30 skipping to change at page 12, line 30
C3) If, after step C1 and C2, the "Advanced.Peer.Ack.Point" is C3) If, after step C1 and C2, the "Advanced.Peer.Ack.Point" is
greater than the Cumulative TSN ACK carried in the received greater than the Cumulative TSN ACK carried in the received
SACK, the data sender MUST send the data receiver a FORWARD TSN SACK, the data sender MUST send the data receiver a FORWARD TSN
chunk containing the latest value of the chunk containing the latest value of the
"Advanced.Peer.Ack.Point". "Advanced.Peer.Ack.Point".
C4) For each "abandoned" TSN the sender of the FORWARD TSN MUST C4) For each "abandoned" TSN the sender of the FORWARD TSN MUST
determine if the chunk has a valid stream and sequence number determine if the chunk has a valid stream and sequence number
(i.e., it was ordered). If the chunk has a valid stream and (i.e., it was ordered). If the chunk has a valid stream and
sequence number the sender MUST include the stream and sequence sequence number the sender MUST include the stream and sequence
number in the forwarded TSN. This information will enable the number in the FORWARD TSN. This information will enable the
receiver to easily find any stranded TSN's waiting on stream receiver to easily find any stranded TSN's waiting on stream
reorder queues. Each stream SHOULD only be reported once; this reorder queues. Each stream SHOULD only be reported once; this
means that if multiple abandoned messages occur in the same means that if multiple abandoned messages occur in the same
stream then only the highest abandoned stream sequence number stream then only the highest abandoned stream sequence number
is reported. If the total size of the FORWARD TSN does NOT fit is reported. If the total size of the FORWARD TSN does NOT fit
in a single MTU then the sender of the FORWARD TSN SHOULD lower in a single MTU then the sender of the FORWARD TSN SHOULD lower
the Advanced.Peer.Ack.Point to the last TSN that will fit in a the Advanced.Peer.Ack.Point to the last TSN that will fit in a
single MTU. single MTU.
C5) If a FORWARD TSN is sent, the sender MUST assure that at least C5) If a FORWARD TSN is sent, the sender MUST assure that at least
skipping to change at page 13, line 14 skipping to change at page 13, line 14
F1) An endpoint MUST NOT use the FORWARD TSN for any purposes other F1) An endpoint MUST NOT use the FORWARD TSN for any purposes other
than circumstances described in this document. than circumstances described in this document.
F2) The data sender SHOULD always attempt to bundle an outgoing F2) The data sender SHOULD always attempt to bundle an outgoing
FORWARD TSN with outbound DATA chunks for efficiency. FORWARD TSN with outbound DATA chunks for efficiency.
A sender MAY even choose to delay the sending of the FORWARD TSN A sender MAY even choose to delay the sending of the FORWARD TSN
in the hope of bundling it with an outbound DATA chunk. 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 by either only
sending a duplicate FORWARD TSN every other SACK or waiting a full
RTT before sending a duplicate FORWARD TSN.
IMPLEMENTATION NOTE: An implementation may allow the maximum delay IMPLEMENTATION NOTE: An implementation may allow the maximum delay
for generating a forward TSN to be configured either statically or for generating a FORWARD TSN to be configured either statically or
dynamically in order to meet the specific timing requirements of dynamically in order to meet the specific timing requirements of
the protocol being carried, but see the next rule: the protocol being carried, but see the next rule:
F3) Any delay applied to the sending of FORWARD TSN chunk SHOULD NOT F3) Any delay applied to the sending of FORWARD TSN chunk SHOULD NOT
exceed 200ms and MUST NOT exceed 500ms. In other words an exceed 200ms and MUST NOT exceed 500ms. In other words an
implementation MAY lower this value below 500ms but MUST NOT raise implementation MAY lower this value below 500ms but MUST NOT raise
it above 500ms. it above 500ms.
NOTE: Delaying the sending of FORWARD TSN chunks may cause delays NOTE: Delaying the sending of FORWARD TSN chunks may cause delays
in the receiver's ability to deliver other data being held at the in the receiver's ability to deliver other data being held at the
receiver for re-ordering. receiver for re-ordering.
F4) The detection criterion for out-of-order SACKs MUST remain the F4) The detection criterion for out-of-order SACKs MUST remain the
same as stated in RFC2960, that is, a SACK is only considered same as stated in RFC2960, that is, a SACK is only considered
out-of-order if the Cumulative TSN ACK carried in the SACK is out-of-order if the Cumulative TSN ACK carried in the SACK is
earlier than that of the previous received SACK (i.e., the earlier than that of the previous received SACK (i.e., the
comparison MUST NOT be made against "Advanced.Peer.Ack.Point"). comparison MUST NOT be made against "Advanced.Peer.Ack.Point").
F5 If a decision to "abandon" a chunk is made based on a F5) If the decision to "abandon" a chunk is made, no matter how such
retransmission decision (e.g T3-Timeout or Fast Retransmit) the a decision is made, the appropriate congestion adjustment MUST be
appropriate congestion adjustment as specified in RFC2960 MUST be made as specified in RFC2960 if the chunk would have been marked
made before any FORWARD TSN chunk is sent. for retransmission later (e.g. either by T3-Timeout or by Fast
Retransmit).
3.6 Receiver Side Implementation of PR-SCTP 3.6 Receiver Side Implementation of PR-SCTP
The receiver side implementation of PR-SCTP at an SCTP endpoint A is The receiver side implementation of PR-SCTP at an SCTP endpoint A is
capable of supporting any PR-SCTP service definition used by the capable of supporting any PR-SCTP service definition used by the
sender at endpoint B, even if that service definition is not sender at endpoint B, even if that service definition is not
supported by the sending side functionality of host A. All that is supported by the sending side functionality of host A. All that is
necessary is that the receiving side correctly handle the necessary is that the receiving side correctly handle the
Forward-TSN-Supported parameter as specified in Section 3.3, and Forward-TSN-Supported parameter as specified in Section 3.3, and
correctly handle the receipt of FORWARD TSN chunks as specified correctly handle the receipt of FORWARD TSN chunks as specified
skipping to change at page 14, line 36 skipping to change at page 14, line 42
107 received 107 received 107 received 107 received
... ... ... ...
In this example, the receiver's cumulative TSN point is first In this example, the receiver's cumulative TSN point is first
updated to 103 and then further advanced to 105. updated to 103 and then further advanced to 105.
After the above processing, the data receiver MUST stop reporting any After the above processing, the data receiver MUST stop reporting any
missing TSNs earlier than or equal to the new cumulative TSN point. missing TSNs earlier than or equal to the new cumulative TSN point.
Note, if the "New Cumulative TSN" value carried in the arrived Note, if the "New Cumulative TSN" value carried in the arrived
FORWARD TSN chunk is found to be behind the current cumulative TSN FORWARD TSN chunk is found to be behind or at the current cumulative
point, the data receiver MUST treat this FORWARD TSN as out-of-date TSN point, the data receiver MUST treat this FORWARD TSN as
and MUST NOT update its Cumulative TSN. The receiver SHOULD send a out-of-date and MUST NOT update its Cumulative TSN. The receiver
SACK to its peer (the sender of the FORWARD TSN) since such a SHOULD send a SACK to its peer (the sender of the FORWARD TSN) since
duplicate may indicate the previous SACK was lost in the network. such a duplicate may indicate the previous SACK was lost in the
network.
Any time a FORWARD TSN chunk arrives, for the purposes of sending a Any time a FORWARD TSN chunk arrives, for the purposes of sending a
SACK, the receiver MUST follow the same rules as if a DATA chunk had SACK, the receiver MUST follow the same rules as if a DATA chunk had
been received (i.e., follow the delayed sack rules specified in been received (i.e., follow the delayed sack rules specified in
RFC2960 [5] section 6.2). RFC2960 [5] section 6.2).
Whenever a DATA chunk arrives with the 'U' bit set to '0' (indicating 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 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 for reordering. Since it is possible with PR-SCTP that a DATA
chunk being waited upon will not be retransmitted, special actions chunk being waited upon will not be retransmitted, special actions
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/