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

From: Martin Duke <[email-masked]>
Date: Tue, 3 Dec 2013 16:01:00 -0800

Comments inline.

On Thu, Nov 21, 2013 at 5:24 AM, Zimmermann, Alexander <
[email-masked]> wrote:

>
> Am 16.10.2013 um 21:32 schrieb Janardhan Iyengar <
> [email-masked]>:
>
> >
> > 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.
>

Perhaps others with more field experience feel differently, but by a
reading of the RFCs, 6582 explains NewReno, and explicitly does not
obsolete 5681. I take that to mean that a host can run Reno and still be
compliant.

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

For reference, the original 4614 had three RFCs at the beginning of Section
3 -- 1323 (timestamps, etc), 2675 (IPv6 jumbograms), and 3168 (ECN).  As
far as I can recall, this was because (a) they didn't fit neatly into a
grouping with other RFCs and we didn't want subsections with 1 RFC; and (b)
1323 and 3168 are really important and should be at the front. It's only
1323 and 3168 that we describe as "fundamental," as a way of introducing
them instead of any sort of formal taxonomy.

I agree that 3168 fits in well under congestion control; as for the two now
in 3.1, I'd just as soon we rename the section as "Miscellaneous changes"
or "general changes" or even "large packets and windows". I'm open to
people's suggestions for naming.

I'm aesthetically displeased with 5482 out there by itself in its own
subsection, and would probably prefer it in "miscellaneous changes," but if
others feel differently it isn't a big deal to me.

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

I concur with Alexander's answers to this comment and all that followed.

<snip>

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

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Wed, 4 Dec 2013 11:44:37 +0000

I think the vast majority of implementations uses NewReno - I checked a number of major OS TCP stacks a few months ago; there might be some very low-end and simple TCP stacks for small SoC/embedded systems, that may do Reno still, but even the lowly embedded gear I play around as a hobby with is running NewReno :)

Richard Scheffenegger

From: tcpm [mailto:[email-masked]] On Behalf Of Martin Duke
Sent: Mittwoch, 04. Dezember 2013 01:01
To: Zimmermann, Alexander
Cc: [email-masked] Extensions; <[email-masked]> Blanton; Braden <[email-masked]>
Subject: Re: [tcpm] Review of draft-ietf-tcpm-tcp-rfc4614bis-00

Comments inline.

On Thu, Nov 21, 2013 at 5:24 AM, Zimmermann, Alexander <[email-masked]<mailto:[email-masked]>> wrote:

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

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

Perhaps others with more field experience feel differently, but by a reading of the RFCs, 6582 explains NewReno, and explicitly does not obsolete 5681. I take that to mean that a host can run Reno and still be compliant.

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

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

For reference, the original 4614 had three RFCs at the beginning of Section 3 -- 1323 (timestamps, etc), 2675 (IPv6 jumbograms), and 3168 (ECN).  As far as I can recall, this was because (a) they didn't fit neatly into a grouping with other RFCs and we didn't want subsections with 1 RFC; and (b) 1323 and 3168 are really important and should be at the front. It's only 1323 and 3168 that we describe as "fundamental," as a way of introducing them instead of any sort of formal taxonomy.

I agree that 3168 fits in well under congestion control; as for the two now in 3.1, I'd just as soon we rename the section as "Miscellaneous changes" or "general changes" or even "large packets and windows". I'm open to people's suggestions for naming.

I'm aesthetically displeased with 5482 out there by itself in its own subsection, and would probably prefer it in "miscellaneous changes," but if others feel differently it isn't a big deal to me.

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

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.

<snip>

> [email-masked]<mailto:[email-masked]>

---

From: "Zimmermann, Alexander" <[email-masked]>
Date: Thu, 5 Dec 2013 09:50:37 +0000

Inline.

Am 04.12.2013 um 01:01 schrieb Martin Duke <[email-masked]>:

> Comments inline.
> 
> On Thu, Nov 21, 2013 at 5:24 AM, Zimmermann, Alexander <[email-masked]> wrote:
> 
> Am 16.10.2013 um 21:32 schrieb Janardhan Iyengar <[email-masked]>:
> 
> >
> > Comments:
> 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.

From standardization point of view is this correct, so I will let the text as it is.
If somebody strongly disagree, he can provide me some text and I will incorporate it :-)

> Personally, I do not like the title "Changes to RFC 0793“ since there are some other

„Fundamental changes“ reflects more the importance of RFC 1323,
„General changes“ is maybe more suitable for RFC 2675. I’m fine
with both of them.

Wes?

> I'm aesthetically displeased with 5482 out there by itself in its own subsection, and would probably prefer it in "miscellaneous changes," but if others feel differently it isn't a big deal to me.

The upcoming draft-ietf-tcpm-rtorestart-01 is also a candidate for the new TCP Timeouts section.
Since RFC 5482 is still not deployed I will move this section into sec. 4 and integrate the
upcoming RFC in RTO Restart too. OK?

---

From: Wesley Eddy <[email-masked]>
Date: Thu, 05 Dec 2013 09:59:03 -0500

On 12/5/2013 4:50 AM, Zimmermann, Alexander wrote:
>
>>
>> For reference, the original 4614 had three RFCs at the beginning of
>> Section 3 -- 1323 (timestamps, etc), 2675 (IPv6 jumbograms), and 3168
>> (ECN).  As far as I can recall, this was because (a) they didn't fit
>> neatly into a grouping with other RFCs and we didn't want subsections
>> with 1 RFC; and (b) 1323 and 3168 are really important and should be
>> at the front. It's only 1323 and 3168 that we describe as
>> "fundamental," as a way of introducing them instead of any sort of
>> formal taxonomy.
>>
>> I agree that 3168 fits in well under congestion control; as for the
>> two now in 3.1, I'd just as soon we rename the section as
>> "Miscellaneous changes" or "general changes" or even "large packets
>> and windows". I'm open to people's suggestions for naming.
> 

I don't have a strong preference, but it seems to me that we
failed to explain a commonality between 1323 and 2675, which
is that both define how to re-interpret pieces of the basic
TCP header and options.  1323 has Window Scaling which
re-interprets the advertised receive window, and 2675 specifies
that MSS or urgent pointer fields of 65,535 are to be treated
specially.

So, to me, that is why both can easily be grouped as "fundamental
changes".  I think we could add a sentence at the beginning of
section 3.1 to explain this, as it would be more informative than
the current 2 sentences there, which are largely just summarizing
text later on in the descriptions of both documents, and not
actually explaining the reason why they're fundamental changes.

-- 
Wes Eddy
MTI Systems

---

From: "Zimmermann, Alexander" <[email-masked]>
Date: Tue, 10 Dec 2013 15:01:41 +0000

Hi Wes,

> actually explaining the reason why they're fundamental changes.

I agree. I add the following text:

RFCs 1323 and 2675 represent fundamental changes to TCP
by redefining how parts of the basic TCP header and options are
interpreted. RFC 1323 defines the Window Scale Option, which
re-interprets the advertised receive window. RFC 2675 specifies
that MSS option and urgent pointer fields with a value of
65,535 are to be treated specially.

---

From: Martin Duke <[email-masked]>
Date: Tue, 10 Dec 2013 11:15:43 -0800

I concur.
On Dec 10, 2013 7:01 AM, "Zimmermann, Alexander" <