Thursday, October 28, 2010

Cloud control

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.

Tuesday, October 26, 2010

IPv4 address exhaustion

One of things that worries me about our current addressing state is that no progress seems to be being made in the US to switch over to IPv6. Everyone knows that IPv4 addresses are running very thin. Current projections (there are a lot more than this one) show that addresses, if allocated at their current rate, will result in address exhaustion by 2011. That’s not that far off! Another thing that worries me is that when IPv4 gets put on the endangered species list, a few individuals are going to take the opportunity to rob the world blind by selling IP address at exorbitantly high prices all because there is no other option for users to get a presence on the web. NAT is a band aid. NAT only works for larger organizations. NAT doesn’t work for the mom and pop internet shops that go out to hosting services and are required to buy a static IP so that they can use SSL to participate in the vast internet ecommerce community. The other issue I see is that when we really start scraping the bottom of the barrel, some consumers might be denied an IP address because there aren’t enough and the few that are left are reserved for those with deeper pockets.

It’s not like there is not a solution to the address problem. The solution has been around for a very long time and is implemented in every major operating system in the world. The only challenge we think we have is that of the IPv6 network stack not being compatible with IPv4’s. I think IPv6 is turned on by default in most operating systems. The only places I see problems would be the network itself. If there are still routers unable to run IPv6 then I think they needed to be replaced regardless because they are probably extremely old. I think it would be easier to deal with the pain of switching now, rather than later.

Thursday, October 21, 2010

Net neutrality

Neutrality of the internet has been a debate raging for a very long time. I will provide a brief summary of what I think the pros and cons are of net neutrality. The internet has grown to a size where I believe regulations might become necessary to keep it working well in addition to maintain its openness. One of the things that people in to realize is that the internet costs money to run. It requires agreements between organizations for traffic to flow across networks. When companies and individual consumers sign-up, they expect a certain quality of service. Their contracts may even make certain guarantees pertaining to that very thing. As such, ISPs may be forced to throttle certain popular internet applications (i.e. P2P) in order to maintain a certain QoS for their other customers. Net Neutrality, in one sense, would prevent that kind of QoS monitoring. Although P2P can be used for completely legal things (ex. getting distros of Linux or other large files, Blizzard uses it to distribute Starcraft 2), I would argue that most users use it to download copyrighted media illegally. Sad, but true. A P2P network is also designed to take advantage of all available network bandwidth. It can easily affect other services on a network if left unchecked. In that instance, I may agree that a non-neutral approach to the internet would be beneficial for all users.

Let’s take it the other direction. I think it is completely wrong for ISPs to censor content and services that  are completely legal. One of the arguments opponents of net neutrality present is that there is a limited amount of bandwidth. That may be true, but maybe instead of investing money in finding more ways to make money, invest money in ways that will more efficiently use the network (i.e. network layer multicast would be great for video games). Another argument I find a little ridiculous is that of certain services “freeloading.” The internet is very much a “request for services” architecture. Skype doesn’t approach you, you as the user approach Skype and ask them to use their service. As the user, I’m paying my ISP so that I can access all these services. The ISP shouldn’t care beyond receiving a check from me every month. Obviously if I stopped paying then I would no longer be able to access Skype and there would be no way they could approach me. Another argument against neutrality is that of the lack of incentives for ISPs to invest. What are we paying the CEOs for then? Are they so out of touch that they can’t come up with other ways to make money in a neutral environment? There are plenty of services that ISPs could offer to monetize in addition to offering access to the internet.

There are definitely pros and cons to complete net neutrality. I don’t think it is possible to actually reach, because money, profit margins and power drive this planet. I do think we can’t leave the fate of the internet to the invisible hand because all the alternatives probably aren’t much better. Like many other things in this country that affect the majority of people’s livelihoods, it will probably have to be kept in check by the government. Whether that is good or not has yet to be seen.

Tuesday, October 19, 2010


Network layer multicast is a really cool idea. It makes the network responsible for replicated data to users who want to receive it. For example, an entity streaming a video would only have to broadcast one copy of it and the network would duplicate the packets out to those you want watch the video. Quite a few people have taken a stab at it that have resulted in protocols such as DVMRP, CBT, and PIM. One of the biggest reasons for its failure is that of the lack of any substantial app that no one can live without. As we’ve discussed network layer multicast in class, I personally believe that multicast was way ahead of its time and that its debut was extremely premature as there was not an internet infrastructure back then as there was today. I think that if the inventors would have waited 15 years or so (i.e. waited for YouTube, Netflix, Hulu, etc.), they would have had a greater chance of making a real impact on networking. That argument obviously hinges on the fact that hardware vendors and service providers would be immediately willing to switch.

Today we use application layer multicast to sort of mimic what the network later would do—not quite the same. We also distribute content via content distribution networks to help the scalability of data access. I often wonder how much we can shove into the application layer. I wonder if at some point all the overhead will catch up with us. Don’t get me wrong, we have been able to craft some incredible things in the application layer. However, there are some interesting ideas that I think would benefit the internet and its users a whole.

Saturday, October 16, 2010

HLP, why is change for the better so difficult?

Often hind sight is 20/20 when look at software and see immediately how things should have been done from the beginning. Such is the thought I had when we were reading about HLP (hyper link-state and path-vector protocol) this past week. The border gateway protocol (BGP) is used to communicate paths between autonomous systems. It’s how routers learn how to get packets from place to another. Some of the biggest problems with BGP is that it advertises changes that don’t need to be advertised and is susceptible to the count to infinity problem. This is the very protocol that is currently routing our packets on the internet.

