Subject: Re: [rtcweb] [Suspected Junk Mail] Endpoints that don't support RTCP

From: Magnus Westerlund <[email-masked]>
Date: Tue, 21 Apr 2015 11:40:23 +0200

Emil Ivov skrev den 2015-03-30 23:00:

> Makes sense to me! (and of course, any number would make sense here
> given how superfluous circuit breakers are in the presence of consent
> checks)
> 

I think you are quite wrong here. The circuit breaker is there to stop
persistent congestion. I think you are likely to get your consent checks
through in sufficient frequency to maintain consent, but have totally
crappy audio due to packet loss in the 10% range.

So please don't confuse the purposes of these mechanisms.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 21 Apr 2015 11:52:10 +0200

Hi,

I think I have a more specific proposal of how to deal with this case
regarding the circuit breakers and legacy peer end-point that don't send
RTCP. I think it is important that we consider these legacy gatewaying
cases. Unfortunately there appear to be a lot of audio RTP senders that
don't send RTCP.

Proposal:

In case circuit breaker #2 RTCP Timeout is triggered and;
 - No RTCP at all has been received;
 - This endpoint neither sends nor receive more than 72 kbps of RTP
   payload data on average over a 5 second window per direction;

then this triggering of the circuit breaker MAY be ignored. This would
be done if it is desired to support legacy RTP sender that lacks RTCP
implementations.

The motivation for the above formulation is really to make it clear that
this is only for legacy, and not create a situation where ignoring the
circuit breaker is okay, even if RTCP is being received, just because
one are in a really low-rate situation.

I wonder if the above should go into the RTP usage or into the circuit
breaker document itself?

Cheers

Magnus Westerlund

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 21 Apr 2015 12:08:40 +0200

> I wonder if the above should go into the RTP usage or into the circuit

I think it belongs to advice on gatewaying, actually - and that gateways
should be prepared to do RTCP synthesis in this situation.

Perpetuating tolerance for the broken behavior of ignoring "MUST send
RTCP" seems like a path that doesn't lead to getting rid of the behavior
in the end.

---

From: Emil Ivov <[email-masked]>
Date: Tue, 21 Apr 2015 13:10:35 +0300

> crappy audio due to packet loss in the 10% range.

I am going to be *very* upset if my browser drops a call because of
10% packet loss. I regularly have calls in hotel networks with up to
20%+ regular packet loss and still enjoy productive conversations
thanks to FEC and PLC.

If my audio does happen to be crappy I will be the one to decide when
to hang up.  The only times I could see as sensible for circuit
breakers to take over would be in situations where no data is getting
through. One example of a userful breakup would be users mistakenly
leaving connections open thinking they are dead. Obviously consent
checks would also cover this scenario.

So as I've mentioned before, I can see circuit breakers as an useful
recommendation for some applications but they are definitely redundant
in the context of WebRTC.

> So please don't confuse the purposes of these mechanisms.

I assure you I am not. One actually serves a purpose as MTI in webrtc
the other doesn't (which is why no one will implement it).

Emil

-- 
https://jitsi.org

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 21 Apr 2015 12:35:35 +0200

> in the context of WebRTC.

The purpose of circuit breakers is not to save the users from themselves.

It is to save the network from the users - to make sure that if WebRTC
users cause persistent congestion in the network, that congestion will
eventually go away.

This is the same purpose as the AIMD algorithm in TCP (which is not
particularly beneficial for each individual user).

---

From: Emil Ivov <[email-masked]>
Date: Tue, 21 Apr 2015 13:53:09 +0300

Hey Harald,

On Tuesday, April 21, 2015, Harald Alvestrand <[email-masked]> wrote:

> > <[email-masked] <javascript:;>> wrote:

Sure, I completely understand the intention. I just think CBs are a very
crude attempt of achieving it. Also somewhat redundant in the context of
WebRTC.

I have repeatedly asked for data that shows how CBs are beneficial in
large-scale diverse deployments and so far I haven't seen any (I have even
been asked by Colin to provide data that they don't work ... which is quite
absurd :) )

