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

Date: Mon, 31 Aug 2009 17:47:45 +0300
From: Ilpo Järvinen <ilpo.jarvinen@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
Precedence: list

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