[asterisk-dev] bridge_unreal: An alternative approach to Local/Unreal channel optimization

[Matthew Jordan]

On Mon, Mar 10, 2014 at 6:59 AM, Joshua Colp <jcolp at digium.com> wrote:

> Matthew Jordan wrote:
>
>>
>>
> <snip>
>
>
>
>> It's important to point out that optimization's goal was never the
>> removal of the channel. If anything, nuking Local channels has - in
>> my opinion - always made life more difficult for everyone, not
>> easier.
>>
>> The goal was performance - minimize the frame path. If I'm picturing
>>  this correctly, this doesn't *quite* optimize as efficiently as
>> completely removing the Local channels - but it may still be
>> sufficient.
>>
>> Real-01       Local-02;1         Local-02;2         Real-03 ------>
>> <-------------> <------------> <------- \   /               \  /
>> \  / -B0-               -NLB-             -B1- Real-03
>> Real-01
>>
>> In this case - and this is assuming I understand the proposed Native
>>  Local Bridge correctly! - Local-02;1 has as its actual destination
>> target Real-03, while Local-02;2 has as it actual destination
>> Real-01. When B0 pushes a frame to Local-02;1, Local-02;1 knows that
>> it should just pass it on to its destination. Rather than passing to
>> its bridge, it writes directly to Real-03. The same happens in
>> reverse for Real-03 to Local-02;2.
>>
>
> As it is right now this approach can't optimize a bridged scenario above
> but I'm not sure that's a bad thing. While having a goal of optimizing
> things as much as possible is good in this scenario that's costing us a lot
> of complex code (with issues) and also requiring outside consumers to
> understand what can happen. I'd personally like to see Local channels
> become a connection between things instead of channels that can
> transmogrify, morph, and disappear. It makes both of our lives easier. To
> outside consumers they become "these channels have the same semantics as
> other channels but are implemented as a connection, and a single event will
> be produced which shows you how they are connected".
>

I don't disagree with that.

Optimization of Local channels is a complexity that is hard for us, and
hard for users of Asterisk. It improves performance - but I'm not sure how
much we improve it by is actually worth that pain.

When it was first written, people cared less about the guts of Asterisk,
and operations internally were generally simpler. If this complexity is
going to stick around, we have to find a way to manage it appropriately.


>
> As for your diagram no NLB would be present there because a bridge does
> not exist within chan_local. Making it use the bridging framework would
> require rewriting it, as it can not work within the confines of what
> bridging requires (ie: you can't have a channel doing two things at once).
>
> Where the NLB would be in use is this:
>
> Real-01 (B1) <-> Local-02;1 <-> Local-02;2 (B2) <-> Local-03;1 <->
> Local-03;2 (B3) <-> Real-02
>
> In this case B2 would be an NLB and optimize things so media coming from
> Real-01 would be queued onto Local-03;2 for reading by B3 and media coming
> from Real-02 would be queued onto Local-02;1 for reading by B1. This
> bypasses Local-02;2 and Local-03;1 in the middle.
>
> This works no matter what each far end is doing.
>
> The reason optimizing your example is hard is because frames have to come
> from a channel within the bridge and pass through it.
>
>
Well, there are both good and bad things about this.

On the good side, AMI events that exist today won't change. Fewer breaking
changes is good. Optimization begin/end events wouldn't occur, but the
semantics of Local channels otherwise behaves the same.

On the bad side, the simplest case is now the case that receives no
improvements. You only get benefit from the Native Local Bridge if you have
chains of Local channels - which I would imagine to be relatively rare in
practice.


>
>
>> Creating a chain of these works by the real 'endpoints' getting
>> passed down the chain of Local channels via control frames.
>>
>> There's two issues I can see with this - one minor, one maybe not.
>> (1) There's a small amount of work here that occurs by the Local
>> channel passing the frame on to its destination channel. It's minor,
>> but it would be slightly more work than what occurs during today's
>> optimization. (2) More seriously: I wonder if the destination
>> shouldn't be a channel but a bridge. The above optimization cannot
>> work for multi-party bridges: there is no single channel destination.
>> Today's optimization does work in that scenario via a bridge swap -
>> the single party on one end gets swapped with the Local channel in
>> the multi-party bridge. This really is a minor case - the idea of
>> optimizing channels into multi-party bridges is admittedly
>> ridiculously new - but it may be useful to think through this use
>> case.
>>
>
> Yes, as it is right now this doesn't optimize as much as the code that
> currently exists. I can say though that now when any video and audio frame
> go through a Local channel they no longer attempt to optimize out. (Yes,
> every 20ms pretty much the code attempts to do the optimization).
>

Which, if it can't optimize, is a bunch of needless work.

Trade-offs!



> I would think you'd need it if you had a hook that needed the audio
> on that Local channel - such as a MixMonitor.
>

The NLB compatibility code actually checks whether something like a
> MixMonitor is on either Local channel and won't allow it to be used.
>
> Now that I've given a diagram to show where things optimize and how it
> isn't inside of chan_local... what do you think NOW? ;)
>

I think this proposal is tantamount to killing Local channel optimization.

I'm not sure that's a bad thing, but I'd certainly like to get more
opinions.

-- 
Matthew Jordan
Digium, Inc. | Engineering Manager
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20140310/784e2f12/attachment-0001.html>