Re: [tcpm] New Version Notification for draft-zimmermann-tcp-lcd-02

" Ilpo Järvinen " <ilpo.jarvinen@helsinki.fi> Mon, 31 August 2009 14:47 UTC

Return-Path: <ilpo.jarvinen@helsinki.fi>
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 1CC3F3A6AD1 for <tcpm@core3.amsl.com>; Mon, 31 Aug 2009 07:47:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.872
X-Spam-Level:
X-Spam-Status: No, score=-5.872 tagged_above=-999 required=5 tests=[AWL=0.427, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 Y9fGiZ-ib3-C for <tcpm@core3.amsl.com>; Mon, 31 Aug 2009 07:47:36 -0700 (PDT)
Received: from mail.cs.helsinki.fi (courier.cs.helsinki.fi [128.214.9.1]) by core3.amsl.com (Postfix) with ESMTP id 31D793A68D5 for <tcpm@ietf.org>; Mon, 31 Aug 2009 07:47:35 -0700 (PDT)
Received: from wel-95.cs.helsinki.fi (wel-95.cs.helsinki.fi [128.214.10.211]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Mon, 31 Aug 2009 17:47:45 +0300 id 00063E36.4A9BE291.00006DDA
Date: Mon, 31 Aug 2009 17:47:45 +0300 (EEST)
From: "=?ISO-8859-15?Q?Ilpo_J=E4rvinen?=" <ilpo.jarvinen@helsinki.fi>
X-X-Sender: ijjarvin@wel-95.cs.helsinki.fi
To: Alexander Zimmermann <alexander.zimmermann@nets.rwth-aachen.de>
In-Reply-To: <C6D4D39B-2E9B-4D88-A4A4-15908B503BB5@nets.rwth-aachen.de>
Message-ID: <alpine.DEB.2.00.0908311640330.29341@wel-95.cs.helsinki.fi>
References: <C6D4D39B-2E9B-4D88-A4A4-15908B503BB5@nets.rwth-aachen.de>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Cc: tcpm@ietf.org
Subject: Re: [tcpm] New Version Notification for draft-zimmermann-tcp-lcd-02
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: Mon, 31 Aug 2009 14:47:37 -0000

On Wed, 26 Aug 2009, Alexander Zimmermann wrote:

> I upload a new version of our draft to the IETF repository:
> http://www.ietf.org/internet-drafts/draft-zimmermann-tcp-lcd-02.txt
>
> As always, comments are more than welcome.

I did read throught -01 before -02 was made available and I quickly went 
through the diffs for -02 (and also did read -00 earlier, was among those 
who had read it). I support adopting this id as WG item. After reviewing 
the Linux implementation too, I'd say it looks very straightforward, 
simple and clean to implement too (with rather little effort).

Then some comments:

2., 2nd paragraph.
I somewhat feel a bit strange on the importance that is placed in this ID 
for I-D.schuetz-... in defining the meaning "short" and "long" 
connectivity disruptions.

3., 2nd to last paragraph.
"This may very well be the case when TCP is recovering lost segments (...)."
It's very unclear to me whether you mean negative or positive statement 
here with the unclarity associated the use of "This".

4.2., 1st paragraph.
"... a timeout-based loss recovery has already been started but not 
completed". Are you sure that it is crystal clear what "not completing"
"timeout-based loss recovery" means?

4.2., the algorithm itself.
Why not just increase backoff_cnt unconditionally on rto and provide the 
proper cap in the "RTO := RTO_base * 2^(Backoff_cnt)" formula? It makes 
very little difference in practice and arquably can even be considered to 
be more "safe" to count lost retransmissions correctly if the rto cap was 
reached (and bypassed) before any icmps did come?

4.2., last paragraph.
IMHO the change to the "new started retransmission timer" isn't that good, 
however, I agree that changing it to something is necessary as the 
the previous use of "RTO" wasn't that good either. Perhaps something like 
"shortened" would be a good replacement to the "started"?

4.3., 4th paragraph.
A self-reference (see Section 4.3)?

Same paragraph.
I think that the sentence starting with "However, " is mis-comma'fied.

4.3., 5th paragraph.
Isn't it enough that any TCP flow with the same 4-tuple matches with
previous one's seqno (not required to be exactly the same flow with the 
correct seqno)? ...I guess it is most likely to happen with the same flow 
though.


Nits:

An revert -> A revert (2.)
..., back offs -> ..., backs off (4.2.)
scheme flood -> scheme to flood (7.)
to attempt to maliciously -> in attempt to maliciously (7.) ?


-- 
  i.