RE: Framing Discussion

["Douglas Otis" <dotis@sanlight.net>]

Julian,

Although the IPS workgroup declares it is using TCP as the transport layer,
there is a strong desire to view this transport as framed rather than as a
byte stream.  Clever schemes to mark the end of a frame or the beginning of
a PDU (some hope at the segment boundary) are still unresolved.  At least
this is openly the case.  I have given up asking how such a scheme of
placing SCSI data into SCSI buffers delivered in out-of-sequence TCP
segments can be done without modifying TCP.  David has clearly declared such
a question out-of-scope.  I will blink and say that there is an application
running iSCSI on an adapter and that the interface for this adapter is akin
to some existing SCSI adapter product.  At least this limits much of the
standard's damage to the adapters.  I still hold only a dim hope with
respect to damage as I have yet to see clarification on the framing scheme.
If you wish to shed additional clarity on this subject, your comments are
always welcome.  Clearly we see this subject from different perspectives but
I would not say I see the truth.

As SCSI is just one of three applications to be supported by this new
framing scheme, then I guess we will see three additional interfaces exposed
at these adapters.  One for network use, one for SCSI, one for VI and yet
another for IPC.  I expect that in the time it will take these products to
mature to the point of not causing disruption with various routing
equipment, SCTP will have supplanted TCP in these applications.  The need
already expressed within this WG are reasons SCTP will be available before
Bill has his version ready.

Doug

> JP,
>
> I think that many people on this list have already discussed the so called
> out of order processing but Doug Otis seems adamant that he is the holder
> of THE truth.
> The reason why framing recovery is deemed necessary is to keep to
> a minimum
> the reassembly memory
> on the NIC cards.  Data can be placed in host memory without being
> delivered (i.e., the ULP made aware that data is there).
>
> Julo
>
> Douglas Otis <dotis@sanlight.net> on 20/12/2000 20:55:56
>
> Please respond to Douglas Otis <dotis@sanlight.net>
>
> To:   JP Raghavendra Rao <Jp.Raghavendra@EBay.Sun.COM>, ips@ece.cmu.edu
> cc:
> Subject:  RE: Framing Discussion
>
>
>
>
> JP,
>
> The VM page flipping will require blocks to be greater than or equal to
> pages in size and that these blocks are aligned at page boundaries.
> Neither
> of these assumptions are true. The goal is clear, the NIC will examine the
> content and then direct data payload to the system through the NIC
> interface.  The desire is to keep the buffers on the NIC small and thus
> allow out of sequence processing of the TCP stream.  This must be
> seen as a
> modification to the normal TCP implementation.  Such operation should
> include a complete description of the API to allow consideration of NIC
> design, inter-operability and security requirements.
>
> Doug
>
>
> > >> The design goal behind the framing discussion
> > >> is avoidance of that copy.  In contrast to the
> > >> typical case for NICs and TCP/IP, read data
> > >> buffers for SCSI data are usually *not*
> > >> interchangeable.
> > >>
> > >Why are they not interchangeable ? This is an
> > >assumption not stated anywhere.  Is there
> > >a list of other assumptions that is documented ?
> > >
> >
> > Typically, the original data buffer is with the application that
> > made the SCSI READ request - and this buffer may not have been
> > allocated with the constraints that should be ready for a simple
> > swapping. Assuming that the constraints are met, it would require
> > VM page flipping, which is considered to be an implementation hack.
> >
> > A protocol level solution to locate the buffer and its offset for
> > the incoming TCP segment is probably a better thing to have.
> >
> > -JP
> >
> >
>
>
>
>
>