[e2e] bytes vs. packets
David P. Reed
dpreed at reed.com
Sat Aug 9 09:03:03 PDT 2003
At 07:46 AM 8/9/2003 -0700, Dave Crocker wrote:
>As I recall, the compelling argument for byte-counting, in TCP, was that
>TCP was permitted to re-frame the data, as it saw fit. So there was no
>guarantee that the datagram boundaries would be preserved.
And in any case, the sender and the receiver may or may not agree on what
are appropriate boundaries in the stream. Even for the "disk to disk"
copy argument often made, it is the case that many operating systems and
file systems choose different disk block sizes.
So creating record markers often appears useful until you look at the real
issue of the application protocol design, and then the application protocol
has to spend lots of time focusing on how to rationalize record sizes, and
how records should be annotated (at the beginning, at the end, or in a
parallel stream) with other app data.
The other design issue is that datagram size implicitly gets involved in
issues of latency and failure. For TCP, the goal of reliable stream
delivery in order without latency guarantees suggested that showing the
datagram characteristics through to the client app would lead to the app
making really bad decisions in many cases.
In the early days, the community I was part of suggested that UDP be the
base of a collection of protocols that needed to emphasize attributes not
well matched to TCP. Unfortunately, this community (which included the
PARC PUP community, the packet voice community, and the RPC community) was
not well organized, and there were few protocols based on UDP. There were
lots of people who thought that UDP was the tool of Satan, rather than a
simple way to expose datagram-level functionality so that interesting
protocols could be built.
Fortunately, RTP, multicast, and DNS demonstrated useful apps of this
sort. And research has continued.
More information about the end2end-interest