----------
X-Sun-Data-Type: text
X-Sun-Data-Description: text
X-Sun-Data-Name: text
X-Sun-Charset: us-ascii
X-Sun-Content-Lines: 84


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.

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.

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.

The ULP protocol is a classic example of this issue.  The TCP spec
deliberately decoupled the packaging of data across the API (the ADPU,
if you will) from the segmentation that TCP does on the wire.  This was
not an accident; it was designed to allow TCPs to be able to adapt to
new and different environments, without requiring that applications
change.  The ULP proposal changes this to tight coupling, since it only
works if the send call units are mapped directly into segments.  So
adopting ULP MAY (and note that one cannot ever be sure that it
will/won't) reduce the freedom of TCP to adapt to future changes.
And contrary to what the ULP proponents claim, it is a very fundamental
change in TCP.  We should think VERY carefully before making such
a change, and we should be honest about what we are doing.

Moral: Over-engineering may be bad for the Internet, eventually.

Finally, an historical irony: the ULP hack is acknowledged to be a
stopgap until SCTP has advanced to save us.  Essentially, SCTP is OSI
TP4 with features.  TCP's idea of decoupling API from wire protocol
units was, at the time of its development a new idea that was at
variance with the evolving OSI suite.  Now, things seem to be
running full circle.  Are we really sure we want to do this?

I will be interested to hear other opinions.

Bob Braden
----------
X-Sun-Data-Type: Multipart
X-Sun-Content-Length: 502
X-Sun-Content-Lines: 22
X-Sun-Charset: us-ascii

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20010322122329.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-williams-tcpulpframe-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-williams-tcpulpframe-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20010322122329.I-D@ietf.org>

--OtherAccess--