[R-C] BoF approved

John Leslie john at jlc.net
Sun Jul 8 20:22:33 CEST 2012


Matt Mathis <mattmathis at google.com> wrote:
> 
> I would like to point out that nobody has actually disagreed:  If "fixing
> the network" means something like "deploy QoS" then yes it is absolutely
> out of scope.   However "diagnosing (the lack of) QoS" is absolutely in
> scope.  It should have the indirect effect of causing the former,
> irregardless of scope or who owns the problem.

   "Deploy QoS" covers an awful lot of ground...

   I claim that deploying QoS can't fix the problem unless

- the application knows how to invoke an appropriate QoS, and

- there is at least one appropriate QoS deployed where it's needed.

   QoS has tended to "guarantee" a byte-rate, meaning that you get that
rate or you get nothing. This is not quite the appropriate QoS.

   QoS also has difficulty working between providers. Only the intersection
of QoS offerings of the different providers can be guaranteed. This isn't
real close to the appropriate QoS: we kind-of-need something that can
function -- however minimally -- at whatever airport a participant may
be waiting at.

   So, IMHO, "deploy QoS" as a mantra isn't a near-term solution. (What
near-term may mean is left to an exercise to the student!)

> Note that the Internet will almost certainly be better served by QoS
> metrics that are built into all applications and determined by their
> needs, rather than the intent of the QoS implementers.

   I agree -- but how do we get there?

> And (I hope) we all agree that rtcweb can not directly fix network
> problems, no matter how well it performs.

   RTP-congestion work is NOT limited to RTCWEB. Please recall our BoF
is called "RTP Media Congestion Avoidance Techniques".

--
John Leslie <john at jlc.net>


More information about the Rtp-congestion mailing list