1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

End to end congestion control

Discussion in 'Tomato Firmware' started by i1135t, Jul 21, 2013.

  1. i1135t

    i1135t Network Guru Member

  2. koitsu

    koitsu Network Guru Member

    I meant to post about this before someone went crazy begging for it -- because for whatever reason people on this forum go absolutely apesh** over things like this. It's a borderline insane obsession.

    MIT has no idea how/why this works (meaning they don't understand why the existing TCP congestion control mechanisms are "worse"). They admit that indirectly (many people did not read the article, including tech people on Slashdot, and even more people don't understand it). Situations like this happen all the time with science, where someone "discovers something amazing" but can't explain the behaviour/problem until someone says "Um, you realise you didn't take into account X/Y/Z". Think I'm kidding? Watch this -- don't skim it, watch it.

    Furthermore, as I understand it, for it to work it requires the algorithm has be implemented on both ends (read: client and server). One end is not enough. The TCP congestion control algorithm they're mainly "playing atop of" is Cubic, which is not what the default is in Tomato-based firmwares (Tomato-based firmwares use Reno by default -- see /proc/sys/net/ipv4/tcp_congestion_control). In fact, Tomato-based firmwares do not include other congestion controls built in to the kernel -- reno is compiled in as the default, and vegas is compiled in as a module (so if loaded you could change to vegas); for proof of this, see release/src-rt/linux/linux-2.6/config_base in the TomatoUSB source code:

    # CONFIG_TCP_CONG_BIC is not set
    # CONFIG_TCP_CONG_CUBIC is not set
    # CONFIG_TCP_CONG_HTCP is not set
    # CONFIG_TCP_CONG_HSTCP is not set
    # CONFIG_TCP_CONG_HYBLA is not set
    # CONFIG_TCP_CONG_LP is not set
    # CONFIG_TCP_CONG_VENO is not set
    # CONFIG_TCP_CONG_YEAH is not set
    # CONFIG_DEFAULT_BIC is not set
    # CONFIG_DEFAULT_CUBIC is not set
    # CONFIG_DEFAULT_HTCP is not set
    # CONFIG_DEFAULT_VEGAS is not set
    If the Remy suite is going to be built and provided anywhere, it would be an Entware package. If you look at the Makefile, you'll see it relies on a library called protobuf, which is not part of Linux 2.6. So in summary, Remy should not be added to any firmware as part of the base system, it should be provided by third-party package systems like Entware or Optware.

    I will say that we should probably consider building/including Cubic as a module; people may see improvements using that, particularly since it's the default congestion algorithm for Linux 2.6 starting as of Linux 2.6.19. I imagine there is a reason, however, that the Tomato firmwares (which use Linux 2.6.22) default/choose Reno -- but that reason is unknown to me.

    Finally, the use of a VPN has no relation to TCP congestion control; any TCP-based protocol (ex. HTTP, HTTPS, SSH, telnet, SMTP, etc.) would be affected. And the VPN implementation people use matters as well (e.g. OpenVPN in TCP mode would be affected, OpenVPN in UDP mode would not be affected, native/true IPsec would not be affected, while IPsec over TCP would be affected). But as I said, there's nothing "unique" about VPNs that make congestion control matter any more or less than any other technology. If you're using a TCP-based VPN mechanism and your VPN provider is far away and has high latency, for all you know Cubic could improve the situation for you. You're welcome to enable Cubic in the kernel config and use it and see what happens.
  3. Victek

    Victek Network Guru Member

    As both of you said, it's and end to end sync. A paper comparing three systems can give a better overview. http://journal.info.unlp.edu.ar/journal/journal35/papers/JCST-Apr13-1.pdf line condition have a strong influence by choosing the right congestion algo, for domestic lines with retries Reno shows better response. For clean lines you can choice Cubic. I tested both systems in static configuration, results are fine but as I said it depends of line condition and number of peers.

    Here are the Tomato RAF settings, reno is not used....in some versions..just Beta test..
    Jan 1 01:00:48 RT-N66 user.info kernel: ipt_account 0.1.21 : Piotr Gasidlo <quaker@barbara.eu.org>, http://www.barbara.eu.org/~quaker/ipt_account/
    Jan 1 01:00:48 RT-N66 user.info kernel: net/ipv4/netfilter/tomato_ct.c [Jul 21 2013 13:55:51]
    Jan 1 01:00:48 RT-N66 user.info kernel: TCP cubic registered
    Jan 1 01:00:48 RT-N66 user.info kernel: NET: Registered protocol family 1

Share This Page