HLP provides a new take on routing and struck me as something that was so intuitive that I couldn’t understand why it hadn’t been thought of from the beginning. As per the name, it is a combination of link-state and path vector routing. It uses link-state routing within a hierarchy. It uses path vector between hierarchies. What’s nice about HLP, is that it uses a fragmented path vector which basically means that node B will tell node A that it has a path to E. What A doesn’t need to know is that that path will also go through C and D. BGP, on the other hand, would let A know all those details even though it didn’t need to know them. The nice thing about HLP is that if cost changes occur between C and D and packets start getting routed through F to get to E, A won’t get notified because it is not important for A to know. This keeps routing tables much smaller, which is good. The paper shows incredible performance benefits over BGP, so why isn’t the IETF taking a good hard look at HLP? Not only that, because the size of the internet is exploding, BGP tables are becoming extremely large. How long can that keep going?

It seems to me like change is never considered until something catastrophic happens. I think an interesting research area in networking would be change deployment. At some point I think we’ve just got to force some changes because it seems to me if we wait until something bad happens, we’re going to wish we changed it earlier anyway. Look at IPv4. The last statistic I heard was that if address usage continues like it is, we will be out of addresses by first quarter next year. That’s not a great thing to hear. Whether it happens or not is a different story. But, point is, there’s going to be panic if we reach that point where no one can allocate an address anymore. I understand and appreciate the hard problem change presents, but we can’t make 100% of the people happy 100% of the time. Let’s just start flipping the switch.

Thursday, October 14, 2010

Computer networks like social networks–part 2

In my previous blob posting, I just threw out the question, “what if the internet was organized like a social network, what would it look like?” I spent a little time throwing out some initial ideas that came to me. A commenter wanted to understand my vision of this concept a little better—do I see this relating to conventional wired networks or to the more free-form wireless mesh networks? I thought that I would pontificate a little more on the subject. Social networks are well connected networks. To lay the wire infrastructure to mimic that on a per-user basis would be prohibitively expensive and not scalable. At an ISP level, we might already see some limited social network behaviors as those who are paying customers might be considered an ISP’s “friend,” however, this is a unidirectional relationship seeing as how an ISP would never route internet traffic over its customers’ networks.

Wireless mesh networks or ad hoc networks, at a distance, seem to fit this model much better. In an ad hoc network, peers are connected to lots of other peers and each acts as sort of a smaller router. To get information from one peer to another, you rely on your other peers to route it appropriately. The relations you have with your peers can change as you move. So, applying social networks to ad hoc networks, we can come up with some interesting things. If you find that you communicate with a friend of a friend more efficiently directly than through your mutual friend, you could connect directly thus making the network more connected. Social networks also have an interesting reputation dynamic as multiple people probably have multiple mutual friends. Reputation in a social network can have a positive or negative effect. It can award you additional friend connections or it can make so that nobody wants to communicate with you. You could forward broadcasts to your friends if you yourself find them interesting. There are lots of ways in which a social network like structure could apply to ad hoc networks.

Saturday, October 9, 2010

Computer networks organized like social networks

I’m supposed to reflect twice a week on things related to networking. We just finished the transport layer, but I’ve got to say, I really don’t have a lot to say about it. Sure we’ve read about some cool protocols like DCCP, but other than that, I’m looking forward to moving on to the next topic. Networks are an interesting things. They connect computers and, ultimately, people together. As I’ve been thinking about things to reflect on, one weird question that came to me was, what if the internet was organized like a social network, what would it look like? How would you route information? Could you prioritize information? What kind of addressing would there be?

I imagine that a social computer network would be able to prioritize traffic very easily because you would give your “friends” higher priority. I can imagine security being an interesting thing in a social computer network. You could probably block certain kinds of content easily without firewalls. You could probably measure the goodness of your “friends” to make sure they are allowing you to cross their network as much as they cross yours. You would be able to easily multicast content because other networks that like your content would “share” it on their network. There are some interesting thoughts that come when applying social structures to networks.

Wednesday, October 6, 2010


I've been in some interesting discussions this week about the transport layer of the network stack, specifically discussions about transport protocols that depart from what might be considered convention. DCCP has been an interesting topic. It stands for Datagram Congestion Control Protocol. Normally when we think of datagrams we think of UDP, a great protocol for things where timeliness is more important than reliability. UDP is useful in applications such as games, VoIP, and streaming video. These applications only care about receiving the most up-to-date information quickly. Loss is usually acceptable (causing artifacts to occur) as long as there is no delay. The biggest downside to UDP is that it can quickly overload a network because there is no congestion control. For this reason, a lot of network administrators block UDP from travelling outside of local area networks.

DCCP provides an interesting solution to this problem. They’re protocol provides congestion control without reliability. One of the issues this automatically presents is that of making sure the latest information still arrives in a timely fashion. One of the approaches they took initially was to take TCP and rip out reliability to see if that worked. It didn’t. It turns out that TCP’s tightly coupled algorithms break when all parties are not present. One of the interesting things about DCCP is that congestion control is modular, meaning, you can swap out congestion control algorithms. I think DCCP is a really good idea. There is plenty of need for congestion controlled unreliable protocols since online video services and VoIP have taken off.