Back to index
A Protocol for Packet Network Intercommunication
Vint Cerf and Bob Kahn
One-line summary: Description, assumptions,
and justification for proposed design features of IP and TCP, given the
philosophy that the internetting protocol's goal should be to make
connection of heterogeneous networks as easy as possible.
The following IP "core
concepts" are introduced in prototype form: (I use "IP" and "TCP" in
this summary, but the names hadn't been fixed when this paper was written)
Philosophy for an internetting protocol: make it as painless as possible to
connect heterogeneous networks.
- gateway and gateway routing based on source and dest addresses
- TCP port demultiplexing
- fragmentation and heterogeneous MTU's
- end-to-end reliability
- window based end-to-end flow control
- end-to-end message reordering based on sequence numbers
- building "logical" connections using connectionless network by
exchanging initial parameters and maintaining state at each end
TCP design philosophy: provide a process-to-process (not just
host-to-host) communication facility on top of IP.
- gateways should insulate networks from link-level addressing
differences, MTU differences, performance differences
- end-to-end reliability needed for hassle-free
internetting, to hide varying reliability in different nw's
- routing: next hop gateway should be "derivable from" source
and/or dest addresses; in the section on TCP, they describe the
predecessor to the masking scheme currently used
- allow for nw's with different MTU's rather than
enforcing a global minimum MTU, because:
- want to isolate internal packet size parameters across
- encryption, associative addressing, etc might cause a
"legal" packet to grow unpredictably larger than MTU
- difficult to increase "global minimum" MTU (inertia,
installed software base, etc.) to exploit new
- Reassembly should not be done at gateways:
serious buffering and state problems, plus
requires all fragments of a packet to pass through same gateway
(reduces flexibility in routing)
- Goal: demultiplexing of messages to different applications
on a host. Proposal: use 16-bit port number per "stream".
- Interesting application: authors mention that if communicating
parties agree in advance on a "port hopping sequence", could use
for privacy by obscuring which messages belong to which stream.
- Streams to different ports shoudl not be multiplexed into
a single TCP-level
message, since this introduces artificial inter-process
dependencies at receiving host (packet parsing, retransmission,
- Routing: original proposal was that a "network address" be an
8-bit network number plus 16-bit TCP port number. Gateways
demultiplex TCP port numbers to applications, but authors allow
for possibility that machines in local network understand the
internetwork addressing scheme.
- Message reordering: use sequence number unique to pair of
- Retransmission after timeout: "It is our expectation that
... [it] will not be called upon very often in practice";
authors felt that IP would mostly be reliable except under severe
- Important. Careful discussion of what a "connection"
really is, in light of evidence (ARPAnet) that connectionless
protocols can be constructed; derivation of the current TCP
meaning of "connection" as shared state using a connectionless
network as medium. IMHO, a major leap of insight.
The assumptions and justifications for each design choice mentioned are
pretty well spelled out. It should be possible to use this as a
"checklist" for design choices in IPv6.
- IP and TCP not as well separated as they became after the OSI
7-layer model was "imposed" on TCP/IP, though the paper does take
care to keep routing and "connections" logically separate.
ideas and concepts are presented, other times implementation
suggestions or data layout.
- It's mentioned that packet accounting will be needed since data
will be traversing networks of different ownership, but this
point is never returned to in detail. Current evidence seems to
suggest it has been de-emphasized :)
Back to index