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

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

> 	* 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.
> 	
> 
> What's the problem of experimenting both? whatever issue 
> identified in IW10 draft will occur with TFO except it'll 
> happen an RTT earlier, except for this case, which is 
> addressed in the new draft in 4.2.2 
> 
> "" Note that if SYN-ACK is lost, regular TCP reduces the initial
> 
> 
>    congestion window before sending any data. In this case TFO is
>    slightly more aggressive in the first data round trip even though
>    it does not change the congestion control.
> """  

This statement is at some rather "random" position in the protocol spec and (at least to me) hard to parse. Our past discussion http://www.ietf.org/mail-archive/web/tcpm/current/msg07329.html describes more verbosely what this issue is, and whether it matters (or not).

Why don't you add a dedicated subsection "Congestion Control Implications" to Section 5?

> Maybe you can suggest what exactly to add in the draft 
> because I am not sure what to do.

This statement 

" 6. Advance to the SYN-RCVD state. If the FastOpened flag is set, the
    server MUST follow the congestion control [RFC5681], in particular
   the initial congestion window [RFC3390], to send more data   packets."

seems to imply to me that a stack either uses fast open or IW10, but MUST not use them both, right? If so, I think that this requires guidance for the app developer do decide whether to select either IW10 or fast open.

If this is not your intention, i. e., it should be allowed that IW10 and fast open are combined, this should be explicitly explained in the document, imho. IW10 will probably be an RFC when this document gets published, and their relationship is pretty apparent. As I said, I really think that people will ask this question.

> 	* 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 
> 
> of course, why not? the server applications (on different) 
> may prefer to use different secrets, whatever reason they 
> think. in our Linux implementation but we'd like to keep the 
> option open.

... but that question implies interoperability, because the client SW design depends on what the cookie is about. Not every TCP endpoint is Linux ;)

> 	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).
> 	
> 
> I am not sure I understand the problem. When a (simul open) 
> client sends a SYN w/ FO cookie request option, he gets a 
> SYN-ACK that may have the Fast Open cookie option (from the 
> other simul-open client)

If in a simulatenous open both SYNs carry an empty FO cookie option, what is the correct behavior?
 
> The null cookie is only used by server responding SYN-ACK to 
> a (simul open) client sending SYN-data with Fast Open cookie 
> option, not FO cookie "request" option.

I don't understand. In simulateous open, the role of client and server is fuzzy. And the distinction between client and server is quite inherent to fast open. This is why I wonder about that corner case..

Michael