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

Fred Baker <> Tue, 27 April 2010 04:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 63A303A6C38 for <>; Mon, 26 Apr 2010 21:13:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -100.216
X-Spam-Status: No, score=-100.216 tagged_above=-999 required=5 tests=[AWL=-0.031, BAYES_40=-0.185, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OiOEkLEL43fP for <>; Mon, 26 Apr 2010 21:13:31 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E0EF73A67A6 for <>; Mon, 26 Apr 2010 21:13:23 -0700 (PDT)
Authentication-Results:; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AjIBACsB1kuQ/uCWiWdsb2JhbACQPYwMFQEBAQoLEREGHKQqmh+FDAQ
X-IronPort-AV: E=Sophos;i="4.52,277,1270425600"; d="scan'208";a="6238017"
Received: from ([]) by with ESMTP; 27 Apr 2010 03:36:22 +0000
Received: from [] ( []) by (8.13.8/8.14.3) with ESMTP id o3R4DA7A005889; Tue, 27 Apr 2010 04:13:10 GMT
Mime-Version: 1.0 (Apple Message framework v1078)
Content-Type: text/plain; charset="us-ascii"
From: Fred Baker <>
In-Reply-To: <>
Date: Tue, 27 Apr 2010 05:13:10 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
X-Mailer: Apple Mail (2.1078)
X-Mailman-Approved-At: Tue, 27 Apr 2010 08:18:41 -0700
Subject: Re: [tcpm] RFC 5827 on Early Retransmit for and Stream Control Transmission Protocol (SCTP)
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 27 Apr 2010 04:13:32 -0000

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.

On Apr 27, 2010, at 4:16 AM, Mark Allman wrote:

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