[e2e] TCP Framing

[Mike Fisk]

An abstract TCP byte stream is very similar to the byte or bit stream
provided by serial links.  It would be useful to know why one wouldn't use
normal byte stuffing to denote frame boundaries within ULP data.  

I assume the argument is that it is inefficient to scan and twiddle bytes
and that some out-of-band (ala packet segmentation) framing looks cheaper.  
But the draft presents this problem in the context of special-purpose NICs
which could presumably handle byte stuffing pretty cheaply.

With regard to your "subtle problems", the one that first comes to my mind
is a new dependence on the end-to-end characteristics of TCP packets.  
With all of the middleboxes munging TCP packets, this seems dangerous.  
Even if the draft is correct in assuming that the ULP payload won't
contain something that looks like a valid ULP header, any performance 
gains from using this protocol are lost in these situations.

Second, from an upper-layer point of view, I don't know that I want to
have to limit my PDUs to the current path MSS or force the protocol to
degrade when the MSS falls below 512.  It doesn't seem far fetched to me
that some future (wireless?) network will only permit very small MTUs.

What if I have an application that thinks in fixed-size blocks of, say 1k.  
Depending on the MSS, this can result in a lot of small packets if one is
trying to preserve message boundaries.  For good reasons, people have gone
to a lot of effort to remove small packets from TCP streams.

Again, it would be helpful if there was a good argument against
byte-stuffing.

On Fri, 23 Mar 2001, Bob Braden wrote:

>   	"Title		: ULP Framing for TCP
> 	Author(s)	: J. Williams et al.
> 	Filename	: draft-williams-tcpulpframe-01.txt
> 	Pages		: 12
> 	Date		: 22-Mar-01
> 	
>     This document proposes a framing protocol for TCP which is designed
>     to be fully compliant with applicable TCP RFC's and fully
>     interoperable with existing TCP implementations. The framing
>     mechanism is designed to work as a 'shim' between TCP and higher-
>     level protocols, preserving the reliable, in-order delivery of TCP
>     while adding the preservation of higher-level protocol record
>     boundaries if the record is less than or equal to the path MTU. The
>     shim is designed to enable hardware acceleration of data movement
>     operations (e.g. direct placement of receive TCP segments into
>     higher-level protocol buffers) for the protocols that use it, even
>     if TCP segments are delivered out-of-order."

> I would like to suggest two things about this, one simple and one
> subtle.  The simple one is this: to say that the ULP framing is fully
> compliant with the applicable TCP RFCs is simply false.  For some of
> us, at least, such a lack of truth in technical advertising is a red
> flag.
> 
> The reason why it is false, and its consequences, form the subtle bit.
> It is true that the proposed shim does not change the definition of the
> TCP protocol on the wire.  However, it does change a more fundamental
> principle of TCP, which is the deliberate decoupling of what happens on
> the wire from what the user sends.  (See the following sentences from
> RFC 793, for example:

-- 
Mike Fisk, RADIANT Team, Network Engineering Group, Los Alamos National Lab
See http://home.lanl.gov/mfisk/ for contact information