> particularly beneficial for each individual user).

Well ... it isn't really the same though is it. AIMD doesn't sadistically
kill your connection at the first whiff of trouble ... :) ... it just MDs
your bandwidth usage.

Ah ... whatever ...

Emil

-- 
--sent from my mobile

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 21 Apr 2015 13:08:15 +0200

Den 21. april 2015 12:53, skrev Emil Ivov:
> Hey Harald,
> 
> On Tuesday, April 21, 2015, Harald Alvestrand <[email-masked]
> <mailto:[email-masked]>> wrote:
> 

When we started out, we kind of hoped it would be rendered OBE by RMCAT,
but that's taken a bit longer than I originally hoped....

> large-scale diverse deployments and so far I haven't seen any (I have
> even been asked by Colin to provide data that they don't work ... which
> is quite absurd :) )

All the data I've seen so far seems to show that it's not going to be a
complete PITA by firing far too often..... but that's what I have....

> Well ... it isn't really the same though is it. AIMD doesn't
> sadistically kill your connection at the first whiff of trouble ... :)
> ... it just MDs your bandwidth usage.

I'd rather describe circuitbreakers as "kills your connection when the
shit has already hit the fan", but the difference between the two is a
matter of whether the trigger point is too low or too high... matter of
debate...

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 21 Apr 2015 06:42:25 -0600

That sounds workable but I think the 72 kbps is a bit low when you consider header extensions for audio level and other things. I'd be more comfortable with something closer to100 kbps. Given the granularity of circuit breakers I don't think 100 vs 72 is going to make circuit breaker not work. 

I think this needs to be in circuit breakers draft. 

> On Apr 21, 2015, at 3:52 AM, Magnus Westerlund <[email-masked]> wrote:
> 
> Hi,
> 
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 21 Apr 2015 16:08:54 +0200

> should be prepared to do RTCP synthesis in this situation.

I think the question here is if the gateways MUST do. From this thread
that answer appears to me to be no. It would be a rough consensus but
still no. That they SHOULD do it in a way that cause minimal issues I
think there is support for.

What I have seen there are several issues here. One if that a gateway
may not know if the gatewayed endpoint will send RTCP. Secondly, the
gateway only reports on part of the path. Which may or may not be an
issue depending on that path. In some cases the path beyond the gateway
to the far end in relation to the WebRTC endpoint will be on reserved
resources / dedicated networks, in others it will be on best effort
networks. Thus, this RTCP helps but is not the full story and that needs
to be clear when such reporting is done.

> RTCP" seems like a path that doesn't lead to getting rid of the behavior

I tend to agree, but the question is what you do when you have such
significant deployed base with this issue. Because in this case the cost
of dealing with that deployed base is not put on the deployed base, but
on the gateways.

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 21 Apr 2015 16:23:06 +0200

Cullen Jennings skrev den 2015-04-21 14:42:
> 
> That sounds workable but I think the 72 kbps is a bit low when you
> consider header extensions for audio level and other things. I'd be
> more comfortable with something closer to100 kbps. Given the
> granularity of circuit breakers I don't think 100 vs 72 is going to
> make circuit breaker not work.

Sorry, but I specified it as RTP Payload bit-rate, which would exclude
header extension. My thought would be to allow for 64 kbps codec plus
some payload format overhead.

However, I have to ask if really audio level header extensions and
legacy audio endpoint that don't send RTCP being a likely combination?

Cheers

Magnus Westerlund

---

From: Martin Thomson <[email-masked]>
Date: Tue, 21 Apr 2015 10:08:33 -0700

> some payload format overhead.

I think that specifying this in terms of b=AS is cleaner.

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 22 Apr 2015 14:22:52 +0200

> I think that specifying this in terms of b=AS is cleaner.

Are you meaning considering the rate for the whole packet, i.e.
IP+UDP+RTP+Payload rate, or as your own implementation calculates b=AS?
The later is very undefined, as there are no defined timescale for which
one calculates b=AS. Sure, for PCM audio this is straight forward, but
for anything that is variable rate it is not.

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 22 Apr 2015 14:31:11 +0200

