It seems that every so often, someone comes up with a buzz to make the internet sound cooler and more hip. As of late, a lot of companies have been throwing around the word ‘cloud’. The term cloud doesn’t just refer to the internet, it refers to a way of life when it comes to hosting and managing your company’s software. The phrase ‘going to the cloud’ is always thrown around by companies that have migrated their software offsite into a large distributed system (maybe with Amazon or Azure) as a means of increasing availability and decreasing onsite management costs. The important thing about the cloud is that everything is host agnostic. At any particular time you could be talking to servers on completely opposite ends of country. With applications becoming more distributed in nature to meet availability demands, challenges arise in regards to controlling these large environments. Cloud environments are usually metered, but how you meter an application? An application can be on many machines at once, but if you want to throttle access to that application as a whole, how do you do that?
A paper presented in SIGCOMM ‘07 presents a system for doing distributed rate limiting. That authors took several approaches to limiting rate such as global random drop, flow proportional share, and global token bucket. They compared their results to a system that used a centralized token bucket. Each methodology had its strengths and weaknesses. In my opinion, I think flow proportional share was probably the best because it was able to “spread the wealth around” a little better. For example, when there were nodes that weren’t using all their allotted bandwidth, it was assigned to another node that could use it. So, generally, when an application that is throttled at 1 Mbps globally, this protocol makes it look like you are accessing one instance of an application at that rate. A really cool idea.