[tcpm] draft-ietf-tcpm-fastopen-07

["Scharf, Michael (Michael)" <[e-mail]>]

Hi Yuchung,

In preparation of the write-up, I read draft-ietf-tcpm-fastopen-07 once again and I run into some (mostly editorial) issues. I probably should have raised such issues ealier - sorry for the late feedback. Also, sorry if I got something wrong - I am obviously busy during the IETF week ;)

Still, I'd appreciate if this would be fixed before moving forward the document - otherwise this could be raised in the IETF LC or by the IESG.


Suggestions regarding the technical content:

- Section 4.1.3:

  draft-07:

   Without this information,
   the data size in the SYN packet is limited to the default MSS of 536
   bytes [RFC1122].

  Wouldn't it make sense to allow for a larger MSS for IPv6, which has a minimum MTU of 1280 byte? For instance:

   Without this information,
   the data size in the SYN packet is limited to the default MSS of 536
   bytes for IPv4 [RFC1122] and 1240 bytes for IPv6 [RFC2460].

  Otherwise, it could make sense to explain why the smaller value makes sense for IPv6 as well.

- Section 4.1.3 and Section 4.2:

  Basically, a lot of the client handling procedures are heuristics. This is mentioned later in Section 4.2.2, but I think it could be worthwhile to state in the earlier sections that some of the guidance consists of heuristics - albeit reasonable ones.


- Section 4.1.3.1:

  draft-07:

   For any negative responses, the client SHOULD disable Fast Open on
   the specific path and port, at least temporarily.

  The term "path" seems a bit problematic to me. TCP only knows endpoints. Do you mean the following?

   For any negative responses, the client SHOULD disable Fast Open on
   the specific combination of source and destination IP address and the remote port, at least temporarily.

  Potentially, some additional heuristic can try to guess paths (e.g., by looking at the local routing table in the endpoint). If that is meant, I'd suggest to call such a "path detection heuristic" more explicitly.    


- Section 4.2:

  Would it make sense to state more explicitly that other TCP events or state transition (e.g., reception of a RST) are not affected by fast open?


- Section 7.2:

  If cookie-less operation allows a cookie length of 0 bytes, couldn't there be issues with distinguishing the Fast Open Cookie Option and the Fast Open Cookie Request option? According to Section 4.1.1, they are distinguished by their length. I haven't fully thought through all details, e.g., for simultaneous open. If it is not an issue, a short sentence that explains why the options are still unique in the cookie-less operation could still be useful, imho.



Phrasing suggestions (I am not a native speaker):

- Abstract:

  draft-07:

   However TFO deviates from the
   standard TCP semantics the data in the SYN could be replayed to an
   application in some rare circumstances.

  Maybe better:

   However TFO deviates from the
   standard TCP semantics since the data in the SYN could be replayed to an
   application in some rare circumstances.


- Section 4.1.1:

  This section could more explicitly state that the cookie size MUST be an even number. This follows implicitly from the fact that the Fast Open Cookie Option length MUST be even.


- Section 4.1.2:

  The implementation example mentions AES_128. In a similar case in past documents, we got LC comments whether the crypto algorithm was save enough. Maybe a statement that crypto algorithms other than AES_128 could obviously be used as well, without any impact on the protocol, could make sense.


- Section 4.1.3:

  draft-07:
 
   In particular it's known IPv4 receiver advertised
   MSS less than 536 bytes would result in transmission of an unexpected
   large segment. 

  I can't fully parse this. Is this meant?

   In particular it's known that an IPv4 receiver advertised
   MSS less than 536 bytes would result in transmission of an unexpected
   large segment. 

  Similar like for the previous sentence (see above), IPv6 could be considered here separately, IMHO.


- Section 5.1:

  draft-07:

   With DHCP, it's possible to obtain
   cookies of past IP addresses without compromising any host.

  I have difficulties to understand that attack based on this sentence. Could it make sense to rephrase it?


- Section 6:

  draft-07:

   Applications here refer
   specifically to the process that writes data into the socket, i.e., a
   java script process that sends data to the server.

  Suggestion:

   Applications here refer
   specifically to the process that writes data into the socket, e.g., a
   JavaScript process that sends data to the server.

  I think "java script" (= JavaScript?) is only one example for an application.


Editorial nits:

- In many other documents, the terminology section comes after the introduction, so having it before the Table of Contents seems a little bit unusual to me. I don't have a strong preference on this, though.

- The document contains a couple of acronyms that are well-known in the IETF ("TCP", "NAT", "DoS", "ICMP", "CPU"). In general, I think acronyms like "TCB" (TCP Control Block) should really be expanded on first use. For some acronyms like "TCP" there may be some gray area whether they may be well-known to a reader ;)

- Section 2: s/to be delivered to application/to be delivered to the application/ ?

- Section 3: s/max amount/maximum amount/ ?

- Section 4.2: s/i.e.,not/i.e., not/

- Section 6.1: s/host(Section/host (Section/

- Section 6.3.3: s/1-RTT/one RTT/

- Section 8.2: s/data ./data./

- Section 8.3: "the latency benefit as TFO": Is this correct English?

- Section 11: Please check the references again. At least reference [BRISCOE12] seems broken.


As far as I recall, I haven't formally concluded the WGLC. This message thus completes the WGLC.

Thanks

Michael