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

["Rodney W. Grimes" <[e-mail]>]

> 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).

The model there is "through lambda" at it.  They do not
believe in either AQM or ECN, they truely never expect
the network at that level to experience congestion, and
hence to date pretty much it is "drop" as a signal.

When trying to "sell" ECN concepts to network operators
at this level I usually get told "our network never
experiences congestion because we overprovision."

You may find it hard to believe, but it is a reality.

But, given light of the current situation perhaps it is time
to go back and talk to some of those operators and see if
they now understand that an event may occur that overwhelms
the overprovision and that ECN and AQM's are infact something
worth looking at getting deployed.

> 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.
> 
> 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.
> 
> 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. 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...).

Another business model I see on "congested" subscriber issues
is "its good when my customers link congests and has problems,
they come to me to buy more bandwidth, I really do not care
to solve this problem for them."

That from the mouth of a continent sized telco/internet
provider.

> 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
> 
> 

-- 
Rod Grimes                                                 [e-mail]