RE: iSCSI: Out of order commands

[Paul Koning <ni1d@arrl.net>]

Excerpt of message (sent 9 November 2001) by Julian Satran:
> Paul,
>
> I should have seen this comming.
> iSCSI assumes that TCP is there to take care of the transport window and
> the transport window is as
> large as it should be. However we are talking about the application
> window.  The application has advertize it's own window in addition to the
> transport windows. With transport having things in order we can avoid
> having to have a complete or even partial duplicate of the windows.  If we
> allow transport to deliver not in order we have to have them duplicated
> (or at least the control part - and whatever DMA schemes we put in place
> won't help).

I'm having trouble parsing some of this, but let me make some
comments.

The iSCSI spec says:

    The queuing capacity of the receiving iSCSI layer is MaxCmdSN -
    ExpCmdSN + 1.

That's quite unambiguous.  It means that you set the application
window to indicate what resources you have, NOT to something smaller
in the hope that the wire delays will save you from being caught at
cheating.

Each layer that has a window must use that window to control the
consumption of resources.  It must advertise the ability to accept
incoming stuff, i.e., resources are available at that layer to handle
incoming traffic.  So TCP advertises a window based on its resources,
and iSCSI (separately) advertises its own window based on iSCSI
resources needed to do iSCSI processing.  Yes, it can rely on in-order
delivery from TCP, because that's the promise TCP makes to the
application layer.  But overcommitting because you hope there will be
packets in flight is an entirely different matter.  The TCP/IP stack
makes no such guarantee, and assuming there is one is broken design.

      paul