RE: iSCSI: RE: Framing Discussion

[Douglas Otis <dotis@sanlight.net>]

Y.P.,

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

> > Yeesh!! Thank goodness all I have to do is drop-in an embedded processor
> > into our chip. I'll let the firmware folks deal with this problem.
> > Certainly, this path does not have to be high-performance since
> > we are going into congestion control anyway, but we have to
> deal with it.
> > We can keep a
> > context stack for the current open TCP sessions which contain
> mappings of
> > TCP sequence numbers to specific CDB context locations (either
> command or
> > offset within the gather list). We can keep this stack as deep as the
> > maximum number of outstanding (i.e. not ack'd) TCP segments which for
> > Randy's example (1.25Gbs and RTT of 100ms) is not too bad (about 8K
> > entries). We can recover the contexts needed to re-build this
> missing TCP
> > segment and re-construct entire PDU(s) so that any necessary
> > digests can be re-calculated. We can then stage this data in memory
> > somewhere and pull-out the exact TCP block that we need to re-send.
> > Lovely.
>
> You forget the most important fact of an iSCSI adapter.  The
> microcode does
> the transmit knows exactly how it creates a TCP segment.  First, it would
> not mix multiple PDU's into a single segment.  Second, there is
> no TCP stack
> in the iSCSI adapter.   While a command or status PDU is created
> on the fly,
> all data PDUs are retransmitted from the application buffers which are not
> freed until an exchange is complete.  Third, there is a separate
> TCP stream
> to each connection.  The task of retransmit is to find the exchange number
> by using the end-point and segment sequence number. The microcode keeps
> track the starting sequence numbers for multiple open exchanges.  However,
> one can take an easy way out by having only one open exchange per
> endpoint.
> Of course, this slows things down.  But, don't be too surprised that some
> implementation might just do that.   As I said before, to keep track of a
> few thousand exchanges, there is a lot of memory needed.  However, the
> algorithm to go through the exchange context to retransmit a
> missing segment
> is straight forward and does not take a rocket scientist!  (Or
> should I say
> an iSCSI scientist?)
>
> In summary, transmit is easy because you got to call the shots as long as
> rules are followed.  Can't say the same for receive when old TCP
> implementations must be honored.
>
>