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

[Yuchung Cheng <[e-mail]>]

On Thu, Apr 5, 2018 at 10:14 AM, Gorry Fairhurst <[e-mail]>
wrote:

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

+1



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