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
From: Ilpo Järvinen <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.
- [tcpm] New Version Notification for draft-zimmerm… Alexander Zimmermann
- Re: [tcpm] New Version Notification for draft-zim… Ilpo Järvinen
- Re: [tcpm] New Version Notification for draft-zim… Zimmermann Alexander