RE: TCP Framing Proposal

[Douglas Otis <dotis@sanlight.net>]

Costa,

I understand a decision to drop a connection should there be a problem but
then you can not assure a sequence within any activity unless there is an
additional transport layer above TCP. SCTP could provide this additional
layer to assist in maintaining sequences and without re-establishing a
connection and all that it entails.  Dropping is not required as SCTP would
sit within a pseudo-frame.  Normally SCTP sits within an Ethernet frame, and
from this, it naturally establishes alignment.  With TCP that is not
practical or possible depending on the number of standards you wish to bend.


| Ethernet Frame |   |         |      |          |        |
    |  Pseudo-Frame  |   Pseudo-Frame    |  Pseudo-Frame  |
    |xxxxxxxxxxx00000|xxxxxxxxxxxxxxxxxx0|xxxxxxxxxxxxxxxx|
    [PDU| PDU  |-----[ PDU | PDU         [          | PDU [...

[ = SCTP header
0 = Padding
x = payload
| = boundary

The Ethernet frame represents the physical frame and SCTP sits within a
fixed interval pseudo-frame which includes a length component (SCTP port
field replaced with length).  Within the SCTP Data Chunk sits the PDU which
can be fragmented as are the Pseudo-Frames.  Should there be an error, the
Pseudo-Frame becomes a defined unit for providing both acknowledgement and
retry as their fixed interval allows resynchronization in the event of an
error.  By placing SCTP as the layer above TCP, you enjoy features offered
by SCTP such as multi-homing nor are you required to drop a connection
should TCP acknowledge bad data. TCP will feed a process that merges the TCP
payloads and parses SCTP at these merged payloads at regular intervals.
SCTP parser then builds the PDU components limited to intervals of 4GB.  The
transport layers never need to deal with units larger than the Pseudo-Frame.
You have defined a low level template devoid of any details of this
additional transport layer.  SCTP seems as good as any for this purpose.  Of
course, there would be a desire to use SCTP directly.

Doug