RE: FCIP and wandering duplicates

["Douglas Otis" <dotis@sanlight.net>]

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 <viv@sequent.com>
> To: <ipfc@standards.gadzoox.com>
> 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
> >
>