From owner-ipfc@standards.gadzoox.com Wed Aug 16 15:28:12 2000 Received: from standards.gadzoox.com (standards.gadzoox.com [216.52.31.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02744 for ; Wed, 16 Aug 2000 15:28:10 -0400 (EDT) Received: (from majordom@localhost) by standards.gadzoox.com (8.8.7/8.8.7) id LAA14752 for ipfc-list; Wed, 16 Aug 2000 11:10:13 -0700 X-Authentication-Warning: standards.gadzoox.com: majordom set sender to owner-ipfc@standards.gadzoox.com using -f Received: from lightsand.com ([208.50.99.84]) by standards.gadzoox.com (8.8.7/8.8.7) with SMTP id LAA14749 for ; Wed, 16 Aug 2000 11:10:04 -0700 Received: from cx926635a (cx926635-a.msnv1.occa.home.com [24.10.148.23]) by lightsand.com (8.9.3+Sun/8.9.1) with ESMTP id MAA19977 for ; Wed, 16 Aug 2000 12:19:51 -0700 (PDT) Message-ID: <004901c007b7$bc833960$17940a18@msnv1.occa.home.com> Reply-To: "Raj Bhagwat" From: "Raj Bhagwat" To: Subject: Fw: IPFC WG Pittsuburgh Draft Minutes Date: Wed, 16 Aug 2000 12:25:27 -0700 Organization: LightSand Communications MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ipfc@standards.gadzoox.com Precedence: bulk Content-Transfer-Encoding: 7bit These are the draft minutes of the IPFC WG meeting in Pittsburgh. If you have any comments, please send them to the reflector. Otherwise, these minutes will be submitted to the IETF. Raj Bhagwat LightSand Communications, Inc. ----- Original Message ----- From: Murali Rajagopal To: Sent: Wednesday, August 16, 2000 12:01 PM Subject: IPFC WG Pittsuburgh Draft Minutes > Agenda: > > 1)RFC 2625 UNH Test Report - Raj Bhagwat, LightSand Communications > > Raj presented the UNH testing results and indicated that 6 companies > (Qlogic, Emulex, Brocade, Sun, Crossroads, Interphase)had > participated in the testing. A matrix of the test suites versus > partcipating companies was briefly presented. It was indicated that the > details of the > testing could be found at the UNH test site > www.iol.unh.edu/testsuites/fc/IP_over_FC.html > > Next Step is to submit with modifications for DRAFT STD consideration > See attachment. > > 2)MIB Status - > a)draft-ietf-ipfc-mib-framework-02.txt : Mark Carlson, SUN Microsystems > > Mark indicated that the document was complete and is ready for starting > the > process of submitting it as an Informational RFC. > > The Chair (Murali) indicated that the draft will sent to WG for Last > Call comments. > > b)Draft-ietf-ipfc-fcmgmt-int-mib-04.txt: Jack Hardwood, EMC Corp. > > Jack stated that the work was undergoing formatting changes only with > no technical content change. > Jack explained the reason for the delay in completing this work > due to the formatting changes and was targeted for completion around the > Dec 2000 time frame. > > c) RFC 2837 "Definitions of Managed Objects for the Fabric Element in FC > Standard" - is now a PROPOSED STD > > > d)Storage Library MIB (SNIA) still an unapproved work item from the > Australia > WG meeting. > > > 3) FC Over IP - draft-ietf-ipfc-fcoverip-02.txt - Raj Bhagwat, LightSand > Comm., > Elizabeth Rodriguez, Lucent Tech > > This presenatation was not a formal work item under this group. > At this time, it was still debated as to where it belongs. > > The presentation was essentially a repeat from the last IETF meeting but > was presented > by Elizabeth (Lucent) with some updates from the latest draft. > > The attachement provides the details of the presentation, but much > discussion in the > room was centered around retransmission of frames if a Transport level > protocol were > to be used (TCP), and its effects on the overall FC end-to-end > transport. Lack of Congestion > Control was brought up as an issue and it was pointed out that > inclusion of this work item under IPS WG would be beneficial. From owner-ipfc@standards.gadzoox.com Thu Aug 24 09:54:28 2000 Received: from standards.gadzoox.com (standards.gadzoox.com [216.52.31.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17179 for ; Thu, 24 Aug 2000 09:54:27 -0400 (EDT) Received: (from majordom@localhost) by standards.gadzoox.com (8.8.7/8.8.7) id FAA19191 for ipfc-list; Thu, 24 Aug 2000 05:36:58 -0700 X-Authentication-Warning: standards.gadzoox.com: majordom set sender to owner-ipfc@standards.gadzoox.com using -f Received: from stewart.chicago.il.us (root@3ff83343.dsl.flashcom.net [63.248.51.67]) by standards.gadzoox.com (8.8.7/8.8.7) with SMTP id FAA19188 for ; Thu, 24 Aug 2000 05:36:55 -0700 Received: from stewart.chicago.il.us (IDENT:randall@stewart.chicago.il.us [10.1.1.1]) by stewart.chicago.il.us (8.9.3/8.8.7) with ESMTP id IAA13034 for ; Thu, 24 Aug 2000 08:47:05 -0500 Message-ID: <39A52759.BD2CB0A9@stewart.chicago.il.us> Date: Thu, 24 Aug 2000 08:47:05 -0500 From: "Randall R. Stewart" X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: ipfc@standards.gadzoox.com Subject: Re:draft-otis-fc-sctp-ip-00.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipfc@standards.gadzoox.com Precedence: bulk Content-Transfer-Encoding: 7bit Greetings: (I apologize for the earlier subscribe mis-send... I should know better than to do anything before a second cup of coffee in the A.M. :->) I have just finished reading both the above mentioned draft and the draft - draft-ietf-ipfc-fcoverip-02.txt I think that Douglas did a nice job of summarizing some of the benefits that FC over SCTP/IP can gain in this draft i.e.: - Headers contained within one frame. - Objects aligned at 32-bit boundaries. - Out of sequence frame processing. - Standard authentication. - Independent streams under common control. - Session restart. - Improved error detection. - Prevention of blind spoofing and denial of service attacks. - Standard Heartbeat and multi-homing. (optional) One other things not mentioned was: - Congestion control Now after reviewing the ipfc-fcoverip draft particularly the section that specifies why TCP should not be used, there may be objections to the Otis draft... One of problems mentioned in ipfc-fcoverip is the retransmission by TCP being in conflict to retransmissions that would occur at the FC level. I would like to call your attention to a draft that I think will solve this problem... http://search.ietf.org/internet-drafts/draft-xie-stewart-usctp-00.txt This draft defines a new extension that we have proposed for SCTP that allows a particular stream to be specified has "no retransmission". This way you can mix both completly reliable and unreliable transmissions over the same association AND still maintain correct congestion control policy's in the network. We still are debating the addition of a couple of things to this draft: - Should we have the ability to turn off checksums on selected data portions traveling on a stream. This way one could disable the alder-32 checksum on a unreliable stream packet but not the header, control, or any reliable data. - How do you handle larger than the P-MTU sized messages? Currently the draft dis-allows this since when sending to an unreliable stream you can never re-assemble the larger packet if a piece of one is lost. We may want to think about adding the ability to still fragment and hook in a mechanism to the reliable re-assembly queues to discard in-complete reassembly's where some datagrams are dropped due to the unreliable transmission. This would be desireable to keep from having to do a double P-MTU discover (one at the SCTP layer and the other at the IPFC layer). We would appreciate any comments on the draft and I would be more than glad to present either here on the mailing list or in San Diego a short overview of both SCTP or SCTP-U if this is helpful... Thanks for your time and I would welcome any comments or questions.. R -- Randall R. Stewart randall@stewart.chicago.il.us or rrs@cisco.com 815-342-5222 From owner-ipfc@standards.gadzoox.com Thu Aug 24 12:48:47 2000 Received: from standards.gadzoox.com (standards.gadzoox.com [216.52.31.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20341 for ; Thu, 24 Aug 2000 12:48:46 -0400 (EDT) Received: (from majordom@localhost) by standards.gadzoox.com (8.8.7/8.8.7) id IAA19341 for ipfc-list; Thu, 24 Aug 2000 08:31:28 -0700 X-Authentication-Warning: standards.gadzoox.com: majordom set sender to owner-ipfc@standards.gadzoox.com using -f Received: from ludwig.troikanetworks.com (host03.troikanetworks.com [12.31.172.3] (may be forged)) by standards.gadzoox.com (8.8.7/8.8.7) with SMTP id IAA19338 for ; Thu, 24 Aug 2000 08:31:25 -0700 Received: by host03.troikanetworks.com with Internet Mail Service (5.5.2650.21) id ; Thu, 24 Aug 2000 09:42:01 -0700 Message-ID: From: Wayland Jeong To: "'Randall R. Stewart'" , ipfc@standards.gadzoox.com Subject: RE: draft-otis-fc-sctp-ip-00.txt Date: Thu, 24 Aug 2000 09:41:53 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipfc@standards.gadzoox.com Precedence: bulk [ stuff deleted ] > Now after reviewing the ipfc-fcoverip draft particularly the > section that specifies why TCP should not be used, there may > be objections to the Otis draft... > > One of problems mentioned in ipfc-fcoverip is the retransmission > by TCP being in conflict to retransmissions that would occur > at the FC level. I would like to call your attention to a > draft that I think will solve this problem... > > http://search.ietf.org/internet-drafts/draft-xie-stewart-usctp-00.txt > > This draft defines a new extension that we have proposed for SCTP > that allows a particular stream to be specified has "no retransmission". > This way you can mix both completly reliable and unreliable > transmissions > over the same association AND still maintain correct congestion control > policy's in the network. We still are debating the addition of > a couple of things to this draft: > The problem with this is that you don't want to rely on an I/O level retry to solve congestion problems in the network. If frames are being dropped due to congestion issues in the network (i.e. WRED) then having SCSI suffer a timeout and retry an entire I/O will help exacerbate congestion issues and bring performance to its knees. Depending on the traffic type, an I/O level retry may result in a 64K block retransmission after a timeout which is on the order of seconds. Unless you can absolutely rely on diffserv and/or RSVP or some other QoS mechanism to guarantee reliable delivery, the overall SCSI performance will suffer. I guess you can solve the problem with a well-tuned private network or a bandwidth matched WAN link, but this can be expensive and takes away from the business case for this technology. I think that any protocol which cannot tolerate lost data must have a reliable transport underneath it in order to achieve performance over gigabit networks. I'm not all that familiar with SCTP, but I thought that one of the features that would be useful is the capability of using SACK and message numbers to implement selective retransmission. It seems like, for storage, if we use SCTP as the transport, we want retransmission. -Wayland From owner-ipfc@standards.gadzoox.com Thu Aug 24 13:23:52 2000 Received: from standards.gadzoox.com (standards.gadzoox.com [216.52.31.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20899 for ; Thu, 24 Aug 2000 13:23:51 -0400 (EDT) Received: (from majordom@localhost) by standards.gadzoox.com (8.8.7/8.8.7) id JAA19394 for ipfc-list; Thu, 24 Aug 2000 09:06:30 -0700 X-Authentication-Warning: standards.gadzoox.com: majordom set sender to owner-ipfc@standards.gadzoox.com using -f Received: from stewart.chicago.il.us (root@3ff83343.dsl.flashcom.net [63.248.51.67]) by standards.gadzoox.com (8.8.7/8.8.7) with SMTP id JAA19391 for ; Thu, 24 Aug 2000 09:06:27 -0700 Received: from stewart.chicago.il.us (IDENT:randall@stewart.chicago.il.us [10.1.1.1]) by stewart.chicago.il.us (8.9.3/8.8.7) with ESMTP id MAA13468; Thu, 24 Aug 2000 12:16:33 -0500 Message-ID: <39A55871.F237BB17@stewart.chicago.il.us> Date: Thu, 24 Aug 2000 12:16:33 -0500 From: "Randall R. Stewart" X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: Wayland Jeong CC: ipfc@standards.gadzoox.com Subject: Re: draft-otis-fc-sctp-ip-00.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipfc@standards.gadzoox.com Precedence: bulk Content-Transfer-Encoding: 7bit Wayland Jeong wrote: > > [ stuff deleted ] > > > Now after reviewing the ipfc-fcoverip draft particularly the > > section that specifies why TCP should not be used, there may > > be objections to the Otis draft... > > > > One of problems mentioned in ipfc-fcoverip is the retransmission > > by TCP being in conflict to retransmissions that would occur > > at the FC level. I would like to call your attention to a > > draft that I think will solve this problem... > > > > http://search.ietf.org/internet-drafts/draft-xie-stewart-usctp-00.txt > > > > This draft defines a new extension that we have proposed for SCTP > > that allows a particular stream to be specified has "no retransmission". > > This way you can mix both completly reliable and unreliable > > transmissions > > over the same association AND still maintain correct congestion control > > policy's in the network. We still are debating the addition of > > a couple of things to this draft: > > > > The problem with this is that you don't want to rely on an I/O level retry > to solve congestion problems in the network. If frames are being dropped due > to congestion issues in the network (i.e. WRED) then having SCSI suffer > a timeout and retry an entire I/O will help exacerbate congestion issues > and bring performance to its knees. Depending on the traffic type, an I/O > level retry may result in a 64K block retransmission after a timeout which > is on the order of seconds. Unless you can absolutely rely on diffserv > and/or RSVP or some other QoS mechanism to guarantee reliable delivery, > the overall SCSI performance will suffer. > The point of the u-sctp draft is that you DO NOT retransmit the data. You let the upper layer do it (if it so desires). Instead you drop your cwnd (as normal) and move forward the cumulative TSN point. There is NO retransmission on a u-sctp stream. Now we also did not specify in this draft if the upper layer should be informed of data not making it to the peer.. this may be a good thing to add ... > I guess you can solve the problem with a well-tuned private network or a > bandwidth matched WAN link, but this can be expensive and takes away > from the business case for this technology. > > I think that any protocol which cannot tolerate lost data must have a > reliable > transport underneath it in order to achieve performance over gigabit > networks. > I'm not all that familiar with SCTP, but I thought that one of the features > that would be useful is the capability of using SACK and message numbers > to implement selective retransmission. It seems like, for storage, if we use > SCTP as the transport, we want retransmission. Hmm. thats an option as well.. but if you look at: http://www.ietf.org/internet-drafts/draft-ietf-ipfc-fcoverip-02.txt it specifically states that you DO NOT want retransmission... In either case a SCTP endpoint that supported u-sctp and sctp would be able to have retransmission turned on OR turned off, on any particular stream... and it would be able to have one association doing both at the same time :-> You basically can have it any way you want it :-) R > > -Wayland -- Randall R. Stewart randall@stewart.chicago.il.us or rrs@cisco.com 815-342-5222 From owner-ipfc@standards.gadzoox.com Thu Aug 24 22:43:48 2000 Received: from standards.gadzoox.com (standards.gadzoox.com [216.52.31.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28918 for ; Thu, 24 Aug 2000 22:43:47 -0400 (EDT) Received: (from majordom@localhost) by standards.gadzoox.com (8.8.7/8.8.7) id SAA19638 for ipfc-list; Thu, 24 Aug 2000 18:26:57 -0700 X-Authentication-Warning: standards.gadzoox.com: majordom set sender to owner-ipfc@standards.gadzoox.com using -f Received: from ludwig.troikanetworks.com (host03.troikanetworks.com [12.31.172.3] (may be forged)) by standards.gadzoox.com (8.8.7/8.8.7) with SMTP id SAA19635 for ; Thu, 24 Aug 2000 18:26:53 -0700 Received: by host03.troikanetworks.com with Internet Mail Service (5.5.2650.21) id ; Thu, 24 Aug 2000 19:37:29 -0700 Message-ID: From: Wayland Jeong To: "'Marjorie Krueger'" , "Randall R. Stewart" Cc: Wayland Jeong , ipfc@standards.gadzoox.com Subject: RE: draft-otis-fc-sctp-ip-00.txt Date: Thu, 24 Aug 2000 19:37:28 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipfc@standards.gadzoox.com Precedence: bulk > It seems like people are missing the intended application of FCoverIP - namely, a > switching device, NOT an endpoint. Switching devices are not aware of the > protocol running over FC and must treat every FC packet similarly. SCSI is only > one application that runs over FC. An FCoverIP device can't selectively decide to > retransmit a packet without implementing some pretty complicated policies, and > looking into the headers of each packet, which would degrade performance so much > that it's questionable whether this would be a feasable application at all. This > has been discussed somewhat on the IPS reflector. > Layer 4 through layer 7 LAN switches exist today (Foundry, Alteon, Extreme, etc.) that inspect deep into each packet and make wire-speed decisions about how to service the data. There are routers and firewalls which terminate TCP and thus run entire stacks in the box. I'm not saying that it is trivial to design a port that can keep-up with the wire and run a session protocol in hardware, but it is not out of the question. If it was, iSCSI would be doomed as a high-performance gigabit solution (and that is an entirely different argument). I guess, what I'm trying to say is that someone should clearly state the requirements for FCoverIP. If the requirements are that it simply run on a private tuned network which can virtually guarantee a loss-less medium, then I would argue that we don't need congestion control and hence a retry mechanism. I would also argue that FCoverIP is a niche, proprietary solution which probably does not belong in IETF since it is not intended for the internet. If the requirement is that FCoverIP must co-exist with other LAN/WAN traffic, then I would argue that at a minimum we need a congestion management scheme since the networks depend on it. If we have a need for congestion management that implies that things are getting dropped (unless QoS ensures that does not happen.). And if things are getting dropped, then retries at the SCSI I/O level could severely limit performance. That was the convoluted reason for my comments about needing to have a retry mechanism. I believe that you need a reliable medium for transporting any SCSI-based protocol. > Marjorie Krueger > Vixel Corporation > -Wayland From owner-ipfc@standards.gadzoox.com Fri Aug 25 04:51:48 2000 Received: from standards.gadzoox.com (standards.gadzoox.com [216.52.31.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14495 for ; Fri, 25 Aug 2000 04:51:47 -0400 (EDT) Received: (from majordom@localhost) by standards.gadzoox.com (8.8.7/8.8.7) id AAA19800 for ipfc-list; Fri, 25 Aug 2000 00:34:58 -0700 X-Authentication-Warning: standards.gadzoox.com: majordom set sender to owner-ipfc@standards.gadzoox.com using -f Received: from stewart.chicago.il.us (root@3ff83343.dsl.flashcom.net [63.248.51.67]) by standards.gadzoox.com (8.8.7/8.8.7) with SMTP id AAA19797 for ; Fri, 25 Aug 2000 00:34:54 -0700 Received: from stewart.chicago.il.us (IDENT:randall@stewart.chicago.il.us [10.1.1.1]) by stewart.chicago.il.us (8.9.3/8.8.7) with ESMTP id DAA15705; Fri, 25 Aug 2000 03:44:54 -0500 Message-ID: <39A63206.503C6A14@stewart.chicago.il.us> Date: Fri, 25 Aug 2000 03:44:54 -0500 From: "Randall R. Stewart" X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: Wayland Jeong CC: "'Marjorie Krueger'" , ipfc@standards.gadzoox.com Subject: Re: draft-otis-fc-sctp-ip-00.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipfc@standards.gadzoox.com Precedence: bulk Content-Transfer-Encoding: 7bit Wayland: My sole reason for pointing out the unreliable/non-retransmit option of SCTP is because of a working group document. In the document it is very very specific and states that the WG does not like TCP because of the retransmit storms that can occur if TCP and the FC layer both retransmit. I simply offered a solution, and since SCTP could offer both non-retransmit and retransmit it takes this argument off the table... Other comments in-line below: Wayland Jeong wrote: > > > It seems like people are missing the intended application of FCoverIP - > namely, a > > switching device, NOT an endpoint. Switching devices are not aware of the > > protocol running over FC and must treat every FC packet similarly. SCSI > is only > > one application that runs over FC. An FCoverIP device can't selectively > decide to > > retransmit a packet without implementing some pretty complicated policies, > and > > looking into the headers of each packet, which would degrade performance > so much > > that it's questionable whether this would be a feasable application at > all. This > > has been discussed somewhat on the IPS reflector. > > > Layer 4 through layer 7 LAN switches exist today (Foundry, Alteon, Extreme, > etc.) that > inspect deep into each packet and make wire-speed decisions about how to > service the > data. There are routers and firewalls which terminate TCP and thus run > entire stacks in > the box. I'm not saying that it is trivial to design a port that can keep-up > with the wire and > run a session protocol in hardware, but it is not out of the question. If it > was, iSCSI would > be doomed as a high-performance gigabit solution (and that is an entirely > different argument). > > I guess, what I'm trying to say is that someone should clearly state the > requirements for > FCoverIP. If the requirements are that it simply run on a private tuned > network which can > virtually guarantee a loss-less medium, then I would argue that we don't > need congestion > control and hence a retry mechanism. I would also argue that FCoverIP is a > niche, proprietary > solution which probably does not belong in IETF since it is not intended for > the internet. > If you ARE on a private net, even if Congestion Control is in place it SHOULD never be engaged. Here a SCTP with non-retransmit will help you. You never have the danger of a retransmit storm, and the fact that your network IS so reliable means you never get the CC algorithms working against you . Also if someone makes a mistake, and puts a private configuration across the big I-Internet it provides a protection.. > If the requirement is that FCoverIP must co-exist with other LAN/WAN > traffic, then I would > argue that at a minimum we need a congestion management scheme since the > networks > depend on it. If we have a need for congestion management that implies that > things are > getting dropped (unless QoS ensures that does not happen.). And if things > are getting > dropped, then retries at the SCSI I/O level could severely limit > performance. And here, no matter what the performance level, one could turn on the reliable side transport of SCTP since it IS on a WAN and the retransmit on the SCTP level would save you from hitting SCSI I/O retransmits.. > > That was the convoluted reason for my comments about needing to have a retry > mechanism. > I believe that you need a reliable medium for transporting any SCSI-based > protocol. > > > Marjorie Krueger > > Vixel Corporation > > > > -Wayland R -- Randall R. Stewart randall@stewart.chicago.il.us or rrs@cisco.com 815-342-5222 From owner-ipfc@standards.gadzoox.com Fri Aug 25 12:45:08 2000 Received: from standards.gadzoox.com (standards.gadzoox.com [216.52.31.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24415 for ; Fri, 25 Aug 2000 12:45:07 -0400 (EDT) Received: (from majordom@localhost) by standards.gadzoox.com (8.8.7/8.8.7) id IAA20181 for ipfc-list; Fri, 25 Aug 2000 08:26:26 -0700 X-Authentication-Warning: standards.gadzoox.com: majordom set sender to owner-ipfc@standards.gadzoox.com using -f Received: from lightsand.com ([208.50.99.84]) by standards.gadzoox.com (8.8.7/8.8.7) with SMTP id IAA20178 for ; Fri, 25 Aug 2000 08:26:21 -0700 Received: from muralir (dhcp074.lightsand.com [192.168.1.74]) by lightsand.com (8.9.3+Sun/8.9.1) with SMTP id JAA29392 for ; Fri, 25 Aug 2000 09:36:07 -0700 (PDT) From: "Murali Rajagopal" To: "IPFC" Subject: FINAL IPFC WG Pittsuburgh Draft Minutes Date: Fri, 25 Aug 2000 09:36:05 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Sender: owner-ipfc@standards.gadzoox.com Precedence: bulk Content-Transfer-Encoding: 7bit Note: All Presentations at this meeting will be made available with IETF Proceedings. The following is the final minutes of the Pittsuburgh Meeting. Agenda: 1)RFC 2625 UNH Test Report - Raj Bhagwat, LightSand Communications Raj presented the UNH testing results and indicated that 6 companies (Qlogic, Emulex, Brocade, Sun, Crossroads, Interphase)had participated in the testing. A matrix of the test suites versus partcipating companies was briefly presented. It was indicated that the details of the testing could be found at the UNH test site www.iol.unh.edu/testsuites/fc/IP_over_FC.html Next Step is to submit with modifications for DRAFT STD consideration. 2)MIB Status - a)draft-ietf-ipfc-mib-framework-02.txt : Mark Carlson, SUN Microsystems Mark indicated that the document was complete and is ready for starting the process of submitting it as an Informational RFC. The Chair (Murali) indicated that the draft will sent to WG for Last Call comments. b)Draft-ietf-ipfc-fcmgmt-int-mib-04.txt: Jack Hardwood, EMC Corp. Jack stated that the work was undergoing formatting changes only with no technical content change. Jack explained the reason for the delay in completing this work due to the formatting changes and was targeted for completion around the Dec 2000 time frame. c) RFC 2837 "Definitions of Managed Objects for the Fabric Element in FC Standard" - is now a PROPOSED STD d)Storage Library MIB (SNIA) still an unapproved work item from the Australia WG meeting. 3) FC Over IP - draft-ietf-ipfc-fcoverip-02.txt - Raj Bhagwat, LightSand Comm., Elizabeth Rodriguez, Lucent Tech This presenatation was not a formal work item under this group. At this time, it was still debated as to where it belongs. The presentation was essentially a repeat from the last IETF meeting but was presented by Elizabeth (Lucent) with some updates from the latest draft. The attachement provides the details of the presentation, but much discussion in the room was centered around retransmission of frames if a Transport level protocol were to be used (TCP), and its effects on the overall FC end-to-end transport. Lack of Congestion Control was brought up as an issue and it was pointed out that inclusion of this work item under IPS WG would be beneficial. Murali Rajagopal IPFC WG Chair LightSand Communications muralir@lightsand.com 408-941-2010 x164 From owner-ipfc@standards.gadzoox.com Fri Aug 25 18:49:03 2000 Received: from standards.gadzoox.com (standards.gadzoox.com [216.52.31.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01318 for ; Fri, 25 Aug 2000 18:49:02 -0400 (EDT) Received: (from majordom@localhost) by standards.gadzoox.com (8.8.7/8.8.7) id OAA20343 for ipfc-list; Fri, 25 Aug 2000 14:31:57 -0700 X-Authentication-Warning: standards.gadzoox.com: majordom set sender to owner-ipfc@standards.gadzoox.com using -f Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [168.159.208.81]) by standards.gadzoox.com (8.8.7/8.8.7) with SMTP id OAA20340 for ; Fri, 25 Aug 2000 14:31:53 -0700 From: Black_David@emc.com Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2448.0) id ; Fri, 25 Aug 2000 18:41:59 -0400 Message-ID: <0F31E5C394DAD311B60C00E029101A0704100F0D@corpmx9.isus.emc.com> To: ips@ece.cmu.edu, ipfc@standards.gadzoox.com Subject: RE: draft-otis-fc-sctp-ip-00.txt Date: Fri, 25 Aug 2000 18:41:58 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-ipfc@standards.gadzoox.com Precedence: bulk A couple of comments: - This discussion should be moved onto the ips mailing list (ips@ece.cmu.edu) as further IETF work on FC-over-IP will occur there. Despite it's name, the fcoverip draft has not been an official work item of the ipfc WG. The use of the ipfc list rather than ips is completely understandable, as the draft was misnamed, nonetheless, further discussion should be on ips. - Wayland wrote: > I guess, what I'm trying to say is that someone should clearly state the requirements for > FCoverIP. If the requirements are that it simply run on a private tuned network which can > virtually guarantee a loss-less medium, then I would argue that we don't need congestion > control and hence a retry mechanism. I would also argue that FCoverIP is a niche, proprietary > solution which probably does not belong in IETF since it is not intended for the internet. Not only is that a good argument, it is in fact basically the position of the IETF, as conveyed by the Area Directors to the authors of the FC-over-IP draft - congestion control is REQUIRED if the work is to advance in the IETF because otherwise the protocol would be unsuitable for the internet. Whether to have a retry mechanism is an engineering decision that can be made as the work progresses (an implementation that didn't have to buffer for retransmission might consume less memory than one that did), but congestion control is REQUIRED, period. Thanks, --David (co-chair of the ips WG-to-be) p.s. For those on ips and not ipfc, I'm going to forward the ipfc discussion in a separate message. --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140, FAX: +1 (508) 497-6909 black_david@emc.com Cellular: +1 (978) 394-7754 --------------------------------------------------- From owner-ipfc@standards.gadzoox.com Sun Aug 27 18:14:58 2000 Received: from standards.gadzoox.com (standards.gadzoox.com [216.52.31.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12492 for ; Sun, 27 Aug 2000 18:14:58 -0400 (EDT) Received: (from majordom@localhost) by standards.gadzoox.com (8.8.7/8.8.7) id NAA21639 for ipfc-list; Sun, 27 Aug 2000 13:58:56 -0700 X-Authentication-Warning: standards.gadzoox.com: majordom set sender to owner-ipfc@standards.gadzoox.com using -f Received: from lightsand.com ([208.50.99.84]) by standards.gadzoox.com (8.8.7/8.8.7) with SMTP id NAA21636 for ; Sun, 27 Aug 2000 13:58:52 -0700 Received: from lightsand.com (cx418298-b.orng1.occa.home.com [24.1.179.117]) by lightsand.com (8.9.3+Sun/8.9.1) with ESMTP id PAA16149; Sun, 27 Aug 2000 15:08:36 -0700 (PDT) Message-ID: <39A9931E.3AD34D80@lightsand.com> Date: Sun, 27 Aug 2000 15:15:58 -0700 From: Murali Rajagopal Organization: @lightsand.com X-Mailer: Mozilla 4.5 [en]C-AtHome0405 (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: ipfc@standards.gadzoox.com CC: fc@network.com, Scott Bradner , "Black_David@emc.com" , Thomas Narten , mankin@isi.edu, Erik.Nordmark@eng.sun.com Subject: Adresss Change and IPOverFC Status Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipfc@standards.gadzoox.com Precedence: bulk Content-Transfer-Encoding: 7bit Dear IPFC WG Members: Please note the change in my company affiliation, address and phone. Murali Rajagopal LightSand Communications 375 Los Coches Street Milpitas, CA 95035 Phone: 408-941-2010 x164 muralir@lightsand.com I will continue to be the IPFC WG Chair. The exact home for FCoverIP work is under consideration by both the INTERNET and TRANSPORT Groups. It is quite likely that it may be under the IPStorage WG with (Fibre Channel rep.) Co-Chairs. A decision is expected to come in sometime in the near future. The T11 FC-BB WG is expected to leverage the work coming out of the IETF. At this time there is a requirement from the Transport Area to add Congestion Control/Management to the current FCoverIP work. However, there is NO mandate to add a formal Transport Protocol. The authors of the current FCOverIP draft are currently considering alternatives to address the Congestion requirement. In this process, they are also looking at available Transport protocols that can satisfy the congestion Managment/Control requirements. I'll keep you'll posted on any new developments. Regards, Murali Rajagopal IPFC WG Chair From owner-ipfc@standards.gadzoox.com Sun Aug 27 20:38:19 2000 Received: from standards.gadzoox.com (standards.gadzoox.com [216.52.31.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13346 for ; Sun, 27 Aug 2000 20:38:18 -0400 (EDT) Received: (from majordom@localhost) by standards.gadzoox.com (8.8.7/8.8.7) id QAA21747 for ipfc-list; Sun, 27 Aug 2000 16:22:11 -0700 X-Authentication-Warning: standards.gadzoox.com: majordom set sender to owner-ipfc@standards.gadzoox.com using -f Received: from mailgate.sbell.com.cn (mailgate.sbell.com.cn [202.96.203.173]) by standards.gadzoox.com (8.8.7/8.8.7) with SMTP id QAA21744 for ; Sun, 27 Aug 2000 16:22:05 -0700 Received: from bellnet-mail3.sbell.com.cn (bellnet-mail3.sbell.com.cn [202.96.203.172]) by mailgate.sbell.com.cn (8.9.2/8.9.2) with ESMTP id IAA13378 for ; Mon, 28 Aug 2000 08:25:28 +0800 (CST) Received: by bellnet-mail3.sbell.com.cn with Internet Mail Service (5.5.2448.0) id ; Mon, 28 Aug 2000 08:33:17 +0800 Message-ID: <77D4835D5290D111B8CC00805FE6AAD502F77E30@bellnet-mail1.sbell.com.cn> From: SRD Zhao Xin To: ipfc@standards.gadzoox.com Subject: unsubscribe Date: Mon, 28 Aug 2000 08:31:01 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="GB2312" Sender: owner-ipfc@standards.gadzoox.com Precedence: bulk > Best regards, > > *************************************** > Zhaoxin > Email: zhaoxin@sbell.com.cn > Tel: 0086-21-58541240-7789 > Add: RM.C701 > Building 388, Ningqiao Road, > Pudong, Shanghai, P.R.China > *************************************** > > From owner-ipfc@standards.gadzoox.com Mon Aug 28 20:19:06 2000 Received: from standards.gadzoox.com (standards.gadzoox.com [216.52.31.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22603 for ; Mon, 28 Aug 2000 20:19:03 -0400 (EDT) Received: (from majordom@localhost) by standards.gadzoox.com (8.8.7/8.8.7) id QAA22521 for ipfc-list; Mon, 28 Aug 2000 16:02:13 -0700 X-Authentication-Warning: standards.gadzoox.com: majordom set sender to owner-ipfc@standards.gadzoox.com using -f Received: from ihemail2.firewall.lucent.com (ihemail2.lucent.com [192.11.222.163]) by standards.gadzoox.com (8.8.7/8.8.7) with SMTP id QAA22518 for ; Mon, 28 Aug 2000 16:02:07 -0700 Received: from ihemail2.firewall.lucent.com (localhost [127.0.0.1]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id UAA27846 for ; Mon, 28 Aug 2000 20:12:23 -0400 (EDT) Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id UAA27831 for ; Mon, 28 Aug 2000 20:12:23 -0400 (EDT) Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2650.21) id ; Mon, 28 Aug 2000 19:12:23 -0500 Message-ID: <80B684C5E29FD211AA8000A0C9CDD91904D098BE@il0015exch005u.ih.lucent.com> From: "Rodriguez, Elizabeth G (Elizabeth)" To: "'ipfc@standards.gadzoox.com'" , "'ips@ece.cmu.edu'" Cc: "'marjorie.krueger@vixel.com'" , "'rajb@lightsand.com'" , "'muralir@lightsand.com'" Subject: FC over IP: Requirements Date: Mon, 28 Aug 2000 19:12:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipfc@standards.gadzoox.com Precedence: bulk Hello all, The authors of the FC over IP draft are still in the process of trying to reformulate the requirements for the FC over IP draft. In addition, (according to what I have been told), the decision for where the FC over IP work item is to be hosted is still being discussed. It may be placed in the IPS working group, or the decision may be made to place it elsewhere. In order to try to minimize confusion, the other authors and I have been talking offline, while monitoring these lists. That said, we list below some of what we (the authors of the FC over IP draft) have been talking about wrt FC over IP requirements: The basic premise of the FC over IP draft remains unchanged -- Have a high speed IP based interconnect which will bridge FC traffic between two (or more) SAN islands, such that only the edge devices are aware of the fact that tunneling of FC frames over IP is being performed. Included in the initial draft was the following assumption: The backbone would be at least as reliable and at least as fast as the FC fabric itself. With such a restriction, it was expected that congestion control would not be necessary. At the Pittsburgh meeting, it was mandated that FC over IP would include congestion management of some form. In addition, a few people have indicated that they expect that this would be run over a lower speed backbone than the fabric itself. So, we are investigating options, including looking at the various transport mechanisms, as well as other non-transport related mechanisms to perform congestion management. As mentioned before, FC over IP is intended (i.e. being written with the assumption that) this protocol will be implemented in a switch device. There will be no prohibitions against implementing in a different type of device, such as an edge device, it will simply not be optimized for implementation in an edge device. Keeping that a switch topology is the target, the addition of transport support/mechanism to an otherwise level 2 type switch seems to the authors to be expensive, especially if retries as specified in many of the transports is required. Expensive in terms of additional overhead to add the transport to every FC frame as well as additional hardware requirements. Another issues that needs to be considered w.r.t. use of a transport is a transport level retry mechanism. Some transports do not provide a means by which retries can be turned off, plus are dynamic in their timeout values (e.g. when retries are invoked). If retries are required to be handled in the transport due to transport design (e.g. we use a transport such as TCP, where retries cannot be turned off), we feel it may conflict with upper level exception handling (as mentioned in the 02 draft) as well as create a cost (financial as well as engineering wise) prohibitive requirement for buffering of packets at the FC over IP SWITCH while waiting for acknowledgements. This is especially when RTT can be on the order of seconds (e.g. approaches RA_TOV). It is for this very reason we are trying to consider the various options available to us. We are considering ECM, ECN, SCTP, TCP as well as other mechanisms. We are monitoring the iSCSI threads regarding Transport for their applicability to this draft as well. While we cannot guarantee that the FC over IP draft will follow the transport method iSCSI selects, it will be considered in the analysis for FC over IP. There has never been any intention for this draft to be constrained to a private network, though that is a possible/plausible environment. There was the assumption of a well engineered network though. This requirement is being omitted, due to both feedback from attendees of the ipfc presentation as well as direction from the ADs. Summary of Requirements for FC over IP (from the authors' perspective) First Draft: (1) FC and IP devices can be used in conjunction with an 'FC over IP' compliant edge device UNMODIFIED to bridge traffic between FC islands over an IP based backbone. (2) FC over IP compliant devices will support some form of congestion management. (3) FC over IP compliant devices will support authentication of the FC over IP devices before the tunnel shall be established. Other possible requirements, which will most likely be deferred to a follow on draft: (4) Dynamic discovery of other FC over IP edge devices. (5) Data Encryption support. Additional requirements are also being sought from the Fibre Channel community. A new effort has recently been chartered in the T11 organization, FC-BB2 (Fibre Channel BackBone 2). This group will be used to solicit further requirements for FC over IP. FC-BB2 will be a companion specification to FC over IP and will leverage work done in FC over IP. It will not redefine/conflict with FC over IP, but instead will identify and define amendments to certain FC documents/values to allow greater distance and performance to be attained over an FC over IP backbone. FC devices will not be required to be FC-BB2 compliant in order to work with FC over IP (this would violate the basic premise of this work), but should a customer choose to upgrade their FC network to comply with FC-BB2, they could expect better performance and longer distances to be attained. Specifically, media specific issues, speed of light vs. timeout issues, BB credit issues, among others will be addressed in this specification. Notes: (1) Indicates that FC devices CAN be used unmodified in conjunction with FC over IP. FC-BB2 will address FC specific issues, and will identify and define amendments to certain FC documents/values to allow for greater distance/performance to be attained. (2) Retries need to be addressed. It needs to be determined if retries support at the transport level, should a transport be included, need to be required, optional or prohibited. The authors believe much of this decision is dependent on how retries are defined by the selected transport. If it can be insured that the selected transport retry mechanism will not conflict with other retry mechanisms, then it may be valuable to support. On the other hand, if requirement of retry support makes the FC over IP device an unattractive solution, due to prohibitive costs associated with implementing retry, then it should not be supported. The authors plan to come back with recommendations as well as an initial FC over IP draft that addresses the new requirements. Please direct any feedback or input to the authors (egrodriguez@lucent.com, muralir@lightsand.com, rajb@lightsand.com, and marjorie.krueger@vixel.com) as well as to the ips(ips@ece.cmu.edu) and ipfc(ipfc@standards.gadzoox.com) mailing lists. Thanks, Elizabeth G. Rodriguez Marjorie Krueger Lucent Technologies Vixel Corporation Murali Rajagopal Raj Bhagwat LightSand Communications LightSand Communications -----Original Message----- From: Black_David@emc.com [mailto:Black_David@emc.com] Sent: Friday, August 25, 2000 5:42 PM To: ips@ece.cmu.edu; ipfc@standards.gadzoox.com Subject: RE: draft-otis-fc-sctp-ip-00.txt A couple of comments: - This discussion should be moved onto the ips mailing list (ips@ece.cmu.edu) as further IETF work on FC-over-IP will occur there. Despite it's name, the fcoverip draft has not been an official work item of the ipfc WG. The use of the ipfc list rather than ips is completely understandable, as the draft was misnamed, nonetheless, further discussion should be on ips. - Wayland wrote: > I guess, what I'm trying to say is that someone should clearly state the requirements for > FCoverIP. If the requirements are that it simply run on a private tuned network which can > virtually guarantee a loss-less medium, then I would argue that we don't need congestion > control and hence a retry mechanism. I would also argue that FCoverIP is a niche, proprietary > solution which probably does not belong in IETF since it is not intended for the internet. Not only is that a good argument, it is in fact basically the position of the IETF, as conveyed by the Area Directors to the authors of the FC-over-IP draft - congestion control is REQUIRED if the work is to advance in the IETF because otherwise the protocol would be unsuitable for the internet. Whether to have a retry mechanism is an engineering decision that can be made as the work progresses (an implementation that didn't have to buffer for retransmission might consume less memory than one that did), but congestion control is REQUIRED, period. Thanks, --David (co-chair of the ips WG-to-be) p.s. For those on ips and not ipfc, I'm going to forward the ipfc discussion in a separate message. --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140, FAX: +1 (508) 497-6909 black_david@emc.com Cellular: +1 (978) 394-7754 --------------------------------------------------- From owner-ipfc@standards.gadzoox.com Tue Aug 29 11:09:07 2000 Received: from standards.gadzoox.com (standards.gadzoox.com [216.52.31.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21028 for ; Tue, 29 Aug 2000 11:09:06 -0400 (EDT) Received: (from majordom@localhost) by standards.gadzoox.com (8.8.7/8.8.7) id GAA23098 for ipfc-list; Tue, 29 Aug 2000 06:48:50 -0700 X-Authentication-Warning: standards.gadzoox.com: majordom set sender to owner-ipfc@standards.gadzoox.com using -f Received: from lightsand.com ([208.50.99.84]) by standards.gadzoox.com (8.8.7/8.8.7) with SMTP id GAA23095 for ; Tue, 29 Aug 2000 06:48:45 -0700 Received: from lightsand.com (cx418298-b.orng1.occa.home.com [24.1.179.117]) by lightsand.com (8.9.3+Sun/8.9.1) with ESMTP id HAA28906; Tue, 29 Aug 2000 07:58:27 -0700 (PDT) Message-ID: <39ABD121.8DFE0A95@lightsand.com> Date: Tue, 29 Aug 2000 08:05:05 -0700 From: Murali Rajagopal Organization: @lightsand.com X-Mailer: Mozilla 4.5 [en]C-AtHome0405 (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: David Robinson CC: ipfc@standards.gadzoox.com, ips@ece.cmu.edu Subject: Re: FC over IP: Requirements References: <200008290042.RAA19306@ha10nwk.EBay.Sun.COM> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipfc@standards.gadzoox.com Precedence: bulk Content-Transfer-Encoding: 7bit David: The authors of FC Over IP draft see at least 3 distinct options. Briefly, this is what we think: 1. Make effective use of the Congestion Indicator (CE) bit from a modern ECN capable Router but without the use of any transport. This indicator will then be used as a feedback signal to the FC-IP device and will have a bearing on the FC BB credit control between this device and the upstream FC Switch. 2. Investigate the possible use of a subset of full TCP functionality that would suit the requirements of this application. 3. Similarly, investigate the posible use of a subset of SCTP. As you can tell, these are mutually exclusive and would be difficult to combine them. Regards, Murali Rajagopal muralir@lightSand.com David Robinson wrote: > > Elizabeth, > It is good to see you making progress on the FC over IP requirements. > As there is now another draft that is FC over IP (with SCTP as > the transport) published, is it possible that we can merge the > two efforts? I would not like to see as a result one protocol > to tunnel between two FC clouds and another to direct attach > FC to IP. > > Possible considerations are if there are mechanisms to adapt > one or the other draft to allow a merging? Are the transport level > retry mechanisms you discuss also going to be fundemental problems > with the SCTP proposal as well? If you do use TCP as a transport > will your solutions to congestion control etc be sufficient to > remove the need for SCTP? I would not like to see two groups > trying to solve the same problem independantly. > > -David > From owner-ipfc@standards.gadzoox.com Tue Aug 29 12:27:01 2000 Received: from standards.gadzoox.com (standards.gadzoox.com [216.52.31.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24573 for ; Tue, 29 Aug 2000 12:27:00 -0400 (EDT) Received: (from majordom@localhost) by standards.gadzoox.com (8.8.7/8.8.7) id IAA23184 for ipfc-list; Tue, 29 Aug 2000 08:09:15 -0700 X-Authentication-Warning: standards.gadzoox.com: majordom set sender to owner-ipfc@standards.gadzoox.com using -f Received: from stewart.chicago.il.us (root@3ff83343.dsl.flashcom.net [63.248.51.67]) by standards.gadzoox.com (8.8.7/8.8.7) with SMTP id IAA23181 for ; Tue, 29 Aug 2000 08:09:11 -0700 Received: from stewart.chicago.il.us (IDENT:randall@stewart.chicago.il.us [10.1.1.1]) by stewart.chicago.il.us (8.9.3/8.8.7) with ESMTP id LAA02988; Tue, 29 Aug 2000 11:19:27 -0500 Message-ID: <39ABE28E.BFF0AE11@stewart.chicago.il.us> Date: Tue, 29 Aug 2000 11:19:26 -0500 From: "Randall R. Stewart" X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: Murali Rajagopal CC: David Robinson , ipfc@standards.gadzoox.com, ips@ece.cmu.edu Subject: Re: FC over IP: Requirements References: <200008290042.RAA19306@ha10nwk.EBay.Sun.COM> <39ABD121.8DFE0A95@lightsand.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipfc@standards.gadzoox.com Precedence: bulk Content-Transfer-Encoding: 7bit Some thoughts and notes: Murali Rajagopal wrote: > > David: > > The authors of FC Over IP draft see at least 3 distinct options. > Briefly, this is what we think: > > 1. Make effective use of the Congestion Indicator (CE) bit from a modern > ECN capable Router but > without the use of any transport. This indicator will then be used as a > feedback signal to the > FC-IP device and will have a bearing on the FC BB credit control between > this device and the upstream > FC Switch. > To do ECN you need more than just the two bits provided in the IP header. You also need a method to communicate to your peer that you have seen the "congestion notification" at a given point in the data stream. This notification must be propagated back to the sender until the sender itself reduces its sending rate and sends forward an acknowledgement that it has done so. The RFC (RFC2481) can be very helpful if you have not read it. It is short and there are some tricks to implementing it... these make it most suitable for implemenation in a transport protocol. I think this is what you would be building to a minor degree if you choose this option. How well deployed and available this is, (in the network) is another question I can't answer. I do like useing ECN though, this is why the SCTP reference implementation comes ECN enabled... You may also need to answer the question of what do you do if ECN is not supported by the routers? Do you kill the iSCSI connection? How do you proceed... if you need to move forward then you must also add back in the TCP friendly congestion control... > 2. Investigate the possible use of a subset of full TCP functionality > that would suit the requirements > of this application. Hmm, you could gut TCP leaving in the congestion control and attempting to put message boundaries in. Look into getting rid of the head-of-line blocking issue (if you need to get around this). This is how SCTP got started and the end result is SCTP... You might possibly not need all the features in SCTP but the more you dig into a transport protocol the more you will find it involves more than you think :) > > 3. Similarly, investigate the posible use of a subset of SCTP. SCTP is fairly sub-settable. You do not have to understand how to do bundling and some of the other features. You do have to understand how to decode a bundle of chunks.. just not encode it. If one wants you can build an implemenation that eliminates the stream concept, by simply only asking for one stream and setting a limit of only one stream on all outbound association setups. I would think you may possibly want the unreliable transport extension that we are currently working on.. but this does seem a item for debate... in any event, it is always available if the WG decides it needs it(the unreliable extension)... In general I think if you dig in a bit you will find that SCTP is A) both extensible and B) can be kept to a minimum subset to some extent. I don't have a complete picture of all of the iSCSI requirments but I think IMHO you will find a closer fit in SCTP then you will in any of the other options... of course you knew I would say that :) R > > As you can tell, these are mutually exclusive and would be difficult to > combine them. > > Regards, > > Murali Rajagopal > > muralir@lightSand.com > > David Robinson wrote: > > > > Elizabeth, > > It is good to see you making progress on the FC over IP requirements. > > As there is now another draft that is FC over IP (with SCTP as > > the transport) published, is it possible that we can merge the > > two efforts? I would not like to see as a result one protocol > > to tunnel between two FC clouds and another to direct attach > > FC to IP. > > > > Possible considerations are if there are mechanisms to adapt > > one or the other draft to allow a merging? Are the transport level > > retry mechanisms you discuss also going to be fundemental problems > > with the SCTP proposal as well? If you do use TCP as a transport > > will your solutions to congestion control etc be sufficient to > > remove the need for SCTP? I would not like to see two groups > > trying to solve the same problem independantly. > > > > -David > > -- Randall R. Stewart randall@stewart.chicago.il.us or rrs@cisco.com 815-342-5222 From owner-ipfc@standards.gadzoox.com Tue Aug 29 18:33:09 2000 Received: from standards.gadzoox.com (standards.gadzoox.com [216.52.31.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02017 for ; Tue, 29 Aug 2000 18:33:08 -0400 (EDT) Received: (from majordom@localhost) by standards.gadzoox.com (8.8.7/8.8.7) id OAA23395 for ipfc-list; Tue, 29 Aug 2000 14:13:43 -0700 X-Authentication-Warning: standards.gadzoox.com: majordom set sender to owner-ipfc@standards.gadzoox.com using -f Received: from stewart.chicago.il.us (root@3ff83343.dsl.flashcom.net [63.248.51.67]) by standards.gadzoox.com (8.8.7/8.8.7) with SMTP id OAA23392 for ; Tue, 29 Aug 2000 14:13:40 -0700 Received: from stewart.chicago.il.us (IDENT:randall@stewart.chicago.il.us [10.1.1.1]) by stewart.chicago.il.us (8.9.3/8.8.7) with ESMTP id RAA01718; Tue, 29 Aug 2000 17:24:17 -0500 Message-ID: <39AC3811.ABAC273F@stewart.chicago.il.us> Date: Tue, 29 Aug 2000 17:24:17 -0500 From: "Randall R. Stewart" X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: Marjorie Krueger CC: ipfc@standards.gadzoox.com, ips@ece.cmu.edu Subject: Re: FC over IP: Requirements References: <200008290042.RAA19306@ha10nwk.EBay.Sun.COM> <39ABD121.8DFE0A95@lightsand.com> <39ABE28E.BFF0AE11@stewart.chicago.il.us> <39AC231E.10AD6D91@vixel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipfc@standards.gadzoox.com Precedence: bulk Content-Transfer-Encoding: 7bit Marjorie Krueger wrote: > > "Randall R. Stewart" wrote: > ..snip.. > > > I would think you may possibly want the unreliable transport extension > > that we are currently working on.. but this does seem a item for > > debate... in any event, it is always available if the WG decides it > > needs it(the unreliable extension)... > > What does the SCTP unreliable transport option offer that UDP doesn't? > > -Marjorie Something that is stated that you are required to have.. congestion control AND as a added benefit multi-homing. R -- Randall R. Stewart randall@stewart.chicago.il.us or rrs@cisco.com 815-342-5222