Subject: Re: [dispatch] I-D on RTP failover problem posted to mmusic

From: "Asveren, Tolga" <[email-masked]>
Date: Mon, 4 Apr 2016 08:52:10 +0000

This certainly is a serious problem for folks dealing with the type of environments described in the document. A solution definitely would be welcome and I hope this initiative can move forward. So, 100% interested here and I am also ready to contribute to the solution/document.

Thanks,
Tolga

> -----Original Message-----
> From: dispatch [mailto:[email-masked]] On Behalf Of Martin
> Taylor
> Sent: Saturday, March 05, 2016 1:53 PM
> To: [email-masked]
> Subject: [dispatch] I-D on RTP failover problem posted to mmusic
> 
> I recently posted https://tools.ietf.org/html/draft-taylor-mmusic-rtp-
> failover-problem-00 to mmusic.
> 
> This I-D describes a common problem associated with network functions that
> terminate or relay large numbers of concurrent RTP sessions such as session
> border controllers or conference bridges.  Network operators typically
> require that no equipment or software failure shall cause more than a
> second or two's interruption to any of the RTP sessions handled by such
> functions.  The only practical solution capable of meeting this need currently
> is for RTP packets to be sent to a service IP address which is capable of being
> moved quickly from one system to another, and the only way to do this
> sufficiently quickly is to for both active and standby systems to be connected
> to the same L2 segment.  This is problematic in two situations: (1) where
> active and standby systems are geographically separated and (2) in L3-centric
> data center fabrics.
> 
> This Informational I-D is intended to stimulate discussion leading to
> consensus on the need for a solution.  The solution is likely to involve
> extensions to SDP to communicate multiple connection addresses at session
> setup time, which is why I originally submitted the I-D to mmusic.  However,
> the solution is also likely to require some new RTP and RTCP procedures - so I
> have posted an email to avtcore alerting them to the existence of this I-D.
> 
> Martin
> 
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 4 Apr 2016 16:39:21 +0200

> This certainly is a serious problem for folks dealing with the type of environments described in the document. A solution definitely would be welcome and I hope this initiative can move forward. So…

naive: Why isn't ICE the answer?
Possibly with one of the extensions like trickle ICE or ICE renomination
currently discussed in the ICE WG.

-- 
Surveillance is pervasive. Go Dark.

---

From: "Asveren, Tolga" <[email-masked]>
Date: Tue, 5 Apr 2016 08:02:25 +0000

Inline...

Thanks,
Tolga

> From: dispatch [mailto:[email-masked]] On Behalf Of Harald
> Alvestrand
> Sent: Monday, April 04, 2016 10:39 AM
> To: [email-masked]
> Subject: Re: [dispatch] I-D on RTP failover problem posted to mmusic
> 
> > This certainly is a serious problem for folks dealing with the type of
> environments described in the document. A solution definitely would be
> welcome and I hope this initiative can move forward. So, 100% interested
> here and I am also ready to contribute to the solution/document.
> 
[TOLGA]  Just some initial thoughts:
We are here talking about "local candidates" on different hosts. Representing them as candidates offered as part of an offer from the same entity wouldn't be consistent with the basic concepts of ICE. IMHO, avoiding such architectural abuses/forced behavior is preferable as it may cause issues sooner or later -as it is not a "target use case" in general-, either as part of the main protocol or in the context of some extension.
What is needed is for the controlled side (using ICE terminology) to be able to decide/force which of the local addresses it offered needs to be used and trigger a change (with as few RTTs as possible) at a given point in time. ICE -as it stands right now- is not suitable for these semantics AFAIK.
There is also a need to support scenarios, where (after initial ICE negotiation is completed) to change/update the list of valid local candidates and this ideally should be done with as few RTTs as possible.
On the more practical/semi-technical side, there are deployment models/environments, where ICE is not used. A solution, which relies on  using existing protocol facilities rather than requiring addition of support for new protocols has a higher adoptability rate in general.
> >> I recently posted
> >> https://tools.ietf.org/html/draft-taylor-mmusic-rtp-
> >> This I-D describes a common problem associated with network functions
> >> that terminate or relay large numbers of concurrent RTP sessions such
> >> as session border controllers or conference bridges.  Network
> >> operators typically require that no equipment or software failure
> >> shall cause more than a second or two's interruption to any of the
> >> RTP sessions handled by such functions.  The only practical solution
> >> capable of meeting this need currently is for RTP packets to be sent
> >> to a service IP address which is capable of being moved quickly from
> >> one system to another, and the only way to do this sufficiently
> >> quickly is to for both active and standby systems to be connected to
> >> the same L2 segment.  This is problematic in two situations: (1)
> >> where active and standby systems are geographically separated and (2) in
> L3-centric data center fabrics.
> >>
> >> consensus on the need for a solution.  The solution is likely to
> >> involve extensions to SDP to communicate multiple connection
> >> addresses at session setup time, which is why I originally submitted
> >> the I-D to mmusic.  However, the solution is also likely to require
> >> some new RTP and RTCP procedures - so I have posted an email to
> avtcore alerting them to the existence of this I-D.
> >>
> >> Martin
> >>

