Subject: iSCSI: Ch7 clarifications

From: "Wheat, Stephen R" <[email-masked]>
Date: Tue, 21 Aug 2001 16:49:49 -0700

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?

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

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

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

---

From: "Mallikarjun C." <[email-masked]>
Date: Tue, 21 Aug 2001 18:36:54 PDT

Stephen,

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

>And, as such, shouldn't the response be more drastic, following the path for

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

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

>  2) if the target chooses to not request retransmission, it must execute

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.

>But, MUST-OR-MUST seems more logical (to me).

Thanks.
--
Mallikarjun 

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions Organization
MS 5668	Hewlett-Packard, Roseville.
[email-masked]