I have the same opinion. Why close the connection if the primary messages of the protocol are still being received and the purpose of the protocol is being achieved? Closing the connection prematurely will add overhead and extraneous traffic on the network.
Tina Iliff
-----Original Message-----
From: Durham, David [mailto:david.durham@intel.com]
Sent: Thursday, April 05, 2001 1:12 PM
To: 'Krishna Prasad Akkineni'; 'IETF RAP WG'
Subject: RE: Keep alive
The Keep Alive messages must sent by the PEP within the periods specified by
the PDP according to the RFC. However, KAs may be slightly delayed due to
the receipt of other large messages (DECs, RPTs, REQs). So, if communication
is happening (messages are still being received) the receiver obviously
should not close the connection simply because a KA hasn't arrived as yet.
-Dave
> -----Original Message-----
> From: Krishna Prasad Akkineni [mailto:krishna.akkineni@wipro.com]
> Sent: Thursday, April 05, 2001 8:12 AM
> To: IETF RAP WG
> Subject: Keep alive
>
>
> Hi,
> This is a query regarding Keep Alive message time.
> While generating Keep alive messages, Does the COPS client
> need to take previous message (from Server/to client) transaction
> time stamp in deciding the time to send Keep alive message?
> From sec.3.9, It looks like time stamp of last sent Keep alive
> message is to be considered.
> But sec.4.6, mentioned "any other COPS message" in the
> explanation.
> Could some one clarify this?
> -------------------------------------------------------------------
> text related to this query from RFC2748 is given below.
>
> 3.9 Keep-Alive (KA) PEP -> PDP, PDP -> PEP
> The keep-alive message MUST be transmitted by the PEP within the
> period defined by the minimum of all KA Timer values
> specified in all
> received CAT messages for the connection.
>
> 4.6 Keep-Alive Operations
>
> If either side does not receive a Keep-Alive or any
> ------
> other COPS message within the minimum KA Timer interval from the
> ------------------
> other, the connection SHOULD be considered lost.
> -------------------------------------------------------------------
>
> thanks
> Krishna
>
> --
> Krishna Prasad.Akkineni
> Telecom & Inter-Networking Solutions
> WIPRO Technologies,
> ----------------------------------------------------
> The opinions expressed here are my personal opinions
> and not necessarily those of WIPRO Technologies.
> ----------------------------------------------------
>
>