---

From: Emil Ivov <[email-masked]>
Date: Tue, 5 Apr 2016 14:06:42 -0500

What bothers me a lot about this work is exactly the fact that it makes 
no mention of neither ICE nor DTLS/SRTP, so it makes me think that there 
might be a desire here to head in a direction that fits poorly with both 
of them.

I do disagree with your assertion that ICE is somehow architecturally 
incompatible with this. The very fact that L2 migration is considered 
suboptimal by the draft and that it sounds like we are going for 
client-side redirection, makes me think that ICE is a mandatory path here.

Now, I do also agree that, in it's current shape, ICE is suboptimal for 
this use case but that's a matter that is prone to improvement and I 
don't think it justifies an ICE-less approach. In fact, should you take 
such a direction, I am pretty sure that whatever you end up with is 
bound to have some overlap with ICE anyway.

Emil

On 5.04.16 г. 3:02, Asveren, Tolga wrote:
> Inline...
>
> Thanks, Tolga
>
>> -----Original Message----- From: dispatch
>> [mailto:[email-masked]] On Behalf Of Harald Alvestrand
>> Sent: Monday, April 04, 2016 10:39 AM To: [email-masked]
>> environments described in the document. A solution definitely would
>> be welcome and I hope this initiative can move forward. So, 100%
>> interested here and I am also ready to contribute to the
>> solution/document.
>>
>> naive: Why isn't ICE the answer? Possibly with one of the
>> extensions like trickle ICE or ICE renomination currently discussed
>> in the ICE WG.
> [TOLGA]  Just some initial thoughts: We are here talking about "local
> candidates" on different hosts. Representing them as candidates
> offered as part of an offer from the same entity wouldn't be
> consistent with the basic concepts of ICE. IMHO, avoiding such
> architectural abuses/forced behavior is preferable as it may cause
> issues sooner or later -as it is not a "target use case" in general-,
> either as part of the main protocol or in the context of some
> extension. What is needed is for the controlled side (using ICE
> terminology) to be able to decide/force which of the local addresses
> it offered needs to be used and trigger a change (with as few RTTs as
> possible) at a given point in time. ICE -as it stands right now- is
> not suitable for these semantics AFAIK. There is also a need to
> support scenarios, where (after initial ICE negotiation is completed)
> to change/update the list of valid local candidates and this ideally
> should be done with as few RTTs as possible.
> On the more
> practical/semi-technical side, there are deployment
> models/environments, where ICE is not used. A solution, which relies
> on  using existing protocol facilities rather than requiring addition
> of support for new protocols has a higher adoptability rate in
> general.
>>
>>>
>>> Thanks, Tolga
>>>
>>>> -----Original Message----- From: dispatch
>>>> [mailto:[email-masked]] On Behalf Of Martin Taylor
>>>> Sent: Saturday, March 05, 2016 1:53 PM To: [email-masked]
>>>> This I-D describes a common problem associated with network
>>>> functions that terminate or relay large numbers of concurrent
>>>> RTP sessions such as session border controllers or conference
>>>> bridges.  Network operators typically require that no equipment
>>>> or software failure shall cause more than a second or two's
>>>> interruption to any of the RTP sessions handled by such
>>>> functions.  The only practical solution capable of meeting this
>>>> need currently is for RTP packets to be sent to a service IP
>>>> address which is capable of being moved quickly from one system
>>>> to another, and the only way to do this sufficiently quickly is
>>>> to for both active and standby systems to be connected to the
>>>> same L2 segment.  This is problematic in two situations: (1)
>>>> This Informational I-D is intended to stimulate discussion
>>>> leading to consensus on the need for a solution.  The solution
>>>> is likely to involve extensions to SDP to communicate multiple
>>>> connection addresses at session setup time, which is why I
>>>> originally submitted the I-D to mmusic.  However, the solution
>>>> is also likely to require some new RTP and RTCP procedures - so
>>>> I have posted an email to
>>>> _______________________________________________ dispatch
>>>> mailing list [email-masked]
>>> _______________________________________________ dispatch mailing
>>> list [email-masked]
>> -- Surveillance is pervasive. Go Dark.
>>
>> _______________________________________________ dispatch mailing
>> list [email-masked]
> _______________________________________________ dispatch mailing
> list [email-masked]

-- 
https://jitsi.org

-- 
https://jitsi.org