> 20%+ regular packet loss and still enjoy productive conversations

Yes, with FEC. And I pulled 10% out of hat. I should of course
calculated the 10* TCP rate for some typical RTT to determine if the
circuit breaker would fire or not.

But, as you already discussed, the point is that your network usage is
grossly unfair and the goodput at 20% loss is substantially reduced,
thus quite far along into congestion collapse.

> the other doesn't (which is why no one will implement it).

Okay, but that was my interpretation of what you wrote. If you believe
that it will not be implemented, fine. I am actually fine with it as
long as the implementation does have some adaptation mechanism. But,
from a specification point of view we did need a stop gap. I think the
progress in RMCAT is clear on that.

I do note that especially when one adds FEC, one do need adaptation. One
cant' use ones redundancy to steam role all other flows sharing a
congested bottleneck.

Cheers

Magnus Westerlund

---

From: John Leslie <[email-masked]>
Date: Wed, 22 Apr 2015 11:29:09 -0400

Magnus Westerlund <[email-masked]> wrote:
> Yes, with FEC.

   We can take Emil at his word that 10% packet loss does not imply
"crappy audio" to at least some users.

   However, Forward Error Correction _is_ leading us down the path to
congestion collapse: in that the reaction to packet loss is to send
more bits. :^(

   How far down that path is an open question... From my experience,
20% packet loss at MAE-East, for example, was too far.

   But we seem to be talking 10-20% at a hotel choke-point. That's a
different story. The damage is mostly limited to hotel customers.
In all likelihood, the _hotel_ would prefer to punish Emil -- but
that's not _our_ job.

> And I pulled 10% out of hat. I should of course [have]  calculated
> the 10* TCP rate for some typical RTT to determine if the circuit
> breaker would fire or not.

   Packet loss is an easier metric for us to understand.

> grossly unfair...

   I doubt folks in Emil's position would agree that 10*TCP is "grossly
unfair". (4*TCP is normal in web-browsing, and IW10 sends a lot more
bits...)

   But perhaps they could agree that 20% packet loss is "too far" down
the road to congestion collapse. (I'm pretty sure they'd agree that
10% packet loss is something the hotel "really-should" fix; and I
suspect we should stay out of that tussle.)

>... I am actually fine with it as long as the implementation does
> have some adaptation mechanism. But, from a specification point of
> view we did need a stop gap. I think the progress in RMCAT is clear
> on that.
> 
> I do note that especially when one adds FEC, one do need adaptation.
> One can't use ones redundancy to steam roll all other flows sharing
> a congested bottleneck.

   My intuition says that 72 kbps goodput must not be guaranteed in
the presence of 20% packet loss -- but that dropping to 0 kbps should
not be the only reduction option.

   YMMV...

--
John Leslie <[email-masked]>

---

From: Martin Thomson <[email-masked]>
Date: Wed, 22 Apr 2015 10:19:02 -0700

> for anything that is variable rate it is not.

That sounds like a problem worth solving to me.

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 22 Apr 2015 12:44:51 -0600

> On Apr 21, 2015, at 8:23 AM, Magnus Westerlund <[email-masked]> wrote:
> 

Ah, OK, that works.  I don't care how it get specified as long as it allows that use case. 

> legacy audio endpoint that don't send RTCP being a likely combination?

Yes, unfortunately, very likely

---

From: Colin Perkins <[email-masked]>
Date: Wed, 22 Apr 2015 23:31:45 +0100

On 21 Apr 2015, at 11:53, Emil Ivov <[email-masked]> wrote:
> Sure, I completely understand the intention. I just think CBs are a very crude attempt of achieving it. Also somewhat redundant in the context of WebRTC.
> 
> I have repeatedly asked for data that shows how CBs are beneficial in large-scale diverse deployments and so far I haven't seen any (I have even been asked by Colin to provide data that they don't work ... which is quite absurd :) )

The benefit is to the network, not to your application, of course. 

And yes, I am looking for cases where the circuit breaker interferes with real applications, because I want to understand if the circuit breaker is being over-sensitive, or if the applications are being unreasonable.

