RE: iSCSI: RE: Framing Discussion

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

Y.P.

So you agree that each application requiring content directed services will
necessitate an additional vendor unique hardware interface.  The T10 group
does have the required parameters to support SCSI, and  Microsoft, Compaq,
and Intel have parameters to support VI and most OS implementations already
support network devices at the transport level or below.  With Microsoft
wishing the addition of IPC, there is now at least 4 vendor unique hardware
interfaces expected of this network connection if such level of service is
required.  Do you see an advantage discussing all these interfaces together
than each separately?  If we can find a non-application specific means of
providing these services, then the world is spared these hardware variants.
I would expect a great deal of complexity in attempting to nail down all the
details required to interface so many clever independent hardware solutions.

With one interface requiring the application to reconstruct the datagrams
for sending a retry, and with the standard method handling such details
below the application, there will be a significant change required to
support both modes of operation.  iSCSI is already a transport layer in
itself by allowing a separate retry mechanism from that of either SCSI or
TCP.  iSCSI combines multiple connections and implements its own flow
control and error detection.  Combine that with a layer between IP and TCP
to inject the concept of iSCSI PDUs as an element contained and aligned with
TCP.  From this alignment or framing, out of sequence network segments can
have the data extracted from application specific encapsulation and placed
within third-hand buffers.  This allows a simple ASIC which uses embedded
memory rather than external memory.  Perhaps more importantly, the number of
drivers to support this plethora becomes another concern if to see
standardization.

Doug

> > With respect to networks, there is more than just SCSI.  Yes, we
> > can create a network interface that solves immediate needs of
> > SCSI, but at the potential expense of adding a unique solution
> > per each application demanding content directed services.
> > IPS advocates are not allowed to discuss impact of this
> > interface such as if this connection is shared with IPs or ports or
> > how an application is indicated.  Once vendor specific details
> of SCSI are
> > solved, this same connection may also then be called upon to create
> another
> > unique interface for VI or IPC.  Are application/vendor unique solutions
> > beneficial if there is only a resemblance to the original protocol where
> > different schemes employed?  As these application standards
> > change, be sure to include Flash memory for your embedded processor.
> > Is this how WinModem was created where application and hardware
> > interface is blurred by vendor unique solutions?
> >
> > Doug
>
> Doug,
>
> What I said that "You can send anything you want, as long as rules are
> followed" doesn't meant it is an incompatible solution requiring special
> API.  An iSCSI adapter is both a NIC and a SCSI adapter.  As a NIC, it is
> capable of RDMA to support VI and Winsock Direct.  As an iSCSI adapter it
> adhere strictly to SCSI API and the IPS specifications syntactically and
> semantically.  It has device drivers for different OS's providing SCSI
> services with the exception of making TCP connections for logins.
>  However,
> having said all these, each iSCSI adapter still has a unique
> implementation
> including the ways it sends and resends TCP frames and supports
> multiple TCP
> connections concurrently.  Being stream-oriented, TCP does give
> us a lot of
> freedom how to segment the byte stream and how to send ACKs.
>
> There are a lot of issues with traditional TCP implementations to support
> networks with long latency delays and high probability of dropping frames.
> But, if someone puts a new implementation inside an adapter, he has the
> freedom to add new options like TCPRDMA and MSGBNDRY, even the
> SMTP protocol
> to overcome the problems.  Not all implementations are created equal.  Not
> everyone supports new options.  The magic word is interoperability.  The
> secret is how two adapters both supporting new options talk to each other.
> I thought the TCP option negotiation permits that already.  What I expect
> from the IPS effort is to tell me how these new options should look like.
>
> Yes, almost all adapters today have a flashable ROM that supports field
> upgrades with new implementations for new TCP options approved by IPS WG.
>
> Y.P.
>
>