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

Mark Allman <> Tue, 22 September 2009 19:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D3CD13A6ACF for <>; Tue, 22 Sep 2009 12:28:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.426
X-Spam-Status: No, score=-2.426 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vvXh+pb8Q82r for <>; Tue, 22 Sep 2009 12:28:55 -0700 (PDT)
Received: from pork.ICSI.Berkeley.EDU (pork.ICSI.Berkeley.EDU []) by (Postfix) with ESMTP id 7B6123A6AC8 for <>; Tue, 22 Sep 2009 12:28:53 -0700 (PDT)
Received: from ( []) by pork.ICSI.Berkeley.EDU ( with ESMTP id n8MJTv8U005871; Tue, 22 Sep 2009 12:29:57 -0700
Received: from ( []) by (Postfix) with ESMTP id 84DC03D2D8F1; Tue, 22 Sep 2009 15:29:50 -0400 (EDT)
Received: from (localhost []) by (Postfix) with ESMTP id 9A1BD4AB959; Tue, 22 Sep 2009 15:29:50 -0400 (EDT)
To: Alexander Zimmermann <>
From: Mark Allman <>
In-Reply-To: <>
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
Message-Id: <>
Subject: Re: [tcpm] Review: draft-ietf-tcpm-early-rexmt-01
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, 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

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


> * 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.