> Well ... it isn't really the same though is it. AIMD doesn't sadistically kill your connection at the first whiff of trouble ... :) ... it just MDs your bandwidth usage.

If the circuit breaker is working correctly, it won't "kill your connection at the first whiff of trouble". It's designed to stop flows that cause long-term and persistent congestion.

> 20%+ regular packet loss and still enjoy productive conversations

Give us some numbers: what packet size, data rate, and approximate RTT are being used for these calls with 10-20% packet loss, so we can evaluate if the circuit breaker will impact them?

-- 
Colin Perkins
https://csperkins.org/

---

From: Colin Perkins <[email-masked]>
Date: Wed, 22 Apr 2015 23:44:13 +0100

> RTCP" seems like a path that doesn't lead to getting rid of the behavior

I tend to agree: this seems like something where the gateway ought to handle the interoperability, and synthesise appropriate RTCP. 

Or, if that's really too onerous, tie into some other consent check that can indicate that the flow is still wanted and not causing problems.

-- 
Colin Perkins
https://csperkins.org/

---

From: Emil Ivov <[email-masked]>
Date: Thu, 23 Apr 2015 08:31:53 +0300

Colin,

Is it really that hard to see that the burden of providing
performence evidence lies with the people advocating a solution?

Please show me the data from all the real world deployments where you
evaluated your mechanism and showed that it performed reasonably well!

Emil

On Thursday, April 23, 2015, Colin Perkins <[email-masked]> wrote:

> On 21 Apr 2015, at 11:53, Emil Ivov <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
> Hey Harald,
>
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
> And yes, I am looking for cases where the circuit breaker interferes with
> real applications, because I want to understand if the circuit breaker is
> being over-sensitive, or if the applications are being unreasonable.
>
> If the circuit breaker is working correctly, it won't "kill your
> connection at the first whiff of trouble". It's designed to stop flows that
> cause long-term and persistent congestion.
>
> You earlier said:
>
> Give us some numbers: what packet size, data rate, and approximate RTT are
> being used for these calls with 10-20% packet loss, so we can evaluate if
> the circuit breaker will impact them?
>
>
>
> --
> Colin Perkins
> https://csperkins.org/
>
>
>
>
>

-- 
--sent from my mobile

---

From: Colin Perkins <[email-masked]>
Date: Thu, 23 Apr 2015 08:46:23 +0100

Emil,

I have repeatedly presented evidence, including measurements on real-world networks and simulations, to show that the proposal works. Varun and Zahed have also done tests and presented their results at IETF. 

You claim the circuit breaker doesn't work in some environments. I'm asking for details, so we can try to evaluate it in similar cases. That doesn't seem unreasonable. 

Colin

On 23 Apr 2015, at 06:31, Emil Ivov <[email-masked]> wrote:

> Colin,
> 
> Is it really that hard to see that the burden of providing performence evidence lies with the people advocating a solution? 
> 
> Please show me the data from all the real world deployments where you evaluated your mechanism and showed that it performed reasonably well!
> 
> Emil
> 

-- 
Colin Perkins
https://csperkins.org/

---

From: Emil Ivov <[email-masked]>
Date: Thu, 23 Apr 2015 12:38:31 +0300

Colin,

On Thu, Apr 23, 2015 at 10:46 AM, Colin Perkins <[email-masked]> wrote:
> Emil,
>
> I have repeatedly presented evidence,

You inadvertently forgot to paste the link to these presentations. I
am particularly interested in the "real-world networks" ones.

> including measurements on real-world
> networks and

The one that I've seen is this:
http://csperkins.org/publications/2013/12/singh2013circuitbreaker.pdf

It discusses a testbed evaluation. That's certainly a useful first
step for a proof of concept sanity check but it is hardly more than
that.

> simulations,

Simulations are handy to evaluate very specific features of CBs in
very specific scenarios.

What we are discussing here is mandating mechanisms that have an
impact in a huge variety of networks.

> to show that the proposal works. Varun and Zahed
> have also done tests and presented their results at IETF.

