Re: [tsvwg] tsw/ospa: Internet phone-in-QoS ?

[Sebastian Moeller <[e-mail]>]

Hi Toerless,


> On Apr 15, 2020, at 02:18, Toerless Eckert <[e-mail]> wrote:
> 
> Thanks, Jonathan,
> 
> a) I have a hard time believing that most bigger SP access
> region paths (outside the home) do not at least have WRED (or better).
> (aka: paths between national streaming clous services and 90%
> of subscribers).

	Wasn't the issue with RED, that it requires some tuning and nobody knows how to automate the tuning, and that it increases the RTT-dependent throughput inequality if flows of different RTTs share a congested hop?


> 
> b) Even within an ISP, i can easily see how the ISP would
> (in the absence of other policies) like to give subscribers who
> have bought more bandwidth also a value add for that bandwidth.
> 
> Same bandwidth under cross-subscriber congestion may
> not be supporting the business goals of the ISP best.

	Well, currently ISPs have mostly zero control over bandwidth sharing at congested hops, so even equal fair sharing will be an improvement, and will also not require to propagate per-subscriber data to all potentially congestable hops. I would guess the current system where the edge restricts each user to at max his/her subscribed rate will work reasonable enough even when core links and transit points resort to flow- or IP-fairness.  

> 
> c)  Even in the absence of this "not every subscriber is equal"
> problem, it is not clear to me that bandwidth is used in
> accordance to e.g.: publiic policies if all subscribers get
> the same share - whether they use entertainment or are supporting 
> critical functions".  Medical staff working from home giving video
> sessions to patients for example.

	Well, the challenge for anything "better" than N-tupel-fairness (with different N) requires to propagate per-packet-information to the potentially congested hops. I believe this is done with-in reason using diffserv markings and PHBs, but that does not scale to differentiating "entertainment or [...] critical functions" in a generic fashion.


> 
> We do have public policies applied to other infrastructures
> that are fairly orthogonal to their funding. Emergency
> vehicles on roads, or commuter lanes for example.

	But there we teach each individual controller/driver to yield to higher priority traffic and we sanction invalid dressing-up as the police...


> We already
> had similar problems to corona during the fires and fire
> departments in california (oh sure, why not let fire dpartments
> pay all-year ridiculous ISP prices when they need the
> traffic volume only in regional emergencies...).

	Unfettered "free" market capitalism, or rather old-school Manchester early-stage capitalism hiding behind the fig-leaf of a free market. With an intentional misinterpretation of "free" referring to free of regulation and not free information (only then is a market a resource optimizer), but I digress.


> 
> d) All the "simple" policies ultimately will AT BEST work in
> the IBM-Server/Terminal, oops: cloud-service vs subscriber
> application model, rwhee you try to come up with some
> (IMHO impossible without policy distinction) recognition
> of subscribers, but no limits on servers. Of course, if
> you would recognize "entertainment" vs. "critical infrastructure"
> servers you could have another set of simple workaround.
> But what if you want to have more resilient applications
> based on a model of peers. Where you do not need to rely
> on specific designated services in the cloud but build
> your eg.: resilient ad-hoc conference app solely between
> subscriber IP addresses ...
> 
> Cheers
>    toerless
> 
> (else, why would a subscriber buy that more bandwidr
> 
> On Tue, Apr 14, 2020 at 11:44:10PM +0300, Jonathan Morton wrote:
>>> On 14 Apr, 2020, at 10:46 pm, Toerless Eckert <[e-mail]> wrote:
>>> 
>>> I have been somewhat following how in the face of COVID-19,
>>> the appropriate way to manage congestion control in the Internet 
>>> seem to be heads of countries reaching out to the one large content provider
>>> they know (Netflix) and ask him to reduce bandwidth pressure on the
>>> Internet. Of course, heads of states with differently aged children
>>> would know that Disney+ or Apple might be other relevant streaming
>>> providers to reach out to, but alas, we have forgotten to elect 
>>> those heads of states on such key criteria.
>>> 
>>> That was of course tongue in cheek of course, but i was somewhat surprised
>>> that nobody took up the opportunity so far to ask something like "how are we
>>> doing on Net Neutrality" ?, or "what the heck would we actually want it to be" ?
>>> 
>>> I can see a lot of operational short term workarounds to
>>> approximate solutions less silly than phoning CEOs of random companies,
>>> but it really strikes me as highly strange that events like the
>>> ones we're in right now should not have us re-think to what extend
>>> our current presumed strategy is sufficient???
>> 
>> I'm pretty sure that if ISPs implemented congestion control measures correctly at layer 3, there would be no need to take traffic-source-specific actions so high up the stack (beyond the machine layers) to merely ensure that backhaul networks and peering arrangements are not flooded into oblivion.  I'm talking about simple, well-understood measures such as:
>> 
>> 1: Implement AQM at every potential bottleneck, to limit effect of excess traffic on latency & reliability.  In this context, even WRED without ECN is better than nothing, but doing better would be nice.
>> 
>> 2: Share bottleneck capacity fairly between subscribers, so that one household's heavy traffic doesn't unduly impact the service to other households.  Want to download three Steam games, five Netflix streams and a 500-peer BitTorrent swarm all at once?  Go right ahead, but your next-door neighbour will get just as much bandwidth for his videoconference call about keeping a factory production line going.
>> 
>> If those two measures were widely implemented, there would be no need for data caps, and streaming services' existing quality adjustment algorithms would automatically adjust to match available capacity.
>> 
>> There are already published RFCs detailing all the necessary technology to make this work.  It's already available in many end-hosts and CPE boxes.  It's just not widely deployed and switched on in ISPs' networks, where it can do the most good.  But there *are* a few ISPs who have done it, and thus might be good sources of practical expertise on the subject, if only the industry at large was willing to listen.
>> 
>> - Jonathan Morton
>