Subject: Re: [rmcat] [tsvwg] FW: Fwd: Submitted ID on delay vs. loss-only rate-adaptive for DiffServ

From: Randell Jesup <[email-masked]>
Date: Mon, 23 Sep 2013 10:26:52 -0400

On 7/27/2013 2:14 PM, Dave Taht wrote:
> On Fri, Jul 26, 2013 at 11:33 PM, Michael Welzl <[email-masked]> wrote:
>> On Jul 26, 2013, at 10:54 PM, Brian E Carpenter <[email-masked]> wrote:
>>
>> [..]
>>
>>> That's why the diffserv model includes the need for admission control.
>> +1, exactly my thinking when I read Michael Ramalho's message.
>>
>> So, with rtcweb planning to use DSCPs just because the application decides to do so, rtcweb steps away from this usage of DiffServ, and yes you get prioritization between classes, but any form of guarantees for go out of the window.
>>
>> I always assumed that ISPs would protect DiffServ traffic that needs to get a certain PHB by having their ingress routers scratch the DSCP for all other traffic (e.g. everything that didn't do admission control). If they don't, they better do now…
> What I observe is the only diffserv marking with e2e survivability on
> ipv4 is CS1. Everything else gets re-marked. IPv6 has thus far
>
> That said, there is a great deal of internal-to-site traffic that
> might benefit, and if the bottleneck gateway from that site is
> respecting some markings you have some hope in case of congestion to
> the outside.
>
> Where it might matter some more is on wifi, although the current (vs
> expected) results of 802.11e, at least on Linux, is dismal, without
> admission control. (aggregation works much better)

Working well on WiFi is going to be a primary case (unfortunately).

> Given that the only marking I see consistently respected is BE and BK,
> I can suggest a couple things for rtcweb - when an browser is running
> rtcweb it could try to open less flows than normal for other tasks,
> and it could also signal e2e intent by dropping the classification to
> CS1 on things like tabs loading in the background.

We've already been planning some ideas on how to avoid the browser 
interfering with itself - not just prioritization, but also backing off 
on typical "load everything as fast as you can" behavior (reduce number 
of immediate open TCP connections, use some type of receive-controlled 
bandwidth limiting if possible - strongest lever we have is limiting 
requests or staggering them).  More work is definitely needed here, and 
also this may play better with SPDY and (eventually, maybe) with QUIC.

>> and that would pretty much eliminate the problem, I think: rtcweb would then get priorities applied between its own flows wherever it can, and it won't harm anything that needs to be protected - in such situations, the network just defaults to putting all the rtcweb stuff in the same BE class, and not much harm is being done, I think rtcweb was meant for the BE Internet from day 1 anyway.
> One of the things I like very much about rtcweb is that traffic inside
> your own domain - a call from upstairs to downstairs - STAYS inside
> your own network, so IF CS4/CS5 classification is used, over wifi, you
> would see this traffic drop into the underused hardware wifi VI queue.
> Whether or not this would be a good thing would require some
> testing...

Yes - that would be very interesting (especially for corporate cases).

-- 
Randell Jesup -- rjesup a t mozilla d o t com
[email-masked] (remove -ietf for personal mail!)