Re: Alternative to M3UA HeartBeat

Deepak,

Your point is generally valid when M3UA is in any
"out-to-lunch" state.  An additional use case may
be considered where the M3UA administrator wishes
to have "quick" determination of misisng M3UA peers,
and can tune the frequency of M3UA BEAT messages,
but does not have the ability to increase the 
frequency of SCTP heartbeats.

SCTP heartbeats might within recommendation be only
every 60 seconds. Certain M3UA applications may not
consider this satisfactory, and want more frequent
BEAT messages.  This is *not* complicated by the fact
that the M3UA BEAT message (as SCTP-user DATA) can
somewhat take the place of SCTP HEARTBEAT messages.
For example, near the beginning of an SCTP 60
second heartbeat period, an M3UA peer can disappear,
and the local [idle] M3UA may not know for a long time,
unless it sends BEAT messages more frequently.

Of course Moloud was originally addressing the converse
problem of no M3UA BEATS with no transport heartbeats.

With thanks, from Chris Benson

On Tue, 25 May 2010, Deepak Gunjal wrote:

>>  Date: Tue, 25 May 2010 23:52:02 +0530
>>  From: Deepak Gunjal <[email protected]>
>>  To: Chris Benson <[email protected]>, Moloud Mousavi <[email protected]>
>>  Cc: "[email protected]" <[email protected]>
>>  Subject: RE: [Sigtran] Alternative to M3UA HeartBeat
>>  
>>  What are the cases where I may require to use BEAT over reliable transport viz. SCTP? I can think of a case where remote M3UA is stuck in a loop and unable to process protocol messages but its SCTP layer can still send and acknowledge heartbeats at SCTP level though M3UA as such is not available. Will this case qualify for using BEAT where peer can detect such problem as BEAT ACK will not be received?
>>  Are there also other use cases which may suggest for use of BEAT over reliable transport?
>>  
>>  Regards
>>  Deepak
>>  
>>  ________________________________________
>>  From: [email protected] [[email protected]] On Behalf Of Chris Benson [[email protected]]
>>  Sent: Tuesday, May 25, 2010 11:40 PM
>>  To: Moloud Mousavi
>>  Cc: [email protected]
>>  Subject: Re: [Sigtran] Alternative to M3UA HeartBeat
>>  
>>  Moloud,
>>  
>>  Although other transports are technically allowed, in practice,
>>  M3UA is (always?) implemented over SCTP, which *does* have its
>>  own heartbeat mechanism.
>>  
>>  I thus consider your question moot.  As you have probably
>>  noted, RFC 4666 only "recommends" that M3UA BEAT be used
>>  over transport layers without heartbeats.  It is thus true
>>  that one could use a different transport layer (without its
>>  own hearbeat mechanism) and not be able to determine quickly
>>  that an M3UA peer has "disappeared".  In certain circumstances,
>>  the determination can be made (e.g. waiting for ASPUP Ack),
>>  but in other circumstances (normal active, idle), the
>>  determination cannot be made by M3UA alone.  So it isn't
>>  a good idea to implement the combination of "M3UA-no-BEATs"
>>  with "transport-no-heartbeats".
>>  
>>  With thanks, from Chris Benson.
>>  
>>  On Tue, 25 May 2010, Moloud Mousavi wrote:
>>  
>>  >>  Date: Tue, 25 May 2010 12:03:53 -0400
>>  >>  From: Moloud Mousavi <[email protected]>
>>  >>  To: "[email protected]" <[email protected]>
>>  >>  Subject: [Sigtran] Alternative to M3UA HeartBeat
>>  >>
>>  >>  Hi,
>>  >>
>>  >>  RFC considers M3UA beat optional; it's needed over transport layers without their own heartbeat mechanism.
>>  >>  My question is: If M3UA beat is off while running over a transport layer without such a mechanism, what would be the system behavior? Does it stay in a wrong status forever or is there an alternative to prevent such a case?
>>  >>
>>  >>
>>  >>  Thanks,
>>  >>  Moloud
>>  >>
>>  >>
>>  >>  NOTICE: This e-mail contains information that may be confidential and proprietary. If you are not the intended recipient, any disclosure or other use of this e-mail or the information contained herein or attached hereto may be unlawful and is strictly prohibited. If you have received this e-mail in error, please notify the sender immediately and delete this e-mail without reading, printing, copying or forwarding it to anyone. Thank you for your kind cooperation.
>>  >>  AVIS : Ce courriel contient des renseignements qui peuvent etre confidentiels ou de propriete industrielle. Si vous n'etes pas le veritable destinataire, la diffusion ou l'usage de ce courriel, des renseignements qu'il contient ou des documents qui lui sont joints pourrait etre illegal. Il est donc strictement interdit de les diffuser ou de les utiliser. Si vous avez recu ce courriel par erreur, veuillez en aviser l'expediteur immediatement et veuillez le supprimer sans le lire, l'imprimer, le sauvegarder ou le diffuser. Merci de votre aimable collaboration.
>>  >>  _______________________________________________
>>  >>  Sigtran mailing list
>>  >>  [email protected]
>>  >>  https://www.ietf.org/mailman/listinfo/sigtran
>>  >>
>>  _______________________________________________
>>  Sigtran mailing list
>>  [email protected]
>>  https://www.ietf.org/mailman/listinfo/sigtran
>>  
>>  "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."
>>