iSCSI-related conclusions from Orlando interim Meeting

[Black_David@emc.com]

This is a summary of the conclusions reached in the iSCSI area
at the interim meeting in Orlando earlier this week.  FCIP-related
conclusions will follow under separate cover.  These conclusions
are stated as preliminary consensus of those in the room in Orlando
and are subject to further discussion and revision on this mailing
list.

(1) Framing
- The iSCSI draft will be revised to add a formal iSCSI interface
	to framing
	- This will support the current marker approach, SCTP, and
		SCTP-like chunking for TCP.
	- The existing description of markers will be moved to an
		appendix as an example.
-The WARP group working on RDMA will write a draft on using SCTP-like
	chunking for iSCSI without RDMA

(2) Error Recovery
- Terminology Changes
	- "Reference Number" and "RN" are used only for SCSI
		-iSCSI uses "Sequence Number" and "SN" instead
	- "AER" is used only for SCSI
		- iSCSI communication of asynchronous events is through a
mechanism
		 	that is now called "Asynchronous Messages" - iSCSI
uses these
			to implement AER
		- If a SCSI initiator has disabled AER, iSCSI does not send
the
			corresponding Asynchronous Messages
- CmdSN (formerly CmdRN) is mandatory in all cases to simplify things.
	- This includes single connection sessions
- SCSI has defined a new (optional) SCSI Command Ref Number
	- iSCSI will use byte #2 in iSCSI header (currently Reserved) to
transport this
	- This is not the ideal solution, but matches the level of support
in FCP.
	- We have to check where mode page is to negotiate this
		- If it's on a transport-specific mode page, iSCSI will
			use a text key to negotiate this instead
- DataSN (formerly DataRN) functionality will be removed.  Error recovery is
now at the
	granularity of commands, not within a command.
- There will be a significant connection recovery write-up, including
details, procedures
	and examples added to the draft.
- Ping/NOP issues
	- A description of intended usage will be added to the draft as
advice to
		implementers.
		- A ping is intended to check whether the corresponding
protocol is alive
	- NOP responses are not permitted to request responses to avoid
loops
- Abort WARNING will be added to the draft.
	- Immediate Delivery of Aborts and similar task management commands
may have
		unexpected results when multiple TCP connections are in use
because
		Abort, Clear Task Set, etc. may bypass command(s) to be
aborted/cleared
		on other TCP connections.
	- Ordered Delivery should be used instead when this is a concern.
(3) CRC
	- iSCSI will use separate CRCs on header and data to make header
modification
		easier for systems that need to do that.
		- Using the same CRC algorithm on header and data is simpler
- in particular
			the idea of using a 16-bit CRC on the header was
discarded.
		- One CRC should cover both the fixed header and optional
extensions
	- Sense of the room on CRC Algorithms
		- CRC-32 is the obvious first/default choice.
		- There is some interest in investigating both weaker
(Adler-32) and
			stronger (CRC-64) CRCs (CRC-64 may not be
appropriate for header,
			and is still a research topic).
	- CRCs are MUST implement
		- Open issue: whether CRC use is negotiable
		- Default: Use CRCs
	- Limiting the amount of data per CRC
		- Probability of undetected error rises with amount of data
covered by
			one CRC.
		- There will be at most one data CRC per PDU
		- This limit SHOULD be enforced limit by fragmenting large
data blocks
			into Multiple Data PDUs
		- Julian Satran will look for the reference that suggests
CRC-32 should
			not be used on data blocks significantly larger than
8-10k.
(4) Security
	- Current iSCSI security digests will be removed in favor of IPsec
and/or TLS
		- Only reason for digests is data integrity (i.e., CRCs)
		- Open issue: How does iSCSI negotiate or detect presence of
lower
			level security?
		- Open issue: What is minimum security required to be used
			(authentication/integrity) by IETF?  David Black
			- SRP and Kerberos login authentication will remain
				in the iSCSI draft pending resolution of
this issue.
(5) Naming
	- UTF-8 will be used instead of ASCII for text strings in iSCSI
login and
		text commands, naming, discovery, etc.
	- Binary values will be encoded in UTF-8 rather than adding
type/length support.
	- Localization of iSCSI text is forbidden on the wire for
interoperability
		reasons (e.g., keys/values in login and text commands are
the same
		byte strings, no matter what the locale).

Ok, comment away ...

Thanks,
--David

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