Subject: [tcpm] I-D Action: draft-ietf-tcpm-rfc793bis-05.txt

From: [email-masked]
Date: Tue, 28 Mar 2017 14:50:48 -0700

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 of the IETF.

        Title           : Transmission Control Protocol Specification
        Author          : Wesley M. Eddy
	Filename        : draft-ietf-tcpm-rfc793bis-05.txt
	Pages           : 95
	Date            : 2017-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 and several other RFCs (TODO: list
   all actual RFCs when finished).

   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-05
https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rfc793bis-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rfc793bis-05

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/

---

From: Wesley Eddy <[email-masked]>
Date: Tue, 28 Mar 2017 18:01:53 -0400

There are some changes in this update that the WG should review.

A summary of what to look for is below, but I also recommend scanning 
the diff:

https://tools.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rfc793bis-05.txt

1. added CWR and ECE bits from ECN to the header format diagram, and 
reference to 3168 for definitions

2. instead of RFC1122 requirement MUST implement slowstart + congestion 
avoidance, added "MUST implement RFC 5681" ---- please review this!

3. added "SHOULD implement ECN" --- please review this!  This is outside 
what 1122 or other documents say, but I think it is the intent of 
publishing 3168 on standards track and having it update 793.

4. updated 1122 text about source quench to reflect that 6633 deprecated it

5. modified text on ICMP messages to also mention ICMPv6 (not covered by 
1122) --  please check this!

6. split 1122 discussion of ICMP handling into soft and hard errors per 
5461, and added notes to reference other discussion in 5461 about 
widespread implementation behavior

On 3/28/2017 5:50 PM, [email-masked] wrote:
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: Joe Touch <[email-masked]>
Date: Tue, 28 Mar 2017 15:06:37 -0700

Some observations:

3.1 currently defined options
    this either needs to be the complete current list or indicate that
the list is elsewhere (the latter seems better to me)
    if list elsewhere, the discussion should be clear that this doc
defines only the following options; others are defined elsewhere
    is there any notion of the minimum required options? if so, is this
that set? (it might be useful to say so)

throughout
    the discussion of PMTU and MSS might benefit from an update as per
draft-iett-intarea-tunnels
    key points:
        PMTU discovery assumes TCP set IP to prevent both on-path (for
IPv4) and source fragmentation (IPv4 and IPv6), otherwise it optimizes
source fragment size rather than avoiding source fragmentation
        MSS is defined in terms of EMTU_R, which is independent of PMTU
        there are two effective MTUs - EMTU_S and EMTU_R. The former is
set and may or may not be limited by PMTU.

I can coordinate off-list on both if useful.

Joe

---

From: Wesley Eddy <[email-masked]>
Date: Tue, 28 Mar 2017 18:18:37 -0400

> that set? (it might be useful to say so)

I propose that this should be described as the minimum required set, and 
that we add pointer to the IANA registry of TCP Option Kind Numbers for 
the complete set:
https://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml

> set and may or may not be limited by PMTU.

If clarity can be improved in 793bis, that sounds good to me.  The text 
currently is patched together from bits of many other RFCs.

> I can coordinate off-list on both if useful.

I think on-list is preferable to make sure everyone else agrees with us :)

---

From: Michael Welzl <[email-masked]>
Date: Wed, 29 Mar 2017 07:42:33 -0500

Hi,

I have a question / concern that’s different from the things Wes mentioned about this diff:

for both the old and new RFC, if I want to implement a TCP that is able to send data on the first SYN (not TFO-style, but as allowed by this spec), how do I make this possible using the API in section 3.9?

This needs application data to be handed over before the handshake is completed. I think this could only be done with “SEND” triggering “OPEN”, as described in this text: 

***
Some implementations may allow users to SEND first; in
         which case, an automatic OPEN would be done.  If the calling
         process is not authorized to use this connection, an error is
         returned.
***

As it stands, when I read this, it makes me think “why would anyone do this?”. I believe there should be some clarification there regarding the point of this - to explain that this can make it possible to send data together with the SYN.

Cheers,
Michael

> On Mar 28, 2017, at 4:50 PM, [email-masked] wrote:
> 
>