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

Zimmermann Alexander <Alexander.Zimmermann@nets.rwth-aachen.de> Thu, 10 September 2009 14:08 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 A342A28C19E for <tcpm@core3.amsl.com>; Thu, 10 Sep 2009 07:08:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.312
X-Spam-Level:
X-Spam-Status: No, score=-4.312 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, 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 aLCibeG1+4lr for <tcpm@core3.amsl.com>; Thu, 10 Sep 2009 07:08:19 -0700 (PDT)
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 86B6328C1A4 for <tcpm@ietf.org>; Thu, 10 Sep 2009 07:08:19 -0700 (PDT)
MIME-version: 1.0
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 <0KPR00NKXDYS0QE0@mta-2.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Thu, 10 Sep 2009 16:08:52 +0200 (CEST)
X-IronPort-AV: E=Sophos; i="4.44,364,1249250400"; d="sig'?scan'208"; a="25447688"
Received: from smarthost-1.ms.rz.rwth-aachen.de (HELO smarthost.rwth-aachen.de) ([134.130.7.89]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Thu, 10 Sep 2009 16:08:52 +0200
Received: from octopussy.informatik.RWTH-Aachen.DE (octopussy.informatik.RWTH-Aachen.DE [137.226.12.181]) by smarthost.rwth-aachen.de (8.13.8+Sun/8.13.8/1) with ESMTP id n8AE8qte021531; Thu, 10 Sep 2009 16:08:52 +0200 (CEST)
Message-id: <7C14E36A-B00F-48DD-80FA-431B530B7E6D@nets.rwth-aachen.de>
From: Zimmermann Alexander <Alexander.Zimmermann@nets.rwth-aachen.de>
To: =?ISO-8859-1?Q?Ilpo_J=E4rvinen?= <ilpo.jarvinen@helsinki.fi>
In-reply-to: <alpine.DEB.2.00.0908311640330.29341@wel-95.cs.helsinki.fi>
Content-type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary=Apple-Mail-1--593572196
Content-transfer-encoding: 7bit
Date: Thu, 10 Sep 2009 16:05:34 +0200
References: <C6D4D39B-2E9B-4D88-A4A4-15908B503BB5@nets.rwth-aachen.de> <alpine.DEB.2.00.0908311640330.29341@wel-95.cs.helsinki.fi>
X-Pgp-Agent: GPGMail 1.2.0 (v56)
X-Mailer: Apple Mail (2.936)
Cc: "tcpm@ietf.org" <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: Thu, 10 Sep 2009 14:08:20 -0000

Hi Ilpo,...

Am 31.08.2009 um 16:47 schrieb Ilpo Järvinen:

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

First of all, thanks a lot for your valuable input to both the Linux  
implementation and the ID.

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

Ack. After all I-D.schuetz... describes a TCP option. However, I think  
the definition of "short"
  and "long" connectivity is important for this draft. We'll rephrase  
that paragraph.

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

Ok, we'll rephrase that.

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

I thought so. But you are right. We should clarify that we regard the
timeout-based loss recovery as "completed" as soon as an acceptable  
ACK arrives.
And not when all losses are recovered. Thanks!

BTW: I think it was never defined in any RFC?

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

Good point. We tried to allow for other RTO backoff schemes than  
RFC2988,
but as the formula now is already highly dependent on RFC2988 we
could very well change that. I have to think about this.

>
> 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"?

Ack. We'll change that.

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

Yep. We'll change that.

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

Jo. We'll change that.

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

True but it is even more unlikely. That would mean the ICMP is so  
late, that
a new flow could get created with the same 4-tuple (previous  
connection out
of TIME_WAIT). But as Joe had some concerns about this case we'll  
explicitly
address that too.

Alex

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