A Protocol for Packet Network Intercommunication April 7, 2009

The biggest contribution in this paper appears to be the transmission control program, or TCP. The TCP as described here seems reminiscent of the stub/remote procedure call model presented in [1]. A TCP provides fragmentation and encapsulation of data, which makes it fairly easy to discern the destination of the packet and (to some extent) what to do with it once it gets there.

Second, TCPs provide some reliability mechanisms, in terms of retransmitting unacknowledged packets and checks for duplicate packets within a certain timeframe.

Third, the concept of gateways as an interface between multiple networks: a gateway is essentially a cut vertex on a network graph. The idea is that one can use two completely different protocols — one for each network — but still get the data through. The gateway may reconstitute and refragment packets as it sees fit, and may readdress something so that it goes to the proper place within a network. A possible analogy is currency-changing: it’s worth the same overall, but separated in different quanta and accepted in different places. I would imagine that the concept of network address translation is a derivative of this.

The paper mentions using a window for retransmission of packets to avoid the problem of finite sequence numbers. However, to transmit a very large piece of data, one might run out of sequence numbers, especially if transmitting a large number of small packets.

References

1. A. D. Birrell and B. J. Nelson, “Implementing Remote Procedure Calls”, ACM Transactions on Computer Systems, Vol. 2, No. 1, pp. 39-59, February 1984.

A Protocol for Packet Network Interconnection April 7, 2009

This paper describes a protocol which seems to be the predecessor of the TCP/IP suite used today by the Internet. It makes the argument that packet networks are likely to use different conventions, which makes trying to standardize on one packet format difficult, if not impossible. Therefore, they propose a standardized internetwork header, which can be read and interpreted (at least in some sense) by the gateways between different networks. This internetwork header contains all of the information necessary to determine the destination of the packet as well as information useful for sequencing and fragmentation. On top of this internetwork header, individual networks are free to add a local header or trailer to allow the packet to traverse that particular network on its way to the next gateway or the destination host. Also described in this paper are addressing formats (network/TCP/port), sequence numbers (which address bytes relative to the start of the message stream), and a very powerful retransmission mechanism. The retransmission mechanism uses a “window” over which data can safely be sent, with the notion that it is safe to send data as long as the receiver knows that it is not receiving outdated packets. The only complicating factor is synchronizing the sequence numbers at the beginning of an association, which is handled by providing a special SYN bit to indicate the start of an association.

In my opinion, the biggest problem with this paper is that they provide no flexibility for future network growth. While the fragmentation mechanism is excellent for supporting larger and larger packet sizes as technology advances, the addressing scheme (as we have seen with the push from IPv4 to IPv6) is limited by what they see as the largest conceivable network. Unfortunately, networks have become much larger than the initial network designers could conceive. Perhaps it would have been better to allocate more bits to the address space (just a stopgap unless it is taken to the extreme a la IPv6), or even better, to somehow make it possible to specify how many bits were being used for addressing. As long as only a few bits are necessary, the header can stay small, but as more bits are required, the header can grow slightly to greatly increase the address space.

Future research in this area might include ways to make the protocol more flexible in the face of networks which greatly surpass the properties of networks conceived of in this work. As mentioned with variable-size addresses above, maybe the approach should be to make a standard, but flexible format which allows organic growth, which might ease the pain we are currently feeling in the transition to IPv6, which requires a dual-stack architecture.

A Protocol for Packet Network Intercommunication April 7, 2009

“A Protocol for Packet Network Intercommunication” by Vinton G.Cerf and Robert E. Kahn is a research paper that describes a protocol to support sharing of resources on different packet switching networks. The paper introduces some important concepts that eventually evolve into IP and TCP.

The paper introduces the concept of a gateway. A gateway is the interface between networks. It is important to note that the gateways route the data using a store and forward method. Using the gateway to reformat packets of data so that the network it represents can read it properly makes sense. Another important point brought up by the authors were routing using a universal source and destination address. Since every gateway needs to be able to read these addresses they must be global. It is also possible for the local network to understand the addressing scheme to bypass the gateway for routing. This is an early influence on IP.

The other concepts that the authors introduce make up TCP. They describe how to handle flow control, time-outs and demultiplexing of messages to different hosts. The key ideas here are the sequence numbers for each packet, the acknowledgements of packets when they are received, time-outs and the sliding window for flow control.

The last big concept the authors address is the notion of a connection. Since there is evidence, from ARPANET, that showed that message based connection free protocols can be constructed they approach the idea of connection carefully. They use the term associates instead, and they show that two associates do not need to know that they are connected until they need to transmit data to one another. This is done by trying to send data from associate A to associate B and waiting for the ack.

Some major problems with the paper are: they use 8 bits for the network address, stating that it will be well then enough when we know now that it is not, the time-out retransmission do not work for all cases which can be a problem from “End-to-End Arguments in System Design” and the idea of routing and transmission should be separated as it is today.

This paper has future implications as a guideline for future protocol designs. This is because this paper lays out their design choices, assumptions and justifications very well.