tcp fast open?

tcp fast open?

[Dave Taht]

I am curious if working code exists for tcp fast open for Linux as yet?

I just finished slamming an implementation of tcp-ledbat v9 into
cerowrt (untested as yet, ledbat vs sfqred
will be interesting), and based on the presentation at the last linux
plumbers conference, tcp fast open looked interesting too.



-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net

Re: tcp fast open?

[Yuchung Cheng]

On Fri, Feb 17, 2012 at 6:38 AM, Dave Taht <dave.taht@gmail.com> wrote:
>
> I am curious if working code exists for tcp fast open for Linux as yet?
>
> I just finished slamming an implementation of tcp-ledbat v9 into
> cerowrt (untested as yet, ledbat vs sfqred
> will be interesting), and based on the presentation at the last linux
> plumbers conference, tcp fast open looked interesting too.
>
>
Hi Dave,

At this moment, we do have a working patch under testing it
internally. The handshake code is the most complicated and critical
piece in TCP. One important test is the fail over if routers drop or
act weirdly on SYN/SYN-ACK with payload and/or experimental TCP
options. If things go well we will upstream it to Linux netdev in
April and I'll CC you.

Btw, I am very interested in learning the result of AQM vs
delayed-based CC like ledbat.

Cheers,

Yuchung

Re: tcp fast open?

[Dan McDonald]

On Fri, Feb 17, 2012 at 07:24:32AM -0800, Yuchung Cheng wrote:

<SNIP!>

> At this moment, we do have a working patch under testing it
> internally. The handshake code is the most complicated and critical
> piece in TCP. One important test is the fail over if routers drop or
> act weirdly on SYN/SYN-ACK with payload and/or experimental TCP
> options. If things go well we will upstream it to Linux netdev in
> April and I'll CC you.

Do you have a paper spec (Internet Draft or other such documentation) so
other platforms can port this?

Thanks,
Dan

Re: tcp fast open?

[Jerry Chu]

[-- Attachment #1: Type: text/plain, Size: 850 bytes --]

Hi Dan,

Good to hear from you!

On Mon, Feb 20, 2012 at 1:40 PM, Dan McDonald <danmcd@nexenta.com> wrote:

> On Fri, Feb 17, 2012 at 07:24:32AM -0800, Yuchung Cheng wrote:
>
> <SNIP!>
>
> > At this moment, we do have a working patch under testing it
> > internally. The handshake code is the most complicated and critical
> > piece in TCP. One important test is the fail over if routers drop or
> > act weirdly on SYN/SYN-ACK with payload and/or experimental TCP
> > options. If things go well we will upstream it to Linux netdev in
> > April and I'll CC you.
>
> Do you have a paper spec (Internet Draft or other such documentation) so
> other platforms can port this?
>

See  http://www.ietf.org/mail-archive/web/tcpm/current/msg06856.html

Also a paper titled "TCP Fast Open" has been published at ACM/CoNEXT 2011.

Best,

Jerry

Thanks,
> Dan
>

[-- Attachment #2: Type: text/html, Size: 1518 bytes --]

Re: tcp fast open?

[Rick Jones]

On 02/20/2012 01:40 PM, Dan McDonald wrote:
> On Fri, Feb 17, 2012 at 07:24:32AM -0800, Yuchung Cheng wrote:
>
> <SNIP!>
>
>> At this moment, we do have a working patch under testing it
>> internally. The handshake code is the most complicated and critical
>> piece in TCP. One important test is the fail over if routers drop or
>> act weirdly on SYN/SYN-ACK with payload and/or experimental TCP
>> options. If things go well we will upstream it to Linux netdev in
>> April and I'll CC you.
>
> Do you have a paper spec (Internet Draft or other such documentation) so
> other platforms can port this?

http://tools.ietf.org/html/draft-cheng-tcpm-fastopen-02

rick jones

>
> Thanks,
> Dan
> _______________________________________________
> Bloat-devel mailing list
> Bloat-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat-devel

Re: tcp fast open?

[Justin McCann]

[-- Attachment #1: Type: text/plain, Size: 1096 bytes --]

On Tue, Feb 21, 2012 at 1:25 PM, Rick Jones <rick.jones2@hp.com> wrote:

> On 02/20/2012 01:40 PM, Dan McDonald wrote:
>
>> On Fri, Feb 17, 2012 at 07:24:32AM -0800, Yuchung Cheng wrote:
>>
>> <SNIP!>
>>
>>  At this moment, we do have a working patch under testing it
>>> internally. The handshake code is the most complicated and critical
>>> piece in TCP. One important test is the fail over if routers drop or
>>> act weirdly on SYN/SYN-ACK with payload and/or experimental TCP
>>> options. If things go well we will upstream it to Linux netdev in
>>> April and I'll CC you.
>>>
>>
>> Do you have a paper spec (Internet Draft or other such documentation) so
>> other platforms can port this?
>>
>
> http://tools.ietf.org/html/**draft-cheng-tcpm-fastopen-02<http://tools.ietf.org/html/draft-cheng-tcpm-fastopen-02>
>
>
>
You might also want to check out their CoNEXT paper (probably sent around
already). It's more of the why and supporting evidence than a spec:
  overview:    http://research.google.com/pubs/pub37517.html
  pdf: http://research.google.com/pubs/archive/37517.pdf

     Justin

[-- Attachment #2: Type: text/html, Size: 1951 bytes --]

Re: tcp fast open?

[Juliusz Chroboczek]

> Btw, I am very interested in learning the result of AQM vs
> delayed-based CC like ledbat.

That's something that I discussed with the creators of LEDBAT a year ago
(when they convinced me to implement µTP in Transmission).  Here's what
I recall of what Shalunov told me -- but it was a long time ago, and
I was badly jetlagged, so I could be speaking nonsense.

LEDBAT reacts to loss in exactly the same way as Reno does -- it reduces
its congestion window by 1/2.  Hence, if the bottleneck is running an
agressive loss-based AQM such as BLUE, then LEDBAT will behave just the
same as NewReno.

Note that this is not the case of the variant of LEDBAT implemented in
µTP, which on loss divides its window by 1/sqrt(2) (if memory serves).
Hence, µTP will, in that case, behave like an aggregate of two Reno
flows.  However, since µTP doesn't implement slow start or fast
recovery, µTP should still end up being far less agressive than Reno.

--jch