Here too you forgot to paste the link. I am sure you wanted to be
helpful and this was not intentional, so could you please send them
over?

A quick google search with the names at site:ietf.org does not
immediately yield pointers to measurements on real-world networks.

> You claim the circuit breaker doesn't work in some environments. I'm asking
> for details, so we can try to evaluate it in similar cases. That doesn't
> seem unreasonable.

I am claiming that we don't have sufficient evidence that they work
and am concerned that they would trigger in situations where common
sense dictates they shouldn't.

Now, I understand that our attitude is "we just need a backup plan on
paper because in practice everyone is going to have some sort of
congestion control anyway" and as such having circuit breakers lets us
sort of pretend we did our job. I am fine with this. Let's just try
not to forget it and treat CBs as rules set in stone (which is why I
made the commented that started this discussion).

Emil

> Is it really that hard to see that the burden of providing performence
> evidence lies with the people advocating a solution?
>

-- 
https://jitsi.org

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Thu, 23 Apr 2015 11:53:16 +0200

> sense dictates they shouldn't.

+1

I completely agree with Emil. In fact, as a WebRTC service providers, 
what we are going to do in case of CB is to re-establish the connection 
immediately (maybe disabling video), so in fact the effectivity of the 
CB are going to be null and only add burdens to developers .

Best regards
Sergio

---

From: Luis López Fernández <[email-masked]>
Date: Thu, 23 Apr 2015 12:28:04 +0200

Hi,
I don't have a strong position on this, but my initial feelings are aligned with the ones of Emil and Sergio. For service and technology providers, CB are a relevant concern and can significantly increase the complexity of developments for managing them. For being in favor of CB I would need to see more clear information on their need and also a deep analysis of the algorithms showing that they are compatible with the whole WebRTC ecosystem, which is beyond P2P models. We have quite bad experiences with bandwidth estimation algorithms that seem to work well in P2P but as sub-optimal when an infrastructure is mediating.

Best.

L.

El 23/04/2015, a las 11:53, Sergio Garcia Murillo <[email-masked]> escribió:

> I completely agree with Emil. In fact, as a WebRTC service providers, what we are going to do in case of CB is to re-establish the connection immediately (maybe disabling video), so in fact the effectivity of the CB are going to be null and only add burdens to developers .
> 
> Best regards
> Sergio
>

---

From: Colin Perkins <[email-masked]>
Date: Thu, 23 Apr 2015 12:01:30 +0100

Emil,

> am particularly interested in the "real-world networks" ones.

They're in the IETF proceedings, for example AVTCORE at IETF 87 and 88:
http://www.ietf.org/proceedings/87/slides/slides-87-avtcore-2.pdf
http://www.ietf.org/proceedings/88/slides/slides-88-avtcore-4.pdf

I had assumed you were at the meetings and saw the presentations, but perhaps not.

> step for a proof of concept sanity check but it is hardly more than

You'll also note that it evaluates the circuit breaker on several thousand packet traces taken over the public Internet, to residential users in the UK and Finland. It is, of course, always possible to do more measurements, and in different scenarios, but to say that this hasn't been tested on real networks is false.

> immediately yield pointers to measurements on real-world networks.

See above. 

> sense dictates they shouldn't.

If you have specific scenarios where you want more evidence, that haven't been tested, then you need to explain those scenarios. 

> made the commented that started this discussion).

Given the number of caveats and the flexibility in the circuit breaker, it can hardly be claimed to be "rules set in stone". It's a tool, needed to protect the network, that if designed properly will rarely be triggered, since it's protecting against sustained overload only.

Colin

-- 
Colin Perkins
https://csperkins.org/

---

From: Colin Perkins <[email-masked]>
Date: Thu, 23 Apr 2015 12:07:04 +0100

On 23 Apr 2015, at 10:53, Sergio Garcia Murillo <[email-masked]> wrote:
> I completely agree with Emil.

What scenarios are you concerned with? I keep hearing claims that the circuit breaker is problematic, but have been given no examples. 

