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

[Yuchung Cheng <[e-mail]>]

On Mon, Mar 11, 2013 at 4:30 PM, Scharf, Michael (Michael) <
[e-mail]> wrote:

> >       * 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?
>
personally I am fine w/ a dedicated subsection but have to consult other
co-authors.


>
> > 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.
>
No I do not imply that. My intention is to say TFO should follow TCP CC,
whatever IETF RFC recommends.  This is the answer to your or similar
questions like can TFO work with any other changes to CC).



> >       * 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
> ;)

Please help me understand by an example of how sever applications on port
17483 and port 432 using two masters keys talking to different TFO client
implementation may break.

A TFO cookie is only meaningful for server applications that permit TFO.


> >       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?
>

On receiving the empty FO cookie option, aka FO cookie request, the server
(also a simul-open client) responds the cookie in SYN-ACK if it supports
TFO on that port.
details are in  Section  4.2.2 " Server: Receiving SYN and responding with
SYN-ACK"


> > 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..
>
If not too much trouble please give a exact case of how simul. fast open
won't work. I don't understand your case. sorry.


>
> Michael