Subject: RE: [IPS] Traditional iSCSI and SCTP

From: [email-masked]
Date: Mon, 14 Mar 2005 09:36:50 -0500

Nicholas,
 
I second Julian's suggestion to write a draft on iSCSI over
SCTP.  Minutes from Minneapolis will be coming shortly, but
a draft defining iSCSI over SCTP is a prerequisite to using
iSCSI/iSER over RDDP/SCTP.  With "running code" in hand,
you're in a great position to write a draft explaining how
it works ;-).

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

________________________________

	From: [email-masked] [mailto:[email-masked]] On Behalf
Of Julian Satran
	Sent: Sunday, March 13, 2005 11:10 PM
	To: Nicholas A. Bellinger
	Cc: iscsi-initiator-core-devel; ips reflector; John Hufferd;
[email-masked]
	Subject: Re: [IPS] Traditional iSCSI and SCTP

	Dear Nicholas, 
	
	Do you think that adding a connection type is the only change
required? 
	My guess is that what is needed is  draft on"iSCSI for SCTP" while
attempting to maintain as much as possible from iSCSI 
	is a better match to SCTP that just connection=stream. In the
absence of such a mapping you could use some vendor keys 
	and the "naive mapping" to feel better about the completeness of
your stack. 
	
	Regards, 
	Julo 

	"Nicholas A. Bellinger" <[email-masked]> 
	Sent by: [email-masked] 

	13/03/2005 19:55 

		To
		ips reflector <[email-masked]>, iscsi-initiator-core-devel
<[email-masked]> 
		cc
		John Hufferd <[email-masked]>, Julian
Satran/Haifa/IBM@IBMIL 
		Subject
		[IPS] Traditional iSCSI and SCTP

	Everyone,
	
	I am not sure how SCTP over non-iSER enabled implementations fits
into
	the overall scheme of things, but I figued that I should ask anyways
	after reading section 4 in draft-hufferd-ips-iser-sctp-ib-00.
	
	To my knowledge, http://www.iscsi-initiator-core.org is the only
	initiator stack to provide support for traditional iSCSI over SCTP.
	As work moves forward to support RDMA enabled hardware of all
network
	interconnect types via iSER with this stack, I am considering if it
	would be worthwhile defining a traditional iSCSI/SCTP conntection
type
	key to prevent needless connection attempts/failures as per the
logic in
	section 4.
	
	I am sure that not many vendors will be supporting iSER/SCTP or
	traditional iSCSI/SCTP in the future, but for completeness of the
	iscsi-initiator-core.org stack, I would like to see something along
the
	lines of the connection type values discussed in section 4 be
defined
	for non-iSER/SCTP today.  I am primarly interested in defining these
	values for iscsi-initiator-core's configuration scripts as soon as
	possible.
	
	I guess my main question is, how should this addition to the
traditional
	iSCSI ecosystem be handled?
	
	-- 
	Nicholas A. Bellinger <[email-masked]>
	Chief Architect, PyX Technologies, Inc.
	http://www.iscsi-initiator-core.org

	_______________________________________________
	Ips mailing list
	[email-masked]
	https://www1.ietf.org/mailman/listinfo/ips

_______________________________________________
Ips mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ips

---

From: [email-masked]
Date: Tue, 15 Mar 2005 11:39:17 -0500

Nicolas,

By all means, write a draft, soliciting whatever help you need
on or off this list.  I can find SCTP expertise to review/
comment/help once the first version of the draft is available.
A draft covering whatever you've run into and/or think is
important in your implementation would be a fine starting point.

If iSER/SCTP material is included in the draft, please keep it
logically separate, just in case it becomes appropriate to handle
iSCSI over SCTP and iSCSI over iSER/SCTP in separate documents.

While markers are not needed over SCTP, the CRC32C digests may
still be useful in providing end-to-end integrity through
iSCSI-level proxies (especially for data).  As an example,
consider an iSCSI/SCTP to iSCSI/TCP proxy.

Thanks,
--David

> -----Original Message-----
> From: Nicholas A. Bellinger [mailto:[email-masked]] 
> Sent: Monday, March 14, 2005 9:04 PM
> To: Julian Satran; David Black
> Cc: John Hufferd; ips reflector; [email-masked]; 
> iscsi-initiator-core-devel
> Julian and David,
> I definately agree that more information is needed than a connection
> type key when it comes to iSCSI/SCTP.  I think a potential draft could
> be kept straightforward, and could primarly focus on iSCSI/TCP features
> that are not longer a requirement with SCTP, the obvious ones being
> CRC32C and Fixed Interval Markers.
> 
> The other debatable point for a iSCSI/SCTP draft would be forcing
> MaxConnections=1 and using SCTP's multihoming feature instead of
> multiplexing at the iSCSI layer.  If MaxConnections=1 is not a strict
> requirement, and I do not think it should so iSCSI/SCTP can take
> advantage of RFC 3720's connection recovery schematincs, the next
> logical question would be if mixed iSCSI/TCP and iSCSI/SCTP sessions
> should be allowed.  I recall that mixed [RDMA,non-RDMA] sessions are
> illegal in the iWARP/iSER draft(s), but I am not sure of any potential
> complications, or benefits of allowing this to occur in traditional
> iSCSI once a connection type key is defined for SCTP/iSCSI.
> 
> Along with the above points, I do not see any additional session or
> connection keys needing to be defined when it comes to multiple
> transport level protocols taking advantage of the traditional iSCSI
> ecosystem.  Also, I would prefer to wait instead adding vendor specific
> keys to the iscsi-initiator-core.org implementation.  I am by no means
> an SCTP expert :-), but I can definately put together some information
> involving basic iSCSI/SCTP considerations baised upon previous
> discussions of how RFC 3720 applies to network interconnects 
> other than iSCSI/TCP.
> 
> Thanks!
> 
> -- 
> On Sun, 2005-03-13 at 23:09 -0500, Julian Satran wrote:
> > 
> > Dear Nicholas, 
> >  
> > is a better match to SCTP that just connection=stream. In 
> the absence
> > of such a mapping you could use some vendor keys  
> > and the "naive mapping" to feel better about the 
> completeness of your
> > stack. 
> > 
> > Regards, 
> > Julo 
> > 
> > 
> > "Nicholas A. Bellinger"
> > ips reflector
> > <[email-masked]>,
> > iscsi-initiator-core-devel 
> > John Hufferd
> > <[email-masked]>, Julian Satran/Haifa/IBM@IBMIL 
> >           Subject
> > [IPS] Traditional
> > iSCSI and SCTP
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > Everyone,
> > 
> > I am not sure how SCTP over non-iSER enabled 
> implementations fits into
> > As work moves forward to support RDMA enabled hardware of 
> all network
> > would be worthwhile defining a traditional iSCSI/SCTP 
> conntection type
> > key to prevent needless connection attempts/failures as per 
> the logic
> > in
> > section 4.
> > 
> > lines of the connection type values discussed in section 4 
> be defined