From: Jenny Liu (jen@cs.washington.edu)
Date: Wed Oct 06 2004 - 08:00:19 PDT
The Cerf and Kahn paper proposed a protocol for multiplexed packet network intercommunication wherein gateways sit between individual networks. The following design decisions are made: there should be a uniform host and process addressing scheme which can be understood by all individual networks; packets should be broken up into smaller packets as necessary during transit; a single packet should contain data only for one process; a window receiving strategy should be used on the packet receiving end; a unique TCB should be created by the sender for each message; the way in which processes set up associations to communicate with each other is defined.
The paper gives clear reasons for making the following design decisions. A uniform host (TCP) and process (port) addressing scheme which can be understood by all individual networks is necessary so that it is not necessary to translate between networks at each gateway. Packet sizes should not be limited to the smallest size that any network can handle to to avoid lack of modularity from one network to another, difficulty in increasing maximum packet size in the face of new technology, and inability to expand packets during transit. A single packet should only contain data for one process since while it almost never helps to combine data for multiple processes into 1 packet, doing so can create process-process interference and be confusing.
However, the proposed protocol seems to be untested at the time of publication. It also skims over many details which may be non-trivial. For example, the paper never explains how the TCP addressing scheme works. How do gateways/ TCPs know where other TCPs are located or where to transmit messages to reach them? Further, some design decisions are simply adopted without much explanation or exploration. Why is the window receiving strategy the best way to go? What are other options?
The paper could be improved by providing explanations of all design decisions and details and by providing test results of an actual implementation of the protocol.
The paper is relevant today since the protocol seems to be the one in use on the Internet. However, it might be helpful to examine design decisions or other options. Are there factors important now that weren't important then (ie scale, security)? It might be helfpul to explore alternative schemes.
This archive was generated by hypermail 2.1.6 : Wed Oct 06 2004 - 08:00:19 PDT