Re: FCIP and wandering duplicates

["Raj Bhagwat" <rajb@lightsand.com>]

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 <dotis@sanlight.net>
To: Raj Bhagwat <rajb@lightsand.com>; Vivek Kashyap <viv@sequent.com>;
<ipfc@standards.gadzoox.com>
Cc: <ips@ece.cmu.edu>
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 <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
> > >
> >
>
>