[Cerowrt-devel] TCP TFO client behaviour

[Cerowrt-devel] TCP TFO client behaviour

[Ketan Kulkarni]

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

Hi,
I am testing tcp tfo behavior with httping client and polipo server.

One observation from my TFO testing  -If for a connection server sends a
cookie to client, client always does TFO for subsequent connections. This
is ok.

If for some reason, server stops supporting TFO (either because server got
restarted without TFO support (in my case) or because path changed and the
nw node is dropping packet with unknown syn option or stripping the
option), client does not clear up its cookie cache. It always sends data in
syn and server never acks the syn-data and client retransmits.

As per kernel code -if syn-data is not acked it is retransmitted
immediately - with the assumption first syn was dropped (but the assumption
server stopped supporting TFO might not have been considered)

My opinion is to flush the cookie for this server and re-attempt the cookie
"negotiation" on subsequent connection.

Your thoughts?

Thanks,
Ketan

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

Re: [Cerowrt-devel] [Bloat] TCP TFO client behaviour

[Eric Dumazet]

On Tue, 2012-12-11 at 22:18 +0530, Ketan Kulkarni wrote:
> Hi,
> I am testing tcp tfo behavior with httping client and polipo server.
> 
> One observation from my TFO testing  -If for a connection server sends
> a cookie to client, client always does TFO for subsequent connections.
> This is ok.
> 
> If for some reason, server stops supporting TFO (either because server
> got restarted without TFO support (in my case) or because path changed
> and the nw node is dropping packet with unknown syn option or
> stripping the option), client does not clear up its cookie cache. It
> always sends data in syn and server never acks the syn-data and client
> retransmits.
> 
> As per kernel code -if syn-data is not acked it is retransmitted
> immediately - with the assumption first syn was dropped (but the
> assumption server stopped supporting TFO might not have been
> considered)
> 
> My opinion is to flush the cookie for this server and re-attempt the
> cookie "negotiation" on subsequent connection.
> 
> Your thoughts?

I really wonder why this is sent to these lists instead of netdev ?

Re: [Cerowrt-devel] [Bloat] TCP TFO client behaviour

[Dave Taht]

>
> I really wonder why this is sent to these lists instead of netdev ?

In my case I find it impossible to read netdev on a regular basis,
with the size of the traffic and the unbelievable patch burden - (not
that I can't filter it, but that fairly often I find a patch too
tempting to not apply and then play with)

I have no problem taking a conversation to netdev if needed...

However I'd note that TCP fast open is not just a linux feature, but
affects the entire internet. Perhaps the readership here has a more
broad view of how this should be approached.

Ketan has been busily adding support for TFO to a couple tools used in
cerowrt. (httping is already out there in a release!)

It's my hope to be able to sanely test it in cerowrt's 3.7.x release.

I also am concerned about TFO wider adoption into other tools like
these (ssh? dns?) and what those effects might be.

I'm probably dropping the syn optimization in simple_qos.sh because of
tcp fast open. But I would prefer to gather data and test, first, with
good tools. Are there any other tools besides chrome and httpping
setup for clients?

I look forward to trying out the polipo support.

>
>
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat



-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

Re: [Cerowrt-devel] [Bloat] TCP TFO client behaviour

[Rick Jones]

If there are bugs/issues in Linux's TFO (and IIRC, Linux is the only 
stack with TFO at present) it would probably be best to have that 
discussion in netdev.  At the very least it will have to "finish" in 
netdev anyway.

As for TFO and tools, theoretically, netperf top-of-trunk now has both 
client and server side support, though I've not been able to get it 
particularly tested as yet.  I am however, quite happy to discuss bugs 
in netperf's use of TFO here rather than netperf-talk :)

happy benchmarking,

rick jones

Re: [Cerowrt-devel] [Bloat] TCP TFO client behaviour

[Dave Taht]

On Tue, Dec 11, 2012 at 7:41 PM, Rick Jones <rick.jones2@hp.com> wrote:
> If there are bugs/issues in Linux's TFO (and IIRC, Linux is the only stack
> with TFO at present) it would probably be best to have that discussion in
> netdev.  At the very least it will have to "finish" in netdev anyway.
>
> As for TFO and tools, theoretically, netperf top-of-trunk now has both
> client and server side support, though I've not been able to get it
> particularly tested as yet.  I am however, quite happy to discuss bugs in
> netperf's use of TFO here rather than netperf-talk :)
>
> happy benchmarking,
>
> rick jones


Both the TFO enabled httping and netperf are now checked into the
ceropackages-3.3 repo, and will be built on the next build of cerowrt
3.6.X (obviously not fully functional until 3.7)

I note that the netperf appears to require that TCP_FASTOPEN be
defined by the underlying C library. Mine (glibc and uclibc) haven't
caught up yet, from a cursory grep... I will add a patch to define it
if not available unless rick beats me to it...

(httping just defines it as 23)

Are there any other tools/apps available to test TCP_FASTOPEN? I note
that I currently fire off netserver via xinetd which I suppose would
need to be modified.

-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

Re: [Cerowrt-devel] [Bloat] TCP TFO client behaviour

[Rick Jones]

On 12/11/2012 12:00 PM, Dave Taht wrote:
> I note that the netperf appears to require that TCP_FASTOPEN be
> defined by the underlying C library. Mine (glibc and uclibc) haven't
> caught up yet, from a cursory grep... I will add a patch to define it
> if not available unless rick beats me to it...

r618 or later in top-of-trunk (added in the last couple minutes) will 
define TCP_FASTOPEN if it isn't already defined.  I've stuck it in the 
same place where MSG_FASTOPEN gets defined and added some #warning 
directives about that so I'll be sure to remove the workaround once the 
defines make it where they are going.

happy benchmarking,

rick jones

Re: [Cerowrt-devel] [Bloat] TCP TFO client behaviour

[Ketan Kulkarni]

On Tue, Dec 11, 2012 at 11:22 PM, Dave Taht <dave.taht@gmail.com> wrote:
>>
>> I really wonder why this is sent to these lists instead of netdev ?
>
> In my case I find it impossible to read netdev on a regular basis,
> with the size of the traffic and the unbelievable patch burden - (not
> that I can't filter it, but that fairly often I find a patch too
> tempting to not apply and then play with)
>
> I have no problem taking a conversation to netdev if needed...
>
Well, I have opened a thread on netdev as well.

> However I'd note that TCP fast open is not just a linux feature, but
> affects the entire internet. Perhaps the readership here has a more
> broad view of how this should be approached.
>
First, I would really like to get wider views about this.
My only concern is -
If syn+data is sent by client and syn-ack only acks the ISN, then isnt
this a sufficient indication that server now is not supporting the
TFO?
So for further connections to this server instead of sending syn+data,
only ask for cookie. (fall back to the state where it was all started)
(Note that this condition is different from syn+data is dropped in the nw.)

Yuchung might be right in saying it doesn't lead to any performance
penalty, however sending syn+data to a server seems a little odd when
we know we have sufficient information to believe that it may not be
accepted at first, retransmitted later. And otherwise we also have a
way to fall back and re-attempt the TFO.

If you guys still insist, I can stop here and continue on netdev.

> Ketan has been busily adding support for TFO to a couple tools used in
> cerowrt. (httping is already out there in a release!)
>
> It's my hope to be able to sanely test it in cerowrt's 3.7.x release.
>
> I also am concerned about TFO wider adoption into other tools like
> these (ssh? dns?) and what those effects might be.
>
> I'm probably dropping the syn optimization in simple_qos.sh because of
> tcp fast open. But I would prefer to gather data and test, first, with
> good tools. Are there any other tools besides chrome and httpping
> setup for clients?
>
> I look forward to trying out the polipo support.
>
>>
>>
>> _______________________________________________
>> Bloat mailing list
>> Bloat@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/bloat
>
>
>
> --
> Dave Täht
>
> Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

Re: [Cerowrt-devel] [Bloat] TCP TFO client behaviour

[Eggert, Lars]

I suggest you discuss this on tcpm@ietf.org, where TFO is being developed.

Lars

On Dec 11, 2012, at 17:48, Ketan Kulkarni <ketkulka@gmail.com> wrote:

> Hi,
> I am testing tcp tfo behavior with httping client and polipo server.
> 
> One observation from my TFO testing  -If for a connection server sends a
> cookie to client, client always does TFO for subsequent connections. This
> is ok.
> 
> If for some reason, server stops supporting TFO (either because server got
> restarted without TFO support (in my case) or because path changed and the
> nw node is dropping packet with unknown syn option or stripping the
> option), client does not clear up its cookie cache. It always sends data in
> syn and server never acks the syn-data and client retransmits.
> 
> As per kernel code -if syn-data is not acked it is retransmitted
> immediately - with the assumption first syn was dropped (but the assumption
> server stopped supporting TFO might not have been considered)
> 
> My opinion is to flush the cookie for this server and re-attempt the cookie
> "negotiation" on subsequent connection.
> 
> Your thoughts?
> 
> Thanks,
> Ketan
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat