Non-static networks

Randy Buck wrote this article for our discussion of the network layer in CS660. It was a really exciting discussion about how relaxing the requirement for finding the shortest path in a network could result in huge benefits in routing table size and routing efficiency (ironic, isn't it?). The downside, however, is that the benefits only work in theory on a static network, which the Internet very much is not -- nodes come and go all the time. I've been trying to think of some way around that problem, but nothing has panned out so far. Here's what I have thought of and the problems therewith:

1. Central registration server. No. Just no. That just becomes the bottleneck in the network, and everything still has to register or time out with it. Why did I even think of this one?

2. Assign nodes with physical location-based names, and have those locations pre-assigned for an entire namespace. Traffic could then try and hit a certain address, and they'd either get a response from it if something exists at that address, or they wouldn't. The problems here would still lie in trying to get something more human-readable, as well as with mobile devices. Perhaps we should only map routers/access points on the network?

3. Whatever somebody else puts here. It seems like a daunting task, and in an area of networking that I'm just not as up-to-date on.

Ownership of the Pipe

Connected to in-class discussion of network neutrality, it was discovered that pretty much everyone there felt good about the idea of letting the consumer/business/other customer own the pipe going to their house/building, then allowing them to choose the ISP they would connect to at some central routing box. This seems like a great way to encourage competition without incurring the overhead and other potential problems associated with regulation. The problem is that certain largish companies have already paid at least a significant portion of the cost to put infrastructure in, and they should be allowed to profit from that. So how do we resolve these ideals? I'm not sure of the answer, but here are a few ideas that were postulated:

1. After a certain amount of time (which has perhaps already passed), the companies have made back their investment plus a reasonable profit, so ownership should pass to someone else (preferably the building owners).

I see a few problems with this approach. For one, it feels a little to close to the principle of nationalization for my liking. Secondly, I don't think it would fly with my understanding of the way things work in the US. Since the companies are losing property, they should be compensated equitably for their loss. That leads me to solution #2:

2. Some plan could be established whereby customers could purchase the pipe going to their house.

Again, I'm not sure about all the details, but I like the principle of this one a little more. The company can be compensated for the effort they exerted building the infrastructure, but either directly or indirectly (perhaps via the municipality), the customer could gain control of their "last mile" pipe and foster competition. Questions I have about this approach are what happens if an ISP doesn't want to sell their pipe, and how will the pricing work?

3. A competing infrastructure could be established.

This seems wasteful both in terms of redundant infrastructure and in tax money already spent subsidizing the existing infrastructure, but it may be the only way to fairly guarantee competition. It might be useful for cities to use their resources to build the infrastructure in an ISP-neutral way, but the cities large enough to afford it also have enough bureaucracy to not be able to do it well.

Anyone else have some thoughts? I'd love to see more competition in ISPs one day.

Network neutrality and panic

Reading Douglas A. Hass' 2008 paper on network neutrality was an interesting experience for me. I've never been a big fan of government regulation anyway (I see it as a last resort), but they made some interesting arguments regarding history; there isn't any to justify the need for net neutrality.

I had never thought about AOL in the context of them being the very monopolistic entity that proponents of net neutrality regulation fear, but this is due to the fact that they failed as that entity! At least up to this point, ISPs that have gotten "too big for their britches" have had huge losses in their customer base (quite a few million in AOL's case), indicating that competition is alive, well, and keeping ISPs from abusing their customers. Until that changes for some reason, I don't see any need to incur the monetary and other costs of increased government regulation on the Internet.

More thoughts on end-to-end

I was reading this paper (actually, the version at the top of that page) and noticed how my previous comments on the end-to-end principle seem to be justified in a paper touting the need for end-to-end congestion control and TCP friendliness. A major observation here is that with the Internet as large and diverse as it is (and this was written in 1999), we cannot simply trust that everyone on the network will play nice. A quote from the conclusions in the paper:

We have argued in this paper on the need for end-to-end congestion
control, and further, on the need for mechanisms in the
network to detect and restrict unresponsive or high-bandwidth
best-effort flows in times of congestion. Such mechanisms
would provide a incentive in support of end-to-end congestion
control for best-effort traffic.

A major portion of this paper recommends the use of network mechanisms to restrict non-compliant (TCP-unfriendly) traffic on the network, thus encouraging others to play fair. At the same time, it is also mentioned how providers could allow premium rates (amazing how this has all played out) that would follow different rules. My point is simply this: whether or not we intended to, we have already violated the end-to-end principle out of necessity. I'm not sure that's a bad thing, as long as we do it in a straightforward and fair way - yes, there will be added complexity in the network, but so long as we have something akin to a standard API for other layers to interact with, this could be a strength.

End of End-to-End

The original objectives for the Internet included an "end-to-end" principle for simplicity, and perhaps therefore for reliability. I think that keeping a system simple has an incredible amount of value in it, but I think that it is possible to take principles that keep one system simple to an extreme, with the result of an unintentionally complex system. We may have reached this point with our networks.

This paper is an example of using a bit in packet headers that only routers set in order to improve congestion control. Through this and other papers, it seemed pretty clear to me that network performance was improved drastically by the addition of a little reporting logic at the router level. This, however, violates the end-to-end principle. So much effort has been put in to do research on improving the prediction of network congestion that we have more or less ignored the fact that we can just find out how bad it is at any given time.

Improving the network is more costly than changing a protocol on client machines, but I've noticed that it happens anyway. People want faster speeds, bigger pipes -- why not use router congestion control as well? Let's not forget that the end-to-end principle is a means to the end of simpler, more robust networks. If it begins to hamper that end, perhaps we should re-evaluate our devotion to that principle.

Fairness and Adoption

We discussed a point in my networking class that I found interesting -- transport protocols in development are extremely concerned with being fair to TCP. I was thinking about whether fairness is necessary or not, and I came to the conclusion that some degree of fairness certainly is -- a network will lose users quickly if transport protocols are so aggressive that one user takes up most/all of the traffic at any given point. Real-time applications, at the very least, would die, and the network would be perceived as unreliable (unless one user consistently got the whole network; then he'd be pretty happy). On the other hand, if a new protocol is fair with other implementations of itself, but not with TCP, it could encourage migrating to the new protocol (hopefully with some benefits connected thereto!). So what's the appropriate level of fairness?

The problem, as I see it, is most visible on large networks with non-technical people, like the Internet. Users who haven't upgraded their OS of choice for whatever reason may find that their TCP connections are wholly unreliable compared to what they used to be, and complain to the network administrators (or ISPs in this case). Enough complaints, enough lost business, and suddenly the new protocol might find itself prohibited or hobbled in some way on the network so that current customers will be happy. Then again, they might simply force their customers to upgrade the protocol on the client side. My question then becomes, "is it appropriate to force users to do a certain thing that they did not agree to on their own machines?" My gut says no, but short of running side-by-side networks, is there some compromise that would solve this issue? I don't yet know.

Peer selection is interesting.

I'm quite glad that I chose to review a paper on peer selection for our last round of applications papers. Peer selection seems to be an area I can really sink my teeth into – it bears similarity to more general algorithmic optimization problems that I enjoy solving. As I seek out possible master's thesis topics, I find myself a bit drawn to the application layer in networking. Prior work in custom-criterion tree searching may prove helpful here.

PlanetLab status histories

PlanetLab is a cool idea – a bunch of interested parties contribute machines to a planet-wide network, allowing them all to request a slice and perform larger-scale experiments than they would otherwise be able to do. One problem that I've noticed as we have tried to experiment with a slice is that there are really no guarantees of availability – our slice was assigned up to a little over a thousand nodes, and we selected a subset of somewhere around 130 nodes. While testing our experiment scripts, we found that a number of those nodes, while reported available and working, did not respond to our SSH requests. Kind of a pain – we want to hit an exact number for this experiment, so knowing which nodes we can rely on seems pretty critical. I would love to have more information on a history of reliability of nodes on PlanetLab rather than the current “responding” sort of status indicator they show. Maybe they do it already, but I haven't seen it, and if not, it doesn't seem like keeping a history of statuses should be too difficult.