Subject: [Gen-art] Gen-ART Review of draft-ietf-tcpm-tcp-roadmap-05

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 30 Jan 2006 11:08:43 -0600

I was selected as General Area Review Team reviewer for this specification
(for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Summary: This document is on the right track for publication as an 
Informational RFC. It is also on the right track for publication as an ISD, 
if we ever start publishing ISDs. But either way, I'm glad to see it being 
Last-Called.

Since this document is in Last Call, I do have some comments that I hope are 
helpful, but I'm not sending them as a Gen-ART reviewer.

Thanks,

Spencer

Last Call comments:

- In Section 3.1, the following text seems confusing:

   Since TCP traditionally (in the absence
   of ECN) uses losses to infer congestion, there is a rather intimate
   coupling between congestion control and loss recovery mechanisms.

Isn't it more correct to say that TCP always infers congestion from losses, 
and may also infer congestion from ECN? The current text makes it seem like 
TCP does not use losses to infer congestion when ECN is being used - I wish 
this could be true, but it's not.

- The origin of "Reno" gets a nice explanation in the RFC 2581 write-up, but 
the origin of "NewReno" isn't explained, and "NewReno" is introduced without 
a reference in Section 3.1 ("For example, if SACK use is not successfully 
negotiated, a host should use the NewReno behavior as a fall-back"). At a 
minimum, s/NewReno/NewReno [RFC3782]/ at first use.

- On a related note - if this document is intended for TCP newcomers (and 
not just oldcomers who can't remember all the RFC numbers in their heads 
anymore), it Would Be Nice to include an ASCII art diagram showing major 
milestones on the TCP roadmap. No one joins the TCP community knowing 
whether NewReno came before, or after, SACK.

- (Nit) In section 3.3, s/currrent/current/. Yes, it's also mispelled in RFC 
2385.

- Also in section 3.3, this text in the RFC 2385 writeup seems vague:

      It defines a new TCP option for carrying an MD5 [RFC1321] digest
      in a TCP segment.  This digest acts like a signature for that
      segment, incorporating information known only to the connection
      end points.

I understand that this text is taken from the RFC 2385 abstract, but if 
"acts like a signature" was explained in a sentence or two, that would be 
helpful (what does "acts like" actually mean?).

- I was surprised that RFC 2757 ("Long Thin Networks") was listed, while 
"End-to-end Performance Implications of Slow Links" (RFC 3150) and 
"End-to-end Performance Implications of Links with Errors" (RFC 3155)  were 
not. RFC 2757 was an Informational RFC that was processed while the PILC 
working group was being chartered, and many of the topics from RFC 2757 were 
looked at more carefully in the PILC BCPs. I don't think the RFC 2757 
recommendations are wrong or dangerous, I'd just like to see the BCP 
specifications listed, since they theoretically got more review in the 
community. If the pointer said "RFC 2757 has been largely superceded by 
BCPs, and these BCPs should be preferred when the same issue is discussed in 
both RFC 2757 and the BCPs", I'd be OK with that, too.

- RFC 3155 also contains the following text: "ABC is worthy of additional 
study, but is not recommended at this time, because ABC can lead to 
increased burstiness when acknowledgments are lost." Is this still the 
community consensus? (it was, when RFC 3155 was last-called as a BCP.) 
Either way, it would be good to add a sentence about the issue to the RFC 
3465 writeup.

- "Advice to link designers on link Automatic Repeat reQues (ARQ)" (RFC 
3366) was also omitted - this text was originally part of the draft that 
became RFC 3819, but was split out because there was more to say than we 
expected. It would be fine just to add a mention to RFC 3366 in the RFC 3819 
write-up. 

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art