Subject: Re: [tcpm] Few TCP Fast Open considerations

From: Ketan Kulkarni <[email-masked]>
Date: Mon, 4 Feb 2013 09:39:18 +0530

Hi Yoshifumi,
With the current draft, there is no way fast open client can
differentiate between these two cases.
However, (albeit with little modification) server can "help" client
differentiate.
Here's how -
In first cases, server is restarted without fast open. So there is no
way server can "communicate" anything about fast open to the client.
In second case however, server supports fast open but is not able ack
syn+data. In such case, it can very well send a NULL cookie to the
client. Client on receipt of a NULL cookie can differentiate between
first and second case.

If client detects first scenario, IMHO, client should stop sending
SYN+Data in subsequent connections to the server, as it has the
sufficient information to believe server is not supporting tcp fast
open.
While in second case, client can still attempt fast open (syn+data) in
subsequent connections as the condition is temporal and it can expect
the syn+data could be acked by the server.

Sounds reasonable?

Thanks,
Ketan

On Thu, Jan 31, 2013 at 11:36 AM, Yoshifumi Nishida
<[email-masked]> wrote:
> Hi Ketan,
>
> On Mon, Jan 28, 2013 at 8:42 AM, Ketan Kulkarni <[email-masked]> wrote:
>
>> If above suggestion is ok, there could probably also be a need of
>> sending NULL cookie (again suggested by Yuchung on netdev) from
>> fast-open server.
>> Specifically, at fast-open client, to detect the difference between
>> the two different scenarios -
>> 1. server restarted without Fast Open and is no longer supporting it
>> (or any of the condition given above)
>> 2. fast-open server exhausted its fast-open backlog and is temporarily
>> not acking the data in SYN.
>>
>> In the 2nd case, server might choose to send the NULL cookie on the
>> receipt of which client understands the server still supports
>> fast-open but unable to do so temporarily.
>> It might also indicate cookie expiration - but I am not sure.
>>
>> I will like a wider view and more thoughts on such scenarios occurring
>> in the network.
>
> It seems to me that 1 and 2 are mostly the same unless you can know
> how long "temporarily" is.
> But, I'm guessing it'll be difficult to know..
>
> --
> Yoshifumi Nishida

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Mon, 4 Feb 2013 11:56:02 +0000

Hi,

Sorry, i'm cached only so i can not check in the draft:

Ketan, you mentioned a cookie revokation also as a potential use for a null cookie. But if the reply to a fo syn is a null cookie to indicate a temporary overload situation (where the server probably doesn't want to hand out new cookies), how would such a cookie revokation during syn happen?

Best regards,
   Richard

Am 04.02.2013 um 05:09 schrieb "Ketan Kulkarni" <[email-masked]>:

> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: Yoshifumi Nishida <[email-masked]>
Date: Wed, 6 Feb 2013 00:22:30 -0800

Hi Ketan,

My concern is how long the temporal condition will last. Is it 5
minutes or 5 days? 5 days might be absurd, but I'm not very sure how
we can guarantee this.
Another concern is false positive. If client see SYN without cookie
just once, it might stop using TFO for the destination.

If we have some smart logic at client side, we can address these
issue. But, then, NULL cookie might not be very necessary.

Thanks,
--
Yoshifumi

---

From: Ketan Kulkarni <[email-masked]>
Date: Thu, 7 Feb 2013 10:29:23 +0530

Hi Yoshifumi,

Well my idea is as follows -

With current draft, tfo client follows this "state machine"

1. Request a cookie from server
2. If cookie is received, cache it.
3. Attempt syn+data to subsequent connections if cookie is cached.

There is no way now for the client to detect the server is not supporting
tfo.

If we modify the state-machine by adding a 4th state as follows -
1. Request a cookie from server
2. If cookie is received, cache it.
3. Attempt syn+data to subsequent connections if cookie is cached.
4. If server does not respond to syn+data (server not acking data in syn),
go back to state 1 for subsequent connections.

By this logic, there is a way for tfo client to go back to state 1 and
re-attempt cookie request.

I already mentioned various conditions earlier in my mails in what all
cases server does not respond to syn+data.
To detect difference between couple of scenarios, I also suggested to have
null cookie (or something else if there is any other way)

Now having the modified "state-machine" prevents your concerns of false
positive.
Even if due to false positives client doesn't attempt syn+data, it does
attempt cookie request. So the penalty could at max well be limited to one
connection. It also gets rid of the temporal aspect of server exhausting
backlog.

Another benefit it provides in cases of server stop supporting tfo. In such
cases, it is seen that client always attempts syn+data and server never
acks data and data in syn is retransmitted.
That is really odd and I don't think it should be acceptable.
If we can have a simpler way to avoid it then why not?

Thanks,
Ketan

---

From: Ketan Kulkarni <[email-masked]>
Date: Thu, 7 Feb 2013 10:43:03 +0530

Hi Richard,
Not sure if I understand your question completely.
Still framing the answer :-)

NULL cookie revocation will happen when the client re-requests the cookie
from server. Probably the modification to the state-machine I proposed in
my last mail might clarify it little further.

Thanks,
Ketan

On Mon, Feb 4, 2013 at 5:26 PM, Scheffenegger, Richard <[email-masked]>wrote:

> Ketan, you mentioned a cookie revokation also as a potential use for a
> null cookie. But if the reply to a fo syn is a null cookie to indicate a
> temporary overload situation (where the server probably doesn't want to
> hand out new cookies), how would such a cookie revokation during syn happen?
>
> Best regards,
>    Richard
>
>
>

---

From: Yoshifumi Nishida <[email-masked]>
Date: Mon, 11 Feb 2013 10:03:58 -0800

Hi Ketan,

Please allow me to clarify your idea here and let me know if I miss
something.
In my understanding, server has 3 choices when it receives TFO option from
clients.

1: server supports TFO and has valid cookie. if it can allow the client to
use TFO, attach valid cookie
2: server supports TFO and has valid cookie. if it cannot allow the client
to use TFO, attach NULL cookie
3: in other conditions, don't attach any cookie.

In case of 1, the client keeps using TFO.
In case of 2, the client stops using TFO, but keeps the cached cookie and
try with the cookie sometime later.
In case of 3, the client invalidates cookie and request new one again.

Case 2 will happen when the server is too busy to use TFO while it has
valid cookies.
This seems to be only case where NULL cookie is used.(if there're more
cases, please let me know)

I'm not denying this, but I'm wondering how this is effective.
This is because I'm not very sure how often Case 2 will happen.
Also, my another question is how long client should stop using TFO as this
will also affect the efficiency.

Thanks,
--
Yoshifumi

On Wed, Feb 6, 2013 at 8:59 PM, Ketan Kulkarni <[email-masked]> wrote:

> Another benefit it provides in cases of server stop supporting tfo. In
> such cases, it is seen that client always attempts syn+data and server
> never acks data and data in syn is retransmitted.