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

Fred Baker <> Tue, 27 April 2010 03:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 87AFA3A6B6E for <>; Mon, 26 Apr 2010 20:00:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -100.247
X-Spam-Status: No, score=-100.247 tagged_above=-999 required=5 tests=[AWL=2.352, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gONHqxiMW-Ga for <>; Mon, 26 Apr 2010 20:00:40 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id F03EE3A6949 for <>; Mon, 26 Apr 2010 20:00:39 -0700 (PDT)
Authentication-Results:; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ArMBAJfv1UuQ/uCWiWdsb2JhbACcRhUBAQEKCxERBhykcpoVhQsEjxg
X-IronPort-AV: E=Sophos;i="4.52,277,1270425600"; d="scan'208";a="6237139"
Received: from ([]) by with ESMTP; 27 Apr 2010 02:23:36 +0000
Received: from [] ( []) by (8.13.8/8.14.3) with ESMTP id o3R30OuS022402; Tue, 27 Apr 2010 03:00:24 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 04:00:24 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To:,, Mark Allman <>,,
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 03:00:41 -0000

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, wrote:

> 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:, 
>          , 
>          ,, 
>        Pages:      15
>        Characters: 35383
>        Updates/Obsoletes/SeeAlso:   None
>        I-D Tag:    draft-ietf-tcpm-early-rexmt-04.txt
>        URL:
> 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
> For searching the RFC series, see
> For downloading RFCs, see
> Requests for special distribution should be addressed to either the
> author of the RFC in question, or to  Unless
> specifically noted otherwise on the RFC itself, all RFCs are for
> unlimited distribution.
> The RFC Editor Team
> Association Management Solutions, LLC
> _______________________________________________
> IETF-Announce mailing list