[e2e] TCP Framing

[Joe Touch]

Jim Williams wrote:
> 
> ----- Original Message -----
> From: "Bob Braden" <braden at ISI.EDU>
> To: <end2end-interest at postel.org>
> Cc: <braden at ISI.EDU>
> Sent: Friday, March 23, 2001 3:54 PM
> Subject: [e2e] TCP Framing
> 
> >Hi.  At the IETF just completed, I sat through an exposition of
> >the following Internet Draft:
> >
> >   "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.
> 
> I hope you are not attacking the honesty of the authors.  I may well be
> the most intellectually dishonest scoundrel to ever roam the internet,
> but I can assure you that the other authors are fine, honest, upstanding
> people who would not let me get away with anything underhanded. :-)
> 
> More seriously, many alternatives had been considered which defined new
> TCP options or defined currently reserved TCP header bits.  The point
> being that the submitted proposal does not do any of those things,
> which leads to the claim of full compliance with existing RFCs.

My primary concern is that this appears to be a stopgap measure until
SCTP is available.
	
Stopgap modifications to widely-deployed protocols (e.g., TCP), even
optional ones, should be considered only very hesitantly.

As a stopgap, it might be sufficient to create a new "protocol" which
happens to be based on a TCP implementation with the addition of record
boundary enforcement, as a new (and somewhat temporary) protocol.
Backward compatibility can be achieved by having the server sit on BOTH
protocol ports - conventional TCP and this new
enhanced-reliable-record-transport.
	
This allows implementers to leverage the current base of
silicon-friendly TCP implementations with somewhat minor modifications.

-----

The concern with having even an optional modification to the TCP API is
that it can creep into the assumptions of the default API. I prefer the
freedom of the existing decoupling; anything that even implicitly
endorses an optional modification to that API is sliding down the path
to a true modification. Given the ephemeral nature of this proposed
modification, that seems premature.

Joe