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

Sebastian Moeller <moeller0@gmx.de> Wed, 15 April 2020 07:44 UTC

Return-Path: <moeller0@gmx.de>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 231D23A10D1; Wed, 15 Apr 2020 00:44:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.648
X-Spam-Level:
X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tkZQariMnnvX; Wed, 15 Apr 2020 00:44:54 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 426E43A10C9; Wed, 15 Apr 2020 00:44:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1586936688; bh=wMBQ9qP7AOCSRk/EkYoeBxr/J5eyDwrnpTyDbcNfUME=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=Ele+dALfCVq5hpgqLUv4W+Cp/OoobucT7uEUkVPwqmKe6r7rDAbZu6GGpS1gd1aXr BRPSK4+nNdzwpIBnH9E9b8R3s1mzxvoW3vls/aRafU/k6V06rzoBc72dsdQvpAB1F3 lrP4LqHeXwoje+206D80J2rtsiTnmJFZdpnes1wI=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from hms-beagle2.lan ([77.1.70.235]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MFKKX-1jVR8r078j-00FiOA; Wed, 15 Apr 2020 09:44:48 +0200
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\))
From: Sebastian Moeller <moeller0@gmx.de>
In-Reply-To: <20200414194641.GA29328@faui48f.informatik.uni-erlangen.de>
Date: Wed, 15 Apr 2020 09:44:46 +0200
Cc: tsvwg IETF list <tsvwg@ietf.org>, opsawg@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <2DE9C061-01AB-4471-93BA-3F3A565AA0F5@gmx.de>
References: <20200414194641.GA29328@faui48f.informatik.uni-erlangen.de>
To: Toerless Eckert <tte@cs.fau.de>
X-Mailer: Apple Mail (2.3445.104.14)
X-Provags-ID: V03:K1:b7Jcwf4AO2ZdBfXIGfmbIAzPIXgH2RCtTnU/9X2q0+vzRHV7fqc 7V35mPddISW+zAMUOXB/X0Tiohf++6foJu2vWEIGylTMA3WsWi1jF5817dU2cbw7JSPt1or +bX9205jzLDotG0lep8fUqv1mynHNSWNtO2X++G+GYWdt/tAUCu0wnnvd9rKcof6rcOeyLT iWF6woG/Et36B8ANhqmyA==
X-UI-Out-Filterresults: notjunk:1;V03:K0:Z2RJyUwn+2k=:k9J36DVPEO9LtEFiD9hdNI iGBhkLCmYAsFkglNdQuTSgSdDm41FoEQP+L8XW8rpUrkvwGXs59usORqxnfeX4rb0z7WXuzib KHPT7pG5cOkoYLVRdPzSBP491RKgUhIFCsD5ROqN9CGkNlfdEuJj35u7z7LzO0U1+d6HtrLZ9 k01V3IecQv/Z9b5GAAioIvZKbPbXc5YKNL8zqZu4IBGGw1pHnfV4WVI23T7g/lOOfP3+cdyYG 7EFk+5DjBbTzN8nUUi+jMpsp3WA66n21YiArz5QJEWnmsRqx4kkboRpP35/tANTM98kHsu79A UnHKQj36fosFCpOgAt/2uzyefuh01elGysyqLFFg64yo4pypCVj59zm6Ucb1JRChEAn2h1d8x hDKrPapDIY7d1CuYCgyVZvzDuLuqQHJenS/7aTupWel4NQ8hcXo6iCjVwNs92WdtHgr2yGvZ4 y5Q+J0/lbUe9mW0aJJcvwfZsAtZPDIhM96z4q0QAogaBSK6nArtheeHgIwGtZJ8Q6UTNYIopq dTSD5TP7zBXRYWEvUQmSx2gHeT81UIFPFq63O+HDAOCTO/nhyDFaK1NKnwJ2jxkAczxSEH3EU 8NrCpSGp38+/59fcvUdhu+w+q4R3790sW9DS6uVq6ilLpJnhoY7nALAg5YGNWru1ad2rCOcaU 7ui4x5cKAved/SO3sJW1yHU2G9ojzee5SRuOGTvQugeHYZdTTJPZxVJskxfnzghV8EmIxMvwb lAKIbDBOcyvfRcguJeX4b8qZ9cdBRyF+YdkRcbogNE+WbheU4eMXsw314ZSKYRu1DljHOw6V8 LXHiBU0cnMPYhF8cevQS0bR2TwpY8mpEZeI3oL3Kb4/xUN19/n9PJYOWQ3VwNCDXkX5+Jy2zv S+NPzyTzm6N6dRb3jWCCJVQHZbDxIoLPqeZzYNVbl/WNahsNTZ89TpPMKJojZcyBT2QfBkqkS +Suiz4uW84j0pdWRXRr1HUtgDc1Wo3NJiC7LAVLEFrXOeRQsD3kR5qVjgCxAqAM+2lOGrd2qZ w2ldpKr96J7DDHw5soytrVlvTUjzQ0ExP8cGIPuDHlkAFMU6C/gR5bDQvy45PgDYfkvnB1L3t hNkPD5kbfQyDEvg2C1ADA7AYLmNfwM0UOyaBhmJnuc29QRBgNQd8kYi1JP70mDXg8D6EASYVJ K63DJI3yonaxGCjjg22UbgiOsnUOtD+DjzMnReMUUxIG3IWMsNDUDId2QazHyfKO0L0KI3k3j IHBdmUUfyaHwervsS
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/izkbNwK1Da1Nr6KHR1avYlfyjXk>
Subject: Re: [tsvwg] tsw/ospa: Internet phone-in-QoS ?
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Apr 2020 07:44:56 -0000

