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

From: Janardhan Iyengar <[email-masked]>
Date: Wed, 16 Oct 2013 12:32:44 -0700

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.

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?
  - 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.
  - 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. 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.
  - 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.
  - Page 22: RFC 1110 -- reason for historic?
  - Page 30: IMO, RFC 6181 belongs in Section 4.4, not in Section 7.4.
  - Page 32: IMO, RFC 6056 belongs in Section 3.7, not in Section 7.5.
  - Page 33: IMO, RFC 6897 belongs in Section 4.4, not in Section 7.5.
  - 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.
  - 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.
  - Page 34: IMO, RFC 6077 belongs in Section 7.4, not in Section 7.7.
  - Page 34: IMO, RFC 5783 really really belongs in the Section on
Congestion Control, not in Section 7.7. At least a reference to it should
exist above in the CC section.

Editorial nits:
  - Page 3: "large number of more experimental" --> "large number of
experimental"
  - Page 4: "practices that is not" --> "practices that are not"
  - 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).
  - 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.
  - Page 20: "additinal" --> "additional"
  - Page 24: "early precursor of the infamous RFC 793" --> "early precursor
of RFC 793". I certainly hope 793 isn't infamous!
  - General suggestion: use one of "predecessor of" or "precursor of"
consistently.
  - Page 25: RFC 872 -- "Conclusion: " Style inconsistency: this
description is a departure in style from a summarizing paragraph.
  - Page 35: "Hazardsin" --> "Hazards in"
  - 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 ...".

---

From: "Zimmermann, Alexander" <[email-masked]>
Date: Thu, 17 Oct 2013 07:59:06 +0000

Thanks Jana. I will incorporate your feedback in the next version. (Together with a detail answer)

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.
> 
>   - 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?
>   - 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.
>   - 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. 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 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.
>   - 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.
>   - 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.
>   - Page 34: IMO, RFC 5783 really really belongs in the Section on Congestion Control, not in Section 7.7. At least a reference to it should exist above in the CC section.
> 
> Editorial nits:
>   - Page 3: "large number of more experimental" --> "large number of experimental"
>   - 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).
>   - 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. 
>   - Page 24: "early precursor of the infamous RFC 793" --> "early precursor of RFC 793". I certainly hope 793 isn't infamous!
>   - General suggestion: use one of "predecessor of" or "precursor of" consistently.
>   - Page 25: RFC 872 -- "Conclusion: " Style inconsistency: this description is a departure in style from a summarizing paragraph.
>   - 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 ...".
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm