Subject: [tcpm] RFC 5827 on Early Retransmit for and Stream Control Transmission Protocol (SCTP)

From: [email-masked]
Date: Mon, 26 Apr 2010 16:50:14 -0700 (PDT)

A new Request for Comments is now available in online RFC libraries.

        RFC 5827

        Title:      Early Retransmit for and Stream 
                    Control Transmission Protocol (SCTP) 
        Author:     M. Allman, K. Avrachenkov,
                    U. Ayesta, J. Blanton,
                    P. Hurtig
        Status:     Experimental
        Stream:     IETF
        Date:       April 2010
        Mailbox:    [email-masked], 
                    [email-masked], 
                    [email-masked],  [email-masked], 
                    [email-masked]
        Pages:      15
        Characters: 35383
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-tcpm-early-rexmt-04.txt

        URL:        http://www.rfc-editor.org/rfc/rfc5827.txt

This document proposes a new mechanism for TCP and Stream Control 
Transmission Protocol (SCTP) that can be used to recover lost segments 
when a connection's congestion window is small.  The "Early Retransmit" 
mechanism allows the transport to reduce, in certain special 
circumstances, the number of duplicate acknowledgments required to trigger 
a fast retransmission.  This allows the transport to use fast retransmit 
to recover segment losses that would otherwise require a lengthy 
retransmission timeout.  [STANDARDS TRACK]

This document is a product of the TCP Maintenance and Minor Extensions Working Group of the IETF.

EXPERIMENTAL: This memo defines an Experimental Protocol for the
Internet community.  It does not specify an Internet standard of any
kind. Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

The RFC Editor Team
Association Management Solutions, LLC

---

From: Mark Allman <[email-masked]>
Date: Mon, 26 Apr 2010 23:16:19 -0400

> In cases in which cwnd < 4, it seems like your biggest concern is to
> elicit the information necessary to trigger the retransmission without
> unnecessarily burdening the path. That is in essence why we use three
> dup-acks as a trigger - it is "enough" information to ensure that with
> high probability it is not being triggered by simple packet
> reordering.  
> 
> Would it make sense to, when cwnd < 4 or all of the data available to
> transmit is in flight, in response to a SACK, send a segment
> containing exactly the TCP header, and one byte of SACKed data? The
> receipt of the SACK says that it is highly likely that the missing
> segment cleared the bottleneck, and would trigger an additional
> dup-ack containing the SACK record in question (which might trigger
> another of the same type of segment). If the missing segment is in
> fact lost, doing that would allow you to trigger three dup-acks in
> three RTTs even if you only had two segments outstanding (cwnd=2 or
> that's all the data you have). You only take the RTO if you literally
> have a single segment outstanding. If the missing segment in fact
> arrived but the ACK was lost, it would trigger the ACK. 

My quick response is ...

  - ER explicitly defers to Limited Transmit (RFC 3042) when possible,
    which is sorta what you describe, but not with dummy sorts of
    packets, but with packets off the top.  But, the point is the
    same---to try to drive the ACK process to a less ambiguous state.

  - I am not a big fan of dummy packets that really don't accomplish any
    work [*] (and, not just here; they've been proposed in a number of
    contexts).  My mental model says one of these packets you sketch
    above is about as much work as a data carrying packet and so why not
    just retransmit and be done with it?  Yeah, if we're wrong because
    of small scale reordering then we needlessly injected a packet.
    But, using the scheme above to try to better ensure the right action
    is taken we also injected a packet (or two).  And, in either case,
    the cwnd is so small cutting it isn't a huge deal, it seems to me.

    [*] By work I mean in the context transfer process, not in terms of
        the underlying mechanisms to get that done.  So, in my mind
        "work" == data packets or their ACKs and not control things such
        as you sketch.

allman

---

From: Mark Allman <[email-masked]>
Date: Tue, 27 Apr 2010 00:18:08 -0400

> I'm sure you're wiser than I. 

Well.

> I'm just thinking that in a context where cwnd<4 (pretty normal at my
> house when uploading to Picasa, which is an obvious file-transfer
> test, because the RTT is relatively short) sending after two dup-acks
> inserts a relatively large delay on the line in the event that it is a
> wrong guess.

Why?  I don't follow.

> If you're going to increase the chance of guessing wrong, it seems
> like you might want to minimize the side-effect of being wrong.

The side effect seems to me to be you inject an additional packet into
the network and cut the cwnd by a packet or two---which is readily
recouped (esp. if the RTT is short).  What else is there?

allman

---

From: Fred Baker <[email-masked]>
Date: Tue, 27 Apr 2010 04:00:24 +0100

Thinking out loud...

In cases in which cwnd < 4, it seems like your biggest concern is to elicit the information necessary to trigger the retransmission without unnecessarily burdening the path. That is in essence why we use three dup-acks as a trigger - it is "enough" information to ensure that with high probability it is not being triggered by simple packet reordering. 

Would it make sense to, when cwnd < 4 or all of the data available to transmit is in flight, in response to a SACK, send a segment containing exactly the TCP header, and one byte of SACKed data? The receipt of the SACK says that it is highly likely that the missing segment cleared the bottleneck, and would trigger an additional dup-ack containing the SACK record in question (which might trigger another of the same type of segment). If the missing segment is in fact lost, doing that would allow you to trigger three dup-acks in three RTTs even if you only had two segments outstanding (cwnd=2 or that's all the data you have). You only take the RTO if you literally have a single segment outstanding. If the missing segment in fact arrived but the ACK was lost, it would trigger the ACK.

On Apr 27, 2010, at 12:50 AM, [email-masked] wrote:

> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce

http://www.ipinc.net/IPv4.GIF

---

From: Fred Baker <[email-masked]>
Date: Tue, 27 Apr 2010 05:13:10 +0100

I'm sure you're wiser than I. I'm just thinking that in a context where cwnd<4 (pretty normal at my house when uploading to Picasa, which is an obvious file-transfer test, because the RTT is relatively short) sending after two dup-acks inserts a relatively large delay on the line in the event that it is a wrong guess. If you're going to increase the chance of guessing wrong, it seems like you might want to minimize the side-effect of being wrong.