Subject: RE: TCP state machine doubts

From: "Abarbanel, Benjamin" <[email-masked]>
Date: Thu, 25 Jul 2002 11:19:11 -0400

Sue: 

   General Comments:

   2.      Do you have any assumptions on Multi-thread processing impacts to
the FSM?

If not, can you mention any operational assumptions?

The multi-thread processing issues would focus around the choice between 1
or 2 FSMs.   The state machine's event 22 and the call collision allows you
to do both.

No assumptions on the multi-threaded processing impacts to the FSM were
made. 

A two state versus 1 state model was allowed.  The single state model is
indicated in the places were TCP and con

Event 22 is merely a an open collision case. I think there is more to it
than just that. There are various phases that BGP goes through that one
might want to use multiple threads. The inter-locking or inter-working
between the threads could affect the state transitions. For example, Say you
are in Establish state and something happens to the session and it is
disconnected. In a single threaded environment it is easy, first come, first
served. In a multi-threaded case with thread priorities and interruptions,
it might get tricky at times. Some assumptions or expectations by the state
machine on actions it should take with regards to semaphore locks (RIB
Table, etc.), thread prioritization, processing, pre-emption and so forth
might be helpfull. Maybe these actions should only be suggestions not
required ways for implementations.

    I hope I have not opened a can of worms here?

Regards,
Ben

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 30 Jul 2002 16:51:58 -0400

On Thu, Jul 25, 2002 at 11:19:11AM -0400, Abarbanel, Benjamin wrote:
> There are various phases that BGP goes through that one

There are certain situations where the FSM suggests that things be
done in certain events where an implementation *could* do things
in a slightly different order.

For example, after the TCP connection has completed, you are supposed
to send your messages *before* reading the socket.  In a multi-threaded
environment, you may obviously not do this.  Indeed, for passive or
unconfigured peers, you may not even send your message immediately.

The FSM would suggest where your synchronization points need to go.
Happily, most of this work seems to need to be done during peering setup.

For the most part, like the 3-rib abstraction, you should be able
to do whatever you want inside your black box so long as it looks
right on the wire.  The FSM gives guidance on what probably is
happening in the box to get things out as you expect them to.

More specific examples might be helpful.

-- 
Jeff Haas 
NextHop Technologies