[e2e] TCP Framing

[Douglas Otis]

Bob,

You are in effect changing the wire specifications of TCP by insisting on
the payload being bound to the TCP frame.  This is a change to the wire
specifications in that a middle box is likely to re-position these bytes
into a non-compatible form forcing a software intervention likely to break
your intended application.  TCP framing is NOT an interim fix if indeed it
is intended to be placed into hardware to perform content directed placement
of data.  As such hardware will not be able to cope with non-aligned data,
you are placing a new requirement on the wire format; that being byte
placement with respect to TCP frames.

At the same time you attempt to implement a major modification to the TCP
API while viewing this modification as unrelated to the TCP standard, there
is already an API/Wire Format that provides the exact features that you
desire that is documented and agreed upon. It is called RFC 2960 or SCTP.
This RFC does the same function as this modified version of TCP is hoped to
do.  The real desire is not for an interim version pending deployment of
SCTP, as anyone knows, protocols built into hardware tend to live much
longer than a short period of time as you allude.  In reality, you are not
happy with SCTP and do not want to use it as it is likely adding features
you do not want to deal with.

What are those features of SCTP that make it hard to deal with I wonder?  Is
it the stream ID that allows multiple independent flows?  A feature surely
to be a boon to hardware implementations as this then requires only a single
flow control for many independent streams.  Is it the multi-homing feature?
Also a boon to those wishing hardware to provide highly reliable
connections.  Is it the ability to prevent spoofing, or DoS attacks?
Perhaps it is the ability of SCTP to identify payloads unlike TCP.  Sorry,
but any framed version of TCP you create will look like a hack compared to
SCTP with its highly desired features.  Please, do not tell me SCTP is too
hard to implement in hardware and only a mangled version of TCP is something
you are willing to attempt.  SCTP will be in place years before your mangled
version of TCP is even seriously considered.

Instead, this is a prelude to something similar to Modem standard wars where
manufactures either could not wait or could not agree to standards.  I think
before you reject SCTP out of hand, you should make some effort to explain
why a record based protocol does not suit your needs and yet only a modified
byte stream protocol does.  Should I desire to attack your adapter, all I
would need to do is to provide you with non-aligned data, something that
anyone will agree is a valid TCP data stream.  Think twice before using PPP
or IP-SEC with your framing equipment.  This framing is likely to be the
worst thing ever afflicted upon TCP as it corrupts wire specifications and
APIs.

Doug

> -----Original Message-----
> From: end2end-interest-admin at postel.org
> [mailto:end2end-interest-admin at postel.org]On Behalf Of Bob Braden
> Sent: Friday, March 23, 2001 12:54 PM
> To: end2end-interest at postel.org
> Cc: braden at ISI.EDU
> Subject: [e2e] TCP Framing
>
>
>