Netdev List
 help / color / mirror / Atom feed
From: Eric Dumazet <eric.dumazet@gmail.com>
To: David Miller <davem@davemloft.net>
Cc: ycheng@google.com, hkchu@google.com, edumazet@google.com,
	ncardwell@google.com, sivasankar@cs.ucsd.edu,
	netdev@vger.kernel.org
Subject: Re: [PATCH 1/7] net-tcp: Fast Open base
Date: Wed, 18 Jul 2012 21:55:49 +0200	[thread overview]
Message-ID: <1342641349.2626.3555.camel@edumazet-glaptop> (raw)
In-Reply-To: <20120716.231644.1189536600250332545.davem@davemloft.net>

On Mon, 2012-07-16 at 23:16 -0700, David Miller wrote:
> From: Yuchung Cheng <ycheng@google.com>
> Date: Mon, 16 Jul 2012 14:16:44 -0700
> 
> > +#define TCPOPT_EXP		254	/* Experimental */
> > +/* Magic number to be after the option value for sharing TCP
> > + * experimental options. See draft-ietf-tcpm-experimental-options-00.txt
> > + */
> > +#define TCPOPT_FASTOPEN_MAGIC	0xF989
> 
> If I apply this, we're stuck supporting this experimental number
> forever.
> 
> Because somewhere, someone will have a kernel running using this
> number, so we have to support this option value as well as whatever
> the official one is.
> 
> Therefore I think the only logical thing we can do is only deploy
> this once an official option number is choosen.

Hi David

This is a chicken and egg problem.

IANA wont grant an official number like that in 2012+. Maybe if billions
of Android/linux devices use TFO in 2015 IANA will grant an official
number.

So we chose to follow Joe touch proposal
(http://tools.ietf.org/html/draft-ietf-tcpm-experimental-options-01) and
the magic 0xF989 was generated according to section 3) to avoid possible
clashes with other experimental options using code option 254

(Code options 253 & 254 are reserved for experimental use.
Linux Cookie extension uses 253 without a magic cookie so 253 cannot be
shared. By the way I wonder if anybody uses it... oh well...) 

Only servers will need to cope with this experimental option plus the
official one (_if_ IANA accepts to unblock one of the many reserved
options, in two or three years)

Yuchung only posted the Client side in this patch series. But we already
run the server side, and supporting the official TFO option plus the
experimental one is adding less than 10 lines of code.

So the plan would be :

1) Use the experimental 254 + magic on TFO Clients/Servers in 2012

2) When/If IANA grants an official number, add its support to servers
   (keeping support for experimental option as well)

3) One/two years later, switch client side to use this official number

4) Ten years later, remove experimental from server side.

Thanks !

PS :

TFO is not mandatory : If the initial SYN TFO option is not understood
by a server, it will reply with a SYN/ACK without the option and cookie,
and client will proceed as today.

  reply	other threads:[~2012-07-18 19:55 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-16 21:16 [PATCH 0/7] TCP Fast Open client Yuchung Cheng
2012-07-16 21:16 ` [PATCH 1/7] net-tcp: Fast Open base Yuchung Cheng
2012-07-17  6:16   ` David Miller
2012-07-18 19:55     ` Eric Dumazet [this message]
2012-07-18 20:18       ` David Miller
2012-07-16 21:16 ` [PATCH 2/7] net-tcp: Fast Open client - cookie cache Yuchung Cheng
2012-07-17  6:15   ` David Miller
2012-07-16 21:16 ` [PATCH 3/7] net-tcp: Fast Open client - sending SYN-data Yuchung Cheng
2012-07-16 21:16 ` [PATCH 4/7] net-tcp: Fast Open client - receiving SYN-ACK Yuchung Cheng
2012-07-16 22:57   ` Vijay Subramanian
2012-07-16 23:33     ` Yuchung Cheng
2012-07-16 21:16 ` [PATCH 5/7] net-tcp: Fast Open client - sendmsg(MSG_FASTOPEN) Yuchung Cheng
2012-07-16 21:16 ` [PATCH 6/7] net-tcp: Fast Open client - detecting SYN-data drops Yuchung Cheng
2012-07-16 21:16 ` [PATCH 7/7] net-tcp: Fast Open client - cookie-less mode Yuchung Cheng

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1342641349.2626.3555.camel@edumazet-glaptop \
    --to=eric.dumazet@gmail.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=hkchu@google.com \
    --cc=ncardwell@google.com \
    --cc=netdev@vger.kernel.org \
    --cc=sivasankar@cs.ucsd.edu \
    --cc=ycheng@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox