Subject: RE: [AVT] RFC 3711 and High Availability

From: "Yuval Nissan" <[email-masked]>
Date: Mon, 22 Nov 2004 10:32:56 +0200

Mark,
I meant the second case you describe, with hot-standby mode.

The problem in HA systems of this kind is that you want minimum updates of the dynamic parameters in order not to overload the boards.

Actually, the main issue I see is with s_l and SEQ that are updated every frame. What is the minimum rate that they are needed to be updated and how should they be estimated?

Thanks,
Yuval

-----Original Message-----
From: Mark Baugher [mailto:[email-masked]]
Sent: Sunday, November 21, 2004 11:26 PM
To: Yuval Nissan
Cc: [email-masked]
Subject: Re: [AVT] RFC 3711 and High Availability

Yuval
   You mention the channel crashing and there seems to be two major 
cases, either the destination or source addresses change or they don't. 
  If they do change, then we effectively have a new session.  Often they 
won't change in an HA system, so I can't immediately recognize any 
affects on the state of the end-systems.  s_l should be easily 
recovered and ROC correctly updated unless there are more than 2^15 
packets lost.

   In the case where a sender or a receiver fail, then I think it will 
be hard to seamlessly handle a transition to another sender and 
receiver unless the addresses remain the same and most of the 
cryptographic context is recovered.  Commercial HA systems can do this, 
at least in a hot-standby mode, can't they?

Mark
On Nov 21, 2004, at 12:18 AM, Yuval Nissan wrote:

> Hello,
>
> I have question regarding SRTP and High Availability. This issue isn’t 
> covered by RFC 3711:
>
> The question is if channel crashes, what are the parameters that need 
> to be recovered by the new channel so that the conversation will 
> continue (in both directions)?
>
> Also in this case it is assumed that we can’t know exactly the dynamic 
> parameters of the channel. For example the current s_l which is 
> updated every frame. This means that part of the parameters need to be 
> estimated.
>
>  
>
> Thanks,
>
>  
>
> Yuval
>
>  AudioCodes
>
>   
>
>  
>
>  
>
> ***********************************************************************
> *************************************
> This email and any files transmitted with it are confidential material.
> They are intended solely for the use of the designated individual or 
> entity to whom they are addressed.
> If the reader of this message is not the intended recipient,
> you are hereby notified that any dissemination,use,
> distribution or copying of this communication is strictly prohibited 
> and may be unlawful.
>
> If you have received this email in error please notify 
> [email-masked] and permanently delete the e-mail and files.
>
>
> ***********************************************************************
> ************************************
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/avt

************************************************************************************************************
This email and any files transmitted with it are confidential material.
They are intended solely for the use of the designated individual or entity to whom they are addressed.
If the reader of this message is not the intended recipient,
you are hereby notified that any dissemination,use,
distribution or copying of this communication is strictly prohibited and may be unlawful.

If you have received this email in error please notify [email-masked] and permanently delete the e-mail and files.

***********************************************************************************************************

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Mark Baugher <[email-masked]>
Date: Mon, 22 Nov 2004 10:46:42 -0800

Yuval,

On Nov 22, 2004, at 12:32 AM, Yuval Nissan wrote:

> The problem in HA systems of this kind is that you want minimum  
> updates of the dynamic parameters in order not to overload the boards.
>
> Actually, the main issue I see is with s_l and SEQ that are updated  
> every frame. What is the minimum rate that they are needed to be  
> updated and how should they be estimated?

s_l (at the receiver), SEQ (at the sender) and potentially the ROC need  
to be updated on every packet to be strictly correct, and I can see why  
this would be impractical in hot-standby mode.  There are a few  
tradeoffs.  If you want a nearly-seamless transition to the standby  
machine, then s_l needs to consistent between receiving machines and  
SEQ between sending machines.  If this is not practical and the HA  
application requirements permit a round-trip signaling message during  
recovery, then Dave Oran's suggestion seems to be a straightforward and  
reliable solution.  I'd opt for this.

Alternatively, consider Appendix A:  Appendix A handles the case where  
the sequence-number wraps to zero, and I think the ROC update will be  
correct so long as s_l stays within 2^15 packets of SEQ.  The replay  
window is a tighter bound.  Thinking out loud, it might be possible to  
update SEQ and s_l infrequently if you take account of the size of  
replay window.  Lazy update at the sender will cause problems at the  
receiver until the sender's SEQ reaches the receiver's s_l.  All of the  
senders packets with a SEQ less than s_l minus the replay-window-size  
(modulo 2^16) will get discarded.  The sender's packets that are within  
that window will get discarded if they match previously-received  
packets or else they would be incorrectly accepted.  So it might be  
possible to update SEQ on the hot-standby machine in increments of the  
replay window size.  When failover occurs, the last recorded SEQ would  
be incremented by the replay-window size and the hot-standby sender  
could resume sending packets with the new SEQ, and the receiver would  
update it's s_l to the new, higher-value SEQ.  This might work, but I'm  
not entirely sure.

Mark