One document matched: draft-tuexen-tsvwg-sctp-multipath-07.xml
<?xml version='1.0' encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd'>
<?rfc toc='yes'?>
<?rfc compact='yes' ?>
<?rfc subcompact='no' ?>
<?rfc strict='no' ?>
<?rfc symrefs='yes' ?>
<rfc category='exp'
ipr='trust200902'
docName='draft-tuexen-tsvwg-sctp-multipath-07.txt'>
<front>
<title abbrev='Loadsharing for SCTP'>
Load Sharing for the Stream Control Transmission Protocol (SCTP)
</title>
<author initials='P. D.' surname='Amer' fullname='Paul D. Amer'>
<organization abbrev='University of Delaware'>
University of Delaware,
Computer and Information Sciences Department</organization>
<address>
<postal>
<street></street>
<city>Newark</city>
<region>Delaware</region>
<code>19716</code>
<country>U.S.A.</country>
</postal>
<phone>+1-302-831-1944</phone>
<email>amer@cis.udel.edu</email>
<uri>http://www.eecis.udel.edu/~amer/</uri>
</address>
</author>
<author initials='M.' surname='Becke' fullname='Martin Becke'>
<organization abbrev='University of Duisburg-Essen'>
University of Duisburg-Essen,
Institute for Experimental Mathematics</organization>
<address>
<postal>
<street>Ellernstrasse 29</street>
<city>45326 Essen</city>
<region>Nordrhein-Westfalen</region>
<country>Germany</country>
</postal>
<phone>+49-201-183-7667</phone>
<facsimile>+49-201-183-7673</facsimile>
<email>martin.becke@uni-due.de</email>
<uri>http://www.scimbe.de/</uri>
</address>
</author>
<!-- ************** THOMAS DREIBHOLZ *************** -->
<author initials="T." surname="Dreibholz" fullname="Thomas Dreibholz">
<organization abbrev="Simula Research Laboratory">Simula Research
Laboratory, Network Systems Group</organization>
<address>
<postal>
<street>Martin Linges vei 17</street>
<city>1364 Fornebu</city>
<region>Akershus</region>
<country>Norway</country>
</postal>
<phone>+47-6782-8200</phone>
<facsimile>+47-6782-8201</facsimile>
<email>dreibh@simula.no</email>
<uri>http://www.iem.uni-due.de/~dreibh/</uri>
</address>
</author>
<author initials='N.' surname='Ekiz' fullname='Nasif Ekiz'>
<organization abbrev='University of Delaware'>
University of Delaware,
Computer and Information Sciences Department</organization>
<address>
<postal>
<street></street>
<city>Newark</city>
<region>Delaware</region>
<code>19716</code>
<country>U.S.A.</country>
</postal>
<email>nekiz@udel.edu</email>
<uri>http://www.eecis.udel.edu/~nekiz/</uri>
</address>
</author>
<author initials='J.' surname='Iyengar' fullname='Janardhan Iyengar'>
<organization abbrev='Franklin and Marshall College'>
Franklin and Marshall College,
Mathematics and Computer Science</organization>
<address>
<postal>
<street>PO Box 3003</street>
<city>Lancaster</city>
<region>Pennsylvania</region>
<code>17604-3003</code>
<country>U.S.A.</country>
</postal>
<phone>+1-717-358-4774</phone>
<email>jiyengar@fandm.edu</email>
<uri>http://www.fandm.edu/jiyengar/</uri>
</address>
</author>
<author initials='P.' surname='Natarajan' fullname='Preethi Natarajan'>
<organization>Cisco Systems</organization>
<address>
<postal>
<street>425 East Tasman Drive</street>
<city>San Jose</city>
<region>California</region>
<code>95134</code>
<country>U.S.A.</country>
</postal>
<email>prenatar@cisco.com</email>
</address>
</author>
<author initials='R. R.' surname='Stewart' fullname='Randall R. Stewart'>
<organization>Adara Networks</organization>
<address>
<postal>
<street></street>
<city>Chapin</city>
<region>South Carolina</region>
<code>29036</code>
<country>U.S.A.</country>
</postal>
<email>randall@lakerest.net</email>
</address>
</author>
<author initials='M.' surname='Tuexen' fullname='Michael Tuexen'>
<organization abbrev='Muenster Univ. of Appl. Sciences'>
Muenster University of Applied Sciences</organization>
<address>
<postal>
<street>Stegerwaldstrasse 39</street>
<city>48565 Steinfurt</city>
<region>Nordrhein-Westfalen</region>
<country>Germany</country>
</postal>
<email>tuexen@fh-muenster.de</email>
<uri>https://www.fh-muenster.de/fb2/personen/professoren/tuexen/</uri>
</address>
</author>
<date />
<keyword>Internet-Draft</keyword>
<abstract>
<t>The Stream Control Transmission Protocol (SCTP) supports multi-homing for
providing network fault tolerance. However, mainly one path is used for data
transmission. Only timer-based retransmissions are carried over other paths
as well.</t>
<t>This document describes how multiple paths can be used simultaneously for
transmitting user messages.</t>
</abstract>
</front>
<middle>
<section anchor='intro'
title='Introduction'>
<t>One of the important features of the Stream Control Transmission Protocol
(SCTP), which is currently specified in <xref target='RFC4960'/>, is network
fault tolerance. This feature is for example required for Reliable Server
Pooling (RSerPool, <xref target='RFC5351'/>). Therefore, transmitting
messages over multiple paths is supported, but only for redundancy. So
<xref target='RFC4960'/> does not specify how to use multiple paths
simultaneously.</t>
<t>This document overcomes this limitation by specifying how multiple paths
can be used simultaneously. This has several benefits:
<list style='symbols'>
<t>Improved bandwidth usage.</t>
<t>Better availability check with real user messages compared to
HEARTBEAT-based information.</t>
</list></t>
</section>
<section anchor='conv'
title='Conventions' >
<t>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 <xref target='RFC2119'/>.</t>
</section>
<section anchor='CMT-SCTP'
title='Load Sharing' >
<t>Basic requirement for applying SCTP load sharing is the Concurrent
Multipath Transfer (CMT) extension of SCTP, which utilises multiple
paths simultaneously. We denote CMT-enabled SCTP as CMT-SCTP throughout
this document. CMT-SCTP is introduced in <xref target='IAS06'/>
and in more detail in <xref target='I06'/>,
some illustrative examples of chunk handling are provided in
<xref target='DBP10a'/>.
CMT-SCTP provides three modifications to standard SCTP (split Fast
Retransmissions, appropriate congestion window growth and delayed
SACKs), which are described in the following subsections.</t>
<section title='Split Fast Retransmissions' anchor='splitfastrtx'>
<t>Paths with different latencies lead to overtaking of DATA chunks.
This leads to gap reports, which are handled by Fast Retransmissions.
However, due to the fact that multiple paths are used simultaneously,
these Fast Retransmissions are usually useless and furthermore lead to a
decreased congestion window size.</t>
<t>To avoid unnecessary Fast Retransmissions, the sender has to keep
track of the path each DATA chunk has been sent on and consider
transmission paths before performing Fast Retransmissions. That is, on
reception of a SACK, the sender MUST identify the highest acknowledged
TSN on each path. A chunk SHOULD only be considered as missing if its
TSN is smaller than the highest acknowledged TSN on its path. Section
3.1 of <xref target='DBP10a'/> contains an illustrated example.</t>
</section>
<section anchor='cwndupdate'
title='Appropriate Congestion Window Growth' >
<t>The congestion window adaptation algorithm for SCTP <xref target='RFC4960'/>
allows increasing the congestion window only when a new cumulative ack (CumAck)
is received by a sender. When SACKs with unchanged CumAcks are generated (due to
reordering) and later arrive at a sender, the sender does not modify its
congestion window. Since a CMT-SCTP receiver naturally observes reordering, many
SACKs are sent containing new gap reports but not new CumAcks. When these gaps
are later acked by a new CumAck, congestion window growth occurs, but only for
the data newly acked in the most recent SACK. Data previously acked through gap
reports will not contribute to congestion window growth, in order to prevent
sudden increases in the congestion window resulting in bursts of data being
sent.</t>
<t>To overcome the problems described above, the congestion window growth has to
be handled as follows <xref target='IAS06'/>:
<list style='symbols'>
<t>The sender SHOULD keep track of the earliest non-retransmitted outstanding
TSN per path.</t>
<t>The sender SHOULD keep track of the earliest retransmitted
outstanding TSN per path.</t>
<t>The in-order delivery per path SHOULD be deduced.</t>
<t>The congestion window of a path SHOULD be increased when the earliest
non-retransmitted outstanding TSN of this path is advanced
('Pseudo CumAck') OR when the earliest retransmitted outstanding TSN of this
path is advanced ('RTX Pseudo CumAck').</t>
</list>
</t>
<t>Section 3.2 of <xref target='DBP10a'/> contains an illustrated
example of appropriate congestion window handling for CMT-SCTP.</t>
</section>
<section anchor='delayedack'
title='Appropriate Delayed Acknowledgements' >
<t>Standard SCTP <xref target='RFC4960'/> sends a SACK as soon as an
out-of-sequence TSN has been received. Delayed Acknowledgements are only
allowed if the received TSNs are in sequence. However, due to the load
balancing of CMT-SCTP, DATA chunks may overtake each other. This leads
to a high number of out-of-sequence TSNs, which have to be acknowledged
immediately. Clearly, this behaviour increases the overhead traffic
(usually nearly one SACK chunk for each received packet containing a
DATA chunk).</t>
<t>Delayed Acknowledgements for CMT-SCTP are handled as follows:
<list style='symbols'>
<t>In addition to <xref target='RFC4960'/>, delaying of SACKs SHOULD
*also* be applied for out-of-sequence TSNs.</t>
<t>A receiver MUST maintain a counter for the number of DATA chunks
received before sending a SACK. The value of the counter is stored
into each SACK chunk (FIXME: add details; needs reservation of flags
bits by IANA). After transmitting a SACK, the counter MUST be reset
to 0. Its initial value MUST be 0.</t>
<t>The SACK handling procedure for a missing TSN M is extended as follows:
<list style='symbols'>
<t>If all newly acknowledged TSNs have been transmitted
over the same path:
<list style='symbols'>
<t>If there are newly acknowledged TSNs L and H so that L
<= M <= H, the missing count of TSN M SHOULD
be incremented by one (like for standard SCTP according to
<xref target='RFC4960'/>).</t>
<t>Else if all newly acknowledged TSNs N satisfy the
condition M <= N, the missing count of TSN M SHOULD
be incremented by the number of TSNs reported in the SACK
chunk.</t>
</list></t>
<t>Otherwise (that is, there are newly acknowledged TSNs on
different paths), the missing count of TSN M SHOULD be
incremented by one (like for standard SCTP according to
<xref target='RFC4960'/>).</t>
</list>
</t>
</list>
</t>
<t>Section 3.3 of <xref target='DBP10a'/> contains an illustrated
example of Delayed Acknowledgements for CMT-SCTP.</t>
</section>
</section>
<section title='Non-Renegable SACK'
anchor='nrsack'>
<!---**************NEGOTIATION********************-->
<section anchor="negotiation" title="Negotiation">
<t>
Before sending/receiving NR-SACKs (see <xref target='YEN10' />), both peer endpoints MUST agree on
using NR-SACKs. This agreement MUST be negotiated during association establishment.
NR-SACK is an extension to the core SCTP, and SCTP extensions that an endpoint
supports are reported to the peer endpoint in Supported Extensions
Parameter during association establishment (see Section 4.2.7 of
<xref target="RFC5061" />.)
The Supported Extensions Parameter consists of a list of non-standard Chunk Types
that are supported by the sender.
</t>
<t>
An endpoint supporting the NR-SACK extension MUST list the NR-SACK
chunk in the Supported Extensions Parameter carried in the INIT
or INIT-ACK chunk, depending on whether the endpoint initiates or
responds to the initiation of the association.
If the NR-SACK chunk type ID is listed in the Chunk Types List of the
Supported Extensions Parameter, then the receiving endpoint MUST assume that
the NR-SACK chunk is supported by the sending endpoint.
</t>
<t> Both endpoints MUST support NR-SACKs for either endpoint to send an NR-SACK.
If an endpoint establishes an
association with a remote endpoint that does not list NR-SACK in the Supported
Extensions Parameter carried in INIT chunk, then both endpoints of
the association MUST NOT use NR-SACKs.
After association establishment, an endpoint MUST NOT renegotiate the use of NR-SACKs.
<!--ask if we should keep this part-->
<!--
So in such a case remote endpoint receiving the INIT chunk
SHOULD not list NR-SACK in Supported Extensions Parameter
carried in INIT-ACK chunk sent in response to INIT
chunk, even though the remote endpoint is capable of supporting NR-SACK.
-->
</t>
<t>
Once both endpoints indicate during association establishment
that they support the NR-SACK extension, each endpoint SHOULD
acknowledge received DATA chunks with NR-SACK chunks, and not SACK chunks. <!--ask about SHOULD-->
That is, throughout an SCTP association, both endpoints SHOULD send either
SACK chunks or NR-SACK chunks, never a mixture of the two.
</t>
</section>
<!-- **********CHUNK TYPE***************** -->
<section anchor="nr-sackchunk" title="The New Chunk Type: Non-Renegable SACK (NR-SACK)">
<t>Table 1 illustrates a new chunk type that will be used to
transfer NR-SACK information.
</t>
<figure align = "center">
<artwork>
Chunk Type Chunk Name
--------------------------------------------------------------
0x10 Non-Renegable Selective Acknowledgment (NR-SACK)
Table 1: NR-SACK Chunk
</artwork>
</figure>
<t>
As the NR-SACK chunk replaces the SACK chunk, many SACK chunk fields
are preserved in the NR-SACK chunk. These preserved fields
have the same semantics with the corresponding SACK chunk fields, as defined in
<xref target="RFC4960" />, Section 3.3.4. The Gap Ack fields from RFC4960 have been renamed as R Gap Ack
to emphasize their renegable nature. Their semantics are unchanged.
For completeness, we describe all fields of the NR-SACK chunk,
including those that are identical in the SACK chunk.
</t>
<t>
Similar to the SACK chunk, the NR-SACK chunk is sent to a peer endpoint to
(1) acknowledge DATA chunks received in-order, (2) acknowledge DATA chunks
received out-of-order, and (3) identify DATA chunks received more than once (i.e., duplicate.)
In addition, the NR-SACK chunk (4) informs
the peer endpoint of non-renegable out-of-order DATA chunks.
<!-- replaced with the above paragraph per Jana's suggestion-->
<!--
The NR-SACK chunk is sent to the peer endpoint to acknowledge
DATA chunks received in-order, to acknowledge received
out-of-order DATA chunk blocks, and to inform the peer endpoint of
non-renegable out-of-order DATA chunk blocks.
-->
</t>
<figure align = "center">
<artwork>
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 = 0x10 | Chunk Flags | Chunk Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cumulative TSN Ack |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertised Receiver Window Credit (a_rwnd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Number of R Gap Ack Blocks = N |Number of NR Gap Ack Blocks = M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Duplicate TSNs = X | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| R Gap Ack Block #1 Start | R Gap Ack Block #1 End |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ /
\ ... \
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| R Gap Ack Block #N Start | R Gap Ack Block #N End |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NR Gap Ack Block #1 Start | NR Gap Ack Block #1 End |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ /
\ ... \
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NR Gap Ack Block #M Start | NR Gap Ack Block #M End |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Duplicate TSN 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ /
\ ... \
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Duplicate TSN X |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>
Type: 8 bits
</t>
<t>
This field holds the IANA defined chunk type for
NR-SACK chunk. The suggested value of this field for IANA is 0x10.
</t>
<t> Chunk Flags: 8 bits
</t>
<t>
Currently not used. It is recommended a sender set all bits to zero on
transmit, and a receiver ignore this field.
</t>
<t>Chunk Length: 16 bits (unsigned integer) [Same as SACK chunk]
</t>
<t>
This value represents the size of the chunk in bytes including the
Chunk Type, Chunk Flags, Chunk Length, and Chunk Value fields.
</t>
<t> Cumulative TSN Ack: 32 bits (unsigned integer) [Same as SACK chunk]
</t>
<t>The value of the Cumulative TSN Ack is the last TSN received before a break
in the sequence of received TSNs occurs. The next TSN value following the
Cumulative TSN Ack has not yet been received at the endpoint sending the NR-SACK.
</t>
<t> Advertised Receiver Window Credit (a_rwnd):
32 bits (unsigned integer) [Same as SACK chunk]
</t>
<t> Indicates the updated receive buffer space in bytes of
the sender of this NR-SACK, see Section 6.2.1 of <xref target="RFC4960" />
for details.
</t>
<t> Number of (R)enegable Gap Ack Blocks (N): 16 bits (unsigned integer)
</t>
<t> Indicates the number of Renegable Gap Ack Blocks included in this NR-SACK.
</t>
<t> Number of (N)on(R)enegable Gap Ack Blocks (M): 16 bits (unsigned integer)
</t>
<t> Indicates the number of Non-Renegable Gap Ack Blocks included in
this NR-SACK.
</t>
<t> Number of Duplicate TSNs (X): 16 bits [Same as SACK chunk]
</t>
<t> Contains the number of duplicate TSNs the endpoint has
received. Each duplicate TSN is listed following the NR Gap Ack Block list.
</t>
<t> Reserved : 16 bits
</t>
<t> Currently not used. It is recommended a sender set all bits to zero on
transmit, and a receiver ignore this field.
</t>
<t> (R)enegable Gap Ack Blocks:
</t>
<t>
The NR-SACK contains zero or more R Gap Ack Blocks.
Each R Gap Ack Block acknowledges a subsequence of renegable out-of-order TSNs.
By definition, all TSNs acknowledged by R Gap Ack Blocks are "greater than" the value of the
Cumulative TSN Ack.
</t>
<t>
Because of TSN numbering wraparound, comparisons and all arithmetic
operations discussed in this document are based on
"Serial Number Arithmetic" as described in Section 1.6 of
<xref target="RFC4960" />.
</t>
<t> R Gap Ack Blocks are repeated for each R Gap Ack Block up to 'N' defined in
the Number of R Gap Ack Blocks field. All DATA chunks with TSNs >=
(Cumulative TSN Ack + R Gap Ack Block Start) and <=
(Cumulative TSN Ack + R Gap Ack Block End) of each R Gap Ack Block are assumed
to have been received correctly, and are renegable.
</t>
<t> R Gap Ack Block Start: 16 bits (unsigned integer)
</t>
<t> Indicates the Start offset TSN for this R Gap Ack Block. This number
is set relative to the cumulative TSN number defined in Cumulative TSN Ack field.
To calculate the actual start TSN number, the Cumulative TSN Ack is added to
this offset number. The calculated TSN identifies the first TSN
in this R Gap Ack Block that has been received.
</t>
<t> R Gap Ack Block End: 16 bits (unsigned integer)
</t>
<t> Indicates the End offset TSN for this R Gap Ack Block. This number
is set relative to the cumulative TSN number defined in the Cumulative TSN Ack field.
To calculate the actual TSN number, the Cumulative TSN Ack is added to this
offset number. The calculated TSN identifies the TSN of the last DATA chunk received in this R Gap Ack Block.
</t>
<t> N(on)R(enegable) Gap Ack Blocks:
</t>
<t>
The NR-SACK contains zero or more NR Gap Ack Blocks. Each NR
Gap Ack Block acknowledges a continuous subsequence of non-renegable
out-of-order DATA chunks.
If a TSN is nr-gap-acked in any NR-SACK chunk, then all subsequently transmitted
NR-SACKs with a smaller cum-ack value than that TSN SHOULD also nr-gap-ack that TSN.
</t>
<t>NR Gap Ack Blocks are repeated for
each NR Gap Ack Block up to 'M' defined in the Number of NR Gap Ack Blocks
field. All DATA chunks with TSNs >= (Cumulative TSN
Ack + NR Gap Ack Block Start) and <= (Cumulative
TSN Ack + NR Gap Ack Block End) of each NR Gap Ack Block are assumed to be received correctly,
and are Non-Renegable.
</t>
<t> NR Gap Ack Block Start: 16 bits (unsigned integer)
</t>
<t> Indicates the Start offset TSN for this NR Gap Ack Block. This number
is set relative to the cumulative TSN number defined in Cumulative TSN Ack field.
To calculate the actual TSN number, the Cumulative TSN Ack is added to
this offset number. The calculated TSN identifies the first TSN
in this NR Gap Ack Block that has been received.
</t>
<t> NR Gap Ack Block End: 16 bits (unsigned integer)
</t>
<t> Indicates the End offset TSN for this NR Gap Ack Block.
This number is set relative to the cumulative TSN number defined
in Cumulative TSN Ack field. To calculate the actual TSN number, the Cumulative
TSN Ack is added to this offset number. The calculated TSN identifies the
TSN of the last DATA chunk received in this NR Gap Ack Block.
</t>
<t>Note:</t>
<t> NR Gap Ack Blocks and R Gap Ack Blocks in an NR-SACK chunk SHOULD acknowledge disjoint sets of
TSNs. That is, an out-of-order TSN SHOULD be listed in either an R Gap Ack Block or an NR Gap Ack Block,
but not the both. R Gap Ack Blocks and NR Gap Ack Blocks together provide the information as do the Gap
Ack Block of a SACK chunk, plus additional information about non-renegability.
</t>
<t>If all out-of-order data acked by an NR-SACK are renegable, then the Number of NR Gap Ack Blocks MUST be set to 0.
If all out-of-order data acked by an NR-SACK are non-renegable, then the Number of R Gap Ack Blocks SHOULD be set
to 0. TSNs listed in R Gap Ack Block will be referred as r-gap-acked.
</t>
<t> Duplicate TSN: 32 bits (unsigned integer) [Same as SACK chunk]
</t>
<t>
Indicates a duplicate TSN received since the last NR-SACK was sent.
Exactly 'X' duplicate TSNs SHOULD be reported where 'X' was defined in Number of
Duplicate TSNs field.
</t>
<t> Each duplicate TSN is listed in this field as many times as
the TSN was received since the previous NR-SACK was sent.
For example, if a data receiver were to get the TSN 19 three times, the data receiver
would list 19 twice in the outbound NR-SACK. After sending the NR-SACK
if the receiver received one more TSN 19, the receiver would list 19 as a duplicate
once in the next outgoing NR-SACK.
</t>
</section> <!--*****End Chunk section *****-->
<!--***************EXAMPLE**************-->
<section anchor="example" title="An Illustrative Example">
<t>
Assume the following DATA chunks have arrived at the receiver.
</t>
<figure align = "center">
<artwork>
--------------------------------
| TSN=16| SID=2 | SSN=N/A| U=1 |
--------------------------------
| TSN=15| SID=1 | SSN= 4 | U=0 |
--------------------------------
| TSN=14| SID=0 | SSN= 4 | U=0 |
--------------------------------
| TSN=13| SID=2 | SSN=N/A| U=1 |
--------------------------------
| |
--------------------------------
| TSN=11| SID=0 | SSN= 3 | U=0 |
-------------------------------
| |
--------------------------------
| |
--------------------------------
| TSN=8 | SID=2 | SSN=N/A| U=1 |
--------------------------------
| TSN=7 | SID=1 | SSN= 2 | U=0 |
--------------------------------
| TSN=6 | SID=1 | SSN= 1 | U=0 |
--------------------------------
| TSN=5 | SID=0 | SSN= 1 | U=0 |
--------------------------------
| |
--------------------------------
| TSN=3 | SID=1 | SSN= 0 | U=0 |
--------------------------------
| TSN=2 | SID=0 | SSN= 0 | U=0 |
--------------------------------
</artwork>
</figure>
<t>The above figure shows the list of DATA chunks at the receiver.
TSN denotes the transmission sequence number of the DATA chunk,
SID denotes the stream id to which the DATA chunk belongs,
SSN denotes the sequence number of the DATA chunk within its stream,
and the U bit denotes whether the DATA chunk requires ordered(=0) or unordered(=1)
delivery <xref target="RFC4960" />. Note that TSNs 4,9,10, and 12 have not arrived.
</t>
<t>
This data can be viewed as three separate streams as follows
(assume each stream begins with SSN=0.)
Note that in this example, the application uses stream 2 for unordered data transfer.
By definition, SSN fields of unordered DATA chunks are ignored.
</t>
<t> Stream-0:</t>
<figure align = "left">
<artwork>
SSN: 0 1 2 3 4
TSN: | 2 | 5 | | 11 | 14 |
U-Bit: | 0 | 0 | | 0 | 0 |
</artwork>
</figure>
<t> Stream-1:</t>
<figure align = "left">
<artwork>
SSN: 0 1 2 3 4
TSN: | 3 | 6 | 7 | | 15 |
U-Bit: | 0 | 0 | 0 | | 0 |
</artwork>
</figure>
<t> Stream-2:</t>
<figure align = "left">
<artwork>
SSN: N/A N/A N/A
TSN: | 8 | 13 | 16 |
U-Bit: | 1 | 1 | 1 |
</artwork>
</figure>
<t> The NR-SACK to acknowledge the above data SHOULD be constructed as follows
for each of the three cases described below (the a_rwnd is arbitrarily set to 4000):
</t>
<t> CASE-1: Minimal Data Receiver Responsibility - no out-of-order deliverable data yet delivered
</t>
<t> None of the deliverable out-of-order DATA chunks have been delivered, and
the receiver of the above data does not take responsibility for any of the
received out-of-order DATA chunks. The receiver reserves the right to renege
any or all of the out-of-order DATA chunks.
</t>
<figure align = "center">
<artwork>
+-----------------------------+-----------------------------+
| Type = 0x10 | 00000000 | Chunk Length = 32 |
+-----------------------------+-----------------------------+
| Cumulative TSN Ack = 3 |
+-----------------------------+-----------------------------+
| a_rwnd = 4000 |
+-----------------------------+-----------------------------+
| Num of R Gap Ack Blocks = 3 |Num of NR Gap Ack Blocks = 0 |
+-----------------------------+-----------------------------+
| Num of Duplicates = 0 | 0x00 |
+-----------------------------+-----------------------------+
|R Gap Ack Block #1 Start = 2 | R Gap Ack Block #1 End = 5 |
+-----------------------------+-----------------------------+
|R Gap Ack Block #2 Start = 8 | R Gap Ack Block #2 End = 8 |
+-----------------------------+-----------------------------+
|R Gap Ack Block #3 Start = 10| R Gap Ack Block #3 End = 13 |
+-----------------------------+-----------------------------+
</artwork>
</figure>
<t> CASE-2: Minimal Data Receiver Responsibility - all out-of-order deliverable data delivered</t>
<t>
In this case, the NR-SACK chunk is being sent after the data receiver has delivered
all deliverable out-of-order DATA chunks to its receiving application(i.e., TSNs 5,6,7,8,13, and 16.)
The receiver reserves the right to renege on all undelivered out-of-order DATA chunks(i.e., TSNs 11,14, and 15.)
<!-- replaced by above per Phil's suggestion
The receiver of this data takes responsibility for all DATA chunks that
could be delivered to the application (e.g., by having data actually delivered to
the application). Within each stream, any continuous sequence of data chunks,
where the data chunk with the smallest TSN is on the head of that stream, is
deliverable.
-->
<!--replaced by above per Phill's suggestion
Any DATA chunk whose 'U'(Unordered) bit is set to '1' is
also deliverable, no matter where the DATA chunk
positions within the stream the DATA chunk belongs.
-->
</t>
<figure align = "center">
<artwork>
+------------------------------+------------------------------+
| Type = 0x10 | 0x00 | Chunk Length = 40 |
+------------------------------+------------------------------+
| Cumulative TSN Ack = 3 |
+------------------------------+------------------------------+
| a_rwnd = 4000 |
+------------------------------+------------------------------+
| Num of R Gap Ack Blocks = 2 | Num of NR Gap Ack Blocks = 3 |
+------------------------------+------------------------------+
| Num of Duplicates = 0 | 0x00 |
+------------------------------+------------------------------+
| R Gap Ack Block #1 Start = 8 | R Gap Ack Block #1 End = 8 |
+------------------------------+------------------------------+
| R Gap Ack Block #2 Start = 11| R Gap Ack Block #2 End = 12 |
+------------------------------+------------------------------+
|NR Gap Ack Block #1 Start = 2 | NR Gap Ack Block #1 End = 5 |
+------------------------------+------------------------------+
|NR Gap Ack Block #2 Start = 10| NR Gap Ack Block #2 End = 10 |
+------------------------------+------------------------------+
|NR Gap Ack Block #3 Start = 13| NR Gap Ack Block #3 End = 13 |
+------------------------------+------------------------------+
</artwork>
</figure>
<t>CASE-3: Maximal Data Receiver Responsibility</t>
<t>
In this special case, all out-of-order data blocks acknowledged are non-renegable.
This case would occur when the data receiver is programmed never to renege, and takes
responsibility to deliver all DATA chunks that arrive out-of-order.
In this case Num of R Gap Ack Blocks is zero indicating all
reported out-of-order TSNs are nr-gap-acked.
</t>
<figure align = "center">
<artwork>
+--------------------------------+-------------------------------+
| Type = 0x10 | 0x00 | Chunk Length = 32 |
+--------------------------------+-------------------------------+
| Cumulative TSN Ack = 3 |
+--------------------------------+-------------------------------+
| a_rwnd = 4000 |
+--------------------------------+-------------------------------+
| Num of R Gap Ack Blocks = 0 | Num of NR Gap Ack Blocks = 3 |
+--------------------------------+-------------------------------+
| Num of Duplicates = 0 | 0x00 |
+--------------------------------+-------------------------------+
| NR Gap Ack Block #1 Start = 2 | NR Gap Ack Block #1 End = 5 |
+--------------------------------+-------------------------------+
| NR Gap Ack Block #2 Start = 8 | NR Gap Ack Block #2 End = 8 |
+--------------------------------+-------------------------------+
| NR Gap Ack Block #3 Start = 10 | NR Gap Ack Block #3 End = 13 |
+--------------------------------+-------------------------------+
</artwork>
</figure>
</section>
<!-- Multiline comment below-->
<!--
<section anchor="parameters" title="New Parameter Types">
</section>
<section anchor="errors" title="New Error Causes">
<section anchor="lastip" title="Error Cause: Request to Delete Last Remaining IP Address">
</section>
<section anchor="oprefused" title="Error Cause: Operation Refused Due to Resource Shortage">
</section>
<section anchor="delsrc" title="Error Cause: Request to Delete Source IP Address">
</section>
<section anchor="badasconfack" title="Error Cause: Association Aborted due to illegal ASCONF-ACK">
</section>
</section>
-->
<!-- **************PROCEDURES***************** -->
<section anchor="procedures" title="Procedures">
<t>
The procedures regarding "when" to send an NR-SACK chunk are identical to
the procedures regarding when to send a SACK chunk,
as outlined in Section 6.2 of <xref target="RFC4960" />.
<!--Replaced by above pargraph per Phill's suggestion-->
<!--
Under identical data flow
an endpoint that uses NR-SACKs would create and send as many
NR-SACKs as SACKs sent by an endpoint that uses SACK, with the same timing.
-->
</t>
<section anchor="sendnrsack" title="Sending an NR-SACK chunk">
<t>
All of the NR-SACK chunk fields identical to the SACK chunk MUST be formed as
described in Section 6.2 of <xref target="RFC4960" />.
</t>
<t>
It is up to the data receiver whether or not to take responsibility for delivery
of each out-of-order DATA chunk. An out-of-order DATA chunk that has already been
delivered, or that the receiver takes responsibility to deliver (i.e., guarantees
not to renege) is Non Renegable(NR), and SHOULD be included in an NR
Gap Ack Block field of the outgoing NR-SACK. All other out-of-order data is (R)enegable, and SHOULD
be included in R Gap Ack Block field of the outgoing NR-SACK.
</t>
<t>
Consider three types of data receiver:
</t>
<t> <list style="hanging">
<t hangText="CASE-1:">
Data receiver takes no responsibility for delivery of any out-of-order DATA chunks
<vspace blankLines="1" /> </t>
<t hangText="CASE-2:"> Data receiver takes responsibility for all out-of-order
DATA chunks that are "deliverable" (i.e., DATA chunks in-sequence within the
stream they belong to, or DATA chunks whose (U)nordered bit is 1)
<vspace blankLines="1" />
</t>
<t hangText="CASE-3:">Data receiver takes responsibility for delivery of all
out-of-order DATA chunks, whether deliverable or not deliverable
<vspace blankLines="1" />
</t>
</list> </t>
<t>
The data receiver SHOULD follow the procedures outlined <!--is should ok,??-->
below for building the NR-SACK.</t>
<t>CASE-1:</t>
<t><list style="hanging">
<t hangText="1A)">Identify the TSNs received out-of-order.
<vspace blankLines="1" />
</t>
<t hangText="1B)">For these out-of-order TSNs, identify the R Gap Ack Blocks.
Fill the Number of R Gap Ack Blocks (N) field,
R Gap Ack Block #i Start, and R Gap Ack Block #i End where i goes from 1 to N.
<vspace blankLines="1" />
</t>
<t hangText="1C)">Set the Number of NR Gap Ack Blocks (M) field to 0.
<vspace blankLines="1" />
</t>
</list></t>
<t>CASE-2:</t>
<t><list style="hanging">
<t hangText="2A)">Identify the TSNs received out-of-order.
<vspace blankLines="1" />
</t>
<t hangText="2B)">
For the received out-of-order TSNs, check the (U)nordered bit of each TSN.
Tag unordered TSNs as NR.
<vspace blankLines="1" />
</t>
<t hangText="2C)">
For each stream, also identify the TSNs received out-of-order but are
in-sequence within that stream.
Tag those in-sequence TSNs as NR.
<vspace blankLines="1" />
</t>
<t hangText="2D)">Tag all out-of-order data that is not NR as (R)enegable.
<vspace blankLines="1" />
</t>
<t hangText="2E)">For those TSNs tagged as (R)enegable, identify the (R)enegable Blocks.
Fill the Number of R Gap Ack Blocks(N) field,
R Gap Ack Block #i Start, and R Gap Ack Block #i End where i goes from 1 to N.
<vspace blankLines="1" />
</t>
<t hangText="2F)">For those TSNs tagged as NR, identify the NR Blocks.
Fill the Number of NR Gap Ack Blocks(M) field,
NR Gap Ack Block #i Start, and NR Gap Ack Block #i End where i goes from 1 to M.
<vspace blankLines="1" />
</t>
</list></t>
<t>CASE-3:</t>
<t><list style="hanging">
<t hangText="3A)">Identify the TSNs received out-of-order. All of these TSNs SHOULD be nr-gap-acked.
<vspace blankLines="1" />
</t>
<t hangText="3B)">Set the Number of R Gap Ack Blocks (N) field to 0.
<vspace blankLines="1" />
</t>
<t hangText="3C)">For these out-of-order TSNs, identify the NR Gap Ack Blocks.
Fill the Number of NR Gap Ack Blocks (M) field,
NR Gap Ack Block #i Start, and NR Gap Ack Block #i End where i goes from 1 to M.
<vspace blankLines="1" />
</t>
</list></t>
<t>
RFC4960 states that the SCTP endpoint MUST report as many Gap Ack Blocks
as can fit in a single SACK chunk limited by the current path MTU.
When using NR-SACKs, the SCTP endpoint SHOULD fill as many R Gap Ack Blocks and NR Gap Ack Blocks starting
from the Cumulative TSN Ack value as can fit in a single NR-SACK chunk limited by the current path MTU.
If space remains, the SCTP endpoint SHOULD fill as many Duplicate TSNs as possible starting from
Cumulative TSN Ack value.
</t>
</section>
<section anchor="recvnrsack" title="Receiving an NR-SACK Chunk">
<t>
When an NR-SACK chunk is received, all of the NR-SACK fields identical to a
SACK chunk SHOULD be processed and handled as in SACK chunk handling outlined in
Section 6.2.1 of <xref target="RFC4960" />.
</t>
<t>
The NR Gap Ack Block Start(s) and NR Gap Ack Block End(s) are
offsets relative to the cum-ack. To calculate the actual range of nr-gap-acked TSNs,
the cum-ack MUST be added to the Start and End.
</t>
<t>
For example, assume an incoming NR-SACK chunk's cum-ack is
12 and an NR Gap Ack Block defines the NR Gap Ack Block Start=5,
and the NR Gap Ack Block End=7. This NR Gap Ack block nr-gap-acks
TSNs 17 through 19 inclusive.
</t>
<t>
Upon reception of an NR-SACK chunk, all TSNs listed in either R Gap Ack Block(s) or NR Gap Ack Block(s)
SHOULD be processed as would be TSNs included in Gap Ack Block(s) of a SACK chunk.
All TSNs in all NR Gap Ack Blocks SHOULD be removed from the
data sender's retransmission queue as their delivery to the receiving
application has either already occurred, or is guaranteed
by the data receiver. </t>
<t>Although R Gap Ack Blocks and NR Gap Ack Blocks SHOULD be disjoint sets,
NR-SACK processing SHOULD work if an NR-SACK chunk has a TSN listed in both an R Gap Ack Block and
an NR Gap Ack Block. In this case, the TSN SHOULD be treated as Non-Renegable.
</t>
<t>Implementation Note:</t>
<t>
Most of NR-SACK processing at the data sender can be implemented by
using the same routines as in SACK that process the cum ack and the gap ack(s),
followed by removal of nr-gap-acked DATA chunks from the retransmission queue.
However, with NR-SACKs, as out-of-order DATA is sometimes
removed from the retransmission queue, the gap ack processing routine should recognize that
the data sender's retransmission queue has some transmitted data removed.
For example, while calculating missing reports, the
gap ack processing routine cannot assume that the highest TSN transmitted
is always at the tail (right edge) of the retransmission queue.
</t>
</section>
<!-- Multiline comment below-->
<!--
<section anchor="negproced" title="Negotiation Procedures">
</section>
<section anchor="genrules" title="General rules">
</section>
-->
</section>
</section>
<section anchor='blocking'
title='Buffer Blocking Mitigation'>
<t>TBD. See <xref target='Dre2012'/>, <xref target='ADB11'/>, <xref target='DBR10'/>.</t>
<section anchor='sndbufsplitting'
title='Sender Buffer Splitting'>
<t>TBD. See <xref target='Dre2012'/>, <xref target='ADB11'/>, <xref target='DBR10'/>.</t>
</section>
<section anchor='rcvbufsplitting'
title='Receiver Buffer Splitting'>
<t>TBD. See <xref target='Dre2012'/>, <xref target='ADB11'/>, <xref target='DBR10'/>.</t>
</section>
<section title='Chunk Rescheduling'
anchor='chrescheduling'>
<t>This algorithm ensures quick blocking resolution for ordered data.
TBD. See <xref target='Dre2012'/>, <xref target='DBR10'/>.</t>
</section>
<section anchor='pf'
title='Problems during Path Failure'>
<t>This section discusses CMT's receive buffer related problems during
path failure, and proposes a solution for the same.</t>
<section title='Problem Description'>
<t> Link failures arise when a router or a link connecting two routers
fails due to link disconnection, hardware malfunction, or software
error. Overloaded links caused by flash crowds and denial-of-service
(DoS) attacks also degrade end-to-end communication between peer hosts.
Ideally, the routing system detects link failures, and in response,
reconfigures the routing tables and avoids routing traffic via the
failed link. However, existing research highlights problems with
Internet backbone routing that result in long route convergence times.
The pervasiveness of path failures motivated us to study their impact on
CMT, since CMT achieves better throughput via simultaneous data
transmission over multiple end-to-end paths.</t>
<t> CMT is an extension to SCTP, and therefore
retains SCTP's failure detection process. A CMT sender uses a tunable
failure detection threshold called Path.Max.Retrans (PMR). When a sender
experiences more than PMR consecutive timeouts while trying to reach an
active destination, the destination is marked as failed. With PMR=5, the
failure detection takes 6 consecutive timeouts or 63s. After every
timeout, the CMT sender continues to transmit new data on the failed
path increasing the chances of receive buffer (rbuf) blocking and
degrading CMT performance during permanent and short-term path failures
<xref target='NEA08'/>.</t>
</section>
<section title='Solution: Potentially-failed Destination State'>
<t>To mitigate the rbuf blocking, we introduce a new destination state
called 'potentially-failed' state in SCTP (and CMT's) failure detection
process <xref target='I-D.nishida-tsvwg-sctp-failover'/>.
This solution is based on the rationale that loss detected by a timeout
implies either severe congestion or failure en route.
After a single timeout on a path, a sender is unsure, and marks the
corresponding destination as 'potentially-failed' (PF).
A PF destination is not used for data transmission or retransmission.
CMT's retransmission policies are augmented to include the PF state.
Performance evaluations prove that the PF state significantly reduces
rbuf blocking during failure detection <xref target='NEA08'/>.</t>
</section>
</section>
<section title='Non-Renegable SACK'>
<t> This section discusses problems with SCTP's SACK mechanism and how
it affects the send buffer and CMT performance.</t>
<section title='Problem Description'>
<t> Gap-acks acknowledge DATA chunks that arrive out-of-order to a
transport layer data receiver. A gap-ack in SCTP is advisory, in that,
while it notifies a data sender about the reception of indicated DATA
chunks, the data receiver is permitted to later discard DATA chunks that
it previously had gap-acked. Discarding a previously gap-acked DATA
chunk is known as 'reneging'. Because of the possibility of reneging in
SCTP, any gap-acked DATA chunk MUST NOT be removed from the data
sender's retransmission queue until the DATA chunk is later
CumAcked.</t>
<t>Situations exist when a data receiver knows that reneging on a
particular out-of-order DATA chunk will never take place, such as (but
not limited to) after an out-of-order DATA chunk is delivered to the
receiving application. With current SACKs in SCTP, it is not possible
for a data receiver to inform a data sender if or when a particular
out-of-order 'deliverable' DATA chunk has been 'delivered' to the
receiving application. Thus the data sender MUST keep a copy of every
gap-acked out-of-order DATA chunk(s) in the data sender's retransmission
queue until the DATA chunk is CumAcked. This use of the data sender's
retransmission queue is wasteful. The wasted buffer often degrades CMT
performance; the degradation increases when a CMT flow traverses via
paths with disparate end-to-end properties <xref target='NEY08'/>.</t>
</section>
<section title='Solution: Non-Renegable SACKs'>
<t>Non-Renegable Selective Acknowledgments (NR-SACKs)
<xref target='nrsack'/> are a new kind of
acknowledgements, extending SCTP's SACK chunk functionalities. The
NR-SACK chunk is an extension of the existing SACK chunk. Several fields
are identical, including the Cumulative TSN Ack, the Advertised Receiver
Window Credit (a_rwnd), and Duplicate TSNs. These fields have the same
semantics as described in <xref target='RFC4960'/>.</t>
<t>NR-SACKs also identify out-of-order DATA chunks that a receiver either:
(1) has delivered to its receiving application, or
(2) takes full responsibility to eventually deliver to its receiving application.
These out-of-order DATA chunks are 'non-renegable.'
Non-Renegable data are reported in the NR Gap Ack Block field of the
NR-SACK chunk as described <xref target='nrsack'/>.
We refer to non-renegable selective acknowledgements as 'nr-gap-acks.'</t>
<t> When an out-of-order DATA chunk is nr-gap-acked, the data sender no
longer needs to keep that particular DATA chunk in its retransmission
queue, thus allowing the data sender to free up its buffer space sooner
than if the DATA chunk were only gap-acked. NR-SACKs improve send
buffer utilization and throughput for CMT flows
<xref target='NEY08' />.</t>
</section>
</section>
</section>
<section anchor='bottlenecks'
title='Handling of Shared Bottlenecks'>
<section title='Introduction' anchor='rpintro'>
<t>CMT-SCTP assumes all paths to be disjoint. Since each path
independently uses a TCP-like congestion control, an SCTP association
using N paths over the same bottleneck acquires N times the bandwidth of
a concurrent TCP flow. This is clearly unfair. A reliable detection of
shared bottlenecks is impossible in arbitrary networks like the
Internet. Therefore, <xref target='BDA12'/> <xref target='DBA11'/>, <xref target='DBP10b'/> apply the idea of
Resource Pooling to CMT-SCTP. Resource Pooling (RP) denotes 'making a
collection of resources behave like a single pooled resource'
<xref target='WHB09'/>. The modifications of RP-enabled CMT-SCTP, further
denoted as CMT/RP-SCTP, are described in the following subsections.
A detailed description of CMT/RP-SCTP, including congestion control
examples, can be found in <xref target='BDA12'/>, <xref target='DBA11'/>, <xref target='DBP10b'/>.</t>
</section>
<section anchor='rpinitial'
title='Initial Values'>
<t>TDB.</t>
</section>
<section anchor='rpcwndgrowth'
title='Congestion Window Growth'>
<t>TDB. See <xref target='Dre2012'/>, <xref target='BDA12'/>, <xref target='DBA11'/>.</t>
</section>
<section anchor='rpcwnddecrease'
title='Congestion Window Decrease'>
<t>TDB. See <xref target='Dre2012'/>, <xref target='BDA12'/>, <xref target='DBA11'/>.</t>
</section>
</section>
<section anchor='schedule'
title='Chunk Scheduling and Rescheduling'>
<t>TDB. See <xref target='Dre2012'/>, <xref target='DST10'/>.</t>
</section>
<section anchor='api'
title='Socket API Considerations'>
<t>
See <xref target='I-D.dreibholz-tsvwg-sctpsocket-multipath'/> and
<xref target='I-D.dreibholz-tsvwg-sctpsocket-sqinfo'/>.
</t>
</section>
<section title="Testbed Platform">
<t>A large-scale and realistic Internet testbed platform with support for the multi-homing feature of the underlying SCTP protocol is NorNet. Particularly, it is also a platform for multi-path transport experiments with CMT-SCTP. A description of and introduction to NorNet is provided in <xref target="PAMS2013-NorNet" />, <xref target="NNUW1-Dreibholz-NorNetCore-Introduction" />, <xref target="NNUW1-Dreibholz-NorNetCore-Tutorial" />. Further information can be found on the project website <xref target="NorNet-Website" /> at http://www.nntb.no.</t>
</section>
<section anchor='IANA'
title='IANA Considerations'>
<!-- <t>This document requires no actions from IANA.</t> -->
<t>NOTE to RFC-Editor:
<list>
<t>"RFCXXXX" is to be replaced by the RFC number you assign this document.</t>
</list>
</t>
<t>NOTE to RFC-Editor:
<list>
<t>The suggested values for the chunk type and the chunk parameter types
are tentative and to be confirmed by IANA.</t>
</list>
</t>
<t>This document (RFCXXXX) is the reference for all registrations
described in this section.
The suggested changes are described below.</t>
<section title="A New Chunk Type">
<t>A chunk type has to be assigned by IANA.
It is suggested to use the values given in <xref target="nrsack"/>.
IANA should assign this value from the pool of chunks with the upper
two bits set to '00'.</t>
<t>This requires an additional line in the "Chunk Types" registry for SCTP:
<figure>
<artwork>
Chunk Types
ID Value Chunk Type Reference
----- ---------- ---------
16 Non-Renegable SACK (NR-SACK) [RFCXXXX]
</artwork>
</figure>
</t>
<t>The registration table as defined in <xref target="RFC6096"/>
for the chunk flags of this chunk type is empty.</t>
</section>
</section>
<section anchor='sec'
title='Security Considerations'>
<t>This document does not add any additional security considerations
in addition to the ones given in <xref target='RFC4960'/>.</t>
</section>
<section anchor='acks'
title='Acknowledgments'>
<t>The authors wish to thank
Hakim Adhari,
Phillip Conrad,
Jonathan Leighton,
Ertugrul Yilmaz and
Xing Zhou
for their invaluable comments and support.</t>
</section>
<!--
<appendix title='Congestion Window Update Algorithm' anchor='CUCv2'>
<t>
<figure>
<artwork>
...
</artwork>
</figure>
</t>
</appendix>
-->
</middle>
<back>
<references title='Normative References'>
<?rfc include='reference.RFC.2119'?>
<?rfc include='reference.RFC.4960'?>
<?rfc include='reference.RFC.5061'?>
<?rfc include='reference.RFC.5351'?>
<?rfc include='reference.RFC.6096'?>
<?rfc include='reference.I-D.nishida-tsvwg-sctp-failover'?>
<?rfc include='reference.I-D.dreibholz-tsvwg-sctpsocket-multipath'?>
<?rfc include='reference.I-D.dreibholz-tsvwg-sctpsocket-sqinfo'?>
</references>
<references title='Informative References'>
<reference anchor='I06'>
<front>
<title>End-to-End Concurrent Multipath Transfer Using Transport Layer Multihoming</title>
<author initials='J.' surname='Iyengar' fullname='Janardhan Iyengar'/>
<date month='April' year='2006'/>
</front>
<seriesInfo name='PhD Dissertation' value='Computer Science Dept., University of Delaware'/>
<format type='PDF' target='http://web1.fandm.edu/jiyengar/papers/iyengar-dissertation.pdf'/>
</reference>
<reference anchor='IAS06'>
<front>
<title>Concurrent Multipath Transfer Using SCTP Multihoming Over Independent End-to-End Paths</title>
<author initials='J.' surname='Iyengar' fullname='Janardhan Iyengar'/>
<author initials='P. D.' surname='Amer' fullname='Paul D. Amer'/>
<author initials='R. R.' surname='Stewart' fullname='Randall R. Stewart'/>
<date month='October' year='2006'/>
</front>
<seriesInfo name='Journal' value='IEEE/ACM Transactions on Networking'/>
<format type='PDF' target='http://web1.fandm.edu/jiyengar/papers/cmt-ton2006.pdf'/>
</reference>
<reference anchor='NEA08'>
<front>
<title>Concurrent Multipath Transfer Using Transport Layer Multihoming: Introducing the Potentially-failed Destination State</title>
<author initials='P.' surname='Natarajan' fullname='Preethi Natarajan'/>
<author initials='N.' surname='Ekiz' fullname='Nasif Ekiz'/>
<author initials='J.' surname='Iyengar' fullname='Janardhan Iyengar'/>
<author initials='P.' surname='Amer' fullname='Paul Amer'/>
<author initials='R.' surname='Stewart' fullname='Randall Stewart'/>
<date month='May' year='2008'/>
</front>
<seriesInfo name='Proceedings' value='of the IFIP Networking'/>
<format type='PDF' target='http://www.cis.udel.edu/~nataraja/papers/networking2008.pdf'/>
</reference>
<reference anchor='NEY08'>
<front>
<title>Non-Renegable Selective Acknowledgments (NR-SACKs) for SCTP</title>
<author initials='P.' surname='Natarajan' fullname='Preethi Natarajan'/>
<author initials='N.' surname='Ekiz' fullname='Nasif Ekiz'/>
<author initials='E.' surname='Yilmaz' fullname='Ertugrul Yilmaz'/>
<author initials='P.' surname='Amer' fullname='Paul Amer'/>
<author initials='J.' surname='Iyengar' fullname='Janardhan Iyengar'/>
<author initials='R.' surname='Stewart' fullname='Randall Stewart'/>
<date month='October' year='2008' />
</front>
<seriesInfo name='Proceedings of the 16th IEEE International Conference on Network Protocols (ICNP)' value =''/>
<format type='PDF' target='http://www.ieee-icnp.org/2008/papers/Index19.pdf'/>
</reference>
<reference anchor='WHB09'>
<front>
<title>The Resource Pooling Principle</title>
<author initials='D.' surname='Wischik' fullname='Damon Wischik'/>
<author initials='M.' surname='Handley' fullname='Mark Handley'/>
<author initials='M. B.' surname='Braun' fullname='Marcelo Bagnulo Braun'/>
<date month='October' year='2009'/>
</front>
<seriesInfo name='Journal' value='ACM SIGCOMM Computer Communication Review'/>
<format type='PDF' target='http://www.adastral.ucl.ac.uk/staff/M.Handley/papers/respool-ccr.pdf'/>
</reference>
<reference anchor='DBP10a'>
<front>
<title>Implementation and Evaluation of Concurrent Multipath Transfer for SCTP in the INET Framework</title>
<author initials='T.' surname='Dreibholz' fullname='Thomas Dreibholz'/>
<author initials='M.' surname='Becke' fullname='Martin Becke'/>
<author initials='J.' surname='Pulinthanath' fullname='Jobin Pulinthanath'/>
<author initials='E.P.' surname='Rathgeb' fullname='Erwin P. Rathgeb'/>
<date month='March' year='2010'/>
</front>
<seriesInfo name='Proceedings' value='of the 3rd ACM/ICST OMNeT++ Workshop'/>
<format
type='PDF'
target='http://www.tdr.wiwi.uni-due.de/fileadmin/fileupload/I-TDR/SCTP/Paper/OMNeT__Workshop2010-SCTP.pdf'/>
</reference>
<reference anchor='DBP10b'>
<front>
<title>Applying TCP-Friendly Congestion Control to Concurrent Multipath Transfer</title>
<author initials='T.' surname='Dreibholz' fullname='Thomas Dreibholz'/>
<author initials='M.' surname='Becke' fullname='Martin Becke'/>
<author initials='J.' surname='Pulinthanath' fullname='Jobin Pulinthanath'/>
<author initials='E. P.' surname='Rathgeb' fullname='Erwin P. Rathgeb'/>
<date month='April' year='2010' />
</front>
<seriesInfo name='Proceedings' value='of the IEEE 24th International Conference on Advanced Information Networking and Applications (AINA)'/>
<format type='PDF' target='http://www.tdr.wiwi.uni-due.de/fileadmin/fileupload/I-TDR/SCTP/Paper/AINA2010.pdf'/>
</reference>
<reference anchor='YEN10'>
<front>
<title>Throughput analysis of Non-Renegable Selective Acknowledgments (NR-SACKs) for SCTP</title>
<author initials='E.' surname='Yilmaz' fullname='Ertugrul Yilmaz'/>
<author initials='N.' surname='Ekiz' fullname='Nasif Ekiz'/>
<author initials='P.' surname='Natarajan' fullname='Preethi Natarajan'/>
<author initials='P.' surname='Amer' fullname='Paul Amer'/>
<author initials='J.' surname='Leighton' fullname='Jonathan Leighton'/>
<author initials='F.' surname='Baker' fullname='Fred Baker'/>
<author initials='R.' surname='Stewart' fullname='Randall Stewart'/>
<date year='2010'/>
</front>
<seriesInfo name='Comput. Commun. (2010), doi:10.1016/j.comcom.2010.06.028' value=''/>
</reference>
<reference anchor='DST10'>
<front>
<title>Transmission Scheduling Optimizations for Concurrent Multipath Transfer</title>
<author initials='T.' surname='Dreibholz' fullname='Thomas Dreibholz' />
<author initials='R.' surname='Seggelmann' fullname='Robin Seggelmann' />
<author initials='M.' surname='Tuexen' fullname='Michael Tuexen' />
<author initials='E. P.' surname='Rathgeb' fullname='Erwin P. Rathgeb' />
<date month='November' year='2010' />
</front>
<seriesInfo name='Proceedings' value='of the 8th International Workshop on Protocols for Future, Large-Scale and Diverse Network Transports (PFLDNeT) ' />
<format type='PDF' target='http://www.tdr.wiwi.uni-due.de/fileadmin/fileupload/I-TDR/ReliableServer/Publications/PFLDNeT2010.pdf' />
</reference>
<reference anchor='DBR10'>
<front>
<title>On the Use of Concurrent Multipath Transfer over Asymmetric Paths</title>
<author initials='T.' surname='Dreibholz' fullname='Thomas Dreibholz' />
<author initials='M.' surname='Becke' fullname='Martin Becke' />
<author initials='E. P.' surname='Rathgeb' fullname='Erwin P. Rathgeb' />
<author initials='M.' surname='Tuexen' fullname='Michael Tuexen' />
<date month='December' year='2010' />
</front>
<seriesInfo name='Proceedings' value='of the IEEE Global Communications Conference (GLOBECOM)'/>
<format type='PDF' target='http://www.tdr.wiwi.uni-due.de/fileadmin/fileupload/I-TDR/SCTP/Paper/Globecom2010.pdf'/>
</reference>
<reference anchor='ADB11'>
<front>
<title>Evaluation of Concurrent Multipath Transfer over Dissimilar Paths</title>
<author initials='H.' surname='Adhari' fullname='Hakim Adhari' />
<author initials='T.' surname='Dreibholz' fullname='Thomas Dreibholz' />
<author initials='M.' surname='Becke' fullname='Martin Becke' />
<author initials='E. P.' surname='Rathgeb' fullname='Erwin Paul Rathgeb' />
<author initials='M.' surname='Tüxen' fullname='Michael Tüxen' />
<date month='March' year='2011' />
</front>
<seriesInfo name='Proceedings' value='of the 1st International Workshop on Protocols and Applications with Multi-Homing Support (PAMS)' />
<format type='PDF' octets='681374' target='http://www.tdr.wiwi.uni-due.de/fileadmin/fileupload/I-TDR/SCTP/Paper/PAMS2011.pdf' />
</reference>
<reference anchor='DBA11'>
<front>
<title>On the Impact of Congestion Control for Concurrent Multipath Transfer on the Transport Layer</title>
<author initials='T.' surname='Dreibholz' fullname='T. Dreibholz' />
<author initials='M.' surname='Becke' fullname='M. Becke' />
<author initials='H.' surname='Adhari' fullname='H. Adhari' />
<author initials='E. P.' surname='Rathgeb' fullname='E. P. Rathgeb' />
<date month='June' year='2011' />
</front>
<seriesInfo name='Proceedings' value='of the 11th IEEE International Conference on Telecommunications (ConTEL)' />
<format type='PDF' target='http://www.tdr.wiwi.uni-due.de/fileadmin/fileupload/I-TDR/SCTP/Paper/ConTEL2011.pdf' />
</reference>
<reference anchor="BDA12">
<front>
<title>On the Fairness of Transport Protocols in a Multi-Path Environment</title>
<author initials="M." surname="Becke" fullname="Martin Becke" />
<author initials="T." surname="Dreibholz" fullname="Thomas Dreibholz" />
<author initials="H." surname="Adhari" fullname="Hakim Adhari" />
<author initials="E. P." surname="Rathgeb" fullname="Erwin Paul Rathgeb" />
<date day="12" month="June" year="2012" />
</front>
<seriesInfo name="Proceedings of the IEEE International Conference on Communications (ICC)" value="" />
<format type="PDF" octets="2016722" target="http://www.tdr.wiwi.uni-due.de/fileadmin/fileupload/I-TDR/SCTP/Paper/ICC2012.pdf" />
</reference>
<reference anchor="Dre2012">
<front>
<title>Evaluation and Optimisation of Multi-Path Transport using the Stream Control Transmission Protocol</title>
<author initials="T." surname="Dreibholz" fullname="Thomas Dreibholz" />
<date day="13" month="March" year="2012" />
</front>
<format type="PDF" octets="37661345" target="http://duepublico.uni-duisburg-essen.de/servlets/DerivateServlet/Derivate-29737/Dre2012_final.pdf" />
</reference>
<reference anchor="NorNet-Website">
<front>
<title>NorNet -- A Real-World, Large-Scale Multi-Homing Testbed</title>
<author initials="J." surname="Xiang" fullname="Jie Xiang" />
<date year="2013" />
</front>
<format type="HTML" octets="1024" target="http://www.nntb.no/" />
<annotation>http://www.nntb.no/</annotation>
</reference>
<reference anchor="PAMS2013-NorNet">
<front>
<title>Design and Implementation of the NorNet Core Research Testbed for Multi-Homed Systems</title>
<author initials="T." surname="Dreibholz" fullname="Thomas Dreibholz" />
<author initials="E. G." surname="Gran" fullname="Ernst Gunnar Gran" />
<date day="27" month="March" year="2013" />
</front>
<seriesInfo name="Proceedings of the 3nd International Workshop on Protocols and Applications with Multi-Homing Support (PAMS)," value="Pages 1094–1100, ISBN 978-0-7695-4952-1, DOI 10.1109/WAINA.2013.71" />
<format type="PDF" octets="20563001" target="http://simula.no/publications/threfereedinproceedingsreference.2012-12-20.7643198512/simula_pdf_file" />
</reference>
<reference anchor="NNUW1-Dreibholz-NorNetCore-Introduction">
<front>
<title>The NorNet Core Testbed – Introduction and Status</title>
<author initials="T." surname="Dreibholz" fullname="Thomas Dreibholz" />
<date day="18" month="September" year="2013" />
</front>
<seriesInfo name="Proceedings of the 1st International NorNet Users Workshop (NNUW-1)" value="" />
<format type="PDF" octets="8599639" target="http://simula.no/publications/Simula.simula.2124/simula_pdf_file" />
</reference>
<reference anchor="NNUW1-Dreibholz-NorNetCore-Tutorial">
<front>
<title>The NorNet Core Testbed – An Experiment Tutorial</title>
<author initials="T." surname="Dreibholz" fullname="Thomas Dreibholz" />
<date day="19" month="September" year="2013" />
</front>
<seriesInfo name="Proceedings of the 1st International NorNet Users Workshop (NNUW-1)" value="" />
<format type="PDF" octets="4560635" target="http://simula.no/publications/Simula.simula.2130/simula_pdf_file" />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 03:19:32 |