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

From: "Yuval Nissan" <[email-masked]>
Date: Tue, 23 Nov 2004 10:21:34 +0200

Mark,
Consider the second solution you propose (the lazy update), there is possibility to make the update much less frequent (but still must be less than every 2^15 packets), and to estimate Transmit SEQ as following:
TransmitSEQ = lastUpdateTransmitSEQ+TimeFromLastUpdate/PacketFrameSize+Delta
(and also update the transmit ROC if needed).

I think this also should work if appendix A is implemented.

Yuval

-----Original Message-----
From: Mark Baugher [mailto:[email-masked]]
Sent: Monday, November 22, 2004 8:47 PM
To: Yuval Nissan
Cc: [email-masked]
Subject: Re: [AVT] RFC 3711 and High Availability

Yuval,

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

>
> 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?

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
>
> 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
>

************************************************************************************************************
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: Tue, 23 Nov 2004 09:08:48 -0800

Yuval,
   I have not thought of anything that would break using such a "lazy"  
synchronization of the SEQ on the sender on an HA system.  Perhaps  
someone else on this list will.  There are so many RTP payload types  
with so many distinct operational characteristics, I'd be careful and  
take the payload type(s) that you are using into consideration when  
analyzing this approach.

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

>
> Mark,
> Consider the second solution you propose (the lazy update), there is  
> possibility to make the update much less frequent (but still must be  
> less than every 2^15 packets),

Specifically, we are concerned with an SRTP replay-window-size number  
of packets; section 3.3.2 of RFC 3711 sets the default to 64, which  
means you will synchronize the hot-standby machine about every 64  
packets rather than following each packet.  Failover occurs within this  
window of 64 packets, but the value of SEQ for the last packet sent is  
unknown.  Thus, it's necessary to advance the SEQ by the window size to  
ensure that subsequent packets don't collide with previous packets  
sent.

> and to estimate Transmit SEQ as following:
> TransmitSEQ =  
> lastUpdateTransmitSEQ+TimeFromLastUpdate/PacketFrameSize+Delta

I think it would be
TransmitSEQ = lastUpdateTransmitSEQ + RTPWindowSize

> I think this also should work if appendix A is implemented.

I think appendix A, or something like it, always needs to be  
implemented.

Mark