[e2e] TCP Framing

[Jim Williams]

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


>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:
>
>    The TCP is able to transfer a continuous stream of octets in each
>    direction between its users by packaging some number of octets into
>    segments for transmission through the internet system.  In general,
>    the TCPs decide when to block and forward data at their own
>    convenience.

These sentences don't seem to support your point.  Stating what
TCPs are able to do, or what they generally do, hardly indicates
what they MUST do.  It seems inconsistant to state on one hand
that APIs are outside the scope of the TCP specification, and
on the other hand claim that a particular implementation is
non-compliant because the API doesn't map to the wire in a
way that suits your liking.

The core of your objections may be that the framing proposal
uses TCP in a way different from what was originally intended.
I would agree with this.  My view is that the point of standards
compliance is interoperability, not "original intent".  If two
consenting endpoints want to violate "original intent", that
should be fine as long they follow all the rules.

>The last sentence may be phrased in a slightly academic manner;
>the reader is assumed to understand the the "convenience" of the
>transport layer is to provide optimal performance.  In an earlier
>paragraph the spec says:
>
>    TCP is designed to work in a very general environment of
>    interconnected networks.
>
>Now for the subtle bit.  Generality and optimization are typically
>contradictory.  The Internet protocol suite was designed deliberately
>and carefully for generality, at the possible expense of optimization.
>It was also designed for simplicity at the expense of optimization.
>We recognized that later engineering efforts would rob some of the
>simplicity in order to reach greater optimization, and indeed,
>this has happened and is probably not a bad thing.  On the other
>hand, we should be very wary of over-engineering optimal solutions
>that cut down the generality.

These types of arguments tend to be more philosophical 
than technical, and probably the best that can be done
is to clearly state the differences in point of view without 
presuming to resolve it one way or the other.

There are certain things that should be decided
by standards organizations and certain things that should be
decided by the market place.  My view is that the best standards
are those that allow the optimization versus generality tradeoffs
to be resolved by the market place while still insuring full
interoperability of the various competing design points.