cubic patch

[Mihai Chelaru]

Hi,

I wrote a little piece of code[1] that should provide us CUBIC congestion control algorithm. Of course, default is still newreno and cubic may be activated using sysctl -w net.inet.tcp.congctl.selected=cubic .

Also in this patch I removed the tcp_sack_newack function that mostly duplicated newreno actions and moved the code mostly inside [new]reno.

Happy testing and please feedback !

[1] - ftp://ftp.netbsd.org/pub/NetBSD/misc/kefren/cubic-current.diff


Thanks,

[Christos Zoulas]

Post by Mihai Chelaru
Hi,
I wrote a little piece of code[1] that should provide us CUBIC
congestion control algorithm. Of course, default is still newreno and
cubic may be activated using sysctl -w
net.inet.tcp.congctl.selected=cubic .
Also in this patch I removed the tcp_sack_newack function that mostly
duplicated newreno actions and moved the code mostly inside [new]reno.
Happy testing and please feedback !
[1] - ftp://ftp.netbsd.org/pub/NetBSD/misc/kefren/cubic-current.diff

Thanks! Looks nice...

christos


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Matthias Scheler]

Post by Mihai Chelaru
Hi,
I wrote a little piece of code[1] that should provide us CUBIC congestion control algorithm. Of course, default is still newreno and cubic may be activated using sysctl -w net.inet.tcp.congctl.selected=cubic .
Also in this patch I removed the tcp_sack_newack function that mostly duplicated newreno actions and moved the code mostly inside [new]reno.
Happy testing and please feedback !
[1] - ftp://ftp.netbsd.org/pub/NetBSD/misc/kefren/cubic-current.diff

Any reason not to make CUBIC the default? It is e.g. what Linux
uses for a long time.

Kind regards

[Greg Troxel]

Post by Matthias Scheler

Post by Mihai Chelaru
[1] - ftp://ftp.netbsd.org/pub/NetBSD/misc/kefren/cubic-current.diff

Any reason not to make CUBIC the default? It is e.g. what Linux
uses for a long time.

I had the impression that CUBIC was not a standards-track RFC, and not
the recommendation of the IETF tcpimpl group, etc. I think we should
tread very carefully in moving beyond IETF recommendations.
Specifically I don't see CUBIC at
http://datatracker.ietf.org/wg/tcpm/

A while ago I looked at Linux TCP, I think BIC, and it seemed that it
was exceeding the amount of transmission allowed by the current
standards. But my memory of this is too fuzzy to really go on. My
point is that Linux setting CUBIC to be the default is not adequate
justification.

Also, I have a pending fix to SACK, that I posted long ago, that I will
try to get in. (By fix I mean a code bug, where after the change we'll
follow the congestion control specs more closely.) But I will need to
page this in again.


Have you compared CUBIC and our default?

[Matthias Scheler]

Post by Greg Troxel
Have you compared CUBIC and our default?

No, only Linux's "reno" and "cubic". And "cubic" seems to be the better
performing of those two.

Kind regards

[Greg Troxel]

Post by Matthias Scheler

Post by Greg Troxel
Have you compared CUBIC and our default?

No, only Linux's "reno" and "cubic". And "cubic" seems to be the better
performing of those two.

So the other question is if it meets the IETF congestion-control
standards. Any TCP implementation can be made to perform better by not
backing off.

I'm also curious if anyone has looked at the behavior in detail with
tcpdump2xplot. WHen I last did that on Linux in 2010 it only had BIC
(but was CentOS and therefore old already).

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Matthias Scheler]

Post by Greg Troxel

Post by Matthias Scheler

Post by Greg Troxel
Have you compared CUBIC and our default?

No, only Linux's "reno" and "cubic". And "cubic" seems to be the better
performing of those two.

So the other question is if it meets the IETF congestion-control
standards. Any TCP implementation can be made to perform better by not
backing off.

Of course. But even ISPs are asking or "cubic" on Linux servers they
deploy. So they clearly not concerned what it does to their networks.

The reality is that their a lots more Linux systems than NetBSD systems.
Networks haven't broken because the Linux systems use Cubic or RFC 6926.
But end user performance has improved a lot because of these changes.
And I think NetBSD should offer those performance improvements as well.

Kind regards

[Mouse]

Any TCP implementation can be made to perform better by not backing
off.

Only for very selfish values of "better" that include, for example,
driving overloaded networks into full-on congestion collapse.

I realize that's today's net all over, but that's no reason for NetBSD
to make it worse.

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Mihai Chelaru]

Post by Greg Troxel

Post by Matthias Scheler

