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

Mark Allman <mallman@icir.org> Tue, 22 September 2009 19:28 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 D3CD13A6ACF for <tcpm@core3.amsl.com>; Tue, 22 Sep 2009 12:28:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.426
X-Spam-Level:
X-Spam-Status: No, score=-2.426 tagged_above=-999 required=5 tests=[AWL=0.173, 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 vvXh+pb8Q82r for <tcpm@core3.amsl.com>; Tue, 22 Sep 2009 12:28:55 -0700 (PDT)
Received: from pork.ICSI.Berkeley.EDU (pork.ICSI.Berkeley.EDU [192.150.186.19]) by core3.amsl.com (Postfix) with ESMTP id 7B6123A6AC8 for <tcpm@ietf.org>; Tue, 22 Sep 2009 12:28:53 -0700 (PDT)
Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id n8MJTv8U005871; Tue, 22 Sep 2009 12:29:57 -0700
Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id 84DC03D2D8F1; Tue, 22 Sep 2009 15:29:50 -0400 (EDT)
Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 9A1BD4AB959; Tue, 22 Sep 2009 15:29:50 -0400 (EDT)
To: Alexander Zimmermann <alexander.zimmermann@nets.rwth-aachen.de>
From: Mark Allman <mallman@icir.org>
In-Reply-To: <A63D9429-A09B-42CD-AD4A-BFF7C9D9E768@nets.rwth-aachen.de>
Organization: International Computer Science Institute (ICSI)
Song-of-the-Day: In the City
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="--------ma9646-1"; micalg="pgp-sha1"; protocol="application/pgp-signature"
Date: Tue, 22 Sep 2009 15:29:50 -0400
Sender: mallman@icir.org
Message-Id: <20090922192950.9A1BD4AB959@lawyers.icir.org>
Cc: tcpm@ietf.org
Subject: Re: [tcpm] Review: draft-ietf-tcpm-early-rexmt-01
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, 22 Sep 2009 19:29:03 -0000

> as requested at the last TCPM meeting in Stockholm that we need some
> reviews for Early Retransmit (draft-ietf-tcpm-early-rexmt-01), here
> are some comments from me:

Many thanks for the comments!

> * The "entry point" of the algorithm could be better described. For
> * example lets begin paragraph 2 in section 2.1 as follows: When an
> * acknowledgment arrives at the sender, the sender ...

I don't entirely understand where you're talking about in section 2.1.
The above sentence fragment does not look like it meshes well with any
of the paragraphs that I can identify that you might be talking about.
I am going to take this for a nit and ignore it for now.  If this is
more than stylistic please send a more verbose change request.

> * What about RFC4653 - Improving the Robustness of TCP to Non-
> Congestion Events? Is Early Retransmit compatible to RFC4653? At
> first  glance I think yes, when we define a priority which algo
> should alter  Dupthresh

We don't need a priority.  The algorithms operate in different regions
of the operating space.  I put the following paragraph in the related
work section:

    [RFC4653] also defines an orthogonal method for altering the
    duplicate ACK threshold.  The mechanisms proposed in this document
    decrease the duplicate ACK threshold when a small amount of data is
    outstanding.  Meanwhile, the mechanisms in [RFC4653] increase the
    duplicate ACK threshold (over the standard of 3) when the congestion
    window is large in an effort to increase robustness to packet
    reordering.


> * Section 1, para 3: s/Small windows/Small congestion windows/

Done.

> * Section 1, last para: Explanation of the difference between
> * Limited  Transmit and Early Retransmit. Maybe we can put here a
> * pointer to the  aforementioned case why a CWND can be small. For
> * example (last  sentence): The "Early Retransmit" mechanism
> * outlined in this document  covers the case when previously unsent
> * data is not available (case 2)  for transmission or cannot be
> * transmitted due to an advertised window  limitation (case 1).

I did this, but instead of "case 1" I used "case 3" which is what I
believe you meant.

allman