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

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 13 Mar 2006 06:27:03 -0600

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-masked]>
To: "General Area Review Team" <[email-masked]>
Cc: <[email-masked]>; "Bob Braden" <[email-masked]>; 
<[email-masked]>; <[email-masked]>; "Jon Peterson" 
<[email-masked]>; "Ted Faber" <[email-masked]>; "Mark Allman" 
<[email-masked]>
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-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: Mark Allman <[email-masked]>
Date: Fri, 17 Mar 2006 00:32:47 -0500

> 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.

Just FYI, the IESG approved this document this morning (well, yesterday
morning now, I guess).  The following are a couple of tweaks that are
being requested of the RFC editor ... including the one you re-flagged
above.

Thanks for the detailed comments!

allman

OLD:  (from section 3.1)

  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.

NEW:

  TCP traditionally treats lost packets as indicating
  congestion-related loss, and cannot distinguish between
  congestion-related loss and loss due to transmission errors.  Even
  when ECN is in use, there is a rather intimate coupling between
  congestion control and loss recovery mechanisms.

===

OLD:  (from section 3.3)

  A draft that is currently in the RFC Editor's queue for
  publication [tcpmd5app] deprecates TCP MD5 for use outside BGP.

NEW:

  RFC 4278 deprecates the use of TCP MD5 outside BGP [RFC4278].

Please change [tcpmd5app] to reference RFC 4278.

===

OLD:

   RFC 2452 S: "IP Version 6 Management Information Base for the
   Transmission Control Protocol" (December 1998)

      This document [RFC2452] augments RFC 2012 by adding an IPv6-
      specific connection table.  The rest of 2012 holds for any IP
      version.
NEW:
   RFC 2452 S: "IP Version 6 Management Information Base for the
   Transmission Control Protocol" (December 1998)

      This document [RFC2452] augments RFC 2012 by adding an IPv6-
      specific connection table.  The rest of 2012 holds for any IP
      version.  RFC 2012 is now obsoleted by RFC 4022.