From owner-ipfc@standards.gadzoox.com Sun Sep 10 18:24:12 2000 Received: from standards.gadzoox.com (standards.gadzoox.com [216.52.31.24]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA10447 for ; Sun, 10 Sep 2000 18:24:12 -0400 (EDT) Received: (from majordom@localhost) by standards.gadzoox.com (8.8.7/8.8.7) id OAA30049 for ipfc-list; Sun, 10 Sep 2000 14:07:55 -0700 X-Authentication-Warning: standards.gadzoox.com: majordom set sender to owner-ipfc@standards.gadzoox.com using -f Received: from gateway.sequent.com (gateway.sequent.com [192.148.1.10]) by standards.gadzoox.com (8.8.7/8.8.7) with SMTP id OAA30046 for ; Sun, 10 Sep 2000 14:07:51 -0700 Received: from eng4.sequent.com (eng4.sequent.com [138.95.7.64]) by gateway.sequent.com (8.9.3/8.8.5) with ESMTP id PAA22592 for ; Sun, 10 Sep 2000 15:17:34 -0700 (PDT) Received: (from viv@localhost) by eng4.sequent.com (8.8.5/8.8.5/token.aware-1.2) id PAA25348 for ipfc@standards.gadzoox.com; Sun, 10 Sep 2000 15:17:32 -0700 (PDT) From: Vivek Kashyap Message-Id: <200009102217.PAA25348@eng4.sequent.com> Subject: FCIP and wandering duplicates To: ipfc@standards.gadzoox.com Date: Sun, 10 Sep 2000 15:17:32 -0700 (PDT) X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipfc@standards.gadzoox.com Precedence: bulk Content-Transfer-Encoding: 7bit I read the FCIP document recently. It does not address the issue of duplicates. Does fibre channel protect itself from duplicates ? I looked at the header and it does not have a time to live field. Thus a duplicate caught in a loop and then released at the 'right' time could be accepted by the receiver. Even if the FC fabric path algorithms do ensure loop free paths transient loops due to errors, switch misconfigurations or failures are possible. Does FC handle such a case ? If it does not then FCIP will exacerbate the problem because the IP network could have 'transient' loops. Such a 'wandering duplicate' could be re-injected into the FC island and be accepted by a newer incarnation of a FC inter-island exchange. Furthermore with no TTL one can't really provide a timout between starting two conversations. Vivek -- Vivek Kashyap IBM-NumaQ viv@sequent.com From owner-ipfc@standards.gadzoox.com Mon Sep 11 01:59:00 2000 Received: from standards.gadzoox.com (standards.gadzoox.com [216.52.31.24]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA20582 for ; Mon, 11 Sep 2000 01:58:59 -0400 (EDT) Received: (from majordom@localhost) by standards.gadzoox.com (8.8.7/8.8.7) id VAA30223 for ipfc-list; Sun, 10 Sep 2000 21:41:32 -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 VAA30220 for ; Sun, 10 Sep 2000 21:41:29 -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 WAA21288; Sun, 10 Sep 2000 22:51:08 -0700 (PDT) Message-ID: <002b01c01bb5$2228bea0$17940a18@msnv1.occa.home.com> Reply-To: "Raj Bhagwat" From: "Raj Bhagwat" To: "Vivek Kashyap" , Cc: References: <200009102217.PAA25348@eng4.sequent.com> Subject: Re: FCIP and wandering duplicates Date: Sun, 10 Sep 2000 22:57:12 -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 Vivek, In a properly implemented FC-only fabric, duplicates should not happen. A frame that enters a fabric should either be delivered within E_D_TOV (typically 2 sec) or be discarded. FC devices don't retransmit a frame before the E_D_TOV timer expires. You do bring up an interesting point when two SAN islands are bridged across an IP network. Once an FC frame enters the IP network, it is hard to say how the E_D_TOV is enforced by that part of the network. As authors of the FCoverIP draft, we have given some thought to the possibility of delivering duplicate frames when both the TCP stack at the FCIP gateway and the original FC device initiate recovery/retransmission procedure in an overlapping time period. This is one of the major reasons why we initially chose to make the FCIP gateway a stateless device with no buffering and no retransmission. The good news is that the {IP encapsulated} FC frame will be protected by the IP TTL once it enters the IP network. The bad news is that detecting the E_D_TOV timeout while the frame is inside the IP network may be difficult. Regards, Raj Bhagwat LightSand Communications ----- Original Message ----- From: Vivek Kashyap To: Sent: Sunday, September 10, 2000 3:17 PM Subject: FCIP and wandering duplicates > I read the FCIP document recently. It does not address the issue of > duplicates. > > Does fibre channel protect itself from duplicates ? I looked at the > header and it does not have a time to live field. Thus a duplicate > caught in a loop and then released at the 'right' time could be > accepted by the receiver. Even if the FC fabric path algorithms do > ensure loop free paths transient loops due to errors, switch > misconfigurations or failures are possible. Does FC handle such a case ? > > If it does not then FCIP will exacerbate the problem because the IP > network could have 'transient' loops. Such a 'wandering duplicate' > could be re-injected into the FC island and be accepted by a newer > incarnation of a FC inter-island exchange. Furthermore with no TTL one > can't really provide a timout between starting two conversations. > > > > Vivek > -- > Vivek Kashyap > IBM-NumaQ > viv@sequent.com > From owner-ipfc@standards.gadzoox.com Mon Sep 11 14:34:11 2000 Received: from standards.gadzoox.com (standards.gadzoox.com [216.52.31.24]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07627 for ; Mon, 11 Sep 2000 14:33:26 -0400 (EDT) Received: (from majordom@localhost) by standards.gadzoox.com (8.8.7/8.8.7) id KAA30743 for ipfc-list; Mon, 11 Sep 2000 10:16: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 KAA30740 for ; Mon, 11 Sep 2000 10:15:53 -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 LAA23159; Mon, 11 Sep 2000 11:25:02 -0700 (PDT) Message-ID: <009301c01c1e$741e18e0$17940a18@msnv1.occa.home.com> Reply-To: "Raj Bhagwat" From: "Raj Bhagwat" To: "Douglas Otis" , "Vivek Kashyap" , Cc: References: Subject: Re: FCIP and wandering duplicates Date: Mon, 11 Sep 2000 11:31:07 -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 Doug, Your point on TTL is well taken. It is there to prevent a packet from getting stuck in a routing loop. Duplicates of unicast packets can happen when the sender retransmits a packet and both the original and the retransmitted packets reach the destination. If the sender does not retransmit for an adequate amount of time, duplicates of unicast packets should not happen. This is true even when there are routing loops or topology changes in the network. As you have pointed out, there is no direct correlation between E_D_TOV and TTL. And that could be a problem. However, setting the TTL to a relatively smaller value (larger than the # of hops between the source and destination FCIP gateways) can reduce the possibility of duplicates when the sender of the FC frame waits for at least E_D_TOV before retransmitting the frame. I don't think SCTP at the FCIP gateway will solve the duplicate problem even with a single retry. There is no synchronization between the FC device and the FCIP gateway for error recovery. So, the FC device can retransmit independent of the SCTP at the FCIP gateway. One way to solve this problem is to fine tune the timeout values on the FC side and at the SCTP level on the FCIP gateway. Regards, Raj Bhagwat LightSand Communications ----- Original Message ----- From: Douglas Otis To: Raj Bhagwat ; Vivek Kashyap ; Cc: Sent: Monday, September 11, 2000 10:14 AM Subject: RE: FCIP and wandering duplicates > Raj, > > Unless you are willing to wrap the FC frame within some protocol, duplicates > can happen and this has nothing to do with TTL. TTL prevents circular paths > from forever sending a packet within a loop. A modified SCTP protocol that > will solve both of these problems, if restricted one time retry. A > Metro-Area-Network should induce about 5ms RTT delay such that a 10ms skew > becomes possible but is limited by the single retry. TTL buys you nothing > with this E_D_TOV, Error_Detect Timeout. > > Doug > > > -----Original Message----- > > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > > Raj Bhagwat > > Sent: Sunday, September 10, 2000 10:57 PM > > To: Vivek Kashyap; ipfc@standards.gadzoox.com > > Cc: ips@ece.cmu.edu > > Subject: Re: FCIP and wandering duplicates > > > > > > Vivek, > > > > In a properly implemented FC-only fabric, duplicates should not happen. A > > frame that enters a fabric should either be delivered within E_D_TOV > > (typically 2 sec) or be discarded. FC devices don't retransmit a frame > > before the E_D_TOV timer expires. > > > > You do bring up an interesting point when two SAN islands are > > bridged across > > an IP network. Once an FC frame enters the IP network, it is hard > > to say how > > the E_D_TOV is enforced by that part of the network. As authors of the > > FCoverIP draft, we have given some thought to the possibility of > > delivering > > duplicate frames when both the TCP stack at the FCIP gateway and the > > original FC device initiate recovery/retransmission procedure in an > > overlapping time period. This is one of the major reasons why we initially > > chose to make the FCIP gateway a stateless device with no buffering and no > > retransmission. > > > > The good news is that the {IP encapsulated} FC frame will be protected by > > the IP TTL once it enters the IP network. The bad news is that > > detecting the > > E_D_TOV timeout while the frame is inside the IP network may be difficult. > > > > Regards, > > > > Raj Bhagwat > > LightSand Communications > > > > > > ----- Original Message ----- > > From: Vivek Kashyap > > To: > > Sent: Sunday, September 10, 2000 3:17 PM > > Subject: FCIP and wandering duplicates > > > > > > > I read the FCIP document recently. It does not address the issue of > > > duplicates. > > > > > > Does fibre channel protect itself from duplicates ? I looked at the > > > header and it does not have a time to live field. Thus a duplicate > > > caught in a loop and then released at the 'right' time could be > > > accepted by the receiver. Even if the FC fabric path algorithms do > > > ensure loop free paths transient loops due to errors, switch > > > misconfigurations or failures are possible. Does FC handle such a case ? > > > > > > If it does not then FCIP will exacerbate the problem because the IP > > > network could have 'transient' loops. Such a 'wandering duplicate' > > > could be re-injected into the FC island and be accepted by a newer > > > incarnation of a FC inter-island exchange. Furthermore with no TTL one > > > can't really provide a timout between starting two conversations. > > > > > > > > > > > > Vivek > > > -- > > > Vivek Kashyap > > > IBM-NumaQ > > > viv@sequent.com > > > > > > > From owner-ipfc@standards.gadzoox.com Mon Sep 11 15:29:03 2000 Received: from standards.gadzoox.com (standards.gadzoox.com [216.52.31.24]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA08354 for ; Mon, 11 Sep 2000 15:28:14 -0400 (EDT) Received: (from majordom@localhost) by standards.gadzoox.com (8.8.7/8.8.7) id LAA30806 for ipfc-list; Mon, 11 Sep 2000 11:11:33 -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 LAA30803 for ; Mon, 11 Sep 2000 11:10:36 -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 MAA23380; Mon, 11 Sep 2000 12:19:44 -0700 (PDT) Message-ID: <00af01c01c26$18bdc9c0$17940a18@msnv1.occa.home.com> Reply-To: "Raj Bhagwat" From: "Raj Bhagwat" To: "Douglas Otis" , "Vivek Kashyap" , Cc: References: Subject: Re: FCIP and wandering duplicates Date: Mon, 11 Sep 2000 12:25:50 -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 Doug, I understand how exactly TTL is used. That is why I stated that TTL should be set to a value larger than the number of hops between the source and destination. An IP end station may not know this and it may choose to set the TTL to the max value of 255. However, an FCIP gateway, with some intelligence, can perhaps know the # of hops to other FCIP gateways it talks to, especially in enterprise networks. It is not clear to me how there can be duplicate frames without the source sending twice. Could you please explain that? Thanks, Raj. ----- Original Message ----- From: Douglas Otis To: Raj Bhagwat ; Vivek Kashyap ; Cc: Sent: Monday, September 11, 2000 11:53 AM Subject: RE: FCIP and wandering duplicates > Raj, > > You can see duplications without the source sending twice. Reducing TTL > value may prevent the packet from ever arriving. The number of times TTL is > decremented depends on the path and not time in transit. > > Doug > > > -----Original Message----- > > From: Raj Bhagwat [mailto:rajb@lightsand.com] > > Sent: Monday, September 11, 2000 11:31 AM > > To: Douglas Otis; Vivek Kashyap; ipfc@standards.gadzoox.com > > Cc: ips@ece.cmu.edu > > Subject: Re: FCIP and wandering duplicates > > > > > > Doug, > > > > Your point on TTL is well taken. It is there to prevent a packet from > > getting stuck in a routing loop. Duplicates of unicast packets can happen > > when the sender retransmits a packet and both the original and the > > retransmitted packets reach the destination. If the sender does not > > retransmit for an adequate amount of time, duplicates of unicast packets > > should not happen. This is true even when there are routing loops or > > topology changes in the network. > > > > As you have pointed out, there is no direct correlation between > > E_D_TOV and > > TTL. And that could be a problem. However, setting the TTL to a relatively > > smaller value (larger than the # of hops between the source and > > destination > > FCIP gateways) can reduce the possibility of duplicates when the sender of > > the FC frame waits for at least E_D_TOV before retransmitting the frame. > > > > I don't think SCTP at the FCIP gateway will solve the duplicate > > problem even > > with a single retry. There is no synchronization between the FC device and > > the FCIP gateway for error recovery. So, the FC device can retransmit > > independent of the SCTP at the FCIP gateway. One way to solve this problem > > is to fine tune the timeout values on the FC side and at the SCTP level on > > the FCIP gateway. > > > > Regards, > > > > Raj Bhagwat > > LightSand Communications > > > > > > ----- Original Message ----- > > From: Douglas Otis > > To: Raj Bhagwat ; Vivek Kashyap ; > > > > Cc: > > Sent: Monday, September 11, 2000 10:14 AM > > Subject: RE: FCIP and wandering duplicates > > > > > > > Raj, > > > > > > Unless you are willing to wrap the FC frame within some protocol, > > duplicates > > > can happen and this has nothing to do with TTL. TTL prevents circular > > paths > > > from forever sending a packet within a loop. A modified SCTP protocol > > that > > > will solve both of these problems, if restricted one time retry. A > > > Metro-Area-Network should induce about 5ms RTT delay such that > > a 10ms skew > > > becomes possible but is limited by the single retry. TTL buys > > you nothing > > > with this E_D_TOV, Error_Detect Timeout. > > > > > > Doug > > > > > > > -----Original Message----- > > > > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > > > > Raj Bhagwat > > > > Sent: Sunday, September 10, 2000 10:57 PM > > > > To: Vivek Kashyap; ipfc@standards.gadzoox.com > > > > Cc: ips@ece.cmu.edu > > > > Subject: Re: FCIP and wandering duplicates > > > > > > > > > > > > Vivek, > > > > > > > > In a properly implemented FC-only fabric, duplicates should > > not happen. > > A > > > > frame that enters a fabric should either be delivered within E_D_TOV > > > > (typically 2 sec) or be discarded. FC devices don't retransmit a frame > > > > before the E_D_TOV timer expires. > > > > > > > > You do bring up an interesting point when two SAN islands are > > > > bridged across > > > > an IP network. Once an FC frame enters the IP network, it is hard > > > > to say how > > > > the E_D_TOV is enforced by that part of the network. As authors of the > > > > FCoverIP draft, we have given some thought to the possibility of > > > > delivering > > > > duplicate frames when both the TCP stack at the FCIP gateway and the > > > > original FC device initiate recovery/retransmission procedure in an > > > > overlapping time period. This is one of the major reasons why we > > initially > > > > chose to make the FCIP gateway a stateless device with no > > buffering and > > no > > > > retransmission. > > > > > > > > The good news is that the {IP encapsulated} FC frame will be protected > > by > > > > the IP TTL once it enters the IP network. The bad news is that > > > > detecting the > > > > E_D_TOV timeout while the frame is inside the IP network may be > > difficult. > > > > > > > > Regards, > > > > > > > > Raj Bhagwat > > > > LightSand Communications > > > > > > > > > > > > ----- Original Message ----- > > > > From: Vivek Kashyap > > > > To: > > > > Sent: Sunday, September 10, 2000 3:17 PM > > > > Subject: FCIP and wandering duplicates > > > > > > > > > > > > > I read the FCIP document recently. It does not address the issue of > > > > > duplicates. > > > > > > > > > > Does fibre channel protect itself from duplicates ? I looked at the > > > > > header and it does not have a time to live field. Thus a duplicate > > > > > caught in a loop and then released at the 'right' time could be > > > > > accepted by the receiver. Even if the FC fabric path algorithms do > > > > > ensure loop free paths transient loops due to errors, switch > > > > > misconfigurations or failures are possible. Does FC handle > > such a case > > ? > > > > > > > > > > If it does not then FCIP will exacerbate the problem because the IP > > > > > network could have 'transient' loops. Such a 'wandering duplicate' > > > > > could be re-injected into the FC island and be accepted by a newer > > > > > incarnation of a FC inter-island exchange. Furthermore with > > no TTL one > > > > > can't really provide a timout between starting two conversations. > > > > > > > > > > > > > > > > > > > > Vivek > > > > > -- > > > > > Vivek Kashyap > > > > > IBM-NumaQ > > > > > viv@sequent.com > > > > > > > > > > > > > > > > > > > From owner-ipfc@standards.gadzoox.com Tue Sep 12 13:30:01 2000 Received: from standards.gadzoox.com (standards.gadzoox.com [216.52.31.24]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA10131 for ; Tue, 12 Sep 2000 13:30:01 -0400 (EDT) Received: (from majordom@localhost) by standards.gadzoox.com (8.8.7/8.8.7) id JAA31419 for ipfc-list; Tue, 12 Sep 2000 09:13:50 -0700 X-Authentication-Warning: standards.gadzoox.com: majordom set sender to owner-ipfc@standards.gadzoox.com using -f Received: from smtp1.cluster.oleane.net (smtp1.cluster.oleane.net [195.25.12.16]) by standards.gadzoox.com (8.8.7/8.8.7) with SMTP id JAA31416 for ; Tue, 12 Sep 2000 09:13:45 -0700 Received: from oleane (dyn-1-1-242.Vin.dialup.oleane.fr [195.25.4.242]) by smtp1.cluster.oleane.net with SMTP id TAA12500 for ; Tue, 12 Sep 2000 19:24:21 +0200 (CEST) Message-ID: <012501c01cdd$dfd062e0$7501a8c0@oleane.oleane.com> From: "Peter Lewis" To: Subject: IP over DWDM 2000 International Conference, Paris 27-30 November, 2000 Date: Tue, 12 Sep 2000 19:21:19 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0122_01C01CEE.A0CC1F60" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ipfc@standards.gadzoox.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0122_01C01CEE.A0CC1F60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This event aims at presenting an up-to-date state of the art in the = design of new Internet network architectures. It will be a unique = opportunity for researchers, network operators and service providers = from both the IP world and the optical networking world to discuss the = potentialities of all these promising perspectives.=20 http://www.upperside.fr/badwdm.htm ------=_NextPart_000_0122_01C01CEE.A0CC1F60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
This event aims at presenting an up-to-date state of the art in the = design=20 of new Internet network architectures. It will be a unique opportunity = for=20 researchers, network operators and service providers from both the IP = world and=20 the optical networking world to discuss the potentialities of all these=20 promising perspectives.
 
http://www.upperside.fr/badwd= m.htm
------=_NextPart_000_0122_01C01CEE.A0CC1F60-- From owner-ipfc@standards.gadzoox.com Tue Sep 12 18:35:32 2000 Received: from standards.gadzoox.com (standards.gadzoox.com [216.52.31.24]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14804 for ; Tue, 12 Sep 2000 18:34:47 -0400 (EDT) Received: (from majordom@localhost) by standards.gadzoox.com (8.8.7/8.8.7) id OAA31580 for ipfc-list; Tue, 12 Sep 2000 14:18:04 -0700 X-Authentication-Warning: standards.gadzoox.com: majordom set sender to owner-ipfc@standards.gadzoox.com using -f Received: from gateway.sequent.com (gateway.sequent.com [192.148.1.10]) by standards.gadzoox.com (8.8.7/8.8.7) with SMTP id OAA31577 for ; Tue, 12 Sep 2000 14:17:17 -0700 Received: from eng4.sequent.com (eng4.sequent.com [138.95.7.64]) by gateway.sequent.com (8.9.3/8.8.5) with ESMTP id PAA20234; Tue, 12 Sep 2000 15:26:45 -0700 (PDT) Received: (from viv@localhost) by eng4.sequent.com (8.8.5/8.8.5/token.aware-1.2) id PAA03330; Tue, 12 Sep 2000 15:26:43 -0700 (PDT) From: Vivek Kashyap Message-Id: <200009122226.PAA03330@eng4.sequent.com> Subject: Re: FCIP and wandering duplicates To: dotis@sanlight.net (Douglas Otis) Date: Tue, 12 Sep 2000 15:26:43 -0700 (PDT) Cc: rajb@lightsand.com (Raj Bhagwat), viv@sequent.com (Vivek Kashyap), ipfc@standards.gadzoox.com, ips@ece.cmu.edu In-Reply-To: from "Douglas Otis" at Sep 11, 2000 03:09:14 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipfc@standards.gadzoox.com Precedence: bulk Content-Transfer-Encoding: 7bit Raj, I am, after reading your and Doug's replies, still unclear whether FC handles duplicates or not. It appears to me that it does not. E_D_TOV seems to be a time out that is set for retransmission between end points. However, it is possible to introduce transient loops in the fabric when a topology change (addtion of a new switch or a link/switch going down) occurs, due to the re-calculation of paths unless such changes are made atomic to the traffic. In such a case there could be duplicates. Of course, if the FC switches are quiesced during the switch updates then loops won't matter. Or is there a different mechanism or an algorithm that guarantees looplessnes? TTL retuning will at most reduce the duplicates but can't guarantee elimination of duplicates. So if FC somehow guarantees duplicate free fabrics and does not handle duplicates then it appears to me that FCIP always will have the danger of corrupting data due to duplicates inserted by IP. Vivek > > Raj, > > I do not understand what tuning TTL does to benefit any situation. The path > between locations is not fixed so such tuning may induce lost packets and is > unrelated to time in transit. Depending on the domain, a packet may be > repeated by equipment that does not necessarily decrement TTL. Although not > a desired feature, duplication may happen if the packet transmit status is > made uncertain by local signaling. > > Doug > > > -----Original Message----- > > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > > Raj Bhagwat > > Sent: Monday, September 11, 2000 12:26 PM > > To: Douglas Otis; Vivek Kashyap; ipfc@standards.gadzoox.com > > Cc: ips@ece.cmu.edu > > Subject: Re: FCIP and wandering duplicates > > > > > > Doug, > > > > I understand how exactly TTL is used. That is why I stated that TTL should > > be set to a value larger than the number of hops between the source and > > destination. An IP end station may not know this and it may choose to set > > the TTL to the max value of 255. However, an FCIP gateway, with some > > intelligence, can perhaps know the # of hops to other FCIP > > gateways it talks > > to, especially in enterprise networks. > > > > It is not clear to me how there can be duplicate frames without the source > > sending twice. Could you please explain that? > > > > Thanks, > > > > Raj. > > > > ----- Original Message ----- > > From: Douglas Otis > > To: Raj Bhagwat ; Vivek Kashyap ; > > > > Cc: > > Sent: Monday, September 11, 2000 11:53 AM > > Subject: RE: FCIP and wandering duplicates > > > > > > > Raj, > > > > > > You can see duplications without the source sending twice. Reducing TTL > > > value may prevent the packet from ever arriving. The number of > > times TTL > > is > > > decremented depends on the path and not time in transit. > > > > > > Doug > > > > > > > -----Original Message----- > > > > From: Raj Bhagwat [mailto:rajb@lightsand.com] > > > > Sent: Monday, September 11, 2000 11:31 AM > > > > To: Douglas Otis; Vivek Kashyap; ipfc@standards.gadzoox.com > > > > Cc: ips@ece.cmu.edu > > > > Subject: Re: FCIP and wandering duplicates > > > > > > > > > > > > Doug, > > > > > > > > Your point on TTL is well taken. It is there to prevent a packet from > > > > getting stuck in a routing loop. Duplicates of unicast packets can > > happen > > > > when the sender retransmits a packet and both the original and the > > > > retransmitted packets reach the destination. If the sender does not > > > > retransmit for an adequate amount of time, duplicates of > > unicast packets > > > > should not happen. This is true even when there are routing loops or > > > > topology changes in the network. > > > > > > > > As you have pointed out, there is no direct correlation between > > > > E_D_TOV and > > > > TTL. And that could be a problem. However, setting the TTL to a > > relatively > > > > smaller value (larger than the # of hops between the source and > > > > destination > > > > FCIP gateways) can reduce the possibility of duplicates when > > the sender > > of > > > > the FC frame waits for at least E_D_TOV before retransmitting > > the frame. > > > > > > > > I don't think SCTP at the FCIP gateway will solve the duplicate > > > > problem even > > > > with a single retry. There is no synchronization between the FC device > > and > > > > the FCIP gateway for error recovery. So, the FC device can retransmit > > > > independent of the SCTP at the FCIP gateway. One way to solve this > > problem > > > > is to fine tune the timeout values on the FC side and at the > > SCTP level > > on > > > > the FCIP gateway. > > > > > > > > Regards, > > > > > > > > Raj Bhagwat > > > > LightSand Communications > > > > > > > > > > > > ----- Original Message ----- > > > > From: Douglas Otis > > > > To: Raj Bhagwat ; Vivek Kashyap ; > > > > > > > > Cc: > > > > Sent: Monday, September 11, 2000 10:14 AM > > > > Subject: RE: FCIP and wandering duplicates > > > > > > > > > > > > > Raj, > > > > > > > > > > Unless you are willing to wrap the FC frame within some protocol, > > > > duplicates > > > > > can happen and this has nothing to do with TTL. TTL > > prevents circular > > > > paths > > > > > from forever sending a packet within a loop. A modified > > SCTP protocol > > > > that > > > > > will solve both of these problems, if restricted one time retry. A > > > > > Metro-Area-Network should induce about 5ms RTT delay such that > > > > a 10ms skew > > > > > becomes possible but is limited by the single retry. TTL buys > > > > you nothing > > > > > with this E_D_TOV, Error_Detect Timeout. > > > > > > > > > > Doug > > > > > > > > > > > -----Original Message----- > > > > > > From: owner-ips@ece.cmu.edu > > [mailto:owner-ips@ece.cmu.edu]On Behalf > > Of > > > > > > Raj Bhagwat > > > > > > Sent: Sunday, September 10, 2000 10:57 PM > > > > > > To: Vivek Kashyap; ipfc@standards.gadzoox.com > > > > > > Cc: ips@ece.cmu.edu > > > > > > Subject: Re: FCIP and wandering duplicates > > > > > > > > > > > > > > > > > > Vivek, > > > > > > > > > > > > In a properly implemented FC-only fabric, duplicates should > > > > not happen. > > > > A > > > > > > frame that enters a fabric should either be delivered > > within E_D_TOV > > > > > > (typically 2 sec) or be discarded. FC devices don't retransmit a > > frame > > > > > > before the E_D_TOV timer expires. > > > > > > > > > > > > You do bring up an interesting point when two SAN islands are > > > > > > bridged across > > > > > > an IP network. Once an FC frame enters the IP network, it is hard > > > > > > to say how > > > > > > the E_D_TOV is enforced by that part of the network. As authors of > > the > > > > > > FCoverIP draft, we have given some thought to the possibility of > > > > > > delivering > > > > > > duplicate frames when both the TCP stack at the FCIP > > gateway and the > > > > > > original FC device initiate recovery/retransmission > > procedure in an > > > > > > overlapping time period. This is one of the major reasons why we > > > > initially > > > > > > chose to make the FCIP gateway a stateless device with no > > > > buffering and > > > > no > > > > > > retransmission. > > > > > > > > > > > > The good news is that the {IP encapsulated} FC frame will be > > protected > > > > by > > > > > > the IP TTL once it enters the IP network. The bad news is that > > > > > > detecting the > > > > > > E_D_TOV timeout while the frame is inside the IP network may be > > > > difficult. > > > > > > > > > > > > Regards, > > > > > > > > > > > > Raj Bhagwat > > > > > > LightSand Communications > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: Vivek Kashyap > > > > > > To: > > > > > > Sent: Sunday, September 10, 2000 3:17 PM > > > > > > Subject: FCIP and wandering duplicates > > > > > > > > > > > > > > > > > > > I read the FCIP document recently. It does not address the issue > > of > > > > > > > duplicates. > > > > > > > > > > > > > > Does fibre channel protect itself from duplicates ? I looked at > > the > > > > > > > header and it does not have a time to live field. Thus > > a duplicate > > > > > > > caught in a loop and then released at the 'right' time could be > > > > > > > accepted by the receiver. Even if the FC fabric path > > algorithms do > > > > > > > ensure loop free paths transient loops due to errors, switch > > > > > > > misconfigurations or failures are possible. Does FC handle > > > > such a case > > > > ? > > > > > > > > > > > > > > If it does not then FCIP will exacerbate the problem because the > > IP > > > > > > > network could have 'transient' loops. Such a 'wandering > > duplicate' > > > > > > > could be re-injected into the FC island and be accepted > > by a newer > > > > > > > incarnation of a FC inter-island exchange. Furthermore with > > > > no TTL one > > > > > > > can't really provide a timout between starting two > > conversations. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Vivek > > > > > > > -- > > > > > > > Vivek Kashyap > > > > > > > IBM-NumaQ > > > > > > > viv@sequent.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Vivek Kashyap Advisory Engineer IBM-NumaQ viv@sequent.com vivk@us.ibm.com 503 578 3422 (o) From owner-ipfc@standards.gadzoox.com Thu Sep 21 13:00:56 2000 Received: from standards.gadzoox.com (standards.gadzoox.com [216.52.31.24]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA10023 for ; Thu, 21 Sep 2000 13:00:54 -0400 (EDT) Received: (from majordom@localhost) by standards.gadzoox.com (8.8.7/8.8.7) id IAA03730 for ipfc-list; Thu, 21 Sep 2000 08:45:48 -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 IAA03727 for ; Thu, 21 Sep 2000 08:45:44 -0700 Received: from muralir (dhcp074.lightsand.com [192.168.1.74]) by lightsand.com (8.9.3+Sun/8.9.1) with SMTP id JAA15975; Thu, 21 Sep 2000 09:55:24 -0700 (PDT) From: "Murali Rajagopal" To: "IPFC" Cc: , , Subject: Last Call For A Framework for Fibre Channel MIBs Informational RFC Date: Thu, 21 Sep 2000 09:55:22 -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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ipfc@standards.gadzoox.com Precedence: bulk Content-Transfer-Encoding: 7bit The authors of the the draft document "A Framework for Fibre Channel MIBs", believe that the document is ready for submission for INFORMATIONAL RFC consideration. This is the Last Call for any comments. Please submit any comments you may have to the reflector before Oct 15, 2000. Regards, Murali Rajagopal IPFC WG Chair LightSand Communications muralir@lightsand.com From owner-ipfc@standards.gadzoox.com Fri Sep 22 04:16:34 2000 Received: from standards.gadzoox.com (standards.gadzoox.com [216.52.31.24]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA03990 for ; Fri, 22 Sep 2000 04:16:34 -0400 (EDT) Received: (from majordom@localhost) by standards.gadzoox.com (8.8.7/8.8.7) id AAA04056 for ipfc-list; Fri, 22 Sep 2000 00:02:08 -0700 X-Authentication-Warning: standards.gadzoox.com: majordom set sender to owner-ipfc@standards.gadzoox.com using -f Received: from mumm.ibr.cs.tu-bs.de (root@mumm.ibr.cs.tu-bs.de [134.169.34.190]) by standards.gadzoox.com (8.8.7/8.8.7) with SMTP id AAA04053 for ; Fri, 22 Sep 2000 00:02:04 -0700 Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id KAA18838; Fri, 22 Sep 2000 10:12:12 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id KAA00768; Fri, 22 Sep 2000 10:12:11 +0200 Date: Fri, 22 Sep 2000 10:12:11 +0200 Message-Id: <200009220812.KAA00768@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: muralir@lightsand.com CC: ipfc@standards.gadzoox.com, mark.carlson@sun.com, gavin@gadzoox.com, lhu3@yahoo.com In-reply-to: Subject: Re: Last Call For A Framework for Fibre Channel MIBs Informational RFC References: Sender: owner-ipfc@standards.gadzoox.com Precedence: bulk >>>>> Murali Rajagopal writes: Murali> The authors of the the draft document "A Framework for Fibre Murali> Channel MIBs", believe that the document is ready for Murali> submission for INFORMATIONAL RFC consideration. Murali> This is the Last Call for any comments. Please submit any Murali> comments you may have to the reflector before Oct 15, 2000. You should indicate which version of the document you are starting last call for. I guess it is but I just wanted to make sure we all read the same document. /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 From owner-ipfc@standards.gadzoox.com Fri Sep 22 09:59:34 2000 Received: from standards.gadzoox.com (standards.gadzoox.com [216.52.31.24]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA14276 for ; Fri, 22 Sep 2000 09:59:34 -0400 (EDT) Received: (from majordom@localhost) by standards.gadzoox.com (8.8.7/8.8.7) id FAA04374 for ipfc-list; Fri, 22 Sep 2000 05:45:04 -0700 X-Authentication-Warning: standards.gadzoox.com: majordom set sender to owner-ipfc@standards.gadzoox.com using -f Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by standards.gadzoox.com (8.8.7/8.8.7) with SMTP id FAA04371 for ; Fri, 22 Sep 2000 05:45:01 -0700 Received: from centralmail1.Central.Sun.COM ([129.147.62.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA11223; Fri, 22 Sep 2000 07:54:59 -0600 (MDT) Received: from esun1as-mm. (esun1as-mm.Central.Sun.COM [129.147.34.144]) by centralmail1.Central.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with SMTP id HAA15253; Fri, 22 Sep 2000 07:54:58 -0600 (MDT) Received: from sun.com by esun1as-mm. (SMI-8.6/SMI-SVR4) id IAA11540; Fri, 22 Sep 2000 08:02:12 -0600 Message-ID: <39CB655E.EB1840EF@sun.com> Date: Fri, 22 Sep 2000 07:57:50 -0600 From: "Mark A. Carlson" Organization: Sun Microsystems, Inc. - Jiro Group http://www.jiro.com X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Juergen Schoenwaelder CC: muralir@lightsand.com, ipfc@standards.gadzoox.com, gavin@gadzoox.com, lhu3@yahoo.com Subject: Re: Last Call For A Framework for Fibre Channel MIBs Informational RFC References: <200009220812.KAA00768@henkell.ibr.cs.tu-bs.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipfc@standards.gadzoox.com Precedence: bulk Content-Transfer-Encoding: 7bit Yes. That is the latest. -- mark Juergen Schoenwaelder wrote: > > >>>>> Murali Rajagopal writes: > > Murali> The authors of the the draft document "A Framework for Fibre > Murali> Channel MIBs", believe that the document is ready for > Murali> submission for INFORMATIONAL RFC consideration. > > Murali> This is the Last Call for any comments. Please submit any > Murali> comments you may have to the reflector before Oct 15, 2000. > > You should indicate which version of the document you are starting > last call for. I guess it is > but I just wanted to make sure we all read the same document. > > /js > > -- > Juergen Schoenwaelder Technical University Braunschweig > Dept. Operating Systems & Computer Networks > Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany > Fax: +49 531 391 5936 From owner-ipfc@standards.gadzoox.com Sat Sep 30 17:09:11 2000 Received: from standards.gadzoox.com (standards.gadzoox.com [216.52.31.24]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA00826 for ; Sat, 30 Sep 2000 17:09:10 -0400 (EDT) Received: (from majordom@localhost) by standards.gadzoox.com (8.8.7/8.8.7) id MAA08898 for ipfc-list; Sat, 30 Sep 2000 12:51:52 -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 MAA08895 for ; Sat, 30 Sep 2000 12:51:42 -0700 Received: from cx418298b (cx418298-b.orng1.occa.home.com [24.1.179.117]) by lightsand.com (8.9.3+Sun/8.9.1) with SMTP id OAA09617 for ; Sat, 30 Sep 2000 14:01:20 -0700 (PDT) Message-ID: <005901c02b22$ae1b96e0$75b30118@orng1.occa.home.com> From: "Murali Rajagopal" To: Subject: Fw: ips Administrative Matters and framework document Date: Sat, 30 Sep 2000 14:09:10 -0700 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.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipfc@standards.gadzoox.com Precedence: bulk Content-Transfer-Encoding: 7bit Dear IPFC WG Members: The FC-IP standardization work is now officially under the charter of the IPS WG. The IPFC WG will continue to operate until its chartered work is complete. We have two drafts - one framework and the other a Management MIB in the process of completion within the IPFC WG. The frame work doc. is now sent out for a Last Call comments. It is expected that the Management MIB will be completed by the San Diego Meeting. Regards, Murali Rajagopal IPFC WG Chair LightSand Communications muralir@lightsand.com ----- Original Message ----- From: To: Sent: Friday, September 29, 2000 3:58 PM Subject: ips Administrative Matters and framework document > The ips WG charter is now posted on the IETF web site at: > > http://www.ietf.org/html.charters/ips-charter.html > > Everyone should read it, as it contains a number of > important statements of goals, requirements, and restrictions, > in addition to a current set of expected milestones. > > There are no drafts currently linked to the charter. The > current plan is to have new versions of the iSCSI and FC over > IP drafts submitted as WG documents (draft-ietf-ips-...) and > link them at that point. Things have changed sufficiently > since the last versions, that linking them to the web > copy of the charter could seriously mislead people who > aren't following the mailing list. This should happen > by the end of October, and hopefully a lot earlier (yes, > this is a public hint to the document authors :-) ). > > That takes care of the first milestone on the charter. > The second milestone is to get an initial version of > the framework document submitted as an Internet-Draft. > The charter says: > > "The WG will produce a framework document that provides > an overview of the environments in which its encapsulated > protocols and related protocols are expected to operate." > > The framework document is the place for discussions of how, why > and where iSCSI and FC-over-IP might be used and what the various > other components are that have to be present to make them usable > aside from implementations of these protocols. This also includes > complementarity of these protocols and discussion of overlap/ > situations in which both might be applicable. > > The initial version of the framework document will be produced > by an off-line author team for review and comment by the WG. > I'm looking for a few good authors for the document - expertise > on networking, SCSI and Fibre Channel will be needed in the > author team. Volunteers should have the time available to produce > significant text in the next couple of months, and there's > a need for one person to put in the time to coordinate this > effort and assemble the text as document editor. The rewards > are fleeting fame as a co-author of the document; I would > guess that it'll go through several serious revisions over the > next 6 months or so before it can be submitted for publication > as an informational RFC. If you're interested (and I hope > a number of folks out there are), please send me email directly. > > 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 > --------------------------------------------------- > >