Subject: [tcpm] Is RFC1323bis' title still appropriate?

From: "Zimmermann, Alexander" <[email-masked]>
Date: Thu, 14 Nov 2013 14:01:35 +0000

Hi,

while scanning the diff of the last version yesterday the
question if the title of the draft is still appropriate
came into my mind.

For me high performance is somehow equal to high throughput,
and for this I do not necessarily need the two options. E.g.
for a 40Gb/s TCP connection in a DC I do not need Timestamps…

So, is a title like „The TCP Windows Scale and TCP Timestamps
option“ (or something similar) not a better title? A reader
knows directly from title what is specified in the RFC.

BTW: IMO the abstract is too short. Could we extent it a little
bit so that the reader has more context in advanced?

Alex

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Thu, 14 Nov 2013 14:52:27 +0000

Hi Alex,

first, thanks for the list of nits you sent me directly (making the "O" in "Window Scale option" lowercase to mirror the style of the Timestamps option; one missing "<" bracket in a xref, one missed "monotonically increasing").

Second, to your comments:

I'd rather not change the title of the RFC, to keep this in line with other RFCs that have been updated over time,

Ie. 3517 / 6675
A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP
Or
2581 / 5681
TCP Congestion Control

And many (non-tcp) others...

As to the slight expansion of the abstract, what about this text

    This document specifies a set of TCP extensions to improve 
    performance over paths with a large bandwidth * delay product and to 
    provide reliable operation over very high-speed paths.  It defines 
    the TCP Window Scale (WS) option and the TCP Timestamps (TS) option 
    and their semantics. The Window Scale option is used to support 
    larger receive windows, while the Timestamps option can be used for 
    at least two distinct mechanisms, PAWS (Protection Against Wrapped 
    Sequences) and RTTM (Round Trip Time Measurement), that are also 
    described herein. 

Is that text agreeable?

I'd like to ask the Chairs to start the WGLC in the next few days, to proceed with this doc to the next phase.

Best regards,

Richard Scheffenegger

> -----Original Message-----
> From: Zimmermann, Alexander
> Sent: Donnerstag, 14. November 2013 15:02
> To: Scheffenegger, Richard; David Borman
> Cc: [email-masked] Extensions
> Subject: Is RFC1323bis' title still appropriate?
> 
> Hi,
> 
> while scanning the diff of the last version yesterday the question if the
> title of the draft is still appropriate came into my mind.
> 
> For me high performance is somehow equal to high throughput, and for this
> I do not necessarily need the two options. E.g.
> for a 40Gb/s TCP connection in a DC I do not need Timestamps...
> 
> So, is a title like "The TCP Windows Scale and TCP Timestamps option" (or
> something similar) not a better title? A reader knows directly from title
> what is specified in the RFC.
> 
> BTW: IMO the abstract is too short. Could we extent it a little bit so
> that the reader has more context in advanced?
> 
> Alex
> 
> 
>

---

From: "Zimmermann, Alexander" <[email-masked]>
Date: Thu, 14 Nov 2013 14:55:41 +0000

Inline.

> A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP

Because we have already a good title here :-)

> 
> And many (non-tcp) others…

Counter example is Gorry’S CWV :-)

>    Sequences) and RTTM (Round Trip Time Measurement), that are also 

Yes!

---

From: "Ilpo Järvinen" <[email-masked]>
Date: Thu, 14 Nov 2013 17:27:15 +0200 (EET)

On Thu, 14 Nov 2013, Scheffenegger, Richard wrote:

> I'd rather not change the title of the RFC, to keep this in line with 
> other RFCs that have been updated over time, 
> 
> Ie. 3517 / 6675

?!?

"A Conservative Loss Recovery Algorithm Based on Selective Acknowledgment 
(SACK) for TCP" says my RFC6675 :-)

...Did you perhaps mean that its meaning wasn't significantly changed?

-- 
 i.

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Thu, 14 Nov 2013 15:57:57 +0000

Yes sorry!

Would you like to see WS and TS in the title, or keep the old one?

Best regards,
   Richard

---

From: "Ilpo Järvinen" <[email-masked]>
Date: Thu, 14 Nov 2013 18:46:09 +0200 (EET)

> Would you like to see WS and TS in the title, or keep the old one?

For some reason I've never liked RFC1323 title to begin with so I'd 
prefer the actual option names here. It would actually be rather 
misleading to say everything that benefits from WS today would have 
particularly "high performance".

BTW, I just noticed that 1323 is also a counter-example:

RFC1072 TCP Extensions for Long-Delay Paths
RFC1185 TCP Extension for High-Speed Paths
RFC1323 TCP Extensions for High Performance
(+RFC2018 TCP Selective Acknowledgment Options)

-- 
 i.

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Thu, 14 Nov 2013 23:38:03 +0000

Ilpo,

Very well then. But I'll need a good speaker to tell me which one is most correct

"TCP Window Scale and Timestamps option" (sounds like one combined option)

"TCP Window Scale and Timestamps options" (sounds odd)

"TCP Window Scale and TCP Timestamps options" (imho better)

"TCP Window Scale option and TCP Timestamps option" (least ambiguity, but is this proper?)

(prefixed with a "The"?)

PS: I'm glad that we have come to the point to discuss the title :)

Richard Scheffenegger

