Re: Collision detect [Re-Posting]

[Russ White <[e-mail]>]

It actually (probably) doesn't matter what the majority is--the
spec should (probably) be written in such a way to make it
obvious that you are trying to prevent two connections, and leave
out anything that implies whether this means you use two fsm's or
one.

Cisco uses one fsm.

:-)

Russ

On Fri, 25 Jan 2002, Alex Zinin wrote:

> 
> Sathya,
> 
>   In fact, that was one of my concerns about the spec.
> 
>   Regardless of whether we stay with the two-FSMs based scheme
>   or move to two transport connections under one, I think
>   we should have a section on processing of incoming transport
>   connection (I actually have it in my version of the FSM I sent
>   to the list a while ago).
> 
>   From my knowledge, at least some major implementations do not
>   treat competing connections as different FSMs. Whether they
>   make the majority or not is something that we should probably
>   ask the WG chairs to check.
> 
> -- 
> Alex Zinin
> 
> Wednesday, January 23, 2002, 7:18:21 PM, Sathya Perla wrote:
> 
> 
> > I think the fundamental problem with Collision Detection is that the spec
> > assumes (without stating it explicitly) that there are two FSMs to deal with
> > the possible two transport connections between a pair of peers. This is
> > evident from the usage of "FSM Cease" to close a transport connection. 
> 
> > One could manage both the transport connections using the same FSM and after
> > the collision detect algorithm is run the "unwanted" transport connection
> > can be closed without requiring a "FSM Cease".
> 
> > If this is not OK, the draft should explicitly state that a separate FSM has
> > to be used for a second connection with the same peer.
> 
> > -Sathya
> 
> 
> > -----Original Message-----
> > From: Kunihiro Ishiguro [mailto:[e-mail]]
> > Sent: Wednesday, January 23, 2002 7:36 AM
> > To: Mathew Richardson
> > Cc: [e-mail]
> > Subject: Re: Collision detect
> 
> 
> >>t0: BoxA initiates TCP connection to BoxB (we'll call this connection 1)
> >>t0: BoxB initiates TCP connection to BoxA (we'll call this connection 2)
> >>t1: BoxA accepts incoming connection from BoxB
> >>t1: BoxB accepts incoming connection from BoxA
> >>t2: BoxA sends an Open message on connection 1
> >>t2: BoxB sends an Open message on connection 2
> 
> > When BoxA accept incoming connection 2 from BoxB, BoxA lookup
> > corresponding status and it is Connect for connection 1.  Here we have
> > a problem.  If BoxA decides which connection should be closed at this
> > moment, BoxB will do the same thing.  Then both connection will be
> > closed.  OK, to avoid this situation collision detect should be done
> > by Open message then take one of them based upon router-id.  (In my
> > very private opinion, if jitter is there this will not happen
> > frequently).  Until that time the both connections should be
> > maintained.
> 
> > BTW, here is my question, when BoxA sends an Open message to BoxB
> > (t2).  BoxA has two connections.  Connection 1 is OpenSent status.
> > Connection 2 will be Connect status.  But where connection 2 status
> > comes from?  Is that generated based upon Connection 1 status?  It is
> > very ambiguous in RFC and draft description.  Initially the peer has
> > only one status.  Some moment the peer has two connections and two
> > independent status.  Finally collision detect close one connection.
> > The status related the connection also goes away.
> 
> > When I implemented BGP this was the biggest obstacle to understand FSM
> > and collision detect.  Still description is not clear.  Should we fix
> > this also?
> 
> 

_____________________________
[e-mail] <>< Grace Alone