From: Seth Cooper (scooper@cs.washington.edu)
Date: Wed Oct 06 2004 - 00:26:25 PDT
The main result of this paper is a description of a protocol that can
be used to reliably communiacte between two processes across networks.
The protocol can be used across packet-switched networks to provide full
duplex communication between two such processes, and can communicate
across networks joined together by "gateways".
A major strength of the paper is that it does an excellent job of
separating the protocol that two hosts can use to communicate from the
underlying network that the hosts are communicating over. The protocol
puts almost all of the burden of implementation on end hosts. There is
also some responsibility placed in "gateways" between networks, because
they must translate packets form one network to the next. But the
protocol designed makes very few assumptions of the transporting
network, and in some cases explicitly tries to be flexible in areas such
a maximum packet size. Building things in to the protocol, such as the
end segment flag and byte ackowledgement, let the packet size vary and
allow the protocol to work across many different network
implementations. How end hosts have to act is even left unspeified in
some cases. For instance, hosts may vary in adjusting their window
size, or how they handle out of order packets. This gives the protocol
even more fleability.
One limitation of the paper is that it doesn't address how the protocol
could detect or adapt to network congestion. The protocol uses an
acknowledgement and retransmit scheme to ensure that the recieving host
gets all the data it wants in order. However, on a high traffic,
packets may be lost due to congestion, causing the sending host to have
to retransmit. This would then increase congestion and make the problem
worse. The paper often mentions that packets recieved out of order can
simply be dropped and retransmitted, withou noting any concern for the
strain that would place on the network itself.
The work could be improved by some concrete observations. The paper
mentions that altough there is uses retransmition, hopefully it will not
need to be used often. It is also not specified how long a host should
wait before assuming a packet is lost and retransmitting. Data on how
often packets are lost or duplicated would be useful. Some way for the
protocol to adapt to the underlying network along these lines would be
good: retransmit times should be higher in a network with large latency
and so forth.
This paper is still relevant today because many of the design ideas are
still embodied in current TCP. For instance, the addressing scheme of
using port numbers to identify an assosciation between two processes is
still used. It is also usefl to know why certain design decisions were
made in regards to one transport protocol when designing another. Even
for an applications programmer, knowing what your underlying transport
protocol handles and why can be useful.
This archive was generated by hypermail 2.1.6 : Wed Oct 06 2004 - 00:27:33 PDT