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

Mark Allman <mallman@icir.org> Tue, 27 April 2010 03:16 UTC

Return-Path: <mallman@icir.org>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92A173A6A08 for <tcpm@core3.amsl.com>; Mon, 26 Apr 2010 20:16:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.864
X-Spam-Level:
X-Spam-Status: No, score=-3.864 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7evxt+KSWH9I for <tcpm@core3.amsl.com>; Mon, 26 Apr 2010 20:16:38 -0700 (PDT)
Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id A080228C0FE for <tcpm@ietf.org>; Mon, 26 Apr 2010 20:16:33 -0700 (PDT)
Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id o3R3GJNQ018973; Mon, 26 Apr 2010 20:16:19 -0700 (PDT)
Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 661E0F22DD7; Mon, 26 Apr 2010 23:16:19 -0400 (EDT)
To: Fred Baker <fred@cisco.com>
From: Mark Allman <mallman@icir.org>
In-Reply-To: <1E5DD920-1E18-4F76-B724-5355431CB4DD@cisco.com>
Organization: International Computer Science Institute (ICSI)
Song-of-the-Day: Friend Of The Devil
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="--------ma22275-1"; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Mon, 26 Apr 2010 23:16:19 -0400
Sender: mallman@icir.org
Message-Id: <20100427031619.661E0F22DD7@lawyers.icir.org>
Cc: jblanton@masaka.cs.ohiou.edu, tcpm@ietf.org, k.avrachenkov@sophia.inria.fr
Subject: Re: [tcpm] RFC 5827 on Early Retransmit for and Stream Control Transmission Protocol (SCTP)
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: mallman@icir.org
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Apr 2010 03:16:39 -0000

> 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