Re: [tcpm] early retransmit done?

Alexander Zimmermann <alexander.zimmermann@nets.rwth-aachen.de> Wed, 11 November 2009 14:05 UTC

Return-Path: <alexander.zimmermann@nets.rwth-aachen.de>
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 42B1628C251 for <tcpm@core3.amsl.com>; Wed, 11 Nov 2009 06:05:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.233
X-Spam-Level:
X-Spam-Status: No, score=-4.233 tagged_above=-999 required=5 tests=[AWL=0.568, BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, 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 mKUQRB2dq21m for <tcpm@core3.amsl.com>; Wed, 11 Nov 2009 06:05:54 -0800 (PST)
Received: from mta-2.ms.rz.rwth-aachen.de (mta-2.ms.rz.RWTH-Aachen.DE [134.130.7.73]) by core3.amsl.com (Postfix) with ESMTP id 12E1528C184 for <tcpm@ietf.org>; Wed, 11 Nov 2009 06:05:54 -0800 (PST)
MIME-version: 1.0
Content-transfer-encoding: 7bit
Content-type: text/plain; charset="us-ascii"
Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-2.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0KSY00J3P76L39A0@mta-2.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Wed, 11 Nov 2009 15:06:21 +0100 (CET)
X-IronPort-AV: E=Sophos;i="4.44,723,1249250400"; d="scan'208";a="33384767"
Received: from relay-auth-2.ms.rz.rwth-aachen.de (HELO relay-auth-2) ([134.130.7.79]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Wed, 11 Nov 2009 15:06:21 +0100
Received: from miami.nets.rwth-aachen.de ([unknown] [137.226.12.180]) by relay-auth-2.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0KSY0094L76L9S40@relay-auth-2.ms.rz.rwth-aachen.de> for tcpm@ietf.org; Wed, 11 Nov 2009 15:06:21 +0100 (CET)
From: Alexander Zimmermann <alexander.zimmermann@nets.rwth-aachen.de>
In-reply-to: <20091027143025.C6B8B55F005@lawyers.icir.org>
Date: Wed, 11 Nov 2009 15:06:22 +0100
Message-id: <AADF073A-3DC7-4ADD-81FB-45009557D3B5@nets.rwth-aachen.de>
References: <20091027143025.C6B8B55F005@lawyers.icir.org>
To: "mallman@icir.org" <mallman@icir.org>
X-Mailer: Apple Mail (2.1077)
Cc: "k.avrachenkov@sophia.inria.fr" <k.avrachenkov@sophia.inria.fr>, "tcpm@ietf.org" <tcpm@ietf.org>, "jblanton@cs.ohiou.edu" <jblanton@cs.ohiou.edu>
Subject: Re: [tcpm] early retransmit done?
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, 11 Nov 2009 14:05:55 -0000

Hi Mark,

here my

*** Comments:

* Line 150-153. On Joe's request, you added some lines about ACK compression...
Ah sorry, Delay ACKs ;-). The first new sentence is fine and IMHO sufficient.
The second one confuse me (a litte bit). Why do you write "we assume that
receivers send immediate ACKs when there is a gap in the received sequence
space"? If a TCP would not send a DUPACK directly when OOO segment is received,
Early Rexmit wouldn't work? Maybe one or two sentence more could me "un-puzzle".

*  Line 252-253. 'We call this reduced ACK threshold enabling "Early
Retransimission"'. Maybe it's my limited english knowledge, you are the native
speaker, but IMHO the sentence sounds strange. What about this: "We call this
reduced duplicate ACK threshold "Early Retransmit".

* Line 222-224. In my last review I mentioned that we could probably better
specify the "entry point" of the algorithm. Example:

   Upon the arrival of an ACK, a sender employing byte-based Early
   Retransmit MUST use the following two conditions to determine
   when an Early Retransmit is sent:

* Line 226. Concerning Joe's question where magic *4* comes from. What do you
think about this?

   (2.a) The amount of outstanding data (ownd)---data sent but not yet
         acknowledged---is less or equal than 3*SMSS bytes, where is
         the lower bound of DupThresh from [RFC5681, RFC3517].


Mark, the last two point are really peanuts. If you don't like them, skip them.

*** Nits:
Missing Reference: 'RFC4653' is mentioned on line 419, but not defined

There are 5 instances of too long lines in the document, the longest one
being 2 characters in excess of 72.


*** Misspellings:
Line 91: s/implemention/implementation
Line 253: s/Retransimission/Retransmission (I know that it was Joe's misspelling ;-))
Line 312: s/Retransimission/Retransmission


Am 27.10.2009 um 15:30 schrieb Mark Allman:

> 
> We believe we have addressed all comments we received on the early
> retranmsit ID.  I just went to submit a new version and have missed the
> cut-off.  I have set a bit to submit when the system opens again on
> Nov/9.  However, until then I put the version I was going to submit here
> ...
> 
>  http://www.icir.org/mallman/papers/draft-ietf-tcpm-early-rexmt-02a.txt
> 
> Comments are very welcome.
> 
> allman
> 
> 
> 
> <ATT00001>_______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm

//
// 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
//