Subject: Re: Comments 30-36 from Siva

From: "Tom Petch" <[email-masked]>
Date: Fri, 13 Dec 2002 22:46:06 -0000

Sue, Jeff

My comment was that if we do not send a KeepAlive (and start the
KeepAlive timer), on exiting from Active with Event 19 to OpenConfirm
then we never will and the connection will die.  Open Confirm state
means valid Open received so we must send a KeepAlive to acknowledge
the Open  (as pointed out in Jeff's other posting) and we never do it
in OpenConfirm state itself (unless the KeepAlive timer expires which
it cannot because we have not started it).

So for me,  OpenSent state Event 18 was and is correct, sending the
KeepAlive without which the connection goes no further and Active
state Event 19 needs to be brought into line.

To say that the timer is started when entering Established state is
fine except for a slight problem; we have no way in this FSM of
defining actions that are taken on entering a state, only actions to
be taken on leaving another state so that is why the KeepAlive actions
need to be where they are (or are not in the case of Active state
Event 19).

Tom Petch
[email-masked]

-----Original Message-----
From: Jeffrey Haas <[email-masked]>
To: Susan Hares <[email-masked]>
Cc: [email-masked] <[email-masked]>
Date: 12 December 2002 23:22
Subject: Re: Comments 30-36 from Siva

>Sue,
>
>On Thu, Dec 05, 2002 at 04:18:18PM -0500, Susan Hares wrote:
>> 33) Handling Event 18 in the OpenSent state
>>
>> >Why do we start the Keepalive timer at this stage ? Isn't it
sufficient =
>> >to do so when we move into Established state ?
>>
>> An earlier comment from Tom (and you) requested the following:
>>
>> <---Open
>> [Open sent state]
>>
>> Open-->
>> [Event 18]
>>
>> <---Open
>> <---Keepalive
>> [Action from Event 18 in Open Sent]
>> [Open Confirm]
>> Keepalive -> [Event 25]
>>
>> [established]
>
>I'm assuming the second OPEN going from right to left is a typo.
>If it isn't, thats a FSM error to the peer on the left.
>
>Theoretically, an implementation that utilizes its keepalive timer
>to send the first keepalive to transition to Established is
>still interoperable.  However:
>
>o Keepalives can be disabled by negotiating hold time of zero
>o We really shouldn't need to restart the Keepalive timer.
>  If there is a delay in the keepalive that transitions from
>  OpenConfirm to Established, its due to the transport connection.
>  It should be reliable and it *should* get through.  If it
>  doesn't, there's other problems and the hold timer for the
>  peer on the right should do the Right Thing and drop the
>  connection.
>
>> What do implementations do?  We'll have to query implementations.
>
>GateD at least waits to enter the Established state prior to starting
>the KeepAlive timer.
>
>--
>Jeff Haas
>NextHop Technologies