RE: Framing Discussion

[Douglas Otis <dotis@sanlight.net>]

Michael,

> At 04:58 PM 12/20/2000 -0800, Douglas Otis wrote:
>
> >problem of the block size being less than the page size.  Unless the SCSI
> >application is forced to allocate in pages and you have a means
> to force the
> >alignment of these blocks as they are delivered by the network, then this
> >MMU technique is not available.
>
> Many file systems allocate in nice multiple 4KB quantities making much of
> this fairly straight to implement and for partials these are
> either placed
> in a multiple 4KB buffer or these tend to align on power of 2 quantities
> buffers so the performance impacts are mitigated.

Here we have a sticky problem of alignment.  You envision an intelligent
adapter forcing this alignment on an application specific basis.  This
intelligent adapter will recognize content of the TCP stream, remove
prefixed iSCSI headers, and pad-out non-page-sized data transfers.  The
intelligent adapter will use content of this TCP stream to direct iSCSI
headers into different buffers than SCSI data and keep a relationship
between header and data.  One means would be to extract the tag within the
header and use the pre-allocated buffer to place data.  In David Black's
view, this interface would be the same as a SCSI adapter.  In that manner,
the header-data association is automatic.  Your desire is to allow a simple
merge of InfiniBand hardware with IP technology.  Presently InfiniBand does
not automate IP nor SCSI, so you are trying to solving more than an SCSI-TCP
specific problem.

Julian has presented his view of adding a suffix to the IP header as a means
of framing and adding InfiniBand-IP differential information.  Those fearful
of this approach could use standard TCP and suffer additional buffer
requirements or retransmissions upon a segment loss.  Will there be enough
performance loss to justify such a transition and will InfiniBand be
motivation for this transition?  InfiniBand is agnostic about the protocol
and has not breached the area of IP or SCSI with perhaps the exception of
using IPv6 size addresses.  With such short-comings of TCP, why use a
modified TCP to instantiate a new SCSI interface?  Solutions being hardware
based, especially for those within InfiniBand, what benefit is derived using
this modified TCP?  You will be forced to handle two such protocols.  Normal
and the enhanced for wide screen.

In Julian's words:

  "Many of the new applications could benefit from using functions
   available from a new transport (like SCTP) but no vendor is going
   to "bet the business" on an all new and radically different
   transport protocol - unless there is a transition plan that
   allows him to start by using a mature transport protocol and then
   migrate it to a new protocol."

This transition plan is going from TCP to TAF-TCP, where the application
interacts at the datagram level to align retransmit and where additional
headers are added ahead of the transport headers.  To review iSCSI, it is
SCSI on iSCSI on TCP on TAF on IP.  How is it good for either IP or
InfiniBand to add additional application specific layers?  To deploy,
network equipment is impacted by this transition so you are not just
stepping on your own TOEs.  It would appear that even Julian agrees that
SCTP is a solution, but he can not see the transition.  RFC 2960 does
provide the framing for RDMA, VI, SCSI, IPC, gaming, multi-media, audio, and
every feature being sought with this TAF extension.  Which provides the
superior solution and allows the cleanest transition?

See:
http://www.haifa.il.ibm.com/satran/ips/draft-satran-transport-adaptation-fra
mework-00.txt

Doug


> InfiniBand is looking to standardize the interface to
> InfiniBand-based TOE
> (TCP Off-load Engine) endnodes so that  a well-defined wire
> protocol can be
> created for all IHVs to implement above the InfiniBand transport
> protocol.  I think there might be some benefit to do the same thing for
> iSCSI as for TOE in an appropriate forum while allowing this workgroup to
> proceed with the iSCSI definition which defines the operational model and
> wire protocol being used.  In fact, if the iSCSI workgroup sets up some
> basic rules as outlined in another response from me today or along the
> lines of the various RDMA proposals, then the wire protocol
> defined by the
> iSCSI workgroup in essence defines much of this needed interface.
>  Need to
> think about what else if anything might be needed.
>
> Mike
>
>