> In fact, as a WebRTC service providers, what we are going to do in case of CB is to re-establish the connection immediately (maybe disabling video),

As described in Section 4.3 of the circuit breaker draft, you mean?

-- 
Colin Perkins
https://csperkins.org/

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 23 Apr 2015 15:13:13 +0200

Hi,

I don't want to argue actual numbers here. My main point is that WebRTC 
traffic can be a substantial part of the load on a given congestion 
point. Fairness is always difficult to discuss, as it is a matter of 
time scales, traffic importance, user impact and what can actually be 
done with technologhy being deployed. But we do need mechanism to 
protect the network. Especially when the network doesn't work as 
intended that do happens from time to time.

On a best-effort network, a WebRTC "call" is no more worth than a video 
stream session, a download of an archive, web-surfing, etc.

> not be the only reduction option.

For circuit breaker it is, but the whole point is that if you have a 
better congestion control / bit-rate adaptation then you may be possible 
to support 30 kbps. The circuit breaker do give you the option of using 
7,2 kbps or less when it triggers.

But, I do note if that if your only supported codec is PCM, then it is 
72 kbps or nothing else than RTCP.

The goal must be to have as much flexibility to offer the media 
communication at the best possible quality that is supported by the 
network.

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 23 Apr 2015 15:15:31 +0200

> That sounds like a problem worth solving to me.
I tried, and failed in MMUSIC. See 
https://datatracker.ietf.org/doc/draft-westerlund-mmusic-sdp-bw-attribute/

Cheers

Magnus Westerlund

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 23 Apr 2015 13:38:47 +0000

I have to agree with Colin's request for details and measurements here.

The first thing I learnt about congestion control (in telephony networks based on Erlang's work) was that sounds like a good solution to congestion does not look as good when you either do the maths or simulate it.

So measurements (or the maths if you are expert in things like Markov chains) are needed for the particular use case to prove that the general testing performed by Colin is invalid for that use case.

Keith

> -----Original Message-----
> From: rtcweb [mailto:[email-masked]] On Behalf Of 
> Colin Perkins
> Sent: 23 April 2015 12:07
> To: Sergio Garcia Murillo
> Cc: [email-masked]
> Subject: Re: [rtcweb] Endpoints that don't support RTCP
> 
> What scenarios are you concerned with? I keep hearing claims 
> that the circuit breaker is problematic, but have been given 
> no examples. 
> 
> > In fact, as a WebRTC service providers, what we are going to do in 
> > case of CB is to re-establish the connection immediately (maybe 
> > disabling video),
>

---

From: John Leslie <[email-masked]>
Date: Thu, 23 Apr 2015 09:47:42 -0400

Magnus Westerlund <[email-masked]> wrote:
> 
> I don't want to argue actual numbers here.

   I'm not wild about arguing numbers, either; but there's no point in
discussing this at all if we can't discuss numbers.

> My main point is that WebRTC traffic can be a substantial part of the
> load on a given congestion point.

   True.

> Fairness is always difficult to discuss, as it is a matter of time
> scales, traffic importance, user impact and what can actually be 
> done with technologhy being deployed.

   Fairness is _always_ in the eye of the beholder. :^(

> But we do need mechanism to protect the network. Especially when the
> network doesn't work as intended that do happens from time to time.

   This would imply that if the network "usually" has 20% packet loss,
then we have no obligation to "protect" it from 20% packet loss...

> stream session, a download of an archive, web-surfing, etc.

   Um... No.

   The worth of any Internet stream cannot be judged that way.

   It is actually quite likely that a WebRTC call is more valuable to
the participants than anything else they might do with their connection.
It's not our job to second-guess that evaluation.

   Further, "best-effort" describes the _network_, not the applications
using the network. Thus, "best-effort" is quite orthogonal to "TCP-
Friendly".

   We _may_ feel an obligation to appear "TCP-Friendly" (I don't.)
If so, we should be looking at how to "enforce" reduction of sending
rate in the presence of congestion.

   "Circuit-breaker" is a bad name for that, IMHO.

   Very roughly speaking, a WebRTC application could add 20% FEC bits
to compensate for 20% packet loss. This _is_ a step down the road to
congestion collapse; but it's not -- of itself -- a _big_ step. Its
effect upon competing TCP traffic _is_ substantial (and there may be
political considerations saying we have to reduce that effect).

   "Circuit-breaker" is not a terribly effective way to do that --
especially when the WebRTC application can simply start another call.

> communication at the best possible quality that is supported by the 

   Reasonable...

   (Gotta run: the IESG telechat starts soon.)

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 23 Apr 2015 13:44:22 -0600

> On Apr 22, 2015, at 4:44 PM, Colin Perkins <[email-masked]> wrote:
> 

People keep talking about gateway's but I'm talking about endpoints that do ICE and DTLS-SRTP but don't do RTCP. They also don't do video. 

The reason they don't do RTCP is because they don't perceive a value in it. I'm not arguing this is right or wrong, I'm just saying they don't see the value. The point the folks that think this is a good idea make is that if RTCP says there is X jitter, or Y % packet loss, there is nothing they can do with this. They will not stop the call until the audio is so bad that user hangs up. Only the user hanging up stops the call. Thus the only thing RTCP does is cause more congestion. Again, not saying this is right but given that most the audio only RTP I see on the network does not have RTCP, I don't think this is likely to change any time soon.  And I want to say again, for video it is the opposite story, the bulk of the interactive video RTP I see has RTCP.

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 23 Apr 2015 13:48:20 -0600

> On Apr 23, 2015, at 7:47 AM, John Leslie <[email-masked]> wrote:
> 

I suspect the IESG will expect whatever we do to meet the existing BCPs, which, for the most part, require TCP Friendly.

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Thu, 23 Apr 2015 22:01:16 +0200

> As described in Section 4.3 of the circuit breaker draft, you mean?

 From the draft:

      4.6
      <https://tools.ietf.org/html/draft-ietf-avtcore-rtp-circuit-breakers-10#section-4.6>.
      Ceasing Transmission

    What it means to cease transmission depends on the application, but
    the intention is that the application will stop sending RTP data
    packets to a particular destination 3-tuple (transport protocol,
    destination port, IP address), until the user makes an explicit
    attempt to restart the call.

I think it is a matter of deciding who is the "application", it it is 
the browser or the HTML/JS app running on it. If the congestion detected 
by the CB is signaled in the WebRTC API to the JS, so my application can 
choose what they want to do, then I am completely fine. If we the 
application is the browser and decides by itself what to do, then that's 
where I have the problem.

If the media stops flowing, they are going to blame my service, not the 
network, not chrome/firefox.

Best regards
Sergio

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 23 Apr 2015 18:32:59 -0400

> especially when the WebRTC application can simply start another call.

I'm just a kibitzer here, but IIUC CB indeed doesn't *intend* to do 
that. Rather, its goal is to motivate the application to do something 
better, so that the CB isn't triggered.

	Thanks,
	Paul

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 24 Apr 2015 10:05:42 +0200

> The reason they don't do RTCP is because they don't perceive a value in it. I'm not arguing this is right or wrong, I'm just saying they don't see the value. The point the folks that think this is…

And I'm arguing (thinking out loud) that if we condone this behavior by
successfully interoperating with these devices from WebRTC
installations, we're prolonging the problem.

If our consensus (or consensus-minus-Emil) is that we need devices to
back off on sending RTP in the face of severe congestion for the sake of
the network, and our consensus is that we need RTCP in order to detect
that condition, the only reasonable conclusion is that we should refuse
to interoperate with those devices that do not send RTCP.

These devices already upgraded to ICE and DTLS-SRTP, presumably because
they wanted to interoperate with WebRTC installations. Sending an RTCP
packet once every few seconds is not going to be what kills them.

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 24 Apr 2015 13:41:50 +0200

> discussing this at all if we can't discuss numbers.

Sure, my main point was that the numbers I early put out in the thread 
was not intended to definitive in any sense or back up. But, below I 
will give my opinion on numbers given.

> then we have no obligation to "protect" it from 20% packet loss...

Yes, but that is a network that has a good-put of less than 80% that is 
not something I would like to operate. A lot of resources down the drain.

> political considerations saying we have to reduce that effect).

My personal view is that it is fine to be using FEC to make sensible 
audio when encountering packet loss. But, the total bit-rate in such a 
scenario would be that audio+FEC should use less bandwidth than prior to 
the indication that you have 20% packet loss.

In my opinion a circuit breaker that triggers for a sustained packet 
loss rate of 20% over a time period of seconds, is in fact doing its 
jobb. If there is a short duration, like 400 ms with that loss rate and 
then it otherwise drops down below 5% for the next 5 seconds and this 
flow is in the region of 30-50 kbps in total, then I think that is fine. 
All based on my judgement. I haven't, but believe that if you run this 
case through the circuit breaker, you might get away with it. It is the 
TCP equation based breaker that is the one that will fire here if any. 
So it depends on the RTT and how many loss events this corresponds with.

> especially when the WebRTC application can simply start another call.

Well, to automatically restart/create a new PC when the circuit breakers 
has triggered is not in the spirit of things. The spirit of things is to 
adjust your parameter settings so that it consumes less bandwidth, then 
start it again, or simply let the session be, unless the human user 
insists.

Cheers

Magnus Westerlund

---

From: Emil Ivov <[email-masked]>
Date: Sun, 26 Apr 2015 17:02:52 +0300

Hey Colin,

On 23.04.15 14:01, Colin Perkins wrote:
>> You inadvertently forgot to paste the link to these presentations.
>> I am particularly interested in the "real-world networks" ones.
>

Indeed not. Thanks very much for forwarding!

Unfortunately, as far as Circuit Breakers are concerned I fail to find 
the "measurements on real-world networks" that you mentioned. Maybe I 
missed something?

The results that Varun and you presented are based on a simulation 
derived from a semi-synthetic data set. Zahed's is exclusively based on 
simulations.

All of this is obviously great work and very rewarding to read (some of 
it was new to me), so thanks for forwarding. Still, none of it however 
represents a practical evaluation of CB behaviour.

Ideally what we need in order to validate CBs is:

A) For a given real-world deployment, how much congestion do we see with 
and without CBs
B) For a given real-world deployment, how does user satisfaction vary 
with and without CBs

