Subject: Re: [tcpm] I-D Action:draft-ietf-tcpm-rfc3782-bis-00.txt

From: "Henderson, Thomas R" <[email-masked]>
Date: Tue, 1 Feb 2011 11:35:43 -0800

Alex, thanks for timely feedback on this draft.  Responses inline below...

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Alexander Zimmermann
> Sent: Monday, January 24, 2011 11:53 AM
> To: tcpm WG
> Subject: Re: [tcpm] I-D Action:draft-ietf-tcpm-rfc3782-bis-00.txt
> 
> What a coincidence! Just at the moment I wrote my comments about
> rfc3782bis, the notification came in...
> 
> Here are some ideas for further improvement. I don't feel strongly
> about any of the following points, However, IMO RFC3782 is too
> complicated. RFC2582 is much easier to understand. Why?
>    * The Problem of "Avoiding Multiple Fast Retransmit" is better
> explain
>    * We don't have in every second sentence an ns2 example call
> 
> 
> * Sec 1: Lack of a proper problem description
> 
> What we have is this (2nd para)
> 
> "Problems can arise, therefore, when multiple packets are dropped from
> a single window of data and the Fast Retransmit and Fast Recovery
> algorithms are invoked."
> 
> But is what really the problem? AFAIK, the "original" problem was that
> Reno run into an RTO, if we have more than two or three losses in a
> single window of data.
> The main problem (AFAIK) was for example not, that we execute multiple
> times FRet in one window (provided that we get enough DUPACKs)

The original RFC (and revisions) jointly addresses two possible problems that can occur with multiple losses in a single window:  1) Reno would typically take a timeout (documented in Janey Hoe's Sigcomm '96 paper), and 2) even if an RTO doesn't occur, multiple fast retransmits and window reductions could occur (documented in Sally Floyd's 1994 technical report).

Based on your comment, I would propose to more clearly state the problems rather than the current language that says "Problems can arise...".

> 
> 
> * New Sec between Sec 2 and Sec 3: Basic idea of the algo
> 
> I love basic ideas! In that case the reader has some ideas how the algo
> works, before he read it step by step.

Rather than a new section, I would propose just adding something like this to the top of Section 3:

"The basic idea of these modifications is to infer, from the arrival of duplicate acknowledgements, whether multiple losses in the same window of data have most likely occurred, and to avoid taking a retransmit timeout or making multiple congestion window reductions due to such an event."

> 
> Here, we could also directly mention that the following step 1), 1b)
> and 6) are require to fix *another* problem that the original one. The
> first time I read RFC3782, is was not that easy to figure out that this
> steps fix another issue.

This problem was originally addressed in Section 5 of RFC 2582, so it was not new for RFC 3782.  In RFC 2582, implementors had to implement the steps in Section 3, then read Section 5 and consider adding more steps to those found in Section 3, and to make a policy choice as to which variant of Section 5 to implement.  In RFC 3782, a single variant was moved forward and integrated with Section 3, so that implementors could just follow a single specification section (Section 3).  

> 
> 
> * Sec 5: IMO delete it or move it to an appendix.

I would be OK with moving it to an appendix since it is not normative material and discusses variations.

> 
> 
> * Sec 6: Really, really complicated...
> 
> Take for example RFC2582 or [GF04] (only the intro). Much easier to
> understand. With
> this two doc, you can understand the problem.
> 
> For example:
>   - In RFC3782, 1st para: It confused the reader more than it helps.
>   - In RFC3782, 3rd para: Oh my god ;-) Regarding to RFC2582, why do we
> delete the most
>     important sentence here: "Thus with NewReno, the problem of
> multiple Fast Retransmits
>     from a single window of data can only occur after a Retransmit
> Timeout."
> 
>     Say the problem/goal: we want to block a FRet *after an RTO* until
> we reach recover.
>   - In RFC3782, 4th para: It confused the reader more than it helps.
> Typically, the changes
>     between versions are not intermixed with a problem description.
> Make an own Section where
>     we can describe the diffs. BTW, we have already such a section.

Without responding point-by-point to the above, I agree that this section would benefit from a rewrite.

> 
> 
> * IMO Section 7,8,9,10,11 should move to an appendix

I would prefer to keep sections 7 and 8 in the main body since it is material that would be useful for implementors to keep in mind.  However, I can see the rationale for moving the other sections (9-11) to appendices since they are more background/informational.

Regarding the citation of ns-2 scripts, I think that it is very useful to be able to refer to these scripts because they document each issue precisely, but I realize that it is probably uncommon to cite them inline in the text as is presently done.  Perhaps in the revision, these can either be moved to the appendices or else turned into more traditional (informative) reference citations.

- Tom 

> 
> Alex
> 
> [GF04]: Resolving Acknowledgment Ambiguity in non-SACK TCP
>