[e2e] TCP Framing

[Jeff Chase]

Bob Braden wrote:
....
> 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.

Bob, your point is indeed subtle.  One could also argue that this
snippet of RFC 793 *supports* the "TCP framing" proposal, which does
nothing more than to affirm the right of mutually consenting TCPs to
block data at their own convenience when speaking amongst themselves (as
negotiated by a ULP).

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

Any TCP implementation that supports this proposal is fully
interoperable with any TCP that does not.  The wire format does not
change, ever, even when the feature is enabled.  Thus it is
interoperable with any other compliant TCP; indeed the RFC snippet you
quoted above ensures this.  So how does it compromise generality?

You almost seem to be suggesting that a TCP implementor should never add
a new locally-selectable policy feature, because any ULP that benefits
from it won't benefit any more if you later take the feature away.  In
this case, the argument is specious because the intended beneficiary (a
layered RDMA protocol called WARP that is still under development) can
run happily over a TCP that does not support this feature; it just won't
be capable of the same degree of hardware acceleration, in the case of
an unreliable network. 

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

No, the ULP proposal does not reduce TCP's freedom of choice, it only
assumes that the TCP sender implementation notifies the ULP of its
choice, e.g., by upcalling to the ULP buffers to fill each segment, as
in many current implementations.  No ULP will rely on this behavior, but
if the sender TCP provides it, then the RDMA ULP can benefit from
hardware acceleration.  In most cases (e.g., BSD) this is a superficial
change to the TCP *implementation* itself, although I will allow that it
may be a fundamental change to the way some might think about the
implementation.  

In any case, the proposal does not affect the TCP wire protocol, it does
not affect interoperability, and it does not affect the congestion
behavior.  That is all that its proponents have claimed.  We are honest
people, and we are sincerely trying to do this in a way that is
responsive to the legitimate but sometimes rather shrill concerns about
"changing TCP" among those most experienced with TCP and its history.

One worthwhile question to ask is: can an intermediary observing the
flow at the TCP level determine for certain if this proposed feature is
in use or not?

Jeff