What I am worried about is that A) might not be particularly important 
because users, server-side apps and JS apps themselves would 
automatically resume calls.

As for B) I suspect that real-world scenarios might cause more cases 
where CBs trigger prematurely, which would have a negative impact on 
user satisfaction.

So with all that in mind I find that at this stage we are likely overly 
confident in CBs to MUST them in cases with no congestion control. Still 
given how people simply ignore the parts they don't like when 
implementing IETF RFCs I don't think we are in the face of a disaster or 
anything ...

Emil

-- 
https://jitsi.org

---

From: Emil Ivov <[email-masked]>
Date: Sun, 26 Apr 2015 17:15:00 +0300

> not something I would like to operate. A lot of resources down the drain.

I don't think anyone wishes to operate such a network. The point is that 
we all find ourselves in them and when we do, we'd rather be able to 
join that important call and make the best of it (and that best is 
actually sometimes quite acceptable to the user even if it looks 
horrible in wireshark).

After all, networks are there to serve users. Not just to be pretty.

> the indication that you have 20% packet loss.

You shouldn't consider FEC as something that is only used as a reaction 
to congestion. Audio codecs such as Opus and Silk allow for inband FEC 
and most apps that I am aware of do turn it on unconditionally prior to 
every call.

> jobb.

This is where I disagree. In many cases sustained 20% packet loss is 
something that inband FEC would fix.

How many users do you think would be happy in such situations when given 
the explanation that: we could have made your call work but it really 
makes us look bad to mess with such crappy networks.

> If there is a short duration, like 400 ms with that loss rate and

Your "spirit of things" does not necessarily coincide with that of the 
application/service providers and users.

Also, given that users will be allowed to insist, what exactly have we 
done to resolve congestion?

Emil

-- 
https://jitsi.org