[e2e] TCP Framing

[Vernon Schryver]

> From: Bob Braden <braden at ISI.EDU>

>         Filename        : draft-williams-tcpulpframe-01.txt

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

As long as such proposals don't consume finite, non-renewable resources
such as protocol or IP option numbers, who cares?  They won't be
implemented by a significant number of hosts.  No one will ask for them,
instead of the usual TCP byte stream framing code (surely in some C++ or
Java class by now).  It will all be forgotten a lot sooner than TP4.
If we're wrong about all of that and it becomes wildly popular,
then no harm is done.

The fact that the proposal does change TCP could be handled.  The easiest
way is to observe that like the recently suggest IP option acceleration,
the idea is ok but the implementation (protocol) is wrong.  It is easy
to change the TCP API without changing the on-wire behavior to get
and put data directly to and from application buffers when things are
going well (e.g. no retransmissions), and fall back to a slow path in
what must be the other, rare cases.  If you're doing enough retransmitting
to notice, you're not going fast enough to care about such things.

In other words, contrary to various claims, no black magic was required
to "page flip" on both input and output more than 10 years ago.


Vernon Schryver    vjs at rhyolite.com