[e2e] bytes vs. packets

[David P. Reed]

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.

Exactly so.

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.