[tcpm] Comments on draft-ietf-tcpm-tcp-edo-13

["Iwashima, Kuniyuki" <[e-mail]>]

Hello Joe,

I'm Kuniyuki from AWS and recently working on this topic with Yoshi.
I have prototyped Extended Data Offset in Linux based on net-next.git and now
extending packetdrill to test EDO.

I have two comments about EDO fallback mechanism and option processing.

Let's say a middlebox merges the final ACK of 3WHS and the following segment
(3rd & 4th packets in the script below).

---8<---
0   socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
+0  setsockopt(3, SOL_TCP, TCP_EXT_DATA_OFFSET, [1], 4) = 0
+0  bind(3, ..., ...) = 0
+0  listen(3, 1) = 0

+0  < S 0:0(0) win 1000 <mss 1000,edoOK>
+0  > S. 0:0(0) ack 1 <edoOK, mss 1460>
+0  < . 1:1(0) ack 1 win 1000 <edo>
+0  < . 1:2(1) ack 1 win 1000 <edo>
---8<---

If the client uses the longer variant or the middle box changes the header length, 
the server notices that the packet has an invalid EDO options.
So, the server falls back to non-EDO mode as mentioned in this part.

---8<---
   >> The EDO Extension option MAY be used only if confirmed when the
   connection transitions to the ESTABLISHED state, e.g., a client is
   enabled after receiving the EDO Supported option in the SYN/ACK and
   the server is enabled after seeing the EDO Extension option in the
   final ACK of the three-way handshake. If either of those segments
   lacks the appropriate EDO option, the connection MUST NOT use any
   EDO options on any other segments.
---8<---


If the server accepts the packet and 3WHS completes, EDO is disabled at 
the server but enabled at the client.
The server will sends an ACK for the (originally 4th) segment without EDO, 
but the segment will be discarded at the client side.
In this case, the client cannot receive any ACK and data from the server.

So, I think the following parts MUST be applied to the final ACK of 3WHS as well.
It would be helpful to clarify that we MUST NOT complete 3WHS with an invalid EDO.

---8<---
   >> The EDO Header Length MUST be at least as large as the TCP Data
   Offset field of the segment in which they both appear. When the EDO
   Header Length equals the Data Offset length, the EDO Extension
   option is present but it does not extend the option space. When the
   EDO Header Length is invalid, the TCP segment MUST be silently
   dropped.
...
   >> When an endpoint receives a segment using the 6-byte EDO
   Extension option, it MUST validate the Segment_Length field with the
   length of the segment as indicated in the TCP pseudoheader. If the
   segment lengths do not match, the segment MUST be discarded and an
   error SHOULD be logged in a rate-limited manner.
---8<---


Also, after that, client may send out another packet for retransmission and 
newly queued data.
On the server side, EDO is disabled, but the packet will be processed ignoring
only EDO option.
Then, options after 60 bytes would be recv()ed accidentally by user.

---8<---
   >> If EDO has not been negotiated and agreed, the EDO Extension
   option MUST be silently ignored on subsequent segments.
---8<---

I think this behaviour is not intended.
So, I think it's better to make it clear that what MUST be ignored should be
the whole segment, instead of EDO Extension option.