[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAPshTCgR585z5sFUbxgR5azb2kZe2mnx=x6i_0M=iint5NEpJg@mail.gmail.com>
Date: Fri, 27 Jul 2012 12:39:06 -0700
From: Jerry Chu <hkchu@...gle.com>
To: Michael Kerrisk <mtk.manpages@...il.com>
Cc: Yuchung Cheng <ycheng@...gle.com>, davem@...emloft.net,
edumazet@...gle.com, ncardwell@...gle.com, sivasankar@...ucsd.edu,
netdev@...r.kernel.org, rick jones <perfgeek@....com>,
Terry Lam <vtlam@...ucsd.edu>
Subject: Re: [PATCH v2 0/7] TCP Fast Open client
On Fri, Jul 27, 2012 at 12:06 PM, Michael Kerrisk
<mtk.manpages@...il.com> wrote:
> On Fri, Jul 27, 2012 at 7:28 PM, Jerry Chu <hkchu@...gle.com> wrote:
>> +rick, terry
>>
>> Hi Michael,
>>
>> Thanks for your interest!
>>
>> On Fri, Jul 27, 2012 at 4:42 AM, Michael Kerrisk <mtk.manpages@...il.com> wrote:
>>> Yuchung,
>>>
>>> On Wed, Jul 18, 2012 at 11:01 PM, Yuchung Cheng <ycheng@...gle.com> wrote:
>>>> ChangeLog since v1:
>>>> - Reduce tons of code by storing Fast Open stats in the TCP metrics :)
>>>> - Clarify the purpose of using an experimental option in patch 1/7
>>>>
>>>> This patch series implement the client functionality of TCP Fast Open.
>>>> TCP Fast Open (TFO) allows data to be carried in the SYN and SYN-ACK
>>>> packets and consumed by the receiving end during the initial connection
>>>> handshake, thus providing a saving of up to one full round trip time (RTT)
>>>> compared to standard TCP requiring a three-way handshake (3WHS) to
>>>> complete before data can be exchanged.
>>>>
>>>> The protocol change is detailed in the IETF internet draft at
>>>> http://www.ietf.org/id/draft-ietf-tcpm-fastopen-00.txt . The research
>>>
>>> This URL appears to be invalid. I assume the following is the correct
>>> current version:
>>> http://tools.ietf.org/html/draft-ietf-tcpm-fastopen-01
>>> ?
>>
>> Correct.
>>
>>>
>>> Is there some sample client and server userspace test code available?
>>
>> There are some sample code in a SIGCOMM paper (
>> http://conferences.sigcomm.org/co-next/2011/papers/1569470463.pdf). It's
>> real simple but we haven't published the server side code yet. (It's been
>> ready but I need to rebase it to the latest net-next.)
>
> The examples in that paper seem to be outdated. At the very least,
> names of constants for socket options etc have changed.
>
> I've been trying to test this feature from userspace, but am not
> getting quite the results I expect. It sounds like you are saying that
> not all the kernel pieces are there yet to support TFO in userspace.
> Is that correct?
Correct. Only the client side code is in net-next but not the server
code. If you
tcpdump you'll see your TFO TCP option is not getting ack'ed because the
server side does not understand TFO yet.
The server side code is ready for review as well, except I just discovered
an implementation detail that I need to fix - I have conveniently added TCP
code for TFO directly to request_sock.c but just realized request_sock is
being used by non-TCP transport (e.g., DCCP) as well so I need to remove
TCP specific code and make it more generic wrt rsk...
Anyway hopefully the code will be ready for review soon (i'm leaving for
vacation in a few days so it will be a little more delay). If you can't wait to
test it i can send you a patch.
Thanks,
Jerry
>
> Thanks,
>
> Michael
>
> --
> Michael Kerrisk Linux man-pages maintainer;
> http://www.kernel.org/doc/man-pages/
> Author of "The Linux Programming Interface", http://blog.man7.org/
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists