Re: iSCSI: Ch7 clarifications

["Mallikarjun C." <cbm@rose.hp.com>]

Stephen,

Thanks for the comments, let me comment on your questions.

>Julian, I have a couple of section 7 questions.
>
>The last paragraph of 7.1 states:
>
>        It is optional for targets to support the replay functionality (as 
>        agreed by the CommandReplaySupport text key at the login time) and 
>        the allegiance switching (as agreed by the CommandFailoverSupport 
>        text key at the login time), while they MUST support the retry bit 
>        and the rest of the retry functionality described in this section.  
>        When a target does not implement replay, it MUST reject the command 
>        with a reason code of "Command Replay Not Supported". 
>
>Question 1a:
>If CommandReplaySupport must have been previously negotiated, isn't it a
>protocol error for an initiator to request it if the target doesn't support
>it, given that the target would never have negotiated to agree on replay?
>And, as such, shouldn't the response be more drastic, following the path for
>protocol errors?

Yes, it may be a protocol error.  The Reject reason code is intended to 
be a more precise identification of the source of the problem as opposed
to a generic "Protocol error" reason code. 

As of rev07, please note that this may also be a genuine case of different 
views of the same task between the two ends - initiator may be attempting to
plug a command which target, if it is done, could be mistaking for a replay.
This ambiguity however, is being fixed as Julian already indicated (check 
http://www.pdl.cmu.edu/mailinglists/ips/mail/msg05800.html).

>
>Question 1b:
>The ", while they MUST support ..." seems unnecessary, given that the
>required actions for a target are otherwise specified.

They are clearly specified - whatever is required to satisfy bullet "(b)" 
(command plugging) - from the way I read it.   What this quote is saying 
is that 2 out of 3 identified scenarios are optional to support, whereas 
targets must process the X-bit and guarantee that initiators can plug 
command sequence gaps deterministically, and must generate a Reject with 
the "command in progress" reason code (para 2, page 114).

>
>I suggest striking the last sentence and a half and rework the paragraph to
>state:
>        Targets MAY support the replay functionality.  Actual use of replay
>is 
>        agreed by the CommandReplaySupport text key at login.
>
>        Targets MAY support allegiance switching.  Actual use of allegiance
>switching is
>        agreed by the CommandFailoverSupport text key at login.
>
>
>Question 2.  In Paragraph 7.4 The following is ambiguous:
>         
>             - If the discarded PDU is an iSCSI data PDU,  
>                       a) Target MAY request retransmission with a R2T. 
>                          [OR] 
>                       b) Target MUST answer with a command response PDU 
>                          with a response-code of delivery-subsystem-
>                          failure and terminate the task.  If the target 
>                          chooses to implement this, it MUST wait to 
>                          receive all the data (signaled by a Data PDU 
>                          with the final bit Set for all outstanding 
>                          R2Ts) before sending the command response PDU. 
>
>This could be interpreted two ways:
>  1) the target could choose option (a) and *not* request retransmission
>or
>  2) if the target chooses to not request retransmission, it must execute
>option (b).

I admit that I am confused by your (1) - if a target chooses option
(a), it is requesting retransmission.  I am not sure what you mean by
"choose (a), and not request"...

Anyway, I see your point.  I will reword it along the lines of the 
initiator actions.

>
>If (2) is intended, then the MAY in (a) should be MUST.
>If (1) is intended, then the MUST in (b) should be MAY.
>
>A similar situation occurs a few paragraphs later, where initiator actions
>are described.  The same situation appears in (a) and (b), but it is clearly
>articulated in (e) (if neither (c) nor (d), then (e)).
>
>Perhaps there is a convention that I'm unaware of where MAY-OR-MUST is
>deterministic.  If so, I've learned something ;^)
>
>But, MUST-OR-MUST seems more logical (to me).
>
>Stephen


Thanks.
--
Mallikarjun 


Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions Organization
MS 5668	Hewlett-Packard, Roseville.
cbm@rose.hp.com