> From: Ilpo Järvinen [mailto:[email-masked]]
> Sent: Donnerstag, 14. November 2013 17:46
> To: Scheffenegger, Richard
> Cc: Zimmermann, Alexander; David Borman; Pasi Sarolahti
> ([email-masked]); [email-masked] Extensions
> Subject: Re: [tcpm] Is RFC1323bis' title still appropriate?
> 
> For some reason I've never liked RFC1323 title to begin with so I'd prefer
> the actual option names here. It would actually be rather misleading to
> say everything that benefits from WS today would have particularly "high
> performance".
>

---

From: David Borman <[email-masked]>
Date: Thu, 14 Nov 2013 18:00:25 -0600

I have mixed feelings about changing the name of the document, but the original title was from when it also included SACK, which was removed before 1323 was published.  So I guess it makes some sense to clarify the title.

> "TCP Window Scale and Timestamps options" (sounds odd)

This one.  It sounds less odd if you switch it to “TCP Timestamps and Window Scale options”, but I think we want to keep Timestamps as the second one, given the pushback on it.

But in any case, Options should be capitalized, because this is a document title.

			-David Borman

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

---

From: <[email-masked]>
Date: Fri, 15 Nov 2013 00:30:07 +0000

"TCP options for window scaling and for timestamps"

Needs to start with "TCP options" to set context.

Lloyd Wood
http://sat-net.com/L.Wood/

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Scheffenegger, Richard [[email-masked]]
Sent: 14 November 2013 23:38
To: Ilpo Järvinen
Cc: [email-masked] Extensions; David Borman
Subject: Re: [tcpm] Is RFC1323bis' title still appropriate?

Ilpo,

(prefixed with a "The"?)

Richard Scheffenegger

---

From: "Zimmermann, Alexander" <[email-masked]>
Date: Fri, 15 Nov 2013 10:01:42 +0000

Am 15.11.2013 um 01:30 schrieb [email-masked]:

> "TCP options for window scaling and for timestamps“

I like this one. Maybe we can omit the 2nd for, but I’m not a
native speaker.

Do we need to talk about RTTM/PAWS in the title?

Eg Like this: TCP options for window scaling and timestamps and their applications

---

From: David Borman <[email-masked]>
Date: Fri, 15 Nov 2013 15:25:53 +0000

> Eg Like this: TCP options for window scaling and timestamps and their applications

Right, RFC1323 isn’t just about defining these two options, but also PAWS and RTTM, mechanisms that use them.  It’s first about identifying the issues when running TCP at high rates of speed and/or large amounts of data, i.e., a large delay*bandwidth, and then the options and algorithms to address those issues.  That’s why I said I had mixed feelings about changing the title.

The first sentence of the abstract is:

   This document specifies a set of TCP extensions to improve
   performance over paths with a large bandwidth * delay product and to
   provide reliable operation over very high-speed paths.

The original title, "TCP Extensions for High Performance”, is compact and encompasses not only the specific defined options, but also the algorithms such as PAWS and RTTM.  So the more I think about it, the more I prefer to just leave as it is.  It just gets too unwieldy if you try and put everything explicitly into it:

	"TCP Options for Window Scaling and Timestamps, and the
	Protection Against Wrapped Sequences and Round Trip Time
	Measurement Algorithms”

It’s a document title, not an all encompassing descriptive statement of what is in the document.  Keep it short and simple, and the original title is just that.  In the document, “High Performance” is defined for connections that suffer performance problems, specifically for large delay*bandwidth situations, referred to as a “long, fat network" (LFN).  The original objection was about “High Performance” in the title, so maybe change just that part:

	“TCP Extensions for Long Fat Networks”
	“TCP Extensions for LFNs”

But I don’t like either of those more than the original title.

So I’d like to leave the title as it is, since it is an updated version of the original, not an entirely new document.  There has to be sufficient reason to change the title, such as it is inaccurate or misleading, and I don’t think it is.  We don’t change the title just because we think we can come up with a better one.

		-David Borman

>> http://sat-net.com/L.Wood/

----------------------------------------------------------------------
The information contained in this transmission may be confidential. Any disclosure, copying, or further distribution of confidential information is not permitted unless such privilege is explicitly granted in writing by Quantum. Quantum reserves the right to have electronic communications, including email and attachments, sent across its networks filtered through anti virus and spam software programs and retain such messages in order to comply with applicable data security and retention requirements. Quantum is not responsible for the proper and complete transmission of the substance of this communication or for any delay in its receipt.

---

From: Mark Allman <[email-masked]>
Date: Fri, 15 Nov 2013 10:34:54 -0500

> So I’d like to leave the title as it is, 

Amen.

Even if there is a better title to be had it isn't better enough to
spend much effort on.  So, my druthers is that this thread ends. :-)

allman

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Fri, 15 Nov 2013 15:44:31 +0000

Very well then;

I'll submit the version fixing the nits and updating the abstract and one paragraph speaking about the validity of TSecr.

Any objections against calling for WGLC then?

Richard Scheffenegger

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Mark Allman
> Sent: Freitag, 15. November 2013 16:35
> To: David Borman
> Cc: [email-masked] Extensions; [email-masked]
> > So I'd like to leave the title as it is,
> 
> Amen.
> 
> Even if there is a better title to be had it isn't better enough to spend
> much effort on.  So, my druthers is that this thread ends. :-)
> 
> allman
> 
>