congestion control confusion

Discussion in 'Tomato Firmware' started by Mangix, Nov 4, 2012.

  1. Mangix

    Mangix Networkin' Nut Member

    After reading this thread: , I've come to the conclusion that all(most?) flavors of tomato use TCP Reno to handle any potential congestion with TCP Vegas available as a hidden setting(nvram variable(s)).

    My question is: Why only those two? TCP Vegas and Reno tend to perform similar in my experience. The interesting ones are TCP Westwood(excellent performance over WiFi in my experience) and TCP Hybla(for satellite links).
  2. lefty

    lefty Addicted to LI Member

  3. rs232

    rs232 Network Guru Member

    Correct, the TCP version (vegas/reno) affects only traffic sourced or destinated to the router itself and not routed/natted traffic
  4. Mangix

    Mangix Networkin' Nut Member

    And in my experience, CUBIC and Westwood do under dd-wrt. CUBIC gives me weird buffering issues with youtube whereas Westwood gives me smoother wifi performance. I've never tested Hybla as I don't have a satellite connection.

    Which begs the question. Why has nobody bothered to implement any other congestion avoidance algorithms? Not important enough?
  5. phuque99

    phuque99 LI Guru Member

    I suppose if the mod maintainers believed in a specific congestion control algorithm or feel that it is important for them, they would have compiled them into their own builds. If a specific algorithm is available in the Linux kernel version used by Tomato, then it is already there. There's no need to "implement". All you need is turn on the compile flags for that specific algorithm.
  6. rhester72

    rhester72 Network Guru Member

    This is what's known as a red herring, because as stated previously, it is impossible for -any- congestion-avoidance algorithm to be applied to anything *except endpoints of the connection*. Since WiFi, by definition, implies the router is _not_ the connection endpoint, it is literally impossible for any CAA to have any effect whatsoever beyond a perceived placebo effect.

  7. Mangix

    Mangix Networkin' Nut Member

    That sounds fine and dandy but when theory doesn't agree with reality, it's a mistake to make reality fit theory no matter the cost. This is what one of the dd-wrt devs says

    My short experience with testing these things agrees with this assessment. No difference between Reno and Vegas but CUBIC and Westwood definitely do. In my case CUBIC gave worse performance as I remember getting buffering issues with YouTube that were not present with Reno, Vegas, or Westwood. For me at least, Westwood seems to give me the best combination of latency and bandwidth and as a result, that is what I use.
  8. rhester72

    rhester72 Network Guru Member

    This simply isn't possible, and I'd advise doing your own research on what the algorithms are and how they work than taking blind advice from a forum (from anyone). TCP congestion avoidance is an endpoint solution, period, and for it to be "assimilated" via intermediate hops would be utterly disastrous (what do you do when one endpoint is Reno, the next upstream hop is Vegas, and your ISP is CUBIC?).

    No further discussion forthcoming from me on this, I just don't want misinformation out there being reported as fact.

  9. gutsman7

    gutsman7 Networkin' Nut Member

  10. Mangix

    Mangix Networkin' Nut Member

    All testing was performed without using QoS(I never use QoS) .

    My initial question was why it's not implemented. As I got the answer(lack of interest) I'll stop as well.
  11. lefty

    lefty Addicted to LI Member

    For the record, Fractal is not one of the dd-wrt devs, he does his own compiles and test builds, but isn't one of the official devs and cannot make commits to the dd-wrt svn tree. His efforts are well appreciated, but you'd be hard pressed to actually see one of the official dd-wrt devs discuss TCP congestion control algorithms, and probably for good reason.
  12. Toastman

    Toastman Super Moderator Staff Member Member

    lefty is correct. TCP vegas (or any other congestion control mechanism) has no effect on traffic passing through the router. Devs are bored with this subject being raised every few months and having to repeat the whole thing again. It has nothing to do with lack of interest, TCP Vegas settings were removed from the GUI because they don't do anything.

    EDIT - there seem to be so many people giving half baked and misleading advice and information. Guys, it doesn't matter a jot what method u choose to run on the router, it will not have any effect on stuff PASSING THROUGH the router. So many people convinced themselves otherwise with TCP Vegas, it was so embarrassing.
  13. Ernesto Elias

    Ernesto Elias Serious Server Member

    Well to whoever wants to activate TCP Westwood go to tools and then go to system then type this into the command box:

    echo "westwood" > /proc/sys/net/ipv4/tcp_congestion_control

    I executed the command and it didn't came back as an error so I'm assuming that it got executed.
  14. Mangix

    Mangix Networkin' Nut Member

    that won't work as it's a read-only filesystem.

    replace echo "westwood" > with cat.
  15. Ernesto Elias

    Ernesto Elias Serious Server Member

    It says reno. So is there a way to activate it then ?
  16. Mangix

    Mangix Networkin' Nut Member

    firmware needs to be recompiled. or maybe unpacking the firmware, fixing the value, and then repacking would work. not sure.
  17. RMerlin

    RMerlin Network Guru Member

    The /proc filesystem is a special, R/W device. It's unrelated to the flash, so you can indeed configure various aspects of the FW by echoing a value to an appropriate entry there.
  18. Marcel Tunks

    Marcel Tunks Networkin' Nut Member

    Nobody has commented on the use of TCP congestion control algorithms on PCs, i.e. the "end" of your end-to-end connection. Is there any value in enabling such algorithms for PC's on a network? (LAN-LAN or LAN-WAN connections?)
  19. Mangix

    Mangix Networkin' Nut Member

    No idea. On Windows 8, I can't figure out how to enable Compound TCP so I can't really tell you.

    That being said, I do use traffic shaping, specifically cFos:

    this completely does not work on shibby's latest build for some reason:

    root@linksys:/tmp/home/root# cat /proc/sys/net/ipv4/tcp_congestion_control
    root@linksys:/tmp/home/root# echo "westwood" > /proc/sys/net/ipv4/tcp_congestion
    echo: write error: No such file or directory
  20. koitsu

    koitsu Network Guru Member

    The Westwood algorithm is not compiled into the kernel. You could have checked /proc/sys/net/ipv4/tcp_available_congestion_control for a list of algorithms available:

    root@gw:/tmp/home/root# cat /proc/sys/net/ipv4/tcp_available_congestion_control
    What's available per the kernel config is only Reno (the stock default), and Vegas (run modprobe tcp_vegas first):

    jdc@debian:~/tomato/release/src-rt/linux/linux-2.6$ grep CONFIG_TCP_CONG config_base
    # 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
    To understand the difference in algorithm models, here you go:

    Remember: westwood != TCP Compound. TCP Compound was discontinued as of 2.6.17 (see the above page).

    I strongly suggest folks do not change their congestion algorithm. Stick with Reno. You really need to have a deep understanding of TCP stacks to truly understand the implications; I have only met 4, maybe 5 at most, people in my entire life who have a decent grasp of TCP enough to know when an alternate algorithm is applicable. There are also bugs in many of the other algorithms -- I know these refer to kernels not in use on TomatoUSB, but they should act as resources that confirm my statements:
  21. Mangix

    Mangix Networkin' Nut Member

    With dd-wrt, westwood has always given me excellent results with youtube. Not a dealbreaker though.

    I forgot to link to tests a dd-wrt forum member did. Unfortunately even though I can compile my own build of tomato to test, I have no equipment to test with.
  22. koitsu

    koitsu Network Guru Member

    Those results are inconclusive; you cannot use Youtube as a test subject unless you have mapped out all their DNS/FQDNs to a specific set of IP addresses (this is a massive undertaking given their CDN). Youtube uses a multitude of load balancing techniques (including anycast if I remember right), as I explain in this thread, so those numbers could simply be the result of talking to a server with a shorter or less latent path than another, or a less overloaded server. Again: you cannot use Youtube as a test subject. You need to use something that's much more static. This is network throughput testing/"benchmarking" 101. *shakes head* :/
  23. Mangix

    Mangix Networkin' Nut Member

    Those results are not mine and in no way have anything to do with YouTube. My comment had to do with my own experience watching youtube videos(faster load in general. Funny enough, CUBIC performed worse than Vegas for me).

    And yes I do agree that YouTube is a bad example because of the load balancing.

    Still, westwood does improve performance when using wifi(which is what it was designed to do in the first place).
  24. koitsu

    koitsu Network Guru Member

    I understand, but you referenced that thread + quoted it as some sort of reference material. So I'll reference this part of it, bolded:

    Now take what that guy said and read what lefty and Toastman wrote earlier in the thread. I'm a little confused by this as well, because I understand how NAT works, but I have never looked at how kernels (both Linux and FreeBSD pf) actually implement portions of NAT code-wise. The general concept though -- focusing on TCP just to keep it simple:

    The client within the reserved IP space (i.e. a client in, but not the router itself) sends a packet to a destination that isn't on its local LAN segment, thus goes out the default gateway (, i.e. the router). The router then has to re-write the IP header portion of the packet (to contain the WAN IP), and choose a different port number (for the WAN side, e.g., then keep track of ("map") what correlates with what (i.e. the TCP session initiated by port 8592 to port 1234 correlates with port 45019). The router has to keep track of TCP sessions getting opened (client->internet), getting closed, as well as some other anomalous states (and reject those).

    cat /proc/net/ip_conntrack sometime. That's the mapping table at any given moment. It's a lot of output, but look at it -- what I said is true.

    Because of how NAT works and how the Linux router has to manipulate portions (but not all of) the packet content, I can see how a different congestion algorithm could affect connections between a client and the router, as well as a client and the Internet. Unless, of course, something like /proc/sys/net/ipv4/netfilter/ip_conntrack_fastnat completely sidesteps any kind of algorithm behaviour when it finds a relevant mapping entry to correlate the inbound packet with. But I don't know how that'd be possible, or else there would be blind situations where no algorithm at all is applied (look at how Reno works first).

    What people would need to do is use something like iperf between a LAN client and the router (i.e. no NAT being used), with different TCP congestion methods being chosen for each test, and then perform the same test but between a LAN client and the Internet (going through the router using NAT, to a specific/static host on the net somewhere). Other tools just aren't going to cut it for reliable testing. Usually when it comes to this type of testing, Wireshark is also involved, or some custom-made utility. TCP algorithms require that you simulate things like packet loss, TCP retransmissions, and a whole bunch of other whatnots -- iperf has these capabilities natively.

    So, consider me, a technical guy, both convinced and confused by both earlier statements in the thread and by what that guy said on the DD-WRT forum. Edit: seems another guy over at the DD-WRT forum is wondering the exact same thing I am.
  25. Mangix

    Mangix Networkin' Nut Member

    I can't say I disagree with anything you have said. Ultimately the way to figure out what's going on is to read the kernel code and see what the kernel is actually doing when applying these different congestion control methods. Linus Torvalds said it best: Standards are paper. I use paper to wipe my butt every day. That's how much that paper is worth.

    In theory this should not be but clearly there is something funny happening. Not something that I can figure out though.

    As for client > router iperf, I may be able to do that in the near future and do some tests. We'll see.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice