[e2e] bytes vs. packets

[Cannara]

David, the question of transport byte vs pkt orientation is not necessarily
related to higher layers or applications.  The use of byte counting in
buffered transport transmissions does allow the sender to add more bytes to a
pkt that has to be retransmitted, if the sending application has delivered
them to the transport and if the datagram size (IP pkt) allows.  

Other than that, there's no need to be concerned with byte or pkt oriented
sequencing & retransmission at the application level.  Since any transport can
accept buffers from above and request datagrams of whatever size it wants,
within the Layer 3 limits, reframing data is only a potential efficiency
benefit when something like the above occurs, or when an Ack suggests a
smaller retransmission can occur.  These events are extremely rare, even when
TCP pkts are being lost.  So, I don't see the argument about "the client app
making really bad decisions".

What does occur, in every TCP pkt (data or ack) is expending pkt space and
network loading on 3 byte counts -- Seq, Ack & Window.  The fact that years of
successful application support by pkt-counting protocols had gone on since the
early '80s indicates that an argument based on pkt counting being harder for
apps is weak.

Alex

Otherwise, 

"David P. Reed" wrote:
> 
> 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.