RE: TCP Framing Proposal

[Douglas Otis <dotis@sanlight.net>]

Costa,

Creating an alignment with the TCP segment and the PDU, even to the point of
dictating how this PDU will be fragmented, does not seem practical in the
event of network errors.  In addition, if there is any extended error
checking as there seems to be a consensus for including, this framing does
not define a means of reissuing an invalidated pseudo-frame in a generic
fashion.  What is the difficulty of including SCTP as a layer within TCP
where a fixed length pseudo-frame is negotiated as an extension to SCTP?
The real frame length can be indicated by replacing the SCTP ports field
with a length much as you have already done in your example.  Using RAM to
allow reconstruction of these pseudo-frames seems like a small price to pay
and can be done without playing games with TCP.  There would be little
benefit from forcing an alignment between TCP and this pseudo-frame which is
larger than the TCP frame in most cases.  The amount of overhead consumed by
this SCTP encapsulation scheme would be virtually identical to this proposal
with the benefits of frame level acknowledgements, selective retries,
multi-homing, session recovery, etc.  With your proposed approach, the TCP
stack must be altered to handle PDU alignments with virtually no benefit
with respect to any error recovery.  As you should expect fragmentation
unless jumbo frames are used for sending FC frames, there will always be
some reconstruction required.  This does not change regardless of the frame
alignment.  SCTP isolates encapsulated PDUs or FC frames with STREAM and
SEQUENCE.  You have yet to make such a definition within your scheme except
to expect such processing is always done sequentially but then again you
have not consider the impact an error will cause.

Doug

> A draft on TCP ULP framing from the ad-hoc WARP RDMA group is now
> available.
> The latest
> version of the draft is at
>
> http://www.stanford.edu/~csapuntz/draft-williams-tcpulpframe-01.txt
>
> A slightly older version is available from the Internet Draft repository
> under the name
> draft-williams-tcpulpframe-00.txt   The algorithm is the same as
> in the -01
> draft but the
> explanatory text and analysis is poorer.
>
> The discussion of this draft will take place on the TSVWG reflector. To
> subscribe
> or browse the archives, go to
>
> http://www1.ietf.org/mailman/listinfo/tsvwg/
>
> Thanks,
> -Costa
>
>
> ----- Original Message -----
> From: "Constantine Sapuntzakis" <csapuntz@cisco.com>
> To: <tsvwg@ietf.org>
> Sent: Monday, March 12, 2001 3:32 PM
> Subject: TCP Framing Proposal
>
>
> > The authors of the TCP ULP framing draft kindly request your
> feedback on a
> > technique for
> > recovering upper-layer protocols headers in TCP segments, even when the
> > segments arrive
> > out-of-order. The upper-layer headers are used to place the data in
> memory;
> > however, the
> > upper-layer still does protocol processing (the control path) in-order.
> >
> > The most current version of the techniques is described in a draft
> available
> > at
> >
> > http://www.stanford.edu/~csapuntz/draft-williams-tcpulpframe-01.txt
> >
> > This draft has been submitted and should appear after the quiet period.
> >
> > A slightly older version is available from the Internet Draft repository
> > under the name
> > draft-williams-tcpulpframe-00.txt   The algorithm is the same as in
> the -01
> > draft but the explanatory
> > text and analysis is poorer.
> >
> > Thanks,
> > Costa
> >
>
>