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

On Nov 15, 2013, at 4:01 AM, Zimmermann, Alexander <Alexander.Zimmermann@netapp.com> wrote:

> 
> Am 15.11.2013 um 01:30 schrieb L.Wood@surrey.ac.uk:
> 
>> "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

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

> 
>> 
>> Needs to start with "TCP options" to set context.
>> 
>> Lloyd Wood
>> http://sat-net.com/L.Wood/
>> 
>> 
>> ________________________________________
>> From: tcpm-bounces@ietf.org [tcpm-bounces@ietf.org] On Behalf Of Scheffenegger, Richard [rs@netapp.com]
>> Sent: 14 November 2013 23:38
>> To: Ilpo Järvinen
>> Cc: tcpm@ietf.org Extensions; David Borman
>> Subject: Re: [tcpm] Is RFC1323bis' title still appropriate?
>> 
>> 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
>> 
>> 
>>> -----Original Message-----
>>> From: Ilpo Järvinen [mailto:ilpo.jarvinen@helsinki.fi]
>>> Sent: Donnerstag, 14. November 2013 17:46
>>> To: Scheffenegger, Richard
>>> Cc: Zimmermann, Alexander; David Borman; Pasi Sarolahti
>>> (pasi.sarolahti@iki.fi); tcpm@ietf.org Extensions
>>> Subject: Re: [tcpm] Is RFC1323bis' title still appropriate?
>>> 
>>> On Thu, 14 Nov 2013, Scheffenegger, Richard wrote:
>>> 
>>>> 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.
>> _______________________________________________
>> tcpm mailing list
>> tcpm@ietf.org
>> https://www.ietf.org/mailman/listinfo/tcpm
>> _______________________________________________
>> tcpm mailing list
>> tcpm@ietf.org
>> https://www.ietf.org/mailman/listinfo/tcpm
> 
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm

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