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

Mark Allman <mallman@icir.org> Tue, 27 April 2010 04:18 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 5184328C0FE for <tcpm@core3.amsl.com>; Mon, 26 Apr 2010 21:18:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.197
X-Spam-Level:
X-Spam-Status: No, score=-5.197 tagged_above=-999 required=5 tests=[AWL=1.402, BAYES_00=-2.599, 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 xBQT08ULdQ-4 for <tcpm@core3.amsl.com>; Mon, 26 Apr 2010 21:18:26 -0700 (PDT)
Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id E99F03A6883 for <tcpm@ietf.org>; Mon, 26 Apr 2010 21:18:22 -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 o3R4I89p023851; Mon, 26 Apr 2010 21:18:09 -0700 (PDT)
Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id D6F51F24164; Tue, 27 Apr 2010 00:18:08 -0400 (EDT)
To: Fred Baker <fred@cisco.com>
From: Mark Allman <mallman@icir.org>
In-Reply-To: <8D6E7279-21DC-44CC-A623-671A18D951C3@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="--------ma25984-1"; micalg="pgp-sha1"; protocol="application/pgp-signature"
Date: Tue, 27 Apr 2010 00:18:08 -0400
Sender: mallman@icir.org
Message-Id: <20100427041808.D6F51F24164@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 04:18:36 -0000

> 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