Re: iSCSI: Iterating long text responses

[Mark Bakke <mbakke@cisco.com>]

Tow-

As you said, adding that functionality would either:

- Require the target to keep state; it would have to build the whole
  response, and keep it until the initiator was finished with it.

-OR-

- Require the target to rebuild the same data, and send a different
  piece of it.  Since the SendTargets response could change in between
  (targets could be added or deleted, acquire new addresses, or have
  authorization changes), using an offset would not work; we would
  have to iterate on something else.

Option #3 (from my earlier response) would give you what you had
requested with some added complexity to the target.

That said, I think that it is in general best to keep the implementation
simpler on targets, especially since most of these are equally complex
for the initiator.

Are you working on a particular initiator that will have trouble
with options 4 or 5?

Thanks,

Mark


Tow Wang wrote:
> 
> Mark (and others):
> 
> I'd like to suggest one extra piece of functionality to option 5: let the
initiator specify not only the amount, but also the OFFSET of the data it
would like to receive, as some implementations of initiators may find it
difficult to reallocate/resize the buffer(s) to receive "SendTargets" data.
Thus, if the initiator finishes processing data for the first n targets
being listed, it would be more flexible to let the initiator say "I am
ready to know about any further targets you'd like to report".
> 
>From the way you described this functionality, I understand that every
time the initiator issues the "SendTargets" key/request, the target will
rebuild all information about all adjacent targets (so that this target
issuing the response will not need to keep state, as you said). If that
is the case, would it be too difficult for the responding target to offset
into the data it has re-built, and pack the remaining bytes into PDU's?
> 
> Please let me know your thoughts about this. Thanks.
> 
> Tow
> 
> -----Original Message-----
> From: Mark Bakke <mbakke@cisco.com>
> Date: Fri, 29 Jun 2001 15:18:20 -0500
> To: IPS <ips@ece.cmu.edu>
> Subject: iSCSI: Iterating long text responses
> 
> > Initiator developers-
> >
> >    Please respond to the questions at the end.
> >
> > Thanks,
> >
> > Mark
> >
> >
> >
> > The current iSCSI draft allows text command and response
> > PDUs of up to 4096 bytes.  While we don't see any real
> > problems for the command PDU size, commands such as SendTargets
> > can easily exceed the response size.
> 
> [snip]
> 
> > 4. Allow multiple response PDUs to a single text command:
> >
> >    I->T  Text Command (F bit set)
> >    T->I  Text Response (first PDU, F bit cleared)
> >    T->I  Text Response (next PDU, F bit cleared)
> >
> >    ...
> >
> >    T->I  Text Response (last PDU, F bit set)
> >
> >    Basically, we are doing (3) without the R2T.  The initiator,
> >    upon sending the text command, must be prepared either to
> >    accept as many PDUs as come back, or throw them away if it
> >    can't handle them.  This solution is a lot like #1, but with
> >    the response spread across 4k PDUs.
> >
> >    Also note that this (and the following scheme) avoid the problem
> >    of the target keeping state; it sends ALL of the response PDUs
> >    without the initiator asking for them.
> >
> > 5. Do #4, but allow the initiator to specify the amount of data
> >    it is willing to accept:
> >
> >    I->T  Text Command (F bit set, AcceptResponseLength=4096)
> >    T->I  Text Response (first PDU, F bit set, TotalResponseLength=12288)
> >
> >    In the above example, we have created a new text command field:
> >
> >       AcceptResponseLength
> >
> >    And in the text response PDU:
> >
> >       TotalResponseLength
> >
> >    The initiator indicated it was willing to accept a 4k response.
> >    The target returned the first 4k in the text response, but set
> >    the F bit since it was at its limit.  It also returned a
> >    TotalResponseLength field.  Since this was greater than the
> >    AcceptResponseLength, the initiator knows the amount of buffer
> >    space it will need to get the full response.  It can then choose
> >    whether it will re-send the command, and if so, can give it a
> >    large enough response length:
> >
> >    I->T  Text Command (F bit set, AcceptResponseLength=12288)
> >    T->I  Text Response (first PDU, F bit clear)
> >    T->I  Text Response (next PDU, F bit clear)
> >    T->I  Text Response (last PDU, F bit set, TotalResponseLength=12288)
> --
> 
> _______________________________________________
> FREE Personalized E-mail at Mail.com
> http://www.mail.com/?sr=signup
> 
> FREE PC-to-Phone calls with Net2Phone
> http://www.net2phone.com/cgi-bin/link.cgi?121

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