[e2e] TCP Framing

[Phillip Conrad]

At 05:40 PM 3/23/2001 -0500, David P. Reed wrote:
>Bob - I agree with you that having TCP control the framing underneath it 
>places a significant burden on future evolution of the TCP and IP.  You 
>are right, as well, about the intention of the TCP spec to avoid linking 
>segmentation to the sequence of calls - it was considered and dropped.
>
>And for that matter, I still don't see the need.  If your data should be 
>processable out of order, why not use multiple TCP connections, RTP, or 
>(gasp) UDP?  If the data needs to be processed in order, then framing can 
>be embedded in the data stream.

Without making any comment on the TCP framing question one way or the 
other, I think I can address David's last question ("why not 
use...?")  Let's take each of the proposed alternatives in turn:

>Why not use multiple TCP connections

   Two reasons: (1) fairness (2) slow start/congestion avoidance.

    Fairness: If I use "n" TCP connections for a single flow because I have 
three logical      streams that I want to be processed out-of-order with 
respect to one another, then I am
getting "n" times greater a share of the bandwidth on congested links that 
I should reasonably be entitled to.

    Slow-start/congestion avoidance: if I have "n" TCP connections for my 
packet flow rather than one, there is no communication among them.  If one 
of my "n" TCP connections experiences a packet loss, then I should probably 
back off my sending rate on all three.

My expectation is that having "n" connections all independently doing 
slow-start/congestion avoidance to find an appropriate sending rate, would 
mean that each of the flows would converge to an appropriate sending rate 
more slowly, than if there were a single flow, with the result that the 
overall goodput of the network is reduced.   I may be wrong on this point.. 
. sometimes intuition leads us astray.  If NS-2 work hasn't already been 
done to investigate this point, it probably should be... but I'd be 
surprised if it hasn't already.  (If someone reading this message knows of 
such work, could they point it out?)

>RTP

    RTP, it seems to me, is widely misunderstood.   While RTP *does* 
contain some transport layer functionality (e.g. end-to-end delivery, 
sequence numbers, etc.) RTP is most definitively NOT a transport protocol 
in the sense that TCP, UDP, or SCTP are transport protocols.   Typically, 
RTP must be layered on top of one of those (TCP, UDP, SCTP, or something 
else in that category).   Thus it is a red herring in this discussion.

>or (gasp) UDP?

Apart from the issue of reliability, the main reason: flow 
control/TCP-friendly congestion control.  Applications without flow control 
don't work well, and those without TCP-friendly congestion control are 
"considered harmful".  Building TCP-friendliness *correctly* into an 
application built on top of UDP is a corner that many developers are 
inclined to cut.

In short, applications need a wide variety of qualities of service at the 
transport layer: total order, partial order, unordered service... reliable, 
unreliable, or something in between... but what ALL applications need to be 
good network citizens is flow-control and TCP-friendly congestion control.

To my way of thinking, this is why the time is right for SCTP, which offers 
a choice between reliable/ordered service, reliable/partially ordered 
service, and now has extensions under development for unreliable and 
partially reliable service as well.

More thinking on this topic can be found at: 
http://www.cis.udel.edu/~pconrad/thesis and in some tech reports at 
http://netlab.cis.temple.edu/techrpts.

Phill Conrad
Asst. Professor, CIS Dept., Temple University