Post by Mihai Chelaru
[1] - ftp://ftp.netbsd.org/pub/NetBSD/misc/kefren/cubic-current.diff

Any reason not to make CUBIC the default? It is e.g. what Linux
uses for a long time.

I had the impression that CUBIC was not a standards-track RFC, and not
the recommendation of the IETF tcpimpl group, etc. I think we should
tread very carefully in moving beyond IETF recommendations.
Specifically I don't see CUBIC at
http://datatracker.ietf.org/wg/tcpm/
A while ago I looked at Linux TCP, I think BIC, and it seemed that it
was exceeding the amount of transmission allowed by the current
standards. But my memory of this is too fuzzy to really go on. My
point is that Linux setting CUBIC to be the default is not adequate
justification.
Also, I have a pending fix to SACK, that I posted long ago, that I will
try to get in. (By fix I mean a code bug, where after the change we'll
follow the congestion control specs more closely.) But I will need to
page this in again.
Have you compared CUBIC and our default?

Hi,

Actually, I implemented CUBIC after consulting an IETF draft (
http://tools.ietf.org/html/draft-rhee-tcpm-cubic-02 ) and other
documents like the one written by Ha, Rhee & Xu. I couldn't find any RFC
regarding CUBIC. On the other hand, NewReno is referenced in several RFCs.

All my tests resulted in total throughput difference between CUBIC and
NewReno that could fit inside margin of error.

[Greg Troxel]

Post by Mihai Chelaru
Actually, I implemented CUBIC after consulting an IETF draft (
http://tools.ietf.org/html/draft-rhee-tcpm-cubic-02 ) and other
documents like the one written by Ha, Rhee & Xu. I couldn't find any
RFC regarding CUBIC. On the other hand, NewReno is referenced in
several RFCs.

Thanks. Perhaps that expired; I didn't see it on the tracker page.
Looking, I see it expired in 2009. Do you know why the people who
prefer CUBIC haven't maintained a draft and at least published it as
EXPERIMENTAL? The notions that it's default in Linux and the draft is
long-expired don't really seem to go together.

Post by Mihai Chelaru
All my tests resulted in total throughput difference between CUBIC and
NewReno that could fit inside margin of error.

That's interesting, but if CUBIC does meet the congestion-control rules
it is not entirely surprising. If you haven't run tcpdump2xplot (and
xplot), you'll probably find that interesting.

I think it's great that we have CUBIC in our system. I don't mean to
sound negative about options. But, I think NetBSD should closely
follow IETF standards-track recommendations for what is the default
behavior.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Mouse]

Post by Matthias Scheler
Networks haven't broken because the Linux systems use Cubic or RFC 6926.

Networks haven't been driven completely unusable, no. But networks
break so often that I'm not sure anyone can really ascribe a cause to
the breakage - or lack thereof - with any real level of confidence.

Post by Matthias Scheler
But end user performance has improved a lot because of these changes.
And I think NetBSD should offer those performance improvements as well.

I remain unconvinced this isn't just Linux, collectively, getting
selfish and aggressively grabbing more of the network, in which case it
would catastrophically fail the "what if everyone did it" test. Linux,
as much as it may outnumber NetBSD, is still way outnumbered by other
systems, notably Windows, and is nowhere near widespread enough to, by
itself, constitute a "what if everyone did it" experiment.

As I wrote in another recent email in this thread, I realize that
today's net _is_ selfishly aggressive, but I still don't think that's
any reason why NetBSD should exacerbate the problem. Until NetBSD can
be confident CUBIC _does_ pass the "what if everyone did it" test, I
think adopting it would be a bad idea.

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Erik Fair]

NetBSD can help a little by implementing RED and/or one of its variants:

http://www.icir.org/floyd/red.html

and a re-read of Nagle's RFC "On Packet Switches with Infinite Storage" is worthwhile:

http://en.wikipedia.org/wiki/Random_early_detection

I'm curious: amongst those of you using NetBSD for IP routing, how many have added ALTQ to the kernel and have configured it?

Erik <***@netbsd.org>


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Mindaugas Rasiukevicius]

Post by Erik Fair
http://www.icir.org/floyd/red.html
http://en.wikipedia.org/wiki/Random_early_detection

Maybe in late 1990s, but not in 2013. There have been recent developments
in the area. You might find this paper interesting:

http://queue.acm.org/detail.cfm?id=2209336

The algorithm itself is quite simple and straightforward to code. However,
we need a well abstracted queueing interface (sorry, but ad hoc addition of
ALTQ via IF_*() macros is pretty horrible).

