Draft: draft-ietf-tcpm-tcp-roadmap-05 Reviewer: Spencer Dawkins [spencer@mcsr-labs.org] Review Date: Monday 1/30/2006 11:09 AM CST IETF LC Date: 02/01/2006 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.