Re: iSCSI: Iterating long text responses

[Stephen Bailey <steph@cs.uchicago.edu>]

>   Please indicate which solution (#4 or #5) appeals to you.

Well, this makes a hearty assumption....

I believe 4 completely misses the point.  The initiator will still
have no control over the resource requirements to swallow the target's
responses.  This is bad both for the initiator and the target since it
can flow-control the connection.  For iSCSI to work well, you must
make sure that the connection is kept `lively' (connection-level flow
control is not engaged).

Solution #5 is better, but you still have an irritating problem
dealing with what happens when the response length is larger than your
reserved resources.

I believe in #2.  If we specify that each text PDU results in at most
one response PDU, that gives you effective control over the resources
required for text messages.  Then, on a case-by-case basis, you build
a protocol for addressing this limitation within its confines.  In the
case if SendTargets, we use an iterator.

In the case of each X-* operation, the protocol is chosen to meet the
needs of the operation.  The reason why you don't want to solve this
problem `in general' (which we haven't actually done with any of these
solutions anyway) for everybody is because `everybody' has different
needs.  Some actions of X-* are NOT going to be idempotent, and the
vendor (or whomever) may want to build an exactly-once protocol which
works across connections, and on recovered sessions.  Other cases,
might want at-most-once semantics, and yet other cases, unreliable,
best-effort.

It's too painful (and pointless) for us to build an exactly-once
protocol for text messages when the only specified application is
SendTargets, which doesn't need exactly-once semantics.

What you're trying to provide is the equivalent of general IP
fragmentation.  For application purposes (as opposed to network
purposes), IP fragmentation just gets in the way.  Provide a basic
datagram capability the upper layer can build everything else as
necessary.

If the application heavy data transfer services, it should use SCSI
directly.  This is already a tradition within SCSI architecture.

Steph