Post by Erik Fair
I'm curious: amongst those of you using NetBSD for IP routing, how many
have added ALTQ to the kernel and have configured it?

[Motoyuki OHMORI]

Hi,

Post by Mihai Chelaru
Happy testing and please feedback !
[1] - ftp://ftp.netbsd.org/pub/NetBSD/misc/kefren/cubic-current.diff

Has it already been removed? If so, is it possible to make it available
again? I am much curious about CUBIC on NetBSD, and would like to experiment
on its performance and friendliness with other congestion control algorithms
such as [new]reno and compound TCP.

Thanks in advance.

Best regards,
--

Post by Mihai Chelaru
Hi,
I wrote a little piece of code[1] that should provide us CUBIC congestion control algorithm. Of course, default is still newreno and cubic may be activated using sysctl -w net.inet.tcp.congctl.selected=cubic .
Also in this patch I removed the tcp_sack_newack function that mostly duplicated newreno actions and moved the code mostly inside [new]reno.
Happy testing and please feedback !
[1] - ftp://ftp.netbsd.org/pub/NetBSD/misc/kefren/cubic-current.diff
Thanks,
--
Mihai Chelaru

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Mihai Chelaru]

Post by Motoyuki OHMORI
Hi,

Post by Mihai Chelaru
Happy testing and please feedback !
[1] - ftp://ftp.netbsd.org/pub/NetBSD/misc/kefren/cubic-current.diff

Has it already been removed? If so, is it possible to make it available
again? I am much curious about CUBIC on NetBSD, and would like to experiment
on its performance and friendliness with other congestion control algorithms
such as [new]reno and compound TCP.
Thanks in advance.

Hi,

A slightly modified version of the original code was merged into -current. Here are the changes:

http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/netinet/tcp_congctl.c.diff?r1=1.17&r2=1.19&sortby=date&only_with_tag=MAIN&f=h
http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/netinet/tcp_congctl.h.diff?r1=1.6&r2=1.7&f=h
http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/netinet/tcp_input.c.diff?r1=1.329&r2=1.330&sortby=date&only_with_tag=MAIN&f=h


Happy to see real testing for CUBIC as I haven't got the necessary setup to do it.

Thanks,

[Thor Lancelot Simon]

Post by Mindaugas Rasiukevicius
Maybe in late 1990s, but not in 2013. There have been recent developments
http://queue.acm.org/detail.cfm?id=2209336
The algorithm itself is quite simple and straightforward to code. However,
we need a well abstracted queueing interface (sorry, but ad hoc addition of
ALTQ via IF_*() macros is pretty horrible).

Another alternative that requires little configuration and still seems to
perform well is SFB.

Thor

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[David Brownlee]

Post by Erik Fair
I'm curious: amongst those of you using NetBSD for IP routing, how many have added ALTQ to the kernel and have configured it?

Only in a simple home routed environment to compensate for a tragic
ISP, and even then priq was enough

# Up/Down 443 / 12.599
interface bge0 bandwidth 380K priq

class priq bge0 class5 NULL priority 5 qlimit 100
filter bge0 class5 0 0 0 0 1 # ICMP
filter bge0 class5 0 53 0 0 17 # dns UDP
filter bge0 class5 0 60000 0 0 17 # mosh UDP
filter bge0 class5 0 60001 0 0 17 # mosh UDP

class priq bge0 class4 NULL priority 4
filter bge0 class4 0 22 0 0 6 tos 0x10 # ssh TCP interactive

class priq bge0 class3 NULL priority 3
filter bge0 class3 0 80 0 0 6 # http TDP port 80

class priq bge0 class2 NULL priority 2 default qlimit 25

class priq bge0 class1 NULL priority 1 qlimit 25
filter bge0 class1 0 22 0 0 6 tos 0x08 # ssh bulk

class priq bge0 class0 NULL priority 0 qlimit 25
filter bge0 class0 0 0 0 51413 6 # torrent

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Motoyuki OHMORI]

Hi,

Post by Mihai Chelaru
http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/netinet/tcp_congctl.c.diff?r1=1.17&r2=1.19&sortby=date&only_with_tag=MAIN&f=h
http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/netinet/tcp_congctl.h.diff?r1=1.6&r2=1.7&f=h
http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/netinet/tcp_input.c.diff?r1=1.329&r2=1.330&sortby=date&only_with_tag=MAIN&f=h
Happy to see real testing for CUBIC as I haven't got the necessary setup to do it.

Ah, your changes have been already committed. I would like to then try them.

Best regards,
--
Motoyuki OHMORI <***@tottori-u.ac.jp>


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de