Subject: [tcpm] WGLC for 793bis - REMINDER

From: "Scharf, Michael" <[email-masked]>
Date: Sat, 3 Oct 2020 18:29:22 +0000

Hi all,

This is a friendly reminder. Please have a look at 793bis!

Thanks

Michael

> -----Original Message-----
> From: tcpm <[email-masked]> On Behalf Of Scharf, Michael
> Sent: Friday, September 18, 2020 2:12 PM
> To: [email-masked] Extensions <[email-masked]>
> Subject: [tcpm] WGLC for 793bis - REVIEW NEEDED
> 
> Dear TCPM contributors,
> 
> This e-mail starts a working group last call for draft-ietf-tcpm-rfc793bis-18.
> Information about the document can be found at this link:
> 
> https://datatracker.ietf.org/doc/draft-ietf-tcpm-rfc793bis/
> 
> For instance, the current version can be found at
> https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rfc793bis-18.
> 
> When adopting draft-ietf-tcpm-rfc793bis, the TCPM working group
> consensus was to limit the scope of 793bis to TCP changes that are specified
> either in standards-track RFCs or in verified errata. Also, the consensus was
> to focus on the base protocol and exclude mechanisms that can be specified
> separately (e.g., congestion control). As a result, 793bis should in principle
> not contain anything new. Nonetheless, we all know that TCP is a complex
> protocol and even small details of the specification matter a lot.
> 
> Given that 793bis will obsolete RFC 793, which is one of the most important
> Internet Standards, this WGLC will run for *four weeks*, i.e., until October
> 16.
> 
> Therefore, *your* help is needed: PLEASE review 793bis in the next weeks!
> The earlier, the better...
> 
> - Any comments or suggestions are important and highly appreciated. Even if
> you don't speak up often on the TCPM mailing list, please let us know if you
> have any feedback.
> 
> - Even if you read the document without finding any errors or issue, please
> let us know ("+1").
> 
> - It is also perfectly fine to look only at a subset of the document, e.g., if you
> are familiar with specific details of TCP. Partial reviews are welcome, too.
> 
> - If you own TCP running code, you definitively should have a very close look;
> this document is supposed to be the new base specification of TCP.
> 
> RFC 793 lays the ground for all work in TCPM, and 793bis is probably one of
> the most important deliverables of TCPM. Please help us with completing
> this milestone.
> 
> Thanks!
> 
> Michael Scharf
> Yoshifumi Nishida
> Michael Tuexen
> (TCPM chairs)
> 
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: Rahul Jadhav <[email-masked]>
Date: Sun, 11 Oct 2020 23:02:51 +0530

This is an incredibly detailed work, covering protocol,
implementation, and different scenarios aspects. The scenarios/context
provided for "Quiet Time specification" and "Reset handling", were
particularly interesting to note for me. Following are my comments:

Section 3.1: "The window size MUST be treated as an unsigned number,
or else large window sizes will appear like negative windows and TCP
will now work (MUST-1)."
[RJ] It should be "TCP will _not_ work (MUST-1)" ... I guess its a typo (?).

Section 3.5.1: ... an application that has called CLOSE cannot
continue to read data from the connection (MAY-1).
[RJ] shouldn't this be that "an application that has called CLOSE
_can_ continue to read data from the connection (MAY-1)"? ... Again I
suppose it's a typo but want to make sure.

Section 3.5.1: See [18] section 2.17 for discussion.
[RJ] This reference is broken since section 2.17 no more exists.

Section 2.1: ... with each TCP segment sent as an Internet Protocol
(IP) datagram.
[RJ] Even though recommended, it isn't necessary that each TCP segment
be sent as a single IP datagram.

Section 2.1: Anycast applications exist that successfully use TCP
without modifications, though there is some risk of instability due to
changes of lower-layer forwarding behavior.
[RJ] A ref would help.

Small Nits:
Section 3.3: ...likelihood of reuse of ports and sequency numbers after reboots.
[RJ] s/sequency/sequence

Section 3.6.5: ...present IPv6 Node Requiements
[RJ] s/Requiements/Requirements

Best,
Rahul

---

From: Wesley Eddy <[email-masked]>
Date: Tue, 13 Oct 2020 12:38:09 -0400

Thank you for the review and comments.  For the most part, these were 
easy to address in my working copy, but there I think the parts around 
half-duplex CLOSE shouldn't change.  Here are some responses to each, 
with more details:

> [RJ] It should be "TCP will _not_ work (MUST-1)" ... I guess its a typo (?).

You're correct; I've now fixed this in the working copy.

> suppose it's a typo but want to make sure.

This is in reference to the peculiar "half-duplex" implementation option 
for the CLOSE sequence.   The first paragraph of this section discusses 
the normal "full-duplex" option, and this second paragraph covers the 
half-duplex option.  So, this is actually correct as-written.  The RFC 
2525 reference mentioned at the end of the section is clear on this.

> [RJ] This reference is broken since section 2.17 no more exists.

It is actually RFC 2525 Section 2.17 (not section 2.17 of 793bis) that 
is referenced here.   The autogenerated hyperlink doesn't seem to 
understand that, but it's clear from the text at least.

> be sent as a single IP datagram.

Hmmm, this I don't know about.  Are you thinking of IP fragmentation?

> changes of lower-layer forwarding behavior.

I think we can add a reference to RFC 7094 here to the document.

https://tools.ietf.org/html/rfc7094

> Section 3.3: ...likelihood of reuse of ports and sequency numbers after reboots.
ACK.
> [RJ] s/Requiements/Requirements
ACK.

---

From: Rahul Jadhav <[email-masked]>
Date: Wed, 14 Oct 2020 21:29:02 +0530

Please find my comments inline.

> understand that, but it's clear from the text at least.

After reading Section 2.17 of RFC 2525, the text was clear to me.

> Hmmm, this I don't know about.  Are you thinking of IP fragmentation?

[RJ] Yep, I had IP fragmentation in mind.

> https://tools.ietf.org/html/rfc7094

[RJ] Yes, this helps and I assume you are referring to Section 4.2 of RFC 7094.

---

From: Wesley Eddy <[email-masked]>
Date: Wed, 14 Oct 2020 13:38:57 -0400

> [RJ] Yep, I had IP fragmentation in mind.

In this case, the segment still is contained in a single datagram before fragmentation and following reassembly, which are the points that the TCP implementation sees it.

If people think it is somehow needs to be more clear, we could append some statement like "that may or may not be fragmented by IP", but personally I think this is distracting and not technically needed since the statement is true of any IP packet.