Re: Linux SCTP: what kind of performance should I expect from netperf?

[Dave Taht <dave.taht@gmail.com>]

On Wed, Apr 16, 2014 at 12:33 AM, Daniel Borkmann <dborkman@redhat.com> wrote:
> On 04/16/2014 03:23 AM, Dave Taht wrote:
> ...
>
>> It appears I despaired of SCTP's performance too early,
>> according to this commit, it just got vastly improved:
>>
>>
>> https://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=362d52040c71f6e8d8158be48c812d7729cb8df1
>>
>> way to go daniel!
>>
>> Have to write some tests for it now!
>
>
> Ok, thanks. That commit needs to be reworked in a different way
> by the original authors or us so that it won't hurt performance.
> The idea from the original commit is good, but the overall
> implementation is not yet fully there it seems.
>
>
>> I do wish someone could get the ledbat linux kernel module up to parity
>> with
>> at least the osx implementation and get it mainlined.
>>
>> https://github.com/silviov/TCP-LEDBAT
>
>
> Sounds interesting!


If it worked correctly... what appeared to happen at the time I'd
tested it is that it never really got into ramping up its window.

You could look at it and say "oh, yes, it's scavanging!" but no, it
was really stuck
at low bandwidth and not taking advantage of the path. Your fix to
sctp reminded me of that behavior of this code.

I figured it would be a fun weekend project to make tcp-ledbat on linux work,
something like 120 weekends ago. (The code has no owner anymore.)

certainly it would be awesome and useful if someone could make it work
- and at the time I last looked at it, which was pre-BQL, the linux
tcp stack was so messed up that I'd thought maybe the problem was
elsewhere. And there wasn't a lot of other ledbat code to compare it against,
which has changed.

But it does look like the code has a bug, see below.

netperf has the ability to select congestion control algos on the fly,
we have several tests in the netperf-wrapper suite that test the known
working tcp cc algorithms (reno, cubic, westwood, lp) against each other,
and I'd dearly like a test against uTP. and support for "SCTP_MAERTS"
in netperf itself.

syntax looks like this - 100mbit empty path:

root@comcast-gw:~# netperf -H 172.26.4.1 -t omni -- -K ledbat,ledbat
OMNI Send TEST from 0.0.0.0 () port 0 AF_INET to 172.26.4.1 () port 0
AF_INET : demo
Local       Remote      Local  Elapsed Throughput Throughput
Send Socket Recv Socket Send   Time               Units
Size        Size        Size   (sec)
Final       Final
65536       87380       65536  10.86   0.31       10^6bits/s

root@comcast-gw:~# netperf -H 172.26.4.1 -t omni -- -K lp,lp
OMNI Send TEST from 0.0.0.0 () port 0 AF_INET to 172.26.4.1 () port 0
AF_INET : demo
Local       Remote      Local  Elapsed Throughput Throughput
Send Socket Recv Socket Send   Time               Units
Size        Size        Size   (sec)
Final       Final
292128      650496      65536  10.02   94.12      10^6bits/s

so it's stuck at well below the capability of this path.

from a theoretical perspective, ledbat originally aimed at a target
delay of 25ms before backing off but that was unachievable in practice,
and they went to 100ms.

Now that we can reliably via various aqm techniques achieve target
delays well below that it would be cool to experiment with a delay based tcp
that could try to back off at 25ms or below...

(tom sawyer, trying to make painting a fence more attractive here)

-- 
Dave Täht

NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article