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

[Zimmermann Alexander <[e-mail]>]

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.