Re: [tcpm] I-D Action: draft-ietf-tcpm-rfc793bis-08.txt

[Gorry Fairhurst <[e-mail]>]

A couple of comments-on-comments in-line,

Gorry


On 29/03/2018 15:10, Yuchung Cheng wrote:
> Thanks for the update. I enjoy reading the new diffserv text.
> 
> comments:
> <quote>
> The IPv4 specification [1] includes a precedence value in the Type of
> precedence will still have to check the precedence of incoming Service
> field (TOS), that was also modified in [15], and then
> segments and possibly raise the precedence level they use on the
> obsoleted by the definition of Differentiated Services (DiffServ)
> connection. [6]. 

I think this text kind of suggests ToS still exists. DiffServ is mature 
technology. I think we shouldn't even be hinting that ToS semantics are 
permitted - I'd suggest we firmly state that Diffserv has obsoleted the 
former TOS semantics.

> In DiffServ the former precedence values are treated as Class
> Selector codepoints, and methods for compatible treatment are
> described in the DiffServ architecture. The RFC 793/1122 TCP
> specification includes logic intending to have connections use the
> highest precedence requested by either endpoint application, and to
> keep the precedence consistent throughout a connection. 
 >
Right, RFC 7657 has slightly more refined text in the same vein on not 
change DSCPs too often.

> There is an
> assumption of bidirectional/symmetric precedence values, however, the
> DiffServ architecture is asymmetric. Problems were described in [17]
> and the solution described is to ignore IP precedence in TCP. Since
> RFC 2873 is a Standards Track document (although not marked as
> updating RFC 793), these checks are no longer a part of the TCP
> standard defined in this document, though the DiffServ field value is
> still is a part of the interface between TCP and the network layer,
/is still is/
> and values can be indicated both ways between TCP and the
> application.
> </quote>
> 
> I am not entirely I get the main points this paragraph tries to convey. Are they
> 1. a TCP stack MUST implement RFC2873
> 2. precedence is obsoleted.
> ?
> 
I think something does have to be said about the way diffserv works, 
although RFC 2873 is all the more vague by avoiding all keywords.

> 
> <quote>
> Note that the DiffServ field is permitted to change during a
> connection (section 4.2.4.2 of RFC 1122). However, the
> application interface might not support this ability, 
 >
Well always possible, but do we really need to say that, since it kind 
of breaks diffserv.

> and the
> application does not have knowledge about individual TCP
> segments, so this can only be done on a coarse granularity, at
> best. This limitation is further discussed in RFC 7657 (sec
> 5.1, 5.3, and 6) [37]. Generally, an application SHOULD NOT
> change the DiffServ field value during the course of a
> connection.
> </quote>
> 

> The underlying assumptions of this text is
> 1. Application can not specify precisely the DiffServ at TCP segments level
> 2. TCP does not tolerate reordering well today
> 
> As API and TCP evolve and socket API isn't the only one, it would be
> good to be explicit about these assumptions. e.g.
> "Generally an application SHOULD NOT change DiffServ field value
> during the course of a connection because it may cause excessive
> reorderings and adversely hurts performance"
> 
> nits:
> p32: s/the DiffServ field value is still is a part/ the DiffServ field
> value still is a part /
> p68: s/ SND.NEXT/SND.NXT/
> p47: s/TCP may be buffer the data/TCP may buffer the data/
> 
> On Wed, Mar 28, 2018 at 9:01 PM,  <[e-mail]> wrote:
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>> This draft is a work item of the TCP Maintenance and Minor Extensions WG of the IETF.
>>
>>          Title           : Transmission Control Protocol Specification
>>          Author          : Wesley M. Eddy
>>          Filename        : draft-ietf-tcpm-rfc793bis-08.txt
>>          Pages           : 102
>>          Date            : 2018-03-28
>>
>> Abstract:
>>     This document specifies the Internet's Transmission Control Protocol
>>     (TCP).  TCP is an important transport layer protocol in the Internet
>>     stack, and has continuously evolved over decades of use and growth of
>>     the Internet.  Over this time, a number of changes have been made to
>>     TCP as it was specified in RFC 793, though these have only been
>>     documented in a piecemeal fashion.  This document collects and brings
>>     those changes together with the protocol specification from RFC 793.
>>     This document obsoletes RFC 793, as well as 879, 2873, 6093, 6429,
>>     6528, and 6691 that updated parts of RFC 793.  It updates RFC 1122,
>>     and should be considered as a replacement for the portions of that
>>     document dealing with TCP requirements.  It updates RFC 5961 due to a
>>     small clarification in reset handling while in the SYN-RECEIVED
>>     state.
>>
>>     RFC EDITOR NOTE: If approved for publication as an RFC, this should
>>     be marked additionally as "STD: 7" and replace RFC 793 in that role.
>>
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-tcpm-rfc793bis/
>>
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-tcpm-rfc793bis-08
>> https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rfc793bis-08
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rfc793bis-08
>>
>>
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> _______________________________________________
>> tcpm mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tcpm
> 
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm
>