Subject: Re: [tcpm] New Version Notification for draft-ietf-tcpm-tcp-rfc4614bis-00.txt

From: "Zimmermann, Alexander" <[email-masked]>
Date: Tue, 3 Dec 2013 17:31:21 +0000

Hi Bob,

thank very much for your review. I incorparte all of your comments.
Please find details below.

Alex

Am 22.08.2013 um 21:40 schrieb Bob Braden <[email-masked]>:

> I promised Alex I would give 4614bis a read through. This message 
> contains my comments but does
>  not include the typos that I saw. Another day.
> 
> Nothing I have to say should be taken as disapproval of the document as 
> a whole. The authors did a really good job disentangling what has become 
> a muddy maze of RFCs! From 30,000 feet, it may reflects a defect in the 
> IETF processes, resulting in conflict and fragmentation of protocol 
> specs. It would seem to be a daunting task for a TCP implementer to 
> figure out what to implement, even with your excellent document.

Hopefully the situation becomes better with RFC793bis.

> Bob Braden

——

> 
> COMMENTS ON draft 4614bis
> 
> o   I was nearly done with RFC 1122 when Dave Crocker spoke up and complained that it was nearly impossible to find a particular requirement. He was clearly right, so I dove back in and produced the Summary charts that appear at the end of each section of 1122. Reading 4614bis, I had Dave's problem. The explanation of RFCxxxx would contain a reference to RFCyyyy, but it was very difficult and time consuming to locate the description of yyyy, which is often in a different section of the document.  I think you should fix this somehow.

I totally agree with you. Very good idea!

> One way might be to add the bis section number to the reference entries. Since the references and the sectionss are ordered by RFC #, it would be an easy 2-step lookup from yyyy to a section number to the roadmap entry for yyyy. The other approach would simply put section ref the in text -- ".... RFCyyyy (see n.m) …"

The references are automatically generated by xml2rfc script. Therefore, I take option 2.

> 
> o First paragraph p 4: says 5681 is "nearly universally deployed" but later it is listed (quite properly, I would
> think) in section 2 as MUST.  That would seem to supercede the deployment frequency. Something like "For instance, RFC 5681 is considered part of the required core functionality of TCP, although RFC 5681 is only a Draft Stndard“.

Fixed.

> 
> o 3rd paragraph of 5681 (p 6) is confusing; turn it around so the sentence begins with 5681 and ends with 1122.

Fixed.

> 
> o Nit: "Jumbograms" is inconsistently capitalized

Fixed.

> 
> o First paragraph p9: omit word "traditionally" as misleading.  It is fundamental to VJ CC.

OK.

> 
> o RFC 6633 p.10: Out of order.
> and: s/provides recommendations/recommends/

Fixed and fixed.

> 
> o Section 3.3:  s/provides performance improvement/improves performance/

Text no longer exist. No changes here.

> 
> o Discussion of RFC 2883, p 11: So, the receiver infers it has unnecessarily retransmitted a packet. What is it supposed to do with that information?

This is not a part of RFC 2883. However, I add a sentence :-)

> 
> o RFC 4015 12: Seems weird that this is a standards track document and classified as a SHOULD in your section 3.4, yet it seems that the Eifel algorithm is defined in an Experimental RFC 3522 in section 4.3. At least comment on the connection in one or the other.

In the old TCP roadmap Eifel Response (RFC 4015) was not part of section 3
(recommended enhancements), but part of section 4. The reasoning was the following:

      1.  RFC 4015 operates on the output of a detection algorithm, for
          which there is currently no available mechanism on the
          standards track.

      2.  The working group was not aware of any wide deployment and use
          of RFC 4015.

      3.  The consensus of the working group, after a discussion of the
          known Intellectual Property Rights claims on the techniques
          described in RFC 4015, identified this section of the roadmap
          as an appropriate location.

Today, point 1 and 2 are no longer true, for which I moved RFC 4015 to
section 3. On the other hand Eifel Destection is still an experimental
RFC, and therefore still in section 4 (like the DSACK detection as well).

In the introduction of Section 3.4. we give the reader a hint that some
of the algorithms are non STD track.

<snip>
The IETF defined multiple algorithms
because there are tradeoffs in whether or not certain TCP options
need to be implemented, and concerns about IPR status.  The Standards
Track documents in this section are closely related to the
Experimental documents in Section 4.4 also addressing this topic.
<snap>

> 
> o First sentence 3.7 (p. 14): s/and/from/

Fixed.

> 
> o RFC 4953 (p 14):   s/resets (RSTs)/reset (send RST)/

Done.

