One document matched: draft-tuexen-tsvwg-sctp-sack-immediately-01.xml

<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc strict="yes" ?>

<rfc category="std" ipr="trust200811" docName="draft-tuexen-tsvwg-sctp-sack-immediately-01.txt">
<front>
<title abbrev="SACK-IMMEDIATELY">SACK-IMMEDIATELY extension for the Stream Control Transmission Protocol</title>


<!-- ************** MICHAEL TUEXEN *************** -->
<author initials="M." surname="Tuexen" fullname="Michael Tuexen">
<organization>Muenster Univ. of Applied Sciences</organization>
<address>
    <postal>
        <street>Stegerwaldstr. 39</street>
        <city>48565 Steinfurt</city>
        <country>Germany</country>
    </postal>
    <email>tuexen@fh-muenster.de</email>
</address>
</author>

<!-- *************** IRENE RUENGELER ***************** -->
<author initials="I." surname="Ruengeler" fullname="Irene Ruengeler">
<organization>Muenster Univ. of Applied Sciences</organization>
<address>
    <postal>
        <street>Stegerwaldstr. 39</street>
        <city>48565 Steinfurt</city>
        <country>Germany</country>
    </postal>
    <email>i.ruengeler@fh-muenster.de</email>
</address>
</author>

<!-- ************** RANDALL STEWART ***************-->
<author initials="R. R." surname="Stewart" fullname="Randall R. Stewart">
<organization>Researcher</organization>
<address>
    <postal>
        <street></street>
        <street></street>
        <city>Chapin</city> <region>SC</region>
        <code>29036</code>
        <country>USA</country>
    </postal>
    <phone></phone>
    <email>randall@lakerest.net</email>
</address>
</author>

<date year="2009" />

<keyword>Internet-Draft</keyword>

<abstract>
<t>This document defines a method for a sender of a DATA chunk
to indicate that the corresponding SACK chunk should be sent
back immediately.</t>
</abstract>
</front>

<middle>

<section anchor="intro" title="Introduction">
<t><xref target='RFC4960'/> states that an SCTP implementation
should use delayed SACKs. In combination with the Nagle algorithm,
reduced congestion windows after timeouts, the handling of
the SHUTDOWN-SENDING state, or other situations this might result
in reduced performance of the protocol.</t>

<t>This document describes a simple extension of the SCTP DATA
chunk by defining a new flag, the I-bit. The sender indicates by
setting this bit that the corresponding SACK chunk should be sent
back without delaying it.</t>
</section>

<section anchor="conventions" 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 title="The I-bit in the DATA Chunk Header">
<t>The following <xref target='ext_data_chunk'/> shows the extended DATA chunk.
<figure anchor='ext_data_chunk'>
<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 = 0    |  Res  |I|U|B|E|           Length              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              TSN                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Stream Identifier      |     Stream Sequence Number    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                  Payload Protocol Identifier                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\                                                               \
/                           User Data                           /
\                                                               \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
The only difference between the DATA chunk in
<xref target='ext_data_chunk'/> and the DATA chunk defined in
<xref target='RFC4960'/> is the addition of the I-bit in the flags
field of the chunk header.</t>
</section>

<section title="Procedures">
<section title="Sender Side Considerations">
<t>Whenever the sender of a DATA chunk can benefit from the corresponding
SACK chunk being sent back without delay, the sender MAY set the I-bit
in the DATA chunk header.</t>

<t>Reasons for setting the I-bit include
<list style='symbols'>
<t>The sender has not enough queued user data to send the remaining DATA
   chunks due to the Nagle algorithm.</t>
<t>The sending of a DATA chunk fills the congestion or receiver window.</t>
<t>The sender is in the SHUTDOWN-PENDING state.</t>
<t>The sender has reduced its RTO.Min such that a retransmission timeout will
   occur if the receiver would delay its SACK.</t>
</list>
</t>
</section>

<section title="Receiver Side Considerations">
<t>On reception of an SCTP packet containing a DATA chunk with the I-bit set,
the receiver SHOULD NOT delay the sending of the corresponding SACK chunk
and SHOULD send it back immediately.</t>
</section>
</section>

<section title="Interoperability Considerations">
<t>According to <xref target='RFC4960'/> a receiver of a DATA chunk with
the I-bit set should ignore this bit when it does not support the extension
described in this document. Since the sender of the DATA chunk is
able to handle this case, there is no requirement for negotiating
the feature described in this document.</t>
</section>

<section title="IANA Considerations">
<t>There are no actions required from IANA.</t>
</section>

<section 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>


</middle>

<back>
<references title='Normative References'>
<?rfc include="reference.RFC.2119" ?>
<?rfc include="reference.RFC.4960" ?>
</references>
<!--
<references title='Informative References'>
<?rfc include="reference.I-D.ietf-pmtud-method" ?>
</references>
-->
</back>
</rfc>