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

[Yuchung Cheng <[e-mail]>]

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

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

"""

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


>
> * 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?
>
> if the client is short of memory, does it matter if  a MUST or a SHOULD? :(
Happy to change to SHOULD if other co-authors agree.

* 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.

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

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.


>
> * 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.
>
I actually consider doing that but I don't know any previous TCP RFC has
done that. I am happy to do that if tcpm list considers this appropriate.


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

I need some help on this text. maybe an example exp RFC that exactly scopes
its experiment.


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

will fix that thx

>
> Thanks
>
> Michael
>
>
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm
>