[e2e] TCP Framing

[David P. Reed]

At 12:00 PM 3/24/01 -0500, Phillip Conrad wrote:
>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.

Don't think this is actually true.  packet drop rate on the shared link has 
nothing to do with port numbers - even RED discriminates only on IP 
address.  Now ECN might cause one TCP to back off and another to back off 
less, but the stable state would seem to be the same, whether multiple TCP 
connections are used or not.  (some of the less end-to-endian notions of 
router fairness might give 3 TCP cnxns better service, by looking deeper 
into the packets).

>    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.

I would think that if the total traffic between the two ends is divided 
among the "n" connections, that slow start would converge just as 
fast.  But it would be an interesting experiment.
>>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.

Don't agree. RTP on UDP is a transport.  UDP was invented (I was there) as 
sugaring of IP layer in order to allow a wide variety of experimental 
transport protocols, one key particular example being protocols like packet 
voice that didn't want reliable delivery, but instead timely delivery  that 
allowed the application to decide what to do with out-of-order and lost 
packets.  RTP is pretty much for that example.

>>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.

One can create a TCP-friendly congestion-controlled protocol on top of UDP 
quite easily.  You just use the same mechanisms as TCP to control the 
aggregate volume of data, respond to the same signals of congestion 
(unack'ed packets from loss and RED, and ECN if capable).  That's what I meant.

>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.

Maybe.  But the problem with SCTP is that it is a "kitchen-sink" protocol, 
full of options and combinations of options that make it hard to test (for 
performance and so forth) in all its combinations.

I did such a protocol once - it was called DSP, and some of the old-timers 
like Vint, Bob Kahn, and Bob B. may remember that I was arguing for it to 
replace TCP, because it was more "general".
It did all of the things that SCTP seems to want to do, but was much 
simpler.  After much thought and debate, it became obvious that I was 
really ignoring my own "end-to-end argument" because most of the 
functionality was only there as a subroutine library for lazy application 
programmers, and we had no particular way to argue that the application 
needs were optimized by the design.  If so, then it should have been a 
subroutine library, not built into the "standard" - instead we created UDP 
to encourage experimentation in those domains - e.g. RTP, DNS, ...

SCTP may seem to do a lot, and it may be fun to deploy, but I'm 
conservative about throwing features into low level protocols until you can 
prove they are needed (not just wanted by folks who could experiment on top 
of UDP).

This fetish of opposing UDP is based on a falsehood - that somehow UDP 
protocols aren't TCP-friendly, or closed-loop congestion-controlling, by 
definition.  Some may be, but that's because no one has thought it through 
for them.






- David
--------------------------------------------
WWW Page: http://www.reed.com/dpr.html