|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: iSCSI: current UNH Plugfest
Sandeep - your note made me look - and I found that I forgot the list -
Sorry - Julo
----- Forwarded by Julian Satran/Haifa/IBM on 01-11-01 21:25 -----
Julian Satran
01-11-01 14:02
To: "Robert D. Russell" <rdr@mars.iol.unh.edu>
cc:
From: Julian Satran/Haifa/IBM@IBMIL
Subject: Re: iSCSI: current UNH Plugfest
Bob,
Comments in text - thanks - Julo
"Robert D. Russell" <rdr@mars.iol.unh.edu>
Sent by: owner-ips@ece.cmu.edu
01-11-01 00:39
Please respond to "Robert D. Russell"
To: ips@ece.cmu.edu
cc:
Subject: Re: iSCSI: current UNH Plugfest
Attached are the new issues that arose during the iSCSI plugfest
at UNH on Wednesday 31-Oct-2001.
(Note: these issues do not take into account any modifications or
clarifications that occured in the standard due to the issues raised
on Monday or Tuesday.)
Bob Russell
InterOperability Lab
University of New Hampshire
rdr@iol.unh.edu
603-862-3774
----------------------------------------------------------------------------
1. Are receivers (initiator or target) REQUIRED to check that reserved
bits and/or fields are set to 0?
Section 3 on page 48 of draft 8 says:
"Any bits not defined MUST be set to zero. Any reserved fields and
values MUST be 0 unless specified otherwise."
and Section 8.3 on page 127 of draft 8 says:
"Explicit violations of the PDU layout rules stated in this document
are format errors. This when detected, usually indicates a major
implementation flaw in one of the parties.
When a target or an initiator receives an iSCSI PDU with a format
error, it MUST reset all transport connections in the session
immediately and escalate the format error to session recovery
(section 8.11.4)."
According to these rules, a PDU with reserved bits and/or fields that
are not set to 0 violates the PDU layout rules. Therefore, if an
initiator or target receives such a PDU, it should immediately close
all connections in the session and go to session recovery.
Clearly a format error has extremely severe consequences!
Although all vendors are setting reserved bits and fields to 0 on
PDUs they are sending, many are NOT checking PDUs they are receiving
to see if these bits and fields are set to 0. Basically, vendors are
saying "who cares if reserved bits and/or fields in incoming PDUs are
not zero? We do not want to take the time to do this checking, and
there is no benefit to doing it. As long as the non-reserved bits and
fields are set properly, we can and should proceed. Any time devoted
to doing this checking is wasted in 99+% of the cases, and in the
(unlikely) case that a non-zero bit or field is found, the
consequences are too severe."
There should be some statement in the standard to clarify what checking
is required and what is optional.
+++
As it was said already on this list there are things that a standard
better leaves unsaid :-)
In accordance with the good tradition of other iSCSI transports I suggest
we stay silent on this.
+++
2. A similar situation arises with respect to checking the consistency
of fields such as Version-max, Version-min and Version-active in Login
Requests and Login Responses.
For example, consider the Version-max field.
Section 3.12.5 says:
"All Login requests within the Login phase MUST carry the same
Version-max."
All vendor initiators are setting Version-max correctly on all
login requests they are sending, but many vendor targets are NOT
checking received login requests to ensure that this rule is enforced.
In particular, many targets simply use the Version-max and Version-min
on the first login request they receive on a new connection, and then
they ignore these fields on all subsequent login requests in the same
login phase.
Strictly speaking, a change in the Version-max field during the login
phase constitutes a protocol error according to section 8.8 on page 130
of draft 8:
"All violations of iSCSI PDU exchange sequences specified in this
draft are also protocol errors. This category of errors can be
addressed only by fixing the implementations; iSCSI defines Reject
and response codes to enable this".
Therefore the target should send back a login response with a status
of 0x0200 and then close the connection.
However, Section 3.12.5 also says:
"The target MUST use the value presented with the first login
request."
This rule seems to imply that the value CAN change, because if it
cannot
change, then it doesn't matter which one of the login requests it is
taken from, they are all the same anyway.
The suggestion is to keep the requirement that the target MUST use the
value presented on the first login request, but to allowed the target
to ignore the value presented on all subsequent login requests in the
same login phase. A similar rewording should be done for the other
fields.
+++
As above.
+++
3. Can commands be sent out of order on the same connection?
The behavior of targets is clearly specified in Section 2.2.2.3 on
page 25 of draft 8, which says:
"Except for the commands marked for immediate delivery the iSCSI
target layer MUST eliver the commands for execution in the order
specified by CmdSN."
Section 2.2.2.3 on page 26 of draft 8 also says:
"- CmdSN - the current command Sequence Number advanced by 1 on
each command shipped except for commands marked for immediate
delivery."
but the meaning of the term "shipped" is vague, and does not
necessarily
require that the PDUs arrive on the other end of a TCP connection
in the same order that the CmdSN values were assigned to these PDUs.
Some initiators have been designed to send commands out of CmdSN
order on one connection. Consider the situation where there is only
one connection and a high-level dispatcher creates a PDU for a SCSI
command that involves writing immediate data to the target. This PDU
is enqueued to a lower-level layer which has to setup, start, and
wait-for a DMA operation to move the immediate data into an onboard
buffer before the PDU can be put onto the wire. While this is
happening, the dispatcher creates another unrelated PDU for a SCSI
read command (for example), and when this PDU is passed to the
lower-level layer it can be sent immediately, ahead of the previous
write PDU and therefore out of order on this connection.
The standard clearly allows this to happen if the two PDUs were sent
on different connections, and seems to imply that this can also happen
when the two PDUs are sent on the same connection.
The suggestion is to put in the standard an explicit statement that
this is allowed or not allowed, as appropriate.
If this is allowed, such a statement would avoid the erroneous
assumption being made by some target implementers that within a single
connection, commands will arrive in order.
If this is not allowed, such a statement would avoid the erroneous
assumption being made by some initiator implementers that within a
single connection, commands can be put on the wire out of order.
+++
will add an explicit statement saying that this behaviour is forbidden.
2.2.2.1 will contain:
On any given connection, the iSCSI initiator MUST send the commands in the
order specified by CmdSN.
+++
4. Three numeric keys (MaxRecvPDULength, MaxBurstSize, FirstBurstSize)
now allow: "A value of 0 indicates no limit."
Is this useful? Does it buy anything?
+++
I have already removed this.
However the numerical negotiation will have 0 (wherever appropriate) as a
means to indicate "I don't care"
The text suggested for this is:
For numerical negotiations, the value 0 MAY be specified by the offering
party as a "don't care"/"unlimited" value for parameters that explicitly
allow it; in this case, the responder may choose any legal value for the
parameter.
And in the MAXBurstSize etc:
A value of 0 MAY be used as a "don't care" offer in negotiations.
+++
The difficulties implementers are having with this are:
1) It is a special case.
2) It causes discontinuous ranges (for example, [0,64..2**24])
3) It violates the min/max function normally used for the key.
4) There is always a limit anyway.
Consider FirstBurstSize, which can have a value that is described
as "<0|number-64-2**24>", and for which the minimum of the 2 numbers
is selected.
I one side offers 0 to mean unlimited, and the other side
has a limit, it will reply with that limit, say 128 Kbytes.
Therefore, the result is not min(0, 128K) but rather max(0, 128K).
The statement in the standard that "the minimum of the 2 numbers is
selected" is therefore wrong when one of the numbers is 0.
Furthermore, when an initiator or target receives an offer for one
of these keys, it cannot simply check that the offered value is
legal by testing it against some minimum and maximum. It must first
check for 0 and then only if that check shows the value is non-zero
can it do the min/max range check for legality (i.e., 64-2**24).
Finally, there is always a limit. If nothing else it is the
limit imposed by the 24-bit DataSegmentLength field of the PDU
requesting the transfer. It is useless to specify a FirstBurstSize
(or MaxRecvPDULength or MaxBurstSize) any bigger than that, because
the largest possible DataSegmentLength in any PDU that can use
this value is 2**24-1.
The suggestion is to just eliminate this special case of 0 and require
that the range 64-to-(2**24-1) be used instead -- it has exactly the
same effect in all cases, it is easier to describe in the standard
because it avoids all the extra words, and it is easier to code
because it avoids all the special cases.
NOTE: the standard should specify the limit in the ranges for
MaxRecvPDULength, MaxBurstSize, and FirstBurstSize as 2**24-1 instead
of 2**24. The number 2**24 cannot be represented in the 24-bit
DataSegmentLength field and therefore can never be used.
5. This is a suggestion for a minor rewording in the standard to avoid
misunderstandings.
In Appendix E on page 188 of draft 8 it says:
"The response to this command is a text response containing a list of
targets and their addresses. Each target is returned as a target
record. A target record begins with the TargetName text key,
followed by a list of TargetAddress text keys, ..."
In fact, there are situations where there are no targets and/or no
addresses. These situations are clearly defined in the draft after
the sentences quoted above, but it would help if those sentences
at least hinted at the possibility that the lists could be empty
or might not contain addresses. A possible rewording would be:
"The response to this command is a text response containing a list of
zero or more targets and, optionally, their addresses. Each target
is returned as a target record. A target record begins with the
TargetName text key, followed by a list of zero or more
TargetAddress text keys, ..."
+++
OK
+++
6. This is a suggestion for another very minor rewording in the standard.
At the end of section 2.2.3 on page 29 of draft 8 it says:
"Before full feature phase is established, only Login PDUs are
allowed. ..."
The suggested rewording is:
"Before full feature phase is established, only Login Request and
Login Response PDUs are allowed. ..."
+++
OK
+++
Home Last updated: Fri Nov 02 17:17:31 2001 7541 messages in chronological order |