I'll try one last time.
If *ALL* of the three following conditions are true, Vegas _MAY_ help with latency _only on heavily congested networks_:
1. One of the endpoints *MUST* be *THE ROUTER ITSELF*. Thus, if you are just using "normal" Tomato, about the only thing it might help is the built-in FTP server, if you have one and have it directly on the Internet. If you are running third-party software on Tomato (transmission, Hiawatha, et al), then Vegas might actually help. If all of your software that actually creates TCP socket connections runs on clients sitting behind your router (Linux boxes, Windows boxes, Mac boxes, what have you), then enabling Vegas on the router _WILL DO NOTHING WHATSOEVER_, because the TCP packet headers that the algorithm modifies are created *ON THE ENDPOINT, NOT THE ROUTER* and that is the ONLY place they can be modified.
2. The connection *MUST* be TCP *ONLY*. UDP need not apply, since sliding TCP windows can't be supported in the absence of TCP headers (or TCP itself!).
3. The other endpoint (on the other side of your TCP socket - see above) _SHOULD_ be using Vegas congestion avoidance as well for maximum effect. If they are using CUBIC, it _may_ benefit. If they are using Reno (the default with most router OSes, but not with Windows XP/Vista/7), Vegas (in the vast majority of cases) will actually make things _worse_.
In general, QoS is going to make a difference only with outbound traffic, where Vegas seeks to optimize _both endpoints_ of a TCP connection…which is why it's a damned good idea to have Vegas on both sides (and where the apps are *ACTUALLY RUNNING*, see point #1). One-way optimization will actually lead to madness, since the outcome is completely unpredictable.
Honestly, the biggest mistake I ever made with the Tomato project was entering into the "arms race" with DD-WRT and implementing Vegas. Fooling around with congestion avoidance is a lost cause unless you really know what you're doing (*particularly* behind an asymmetric connection like consumer-grade DSL, cable modem, or FiOS, since all of the inbound buffering is done at the ISP completely outside of your control). QoS, on the other hand, can produce very real, useful results if used with forethought and understanding of how IP communications works in general (and you accept up front that you will only ever be able to optimize the outbound leg of any connection).
So…since 99.99% of the population does NOT fall into the above categories, despite the fact that Vegas is indeed implemented and working in Tomato, it _is_ snake oil because it *cannot* and *will not* help them…and _ANY_ reports you have read otherwise are wishful thinking in complete ignorance of what TCP Vegas actually is and does.
I've tried my best to explain this time and again, and pointed people at the whitepapers written by the creator of the algorithm, all to no avail. If people refuse to listen, I really can't help that.
No, CUBIC is not in Tomato, and it never will be on my watch, because every single thing I said above also applies to CUBIC, and nobody's going to listen to me talk about how CUBIC is useless except in very special cases, either.
It may be useful for you to read up on Vegas (and congestion control in general), where you'll quickly come to understand that a) none of them really apply to asymmetric connectivity and b) all of the tests showing benefit are on closed-loop LANs with the same algorithm in use on both endpoints - in other words, a local test lab. Local test lab != low-speed consumer-grade asymmetric WAN connection crossing oceans.
This is the last I will ever write about this subject, simply because I have better things to do with my time than repeat myself every few months. If I had the means, I'd rip Vegas out of Tomato forever, because this "debate" seems to have no end whatsoever.
And I sincerely apologize for coming across as rude, but I hope you can appreciate my frustration. Your questions - and doubts - suggest strongly you haven't done much research on the subject, and have refused to believe what you've read from people that actually know what they are talking about. So, that having been said, use it if you want - it won't make any (positive) difference, and won't change my life one way or the other.
FYI, none of this has _anything_ to do with PowerBoost whatsoever - PowerBoost is a means of using header stripping and compression, in addition to edging channel boundaries out a bit, to try to appear to be faster than you really are. In practice, it is _also_ snake oil, but I lack the patience to rant any further about that…Google is your friend.
It's simply not possible to get something out of nothing, and there is no "magic bullet" that is suddenly going to make a home DSL connection start behaving like a bonded T3. The best you can hope for is to control the order of the bits you're sending out - that's it. If you want to go faster, buy a fatter pipe from your telco or cable provider.