[Bloat] initial spreading patch?

[Dave Taht]

dear renaud:

my take on this was that we should measure this from a couple RTT samples
in the case of SSL, rather than a fixed qty, although the syn/synack
pair might be good enough for many purposes.

that said, do you have the simple patch lying around? the
dslreports.com tests show the
carnage when 8 or 24 flows start simultaneously.

I know that those that need TSO for their short transactions will hate
it but in my case what
I am seeing on an uplink (10mbit) is a giant IW10 GRO packet arrives
in the latest routers (where we do not break it up, presently, back
into packets), so I would like to fiddle with the concept more.

On Fri, Mar 21, 2014 at 8:53 AM, renaud sallantin
<renaud.sallantin at gmail.com> wrote:
> For our tests,  we needed to adjust the "tcp_initial_quantum" in the FQ,
> but as you said, it is just a FQ parameter.
>
> The "patch" we added, and once again, it was just a  few lines, enabled to
> set, via a sysctl parameter, the initial pacing value, regardless of the
> RTT.
> This can be valuable for different reasons:
>      o  In case of long RTT, not set the pacing value is going to introduce
> an un-necessary delay
> (we aims to use this mechanism for satcom, so the delay could be greater
> than 500ms)
>      o  In case of a wrong RTT measurement, i.e. an RTT measurement that is
> higher that the real RTT (because of congestion for example),  you are going
> to have a wrong pacing evaluation...
>
> and finally, for experimental purpose, be able to change the initial pacing
> value could be very interesting
>
>
> 2014-03-21 16:06 GMT+01:00 Eric Dumazet <eric.dumazet at gmail.com>:
>>
>> On Fri, 2014-03-21 at 09:15 +0100, renaud sallantin wrote:
>>
>> >
>> > FQ/pacing enables to do a lot of things,
>> > and as I already said, it could be used to easily implement the
>> > Initial Spreading.
>> > (we did it and it' s just a few lines to add, and a couple of
>> > parameters to change)
>> >
>> >
>> > But for the moment, FQ/Pacing sends the IW in one burst (up to 10
>> > segments).
>> >
>>
>> This is not true. This depends on RTT and your qdisc parameters.
>>
>> Whole point of TSO autosizing is to make all this stuff automatic.
>>
>> Here is the tcpdump output for a 10ms RTT, which is quite standard.
>>
>> You can see 5 packets are sent, with a delay of more than 1 ms.
>>
>> 07:58:52.616379 IP 10.246.11.51.39905 > 10.246.11.52.41276: S
>> 2187811646:2187811646(0) win 29200 <mss 1460,nop,nop,sackOK,nop,wscale 6>
>> 07:58:52.626575 IP 10.246.11.52.41276 > 10.246.11.51.39905: S
>> 81785763:81785763(0) ack 2187811647 win 29200 <mss
>> 1460,nop,nop,sackOK,nop,wscale 7>
>> 07:58:52.626642 IP 10.246.11.51.39905 > 10.246.11.52.41276: . ack 1 win
>> 457
>> 07:58:52.626671 IP 10.246.11.51.39905 > 10.246.11.52.41276: . 1:2921(2920)
>> ack 1 win 457
>> 07:58:52.627740 IP 10.246.11.51.39905 > 10.246.11.52.41276: .
>> 2921:5841(2920) ack 1 win 457
>> 07:58:52.628815 IP 10.246.11.51.39905 > 10.246.11.52.41276: .
>> 5841:8761(2920) ack 1 win 457
>> 07:58:52.629946 IP 10.246.11.51.39905 > 10.246.11.52.41276: .
>> 8761:11681(2920) ack 1 win 457
>> 07:58:52.631054 IP 10.246.11.51.39905 > 10.246.11.52.41276: .
>> 11681:14601(2920) ack 1 win 457
>> 07:58:52.637147 IP 10.246.11.52.41276 > 10.246.11.51.39905: . ack 2921 win
>> 274
>> 07:58:52.637207 IP 10.246.11.51.39905 > 10.246.11.52.41276: .
>> 14601:17521(2920) ack 1 win 457
>> 07:58:52.638117 IP 10.246.11.51.39905 > 10.246.11.52.41276: .
>> 17521:20441(2920) ack 1 win 457
>> 07:58:52.638114 IP 10.246.11.52.41276 > 10.246.11.51.39905: . ack 5841 win
>> 320
>> 07:58:52.639011 IP 10.246.11.51.39905 > 10.246.11.52.41276: .
>> 20441:23361(2920) ack 1 win 457
>>
>>
>> You also can tune /proc/sys/net/ipv4/tcp_min_tso_segs from 2 to 1 if you
>> really want...
>>
>> No kernel patches needed...
>>
>>
>>
>



-- 
Dave Täht
Open Networking needs **Open Source Hardware**

https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67