SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    Official IPS Orlando interim minutes



    IPW Working Group
    Orlando Interim Meeting Minutes, January 16-17, 2001
    ----------------------------------------------------
    
    These minutes report conclusions reached at the meeting with comments
    on subsequent action on the mailing list where appropriate.
    
    -- iSCSI and related items (January 16th, plus about an hour on
    	the morning of January 17th)
    
    (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, but
    may
    			still send iSCSI to iSCSI Asynchronous Messages that
    			do not cause AER events visible to SCSI.
    - 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 the iSCSI header (currently Reserved)
    		to transport the SCSI CRN when it is present.
    	- This is not the ideal solution, but matches the level of
    		support in FCP.
    	- SCSI uses a transport-specific mode page to negotiate CRN
    		usage, therefore iSCSI will use a text key to handle
    		this negotiation (updated based on investigation after
    		the meeting).
    - 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 further responses
    		in order to avoid NOP 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 in a single iSCSI session 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.]]
    		NOTE: This meeting conclusion was *rejected* on the mailing
    		list and hence remains an open issue.
    		- 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.  
    			NOTE: This conclusion to not use 16-bit CRC
    algorithms
    				remains the WG consensus. 
    		- One CRC should cover both the fixed header and optional
    			extensions.
    			NOTE: This is part of the separate CRCs conclusion
    that
    				was rejected on the list, and hence this
    issue is
    				open.
    	- 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 about 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?
    			Resolution: IETF requires implementation of strong
    				security sufficient for public networks, but
    				permits negotiation down to weaker (or even
    				no security), *provided that* the
    negotiation
    				is secure (e.g., against man in the middle
    				attack to force negotiation of "no
    security".
    			- SRP and Kerberos login authentication will remain
    				in the iSCSI draft.
    (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 translated to text strings [further
    		discussion on the list indicated a preference for
    		hex (0xnnn format) and decimal representations] and
    		encoded in UTF-8 rather than adding type/length support
    		to send them natively.
    	- 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).
    
    -- FCIP and related items (January 17th)
    
    1) Ralph Weber verbally presented some changes to the FCIP draft,
    specifically dealing with framing, header and timestamps. A formal proposal,
    in the form of a draft, has been submitted in mid-February.
    
    2) SOF/EOF encodings.  The current draft uses the same SOF/EOF encodings as
    are in the FC-BB specification.  While that draft lists a number of
    encodings, only a subset are required by that document.  Discussions about
    the various encodings have lead to the conclusion that the subset should be
    the only SOF/EOF encodings specified in the FCIP document.  That subset is
    restricted to class 2 and class 3 support.  The other encodings are either
    not defined in FC-FS (framing and signaling), are Class 1 specific (which is
    not currently used in the industry) or class 4 (which is not yet defined).
    
    3) Figure 4 in the document needs to be updated.  It currently implies that
    the FC header will immediately follow the TCP header.  Misleading, in that
    it appears to be at a fixed offset and does not indicate that optional TCP
    headers may be in place between the TCP and FC headers.  In particular, put
    a box with ellipses in it to make this clearer.
    
    4) David Black provided input on QoS (David is a coauthor of the
    Differentiated Services header and architecture RFCs).  The FCIP draft
    should
    be revised to avoid specifying a specific Differentiated Services Code Point
    (DSCP) and should instead specify expected/required performance criteria.
    
    5) Error recovery is still a major issue in the current specification, in
    particular the handling of the FC and TCP timeouts and their correlation.
    Ralph Weber's discussion earlier in the session applicable here.  We really
    need more input on this from the FC switch vendors.  This will be discussed
    in the FC-BB2 meeting at T11 to solicit their input.
    
    6) Security -- Authentication a must.  IPSec and TLS are the logical choices
    here.  TLS may be the better choice of the two.  iSCSI facing the same
    issues.  FCIP should take iSCSI decisions/considerations into account and
    try to align with iSCSI if possible.
    
    7) Clarification needed to the document indicating that E_Ports are
    supported by this document.  While not prohibited by the current document,
    not clear that this is supported either.
    
    IETF IP Storage (ips) WG
    Interim Meeting Attendees
    Orlando, Florida - January 16, 2001
    -----------------------------------
    
    David Black			black_david@emc.com
    John Hufferd		hufferd@us.ibm.com
    Jack Harwood		jharwood@emc.com
    David Peterson		dap@cisco.com
    Julian Satran		Julian_Satran@il.ibm.com
    Costa Sapuntzakis		csapuntz@cisco.com
    Steve DeGroote		sdegroote@cisco.com
    Mark Bakke			mbakke@cisco.com
    Naoki Watanabe		naoki.wtanabe@hds.com
    Neil Wanamaker		ntw@crossroads.com
    Donald Getty		donald_getty@ti.com
    Larry Lamers		LJLAMERS@ieee.org
    Jim Hafner			hafner@almaden.ibm.com
    Bob Nixon			bob.nixon@emulex.com
    Ken Moe			kenneth.moe@sun.com
    Mark Edwards		medwards@eurologic.com
    Wayland Jeong		wayland@troikanetworks.com
    Bill Terrell		terrell@troikanetworks.com
    Bob Snively			rsnively@brocade.com
    Ralph Weber			roweber@acm.org
    Stephen Ostrowski		sostrowski@giganet.com
    Jim Williams		jimw@giganet.com
    Mike Mesnier		michael.mesnier@intel.com
    Randy Haagens		randy_haagens@hp.com
    Bill Lynn			bill-lynn@corp.adaptec.com
    Rob Haydt			robhay@microsoft.com
    Vit Novak			vit.novak@sun.com
    Albert Chang		albert.chang@compaq.com
    Roger Cummings		roger.cummings@veritas.com
    Howard Hall			howard@pirus.com
    John Scheible
    Dal Allan
    Mike Fitzpatrick		mfitzpatrick@fcpa.fujitsu.com
    Jon Sreekanth		jon.sreekanth@trebia.com
    Elizabeth Rodriguez	egrodriguez@lucent.com
    Joe Steinmetz		joe_steinmetz@agilent.com
    Matt Wakeley		matt_wakeley@agilent.com
    Luciano Dalle Ore		luciano.dalle.ore@quantum.com
    Kevin Gibbons		kgibbons@nishansystems.com
    Josh Tseng			jtseng@nishansystems.com
    Charles Monia		cmonia@nishansystems.com
    Henry Yang			Henry.Yang@mcdata.com
    Paul Congdon		paul_congdon@hp.com
    Vi Chau			vchau@gadzoox.com
    Gaby Hecht			ghecht@gadzoox.com
    Pierre Labat		pierre_labat@hp.com
    James Pinkerton		jpink@microsoft.com
    Terry Gibbons		terry.gibbons@lsil.com
    Craig Carlson		cwc@ancor.com
    John Vrabel			j.vrabel@san.com
    Somesh Gupta		somesh_gupta@ieee.org
    
    IETF IP Storage (ips) WG
    Interim Meeting Attendees
    Orlando, Florida - January 17, 2001
    -----------------------------------
    
    Elizabeth Rodriguez	egrodriguez@lucent.com
    David Black			black_david@emc.com
    Murali Rajgopal		muralir@lightsand.com
    Craig Carlson		craig.carlson@qlogic.com
    David Peterson		dap@cisco.com
    Josh Tseng			jtseng@nishansystems.com
    Kevin Gibbons		kgibbons@nishansystems.com
    John Vrabel			j.vrabel@san.com
    Albert Chang		albert.chang@compaq.com
    Bob Nixon			bob.nixon@emulex.com
    Jon Sreekanth		jon.sreekanth@trebia.com
    Mike Fitzpatrick		mfitzpatrick@fcpa.fujitsu.com
    Donald Getty		donald_getty@ti.com
    Jack Harwood		jharwood@emc.com
    Wayland Jeong		wayland@troikanetworks.com
    Mark Edwards		medwards@eurologic.com
    Henry Yang			Henry.Yang@mcdata.com
    Paul Congdon		paul_congdon@hp.com
    Steve Degroote		sdegroote@cisco.com
    Vi Chau			vchau@gadzoox.com
    Gaby Hecht			ghecht@gadzoox.com
    Venkat Rangan		venkat@rhapsodynetworks.com
    Howard Hall			howard@pirus.com
    Larry Lamers		LJLAMERS@ieee.org
    Lucian Dalle Ore		Luciano.Dalle.Ore@quantum.com
    
    


Home

Last updated: Tue Sep 04 01:05:31 2001
6315 messages in chronological order