> 
> o RFC 5827 (p18) "(and SCTP)" raises the interesting question: can one say that all the discussion in section 4.2 hold for SCTP as well as TCP?

Uff, maybe… Some of the algos like F-RTO, IW10 and the like also exist for SCTP, but
to be honest, I do not like to open a can of worms :-)

> 
> o I am mystified by Multipath TCP RFCs being scattered into 4.4, 6.2, 6.4, and 6.5. They all seem to be Experimental. Do you have some reason for these choices??

This is not (fully) true. RFCs that specify the MPTCP itself are experimental
and part of section 4.5 (the numbering has changed). This are RFC 6356 and
RFC 6824.

Any other MPTCP doc is informational (RFC 6182, RFC 6181 RFC 6897), and which
is the reason why we listed them in section 6 (support documents).

In the introduction of the MPTCP section (sec. 4.5), we give the reader a hint
that also support docs exist that are not part of this section.

<snip>
The documents listed in this section specify
the Multipath TCP scheme, while the documents in Sections 7.2, 7.4,
and 7.5 provide some additional background information.
<snap>

> 
> o RFC 1693. Surely "use more specialized transport protocols" cannot be the right answer. Is it likely that these specialized protocols implement all the appropriate TCP congestion control and avoidance, etc? I think not.

We clarified that sentence from:

"use more specialized transport protocols"
to:
"use specialized transport protocols other than TCP, such as PR-SCTP
[RFC 3758]."

> 
> o RFC 1705 (p 22)  Is it worthwhile to point out that this is
> the identifier/locator split that has been the subject of much
> discussion?

We added:

"Later work on splitting locator and identifier values is summarized
well in RFC 6115, but no resulting changes to TCP have occurred."

> 
> o RFC 6013 (p 22): s/is publish in 2011/was published in 2011/

Fixed.

> 
> o RFC 761: s/mostly the/mostly to the/

Fixed.

> RFC 872: s/ON-A/on-a/

Fixed.

> 
> RFC 896: This was a trememdously important RFC at the time. I believe that it first introduced the term and the concept of
> congestion collapse. 
> 
> Furthermore, it defined an algorithm for
> efficient transmission of small packets that is still called
> the Nagle Algorithm or simply "Nagle“.

I add a sentence about the Nagle algorithm.

> RFC 3439: the word "extents" is obviously wrong. Also, 'primary 
> mechanism" does not sound right. How about "... complexity is the primary impediment to efficient scaling“

Funny. The authors of RFC3439 use the word „extent“ in their abstract.
Anyway, I changed it into „updates"

> 
> RFC 2757: ... long thin networks (i.e., networks with low bandwidth and high delay) …

added

> 
> ZRFC 3366 and 3819 appear to cover roughly the same ground. I assume they are both the result of Phil Karn's passionate pleas.
> In any case, if I am right it would be nice to point out the
> kinship in the Roadmap.

In the 3819 description, we added:

"RFC 3366 specifically focuses on ARQ mechanisms, while RFC 3819
more widely covers additional aspects of the underlying layers."

> 
> o RFC4774: It is unclear that this belongs here; how abou 6.2?

I guess you mean 7.2.  Architectural Guidelines. Right?

> Also, suggest s/co- existence in an Internet that may include/\
>             co-existence with/

Fixed.

> 
> o RFC 5033: Since this document seems to be opposing 2914, 	ouldn't it be better to move 5033 to section 6.2 where
> 	2914 appears?

My comment to Wes…

What do you think? I would like to take the other way around.
Move 2914 where  5033 appears.

and Wes…

This is a good point.  I took the opportunity now to re-look at
both of them, and I actually think that 2914 is still pretty good
where it's at, though I think we should add a note to it that mentions
5033.  Something like:

"Later work on TCP has included several more aggressive mechanisms than
Reno TCP includes, and RFC 5033 provides additional guidance on use of
such algorithms.  The fundamental architectural discussion in RFC 2914
remains valid, regarding the standards process role in defining protocol
aspects that are critical to performance and avoiding congestion
collapse scenarios."

> 
> o RFC 2525: s/in doing so//

Fixed

> 
> o RFC 1337; missing space in title

Fixed

> 
> o Header prediction p35: was the typo "acpacket" in Van's message?

No ;-)

> 
> I am glad youi included Van's message. I have a mailbox on disk in which I collected Van's messages over a number of years. I
> always hoped to find time to do a light editing and publish it
> on the web (Van did give me permission) All together, it is a
> course in the subtleties of protocols!
> 
> o Forward Acknowledgement(FACK): Did you define fast retransmit
>   somewhere earlier?

Yes in the description of RFC 5681.

> A backward ref to it would be helpful here.

added

> Cheers,
> Bob Braden