[tcpm] draft-ietf-tcpm-fast-open

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

Hi all,

With the chair hat off:

I've read draft-ietf-tcpm-fast-open. I think that the draft significantly improved, but I still came up with a number of questions:

* Section 3, "performing TCP fast open" (and other places): I recall both some meeting as well as mailing list discussion what will happen if draft-ietf-tcpm-fast-open is combined with draft-ietf-tcpm-initcwnd. I really wonder why there is hardly any text on congestion control implications in the draft. Even if the impact may be minor and congestion control is not the major focus of this draft, I think that implementors and users will wonder like me about that question and some explanation would help them. The way the draft is written right now seems to imply that an application developer may have to decide whether to experiment with IW10 or with fast open. If an app developer has to decide this, this will be a non-trivial tradeoff for him, in particular at design time.

* Section 4.1.1: I don't recall a discussion about cookie option size, right? Out of my head, 4 bytes seem reasonable; beyond that I wonder about the tradeoff between option size consumption and security. I am not sure, but maybe even 2 bytes could be sufficient in some cases (see also below)? At least, some guidance on the length would really make sense.

* Section 4.1.3: I wonder why the client "MUST" cache cookies. Why is not a "SHOULD"? At least if the client is short of memory, there might be valid reasons to "forget" cookies?

* Section 4.1.3: "Since TFO is enabled on a per-service port basis but cookies are independent of service ports, clients' cache should include remote port numbers too." Is it possible that there are different cookies for different service ports on the same server IP? This is probably not what the specification intends, but I wonder whether it would be a possible system design. I also wonder if that could improve security (e. g., possibly a shorter cookie)?

* Section 4.2.2: Thanks for adding the text on simultaneous open! I think that this scenario can only occur if fast open is activated on the corresponding ports on both endpoints, i. e., it is really a corner case. But are the fast open cookie semantics in that corner case indeed clear? In particular, I wonder whether one can savely distinguish between a client "Fast Open Cookie Request Option" (Sect. 4.1.1) and a server "null cookie" (Section 4.1.2).

* General: The draft explicitly states that API changes are outside the scope of the document. Still, I wonder if that could be discussed briefly in an non-normative appendix.

* General: This draft is heading for experimental track. Recent IESG feedback suggests that the IESG is interested in statements about the scope of such experiment. Maybe some text on that could be added? (Very obvious is further real-world experince on the performance benefit.)

Editorial nit: Section 2.1, second paragraph: "applications in section 2.1" looks like a self-reference

Thanks

Michael