Hi Toerless,


> On Apr 14, 2020, at 21:46, Toerless Eckert <tte@cs.fau.de> 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.

	A misconception, it was the EU's commissioner for the internal market Thierry Breton (https://ec.europa.eu/commission/commissioners/2019-2024/breton_en) who technically is not a head of a country. And the twitter messaging with Netflix and Co. was the "PR leg" of a joint statement of the EU commission and the Body of European Regulators for Electronic Communications (BEREC)(https://berec.europa.eu/eng/document_register/subject_matter/berec/others/9236-joint-statement-from-the-commission-and-the-body-of-european-regulators-for-electronic-communications-berec-on-coping-with-the-increased-demand-for-network-connectivity-due-to-the-covid-19-pandemic) aimed at european ISPs giving them guidance how to deal with potential congestion due to shifted traffic pattern caused by the mitigation approaches to limit COVID-19 spread. Reading that makes it clear that the EU accepted that in the current situation, the goal is not to let the consumers feel the quality differences between different ISPs but give ISP exceptional temporary permits to shed network load in line with the EU's net neutrality regulation.
In a sense the EU was presenting the thumb-screws and laid out under which conditions they might be used. Most of the streaming media companies read the signs correctly and decided to pro-actively reduce their bandwidth use on their own terms, instead of risking indifferent packet dropping by ISPs...
	IMHO both sides, the political/regulatory and the private enterprises, acted quite rationally and efficient. The fact that there is currently no wide-spread network overload does not make it a bad idea to pro-actively take measures to reduce known bandwidth hogs... Honestly, that is what I expect from halfway decent policy makers, address issues before the house is on fire (but hey, I also consider how the Y2K situation resolved, not to be a sign of undeserved alarmism, but rather successful mitigation after realization of the importance of the issue).



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

	Nope, at the time of the twitter message disney+ had not started serving Europe yet, Disney came around promising to pro-actively reduce their streaming bandwidth by 25% even before starting.


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

	Sorry, the joint statement explicitly tackled the issue of how to shed overload in compliance with the EU's net neutrality rules and regulations. Now, you might not agree with the taken decision, but that is different from the questions you posed, no?


> 
> I can see a lot of operational short term workarounds to
> approximate solutions less silly than phoning CEOs of random companies,

	Again, that was the PR side, the "meat" is/was in the clarification to European ISPs how to shed load in compliance with the EU's NN rules.


> 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 beyond workarounds:
> 
> - Best effort is all we need

	That is not true today, ISPs and CDN's as far as I know already use SLAs to prioritize e.g. VoIP traffic at peering points, so we already have more than best effort for the few things where it matters?

> - The Internet MUST NOT be able to further distinguish traffic.

	IMHO that is a sane approach because traffic carries very little reliable information to meaningfully distinguish traffic. Sure in an ideal world an overloaded hop would divine which packets are least important and target queuing/dropping to those while keeping important traffic fast. Alas, the required oracle seems to be amiss... Also note that NN rules where pushed, because ISPs where playing games with treating traffic differentially with the sole goal of extracting more revenue/income out of the same amount of traffic, is that really what we want?


> - Its just a matter of more money to eliminate inacceptable congestion.

	That hinges on the definition of "inacceptable", but sure money will allow to increase "bandwidth" and hence reduce congestion for the same amount of traffic (or move the point of congestion to some other place).

> 
> Is this what we want to proliferate ?

	What alternative do you propose instead?


> Am i the only one wondering about this  ?
> 
> Obnoxious as i am i think i should quit my Netflix account and instead
> subscribe to other streaming services for the time being, small enough
> not to be subject to phone-in-QoS. Hmm... HBO or Showtime ??

	Mmh, Showtime only serves the US, and HBO only serves parts of Europe, but assuming you get their content streamed to a receiver in Europe, according to EU commission and BEREC that data could still be subject to throttling (I guess you would need a VPN and hence in practice would avoid being limited).

> 
> Or is the solution really: We MUST only have few big quasi-monopolies, because
> our heads of state only have that much time to control Internet QoS through
> their phone calls ?

	No, we have big quasi-monopolies because economists and so-inclined politicians for decades have chiseled away at antitrust regulations... (I find it delicately ironic that the same people who preach "free market" typically are the first that welcome approaches to side-step the market. It is the same "experts" that simultaneously only see limits to what is okay for a company to do by regulations and the law AND work hard to get rid of regulations and laws, but I digress). 


> Aka: the evolution of the Internet to where we
> are today is really a great thing, especially to manage QoS the way we can ?
> 
> Cheers
>    Toerless
>