iSCSI: Yokohama meeting technical issues

[Black_David@emc.com]

The following iSCSI technical issues were discussed
at the Yokohama meeting (minutes are coming ...).

The following paragraphs report the rough consensus
of the room in Yokohama and I believe they are the rough
consensus of the IP Storage WG.  In Yokohama, some of
these consensus calls were over the objection of one
person (not the same person each time).  This is an
opportunity for those who couldn't make it to Yokohama
to voice a different opinion:

(1) Long Lived Discovery sessions.  Support for these
is not intended.  The only PDUs that an initiator is
allowed to send on a Discovery Session are a Send Targets
text request and a logout request that specifies "close
the session".  Targets MUST reject all other PDUs.

(2) Decimal encoding.  Follows the rough consensus on
the list, decimal encoding can only be used when the
parameter being encoded has a fixed size (bits that
the decoded value occupies) and that size is 64 bits
or less.  If one of the authentication bignums happens
to have a value that fits in 64 bits, decimal cannot
be used because the bignum has a considerably larger
size.

(3) Size requirements for negotiation.  Compromised on
8kb as the minimum amount of text that MUST be accepted
during a negotiation (consensus called over one person's
objection).  64k limit applies only when an AuthMethod is
supported that requires large binary values - in the meeting,
this was thought to be only SPKM, but a quick check of
the draft suggests that the 64k limit also has to apply
apply to Kerberos - it does not apply to CHAP or SRP.

(4) Error Recovery Level 0.5.  An implementation that does
not support both of the major features required for
ErrorRecoveryLevel 1 (within-connection and within-command
recovery) MUST negotiate ErrorRecoveryLevel 0, as to
negotiate 1 would promise support for both.  When
0 is negotiated, an initiator MAY try within-connection
recovery or within-command recovery, but it MUST be prepared
for a target to reject the attempts, as the target may be
strictly operating at ErrorRecoveryLevel 0.  A new value
of the ErrorRecoveryLevel key will *NOT* be defined to enable 
partial support of level 1 to be negotiated.

(5) BidiInitialR2T.  This key will be removed, InitialR2T will
also cover the bidirectional case, in part because this
corresponds to Fibre Channel's behavior.

(6) Resegmenting Data SNACKS - an intrepid design team came
up with a compromise solution between the Monday and Tuesday
sessions (including a trans-pacific conference call).

Summary of the problem situation:

	- SCSI Read or similar command is active on an
		iSCSI connection.
	- The initiator reduces the Maximum Data PDU size it
		is willing to accept.
	- The initiator discovers that it's missing some
		of the inbound data and requests retransmission.

iSCSI's data retransmission is based on resending
the same PDUs that were sent the first time.  That doesn't
work in this case because they may be too large.  When they're
made smaller, the count of Data PDUs in the SCSI Response PDU
may have to be changed.  This should be a rare case.

A rough summary of the compromise solution:

	- Existing Data SNACK MUST NOT resegment.  Targets
		MUST check this.
	- A new R-Data SNACK code is defined for the resegmenting
		case.  It always requests transmission of all
		unacknowledged data, and of a new SCSI Response
		since the count of Data PDUs may have changed.
		The new SCSI Response uses the same StatSN number.
	- A new SNACK tag is sent in an R-Data SNACK and
		returned in the new SCSI Response to ensure
		that the new response with the correct count
		of Data PDUs is used, as there may be one or
		more SCSI Responses to this command with the
		the wrong count in flight when the R-Data
		SNACK is issued (if you're wondering how
		multiple SCSI Responses could be in flight,
		think about Status SNACKs and large delays).

There are a number of additional details that can be found
in the working draft.

I believe the above six items represent the rough consensus
of the IP Storage WG, but this is an opportunity for those
who differ (and could not make it to the Yokohama meeting)
to object (quickly, please).

Thanks,
--David
---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 249-6449            FAX: +1 (508) 497-8018
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------