Tuesday, September 1, 2009

The Design Philosophy of the DARPA Internet Protocols

I found this a very interesting paper, primarily because it focused on a ranked list of the design goals for the IP protocol. Remembering the motivating factors in a design is an important part of evaluting the success of the design, and in deciding whether a new design is warranted or not.

The paper lays out the design goals of the IP, whose primary purpose was to unite the existing networks at the time. There could have been a whole new network designed, but it was felt that leveraging the existing networks was a better choice. Thus packet switching was selected as the best architecture. The paper also emphasizes that survival in the face of failure as the primary goal, and from there justifies the fate-sharing decision that was made in which all connection state is kept at the end points for a particular connection. Thus if an endpoint dies, the connection state is lost.

Secondly, the paper addresses the various protocols built on top of IP. TCP was originally thought to be The One protocol, but with voice as a motivating example we see that it isn't possible to provide all desired types of service within TCP. This lead to the birth of UDP, and really history seems to have proved that between TCP and UDP most applications are covered.

Given the more philosophical and 'history of the Internet' slant of this paper I'm not sure what would count as related work or background material. I suppose an understanding of how IP actually works would be useful as this isn't really covered in the paper. Work on circuit switching would be useful for understanding why packet switching was a better choice given the goals set out.

I thoroughly enjoyed this paper and felt it gave an excellent look at why IP is the way it is. The fate sharing model makes a lot of sense, especially given the fact that if an endpoint dies the connection is probably useless anyway.

I do think some of the assumptions made at the time IP was designed could be questioned, given the recent rise in distributed system, esspecially those running in totally controlled environments. What I mean is, in a distributed system we have a number of nodes, often times nodes that are replicas of each other (i.e. provide the same functionality). It would be useful to be able to inform the transport layer (just in the controlled network) of replicas and have the layer route requests to any available node that could service the request. As it is, this needs to be done at a higher layer which adds a great deal of complexity to any distributed system.

Overall a good paper, and one I would keep on the reading list.

No comments:

Post a Comment