Re: iSCSI: Iterating long text responses

[Mark Bakke <mbakke@cisco.com>]

Steph-

Comments are below.

--
Mark

Stephen Bailey wrote:
> 
> >   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).

Absolutely true.

> 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.

Also true, but at least the initiator is in control of the amount
of data it receives; the target must not send more than was requested,
and simply indicates the amount of data the would have been available
had the initiator been able to receive it.

> 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.

Your arguments for #2 do make sense.

However, The reason I had favored #5 over #2 is that I felt 5 would be
simpler; subject to occasional flow control for a large response
(which I hope will be rare), the target does not have to keep
track of where it was during the response.  Sending messages
fragmented in this way is very simple, although it might make
receiving and piecing them together more difficult.  This didn't
really bother me, though; I'd rather put more of the burden
on the initiator than on the target for anything discovery-
related, since the target is not in control of when and how often
this happens.

Anyway, #2 would work fine as well, but again, I'd really like
to avoid keeping state on the target.

--
Mark

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

Agreed.

> Steph

-- 
Mark A. Bakke
Cisco Systems
mbakke@cisco.com
763.398.1054