RE: FW: [Ips] Recent comments about FCoE and iSCSI

"John Hufferd" <jhufferd@Brocade.COM> Thu, 26 April 2007 00:42 UTC

Return-path: <ips-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgs42-000180-55; Wed, 25 Apr 2007 20:42:26 -0400
Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1Hgs40-00017v-E0 for ips-confirm+ok@megatron.ietf.org; Wed, 25 Apr 2007 20:42:24 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgs40-00017n-3o for ips@ietf.org; Wed, 25 Apr 2007 20:42:24 -0400
Received: from mail.brocade.com ([66.243.153.242] helo=mx10.brocade.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hgs3y-0004qP-PW for ips@ietf.org; Wed, 25 Apr 2007 20:42:24 -0400
Received: from mailhost.brocade.com (HELO discus.brocade.com) ([192.168.126.240]) by mx10.brocade.com with ESMTP; 25 Apr 2007 17:42:22 -0700
X-IronPort-AV: i="4.14,452,1170662400"; d="gif'147?scan'147,208,217,147"; a="9519139:sNHT57011815"
Received: from HQ-EXCHFE-2.corp.brocade.com (hq-vipexchfe-2.brocade.com [192.168.126.214]) by discus.brocade.com (Postfix) with ESMTP id 5E5CF23836B; Wed, 25 Apr 2007 17:41:11 -0700 (PDT)
Received: from hq-exch-1.corp.brocade.com ([10.3.8.21]) by HQ-EXCHFE-2.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Apr 2007 17:42:21 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: FW: [Ips] Recent comments about FCoE and iSCSI
Date: Wed, 25 Apr 2007 17:42:20 -0700
Message-ID: <39BA3BC178B4394DB184389E88A97F8C022C5C6C@hq-exch-1.corp.brocade.com>
In-Reply-To: <006001c7876e$12cc26f0$05faa8c0@ivivity.com>
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
Thread-Topic: FW: [Ips] Recent comments about FCoE and iSCSI
Thread-Index: AceHbhab+EXeFVfgQWiH7jzYWydYaAAKX7IQ
From: "John Hufferd" <jhufferd@Brocade.COM>
To: "Eddy Quicksall" <Quicksall_iSCSI@Bellsouth.net>, "Julian Satran" <Julian_Satran@il.ibm.com>
X-OriginalArrivalTime: 26 Apr 2007 00:42:21.0806 (UTC) FILETIME=[C03A10E0:01C7879B]
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 1459dca363a7eac530b0f3f218abff0f
Cc: ips@ietf.org
X-BeenThere: ips@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Storage <ips.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ips>, <mailto:ips-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ips@ietf.org>
List-Help: <mailto:ips-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ips>, <mailto:ips-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0678873095=="
Errors-To: ips-bounces@ietf.org

Eddy,

The pause that is being analyzed as part of a Data Center Ethernet is
NOT the total stuff that is being handled.  The proposal that is being
worked on is called PPP (Per Priority Pause - which probably should be
called Per Class Pause).  The purpose of this is to use it as a flow
control alternative to a credit based approach which seems to be "not
going to happen" in the 802.1 committee.  This is a pause by class or
priority instead of the current Pause that effects every thing on the
link.  However, this is only a part of the total solution.  Another
committee is working on the Congestion issues, however, a number of
vendors, after looking at all the issues believe that we need more than
just the various congestion management approaches that are being
examined.  Therefore, many vendor think that adding a flow control such
as PPP can be part of the total solution to providing management of
congestion, at least for some of the higher priorities (classes).  

 

That being said let me say, that FCoE is not to be considered a
replacement for iSCSI.  It is just another tool for providing storage to
the application.  One approach does not fit all needs.  Fibre Channel is
important to the Enterprise Market.  They are not going to rip out and
replace their current FC infrastructure and replace it with an all iSCSI
or all FCoE network.  So FC is going to be with us.  I do not understand
why folks are going so hyper over the FC frames being transported on a
special Data Center Ethernet link instead of a FC physical Link.  It is
still FC, and we have that today. 

 

Many servers are asking for an evolutionary way to combine their
Networking connections from the Server.  The customers I have dealt with
do NOT want to rip out FC, they want to provide a single Link for
transport of all networking needs, including storage, exiting their
servers.  One needs to understand: this is still FC. But now the needs
of a single connection type can be phased in one Host system at a time,
and at some other time even the storage can be connected via FCoE.
However, there does not seem to be a compelling argument for the use of
FCoE to storage, at least not as compelling as the Server side.  But
some vendors will probably offer an FCoE connected storage controller.
This however, has little need for link consolidation, and FC will
continue to operate very well and I expect that even is FCoE is accepted
at the server side, most storage controller will remain FC.  

 

iSCSI still has an important place in the enterprise, but one approach
(FC, iSCSI, or FCoE) does not fit all.

 

.

.

.

John L Hufferd

Sr. Executive Director of Technology

jhufferd@brocade.com <mailto:jhufferd@brocade.com> 

Office Phone: (408) 333-5244; eFAX: (408) 904-4688

Alt Office Phone: (408) 997-6136; Cell: (408) 627-9606

 

________________________________

From: Eddy Quicksall [mailto:Quicksall_iSCSI@Bellsouth.net] 
Sent: Wednesday, April 25, 2007 12:15 PM
To: Eddy Quicksall; Julian Satran
Cc: ips@ietf.org; John Hufferd
Subject: Re: FW: [Ips] Recent comments about FCoE and iSCSI

 

Further, I think PAUSE is only for point-to-point and I think that is
too restrictive. 

 

Eddy

	----- Original Message ----- 

	From: Eddy Quicksall <mailto:Quicksall_iSCSI@Bellsouth.net>  

	To: Julian Satran <mailto:Julian_Satran@il.ibm.com>  

	Cc: ips@ietf.org ; John Hufferd <mailto:jhufferd@Brocade.COM>  

	Sent: Wednesday, April 25, 2007 2:55 PM

	Subject: Re: FW: [Ips] Recent comments about FCoE and iSCSI

	 

	If it was not obvious in my wording, I meant to agree with you
on your observations.

	 

	Eddy

		----- Original Message ----- 

		From: Julian Satran <mailto:Julian_Satran@il.ibm.com>  

		To: Eddy Quicksall
<mailto:Quicksall_iSCSI@Bellsouth.net>  

		Cc: ips@ietf.org ; John Hufferd
<mailto:jhufferd@Brocade.COM>  

		Sent: Wednesday, April 25, 2007 11:52 AM

		Subject: Re: FW: [Ips] Recent comments about FCoE and
iSCSI

		 

		
		Sorry Eddy by sizable I meant even at the size of a
modern data center. Julo 
		
		

"Eddy Quicksall" <Quicksall_iSCSI@Bellsouth.net> 

25/04/07 11:08 

To

Julian Satran/Haifa/IBM@IBMIL 

cc

ips@ietf.org, John Hufferd <jhufferd@Brocade.COM> 

Subject

Re: FW: [Ips] Recent comments about FCoE and iSCSI

 

 

 

		
		
		
		I basically said that in the summery line by saying "it
will not route on the "global" scale like TCP/IP would". 
		----- Original Message ----- 
		From: Julian Satran <mailto:Julian_Satran@il.ibm.com>  
		To: Eddy Quicksall
<mailto:Quicksall_iSCSI@Bellsouth.net>  
		Cc: ips@ietf.org ; John Hufferd
<mailto:jhufferd@Brocade.COM>  
		Sent: Wednesday, April 25, 2007 11:04 AM 
		Subject: Re: FW: [Ips] Recent comments about FCoE and
iSCSI 
		
		
		Eddy, 
		
		That is oversimplified and ignore the drop rate
assumption and error rate assumptions made in FCP(FCP has no transport
layer). To get to it on a sizable network requires more than PAUSE. 
		
		Julo 

"Eddy Quicksall" <Quicksall_iSCSI@Bellsouth.net
<mailto:Quicksall_iSCSI@Bellsouth.net> > 

25/04/07 10:07 

 

To

"John Hufferd" <jhufferd@Brocade.COM <mailto:jhufferd@Brocade.COM> >,
Julian Satran/Haifa/IBM@IBMIL <mailto:Satran/Haifa/IBM@IBMIL>  

cc

<ips@ietf.org <mailto:ips@ietf.org> > 

Subject

Re: FW: [Ips] Recent comments about FCoE and iSCSI

 

 

 

		
		
		
		
		Basically, it is sending FC frames over Ethernet. This
localizes the traffic unless you route based on MAC addresses. So you
send 2146 bytes of FC frame plus 18 bytes of Ethernet overhead as FCoE
"standard" packet. 18 bytes of Ethernet gets stripped and you have
straight FC frame that can go through any FC network. Now you can have
10G Ethernet pipes into existing FC SANs. Limited market potential as
far as I can see. The key argument is it much easier to implement than
iSCSI and also has less overhead and uses all the benefits of FC. End to
End credits are simulated using PAUSE command on Ethernet and MAC
addresses are mapped into WWNs. 

		Biggest knock is that it will not route on the "global"
scale like TCP/IP would. 

		Eddy 

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips