Sunday, October 3, 2010

Vegas vs. Reno

I'm not exactly sure why all the names of the TCP spin-offs happen to be cities in Nevada, but I'm more interested in the concepts behind the protocols, rather than trying to understand naming conventions in networking research. The papers we read on Vegas and Reno were fairly interesting, mainly because it showed that Vegas was a better protocol, but for some reason Reno is still in use.

The first paper was by the original creators of Vegas, showing off how much better than Reno their protocol was. The second paper reaffirmed a lot of the things that were stated in the first paper, but the authors noted a flaw in the Vegas protocol: Reno was more aggressive and stole bandwidth from Vegas. This issue was fixed in the third (and final) paper we read, stating that alpha and beta default values of Vegas could be optimized to improve fairness with Vegas.

However, we're still using Reno. We know Vegas is good (better than Reno), but its not good enough to change the norm. From what I understand from my professor, Reno already has a large install base and Vegas isn't a big enough improvement over the current norm (Reno) to justify a switch. Protocols like CUBIC were more aggressive than Reno, while Vegas was less aggressive and neither managed to work well with Reno, so they weren't accepted. Maybe it was because they couldn't integrate well and then outperform the existing protocol or maybe because, although the fairness issue was resolved, the paper didn't go into detail on how to measure buffer capacity in order to improve the fairness. Whatever the issue, most research seems to have moved on from trying to improve TCP and have focused on high speed transport protocols, which I'll probably read for next week.

No comments:

Post a Comment