This revision of the document addresses most of my review comments. I still
have a concern about the comment I made on section 3.1, but it should not be
a blocking concern (and others may not share it). Ready for publication as
Informational.
Not sure who the "TSV AD" will be for this document, by ballot time, so
adding Magnus as well as Jon...
Thanks for the quick turnaround!
Spencer
From: "Spencer Dawkins" <[EMAIL PROTECTED]>
To: "General Area Review Team" <[email protected]>
Cc: <[EMAIL PROTECTED]>; "Bob Braden" <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; "Jon Peterson"
<[EMAIL PROTECTED]>; "Ted Faber" <[EMAIL PROTECTED]>; "Mark Allman"
<[EMAIL PROTECTED]>
Sent: Monday, January 30, 2006 11:08 AM
Subject: Gen-ART Review of draft-ietf-tcpm-tcp-roadmap-05
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 protected]
https://www1.ietf.org/mailman/listinfo/gen-art
