Subject: Re: [tcpm] Review of draft-ietf-tcpm-tcp-rfc4614bis-00

From: "Zimmermann, Alexander" <[email-masked]>
Date: Thu, 21 Nov 2013 13:24:47 +0000

Hi Jana,

thanks for the useful feedback. Comments bellow.

Alex

Am 16.10.2013 um 21:32 schrieb Janardhan Iyengar <[email-masked]>:

> Hi all,
> 
> Late, but as promised. Here's my pipe-dream: I would _LOVE_ to see a complementary document that documents the current state of various popular implementations, using the structure in this document as a basis. A simple table with booleans for each of the RFCs listed here may be a start.

Such an RFC is even faster outdated as the roadmap. IMO such a list shout be part of /net/*/tcp.c of the kernel
source file. But I agree that such a list (wherever be placed) is useful.

> 
> Thanks for all your work!!
> - jana
> 
> Comments: 
>   - Page 6: "This is generally regarded as the least common denominator among TCP flavors currently found running on Internet hosts." I thought that the least-common denominator was NewReno. Is that incorrect?

This is C&P text from the original roadmap. Since I’m not the author of this section, I have problems to value your comment.
If the WG has (now) feeling that NewReno and not Reno is the least common denominator I can delete the sentence. NP.

>   - Page 7: What do you mean by "Fundamental Changes"? As in changes to RFC 793? If so, can the Section be called that -- "Changes to RFC 0793"? At least state it clearly in the intro paragraph to this section. Without a clear explanation, it is difficult to see why 5482 is a Fundamental Change.

From the introduction text of section 3 of the old roadmap:

"3.  Recommended Enhancements
   This section describes recommended TCP modifications that improve
   performance and security.  RFCs 1323 and 3168 represent fundamental
   changes to the protocol. …
"

So, the authors of the RFC4614 saw this two RFCs as fundamental changes.
The only thing that I did, was the creation of a new section with exactly this
wording.

Nevertheless you (and also Yuchung) are right that RFC 5482 is *not* a fundamental change.
Therefore I move RFC 5482 out of this section, but leave the title as it is.

Personally, I do not like the title "Changes to RFC 0793“ since there are some other
RFC that also make changes to 793 but do not belong to this section. 

>   - I'll echo Yuchung's earlier comment that 3.2, 3.3, 3.4, 3.5 should be reorganized into two sections: Congestion Control, and Loss Recovery.

Yes and no. Yuchung suggested to re-organize section 3.2 and 3.3, but *not* 3.4 and 3.5.
In version 01 we have now:

3.2.  Congestion Control Extensions
3.3.  Loss Recovery Extensions
3.4.  Detection and Prevention of Spurious Retransmissions

and the same structure in sec 4. (which was not suggested by Yuchung ;-))

Strictly speaking, sec 3.4 is a subcategory of sec. 3.3. You are right. But for a better
structuring, I suggest that we put every spurious detection/reaction algo into a separate
sub-section. A reader can find the docs in question much easier.  BTW, we did the same
thing with MPTCP. All MPTCP docs belongs in some way to CC and LR too, but have their
own sub-section.

> You may want to note somewhere that there is some functional overlap between these two sections -- dealing with spurious retransmissions will fit in the Loss Recovery section, but intersects with congestion control.
>   - Page 17: Consider an equivalent reorganization for section 4.2 and 4.3.

done for sec 4.2

>   - Page 20: It seems to me that RFC 6182 also belongs in Section 4.4 on MPTCP (I'm a bit ambivalent about it being in section 7.2). I'd suggest leaving it in 7.2, and adding a reference to it in Section 4.4's intro paragraph.

The creation of the MPTCP section was with the collaboration of the MPTCP folks. We commonly agree with the
current structure. Personally, I would like to strictly follow the current roadmap structure/philosophy to
move RFCs that change the TCP protocol itself into sec 3/4 and move other docs into sec 7. When applying this
strategy, some RFCs that belong together by topic, may still belong to multiple sections, though. To overcome this
downside, we indicate in the introduction text of a section that other RFCs to this topic are also listed in other
sections:

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

>   - Page 22: RFC 1110 -- reason for historic?

RFC 6247

>   - Page 30: IMO, RFC 6181 belongs in Section 4.4, not in Section 7.4. 

see above (comment to page 20)

>   - Page 32: IMO, RFC 6056 belongs in Section 3.7, not in Section 7.5.

RFCs in section 3.7 make changes to the protocol itself, whereas RFC 6056 is purely
an implementation advice. (This is IMO also the reason why RFC6056 is BCP).
BTW the same applies also for RFC 3360, which is (and was also in RFC 4614) part
of this section.

>   - Page 33: IMO, RFC 6897 belongs in Section 4.4, not in Section 7.5.

see above (comment to page 20)

>   - Consider putting 7.5 and 7.7 next to each other -- they are semantically related to each other, and MIB has no reason to be in between them.

yes

>   - WooHoo -- Self Reference!! I really don't think RFC 4614 belongs in this list at all... the doc so far isn't listing previous versions of documents. I don't see a reason to list a previous versions of *this* document.

ok

>   - Page 34: IMO, RFC 6077 belongs in Section 7.4, not in Section 7.7.

Yes, why not.

>   - Page 34: IMO, RFC 5783 really really belongs in the Section on Congestion Control, not in Section 7.7.

I don’t think so. All documents in sec 3 and 4 make changes to the protocol itself. RFC 5783 is a survey
similar to the TCP roadmap, which no modification at all. It’s really a support doc.

> At least a reference to it should exist above in the CC section.

Done

> 
> Editorial nits:
>   - Page 3: "large number of more experimental" --> "large number of experimental“

OK

>   - Page 4: "practices that is not" --> "practices that are not“

OK

>   - Page 7: RFC 6298: "Abstract: "This document defines the standard algorithm that ..." Why this sudden departure in style to quoting the abstract? I see this departure appear later as well (Sections 3.5, 3.6, 7.3).

Because we C&P text here. Anytime we C&P an abstract from an RFC, we quote it.
The old roadmap uses the same style.

>   - Page 7: "Based on their investigation, .." The previous sentence talks about RFC 6093, not about the authors of 6093 ("their"). I would recommend removing that phrase altogether; it seems redundant. 

OK

>   - Page 20: "additinal" --> „additional"

OK

>   - Page 24: "early precursor of the infamous RFC 793" --> "early precursor of RFC 793". I certainly hope 793 isn't infamous!

Fixed :-)

>   - General suggestion: use one of "predecessor of" or "precursor of" consistently.

OK

>   - Page 25: RFC 872 -- "Conclusion: " Style inconsistency: this description is a departure in style from a summarizing paragraph.

If C&P the abstract from a RFC we write: Abstract „Foo Bar …“ [RFC007]

Here, we C&P the conclusion of the RFC. It exists a paragraph „Conclusion“ in RFC 872.

>   - Page 35: "Hazardsin" --> "Hazards in“

OK

>   - Page 36: FACK -- this loss recovery component is only a part of the FACK document. The entire FACK algorithm includes a more accurate estimation of outstanding bytes, and is, AFAIK, not implemented in Linux. I would correct the reference to state that "FACK [MM96] includes an alternate algorithm …".

OK

> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm