Re: [tcpm] Review: draft-ietf-tcpm-early-rexmt-01

Joe Touch <touch@ISI.EDU> Wed, 23 September 2009 15:40 UTC

Return-Path: <touch@ISI.EDU>
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 A77013A659A for <tcpm@core3.amsl.com>; Wed, 23 Sep 2009 08:40:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 7+42Ra2tKZPO for <tcpm@core3.amsl.com>; Wed, 23 Sep 2009 08:40:05 -0700 (PDT)
Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 1C43C3A6887 for <tcpm@ietf.org>; Wed, 23 Sep 2009 08:40:05 -0700 (PDT)
Received: from [70.208.68.126] (126.sub-70-208-68.myvzw.com [70.208.68.126]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id n8NFebfL018789 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 23 Sep 2009 08:40:41 -0700 (PDT)
Message-ID: <4ABA4174.6030207@isi.edu>
Date: Wed, 23 Sep 2009 08:40:36 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Alexander Zimmermann <Alexander.Zimmermann@nets.rwth-aachen.de>
References: <20090923130457.50D1D4AEFE3@lawyers.icir.org> <4ABA307D.5080408@isi.edu> <AB41211F-A648-4C5A-8DED-819231902693@nets.rwth-aachen.de>
In-Reply-To: <AB41211F-A648-4C5A-8DED-819231902693@nets.rwth-aachen.de>
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-MailScanner-ID: n8NFebfL018789
X-ISI-4-69-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: "tcpm@ietf.org" <tcpm@ietf.org>, "mallman@icir.org" <mallman@icir.org>
Subject: Re: [tcpm] Review: draft-ietf-tcpm-early-rexmt-01
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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: Wed, 23 Sep 2009 15:40:11 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Works for me.

Joe

Alexander Zimmermann wrote:
> Hi Joe, hi Mark,
> 
> may be we can reuse a paragraph from RFC 3517:
> 
> "We define a variable "DupThresh" that holds the number of duplicate
> acknowledgments required to trigger a retransmission. Per [RFC2581] this
> threshold is defined to be 3 duplicate acknowledgments. However,
> implementers should consult any updates to [RFC2581] to determine the
> current value for DupThresh (or method for determining its value)."
> 
> First, it's easier to see where the magic *4* comes from, second it's 
> future-proof when "5681bis" alters the number of duplicate Acks required
> for fast retransmit. :-)
> 
> Alex
> 
> Am 23.09.2009 um 16:28 schrieb Joe Touch:
> 
>> ...
>>>> In 2.1, do you want to define this in terms a fixed value of 4*SMSS,
>>>> or define it as a pointer (i.e., to the initial CWND, so if init CWND
>>>> increases, so does this?) same for the part about packet-based (again,
>>>> would that be segment-based?) not referring to 4, but the number of
>>>> segments in the initial CWND (e.g., as "currently 4" -- PS, should
>>>> that be 4, or shouldn't it be "initial_CWND/SMSS", i.e., a max of 4,
>>>> but in most current cases it seems like this would still be 3).
>>>
>>> No, I don't.  This doesn't have anything to do with the initial
>>> congestion window size.  The "4"---which I thought was well motivated,
>>> perhaps not---comes from fast retransmit's magic constant of "3".  I.e.,
>>> if there are at least 4 segments outstanding and we lose one then we'll
>>> have a shot at getting 3 dupacks.  If there are fewer segments
>>> outstanding then we will have no chance at getting 3 dupacks.  So, this
>>> has nothing to do with the initial window.
>>
>> I didn't get that as clearly. It might be useful to reiterate it when
>> the number is introduced (maybe a few times for people like me who
>> miss it).
> 
> //
> // Dipl.-Inform. Alexander Zimmermann
> // Department of Computer Science, Informatik 4
> // RWTH Aachen University
> // Ahornstr. 55, 52056 Aachen, Germany
> // phone: (49-241) 80-21422, fax: (49-241) 80-22220
> // email: zimmermann@cs.rwth-aachen.de
> // web: http://www.umic-mesh.net
> //
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iEYEARECAAYFAkq6QXQACgkQE5f5cImnZrvejQCg53uwYJsYZ2S1vVQ1udQT4/LL
eFUAn0/WXmKENoHZPHqWX6in8De+V3cw
=eLRy
-----END PGP SIGNATURE-----