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

[Yuchung Cheng <[e-mail]>]

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]. 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. 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,
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.
?


<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, 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 DiffServe field vale
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