Subject: Re: iSCSI: plugfest4 issues

From: "Robert D. Russell" <[email-masked]>
Date: Thu, 1 Aug 2002 09:12:19 -0400 (EDT)

Julian:

Would you please clarify your answer to issue 2 below:

Do you mean the target should simply disconnect in all cases of a PDU
received during Login Phase that is not a Login Request PDU, or only
when the first PDU received during Login Phase is not a Login Request?

If the answer is "all cases", then there would appear to be no need
for the Login Response Status code 0x020b "Invalid Request type during
Login" and it should be removed to avoid further confusion.

I believe disconnect is fully justified when the first PDU in Login
Phase is not a Login Request, for both security and implementation
reasons, as stated in a posting by Eddy Quicksall.  However, after the
first Login Request PDU has been successfully received, the Login Phase
has clearly begun and it seems to me easier then to deal with all errors
on the target side, including reception of a non-Login Request PDU, in the
same manner, which is to send back a Login-Reject with the appropriate
status code and then close the connection.  I believe this is why the
0x020b Status code was introduced, and could anticipate the usefulness
of having this if, for example, the initiator concludes Login Phase
and begins sending FFP PDUs, but for whatever reason the target has not
concluded Login Phase and continues to expect to receive only Login
Request PDUs.

Thank you,

Bob Russell

> 2. The last paragraph of section 2.2.3 says:
>
>    "Before the Full Feature Phase is established, only Login Request and
>    Login Response PDUs are allowed. Any other PDU, when received at ini-
>    tiator or target, is a protocol error and MUST result in the connec-
>    tion being terminated. ..."
>
>    The question is the following:  is this rule literally true for the
>    target (i.e., can the target disconnect as soon as it receives a
>    non-Login PDU from the initiator) or does the target have to first
>    send a Login Response with Login reject PDU before disconnecting, as
>    it does for all other errors detected by the target during Login
>    Phase (according to section 4.3.1)?
>
>    A related question is: does the target take the same action when
>    the very first PDU it receives on a new TCP connection is not a
>    Login Request PDU?
>
>    If the target has to send the Login reject PDU before disconnecting,
>    then the last paragraph of section 2.2.3 should be reworded along
>    the following lines (modeled after the last paragraph of section 4.3):
>
>    "Before the Full Feature Phase is established, only Login Request
>    and Login Response PDUs are allowed.  If the target receives any PDU
>    other than Login Request, it must send a Login reject (code 0x020b)
>    and then disconnect.  If the initiator receives any PDU other than
>    Login Response, it MUST drop the connection. ..."
>
>    This wording would also appear to cover the case of when the very first
>    PDU a target receives on a new TCP connection is not a Login Request.
> +++ I would suggest sticking with disconnecting. +++
>

---

From: "Robert D. Russell" <[email-masked]>
Date: Thu, 1 Aug 2002 19:41:28 -0400 (EDT)

Julian:

Only one minor issue came up today, Thursday, 1-August-2002, at the
iSCSI plugfest.

1. According to the change log for draft 11 (which, of course, is
   not part of the official draft), the TTT field was added to the
   Data-In PDU to carry information when the A bit is 1.  However,
   the way the standard is currently written, section 9.7.3 requires
   a valid Target Transfer Tag when the A bit is 1, but says nothing
   about its value when the A bit is 0, which implies that it may be
   valid but does not have to be valid.

   The question is, what use is a valid TTT in a Data-In PDU when
   the A bit is 0?  No reply is ever expected from the initiator
   in this case (because the A bit is 0), so the initiator can
   never use this TTT value in any future PDU.

   Perhaps the first sentence of the second paragraph of section
   9.7.3 should be modified to read:

   "On incoming data, the Target Transfer Tag MUST be provided by the
   target if the A bit is set to 1 and MUST be reserved otherwise."

Thank you for your consideration.

Bob Russell
InterOperability Lab
University of New Hampshire
[email-masked]
603-862-3774