Re: iSCSI: Iterating long text responses

["Tow Wang" <towwang@mail.com>]

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