Re: [Apn] [Network-tokens] [arch-d] Questions for APN: Q#5

Lars Eggert <lars@eggert.org> Wed, 30 September 2020 07:28 UTC

Return-Path: <lars@eggert.org>
X-Original-To: apn@ietfa.amsl.com
Delivered-To: apn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 331C63A129C; Wed, 30 Sep 2020 00:28:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eggert.org
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 H3qil8g0TCg1; Wed, 30 Sep 2020 00:28:16 -0700 (PDT)
Received: from mail.eggert.org (mail.eggert.org [91.190.195.94]) (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 687E83A1299; Wed, 30 Sep 2020 00:28:16 -0700 (PDT)
Received: from [IPv6:2a00:ac00:4000:400:64e8:8d4c:6d6a:9695] (unknown [IPv6:2a00:ac00:4000:400:64e8:8d4c:6d6a:9695]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id CF17961795C; Wed, 30 Sep 2020 10:28:01 +0300 (EEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1601450881; bh=lTc5q87Z6+mrj9HwzBckDXlbNgTu0jdIS7iu2WytaEM=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=fiDro4wFtLgno/EUKSkMq4tRF0srliiFULCKdpn/2cnwzXhmTKXSM5RFEu+qx0nK6 OJu01pwCzAoKeJGdHJrUTtY0dAbtG3UMLAP13m1ONHQOHSFuy/yATb+nYfgJ3kLA7d 6WDEsFd980qOs8uUcanDrLrxoXZk5+zGRK4kpo4o=
From: Lars Eggert <lars@eggert.org>
Message-Id: <121369D4-F4C7-44E9-9BFC-FA26A7265E98@eggert.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_EA105A3E-4B70-4198-AA12-CD2BC8FAB7C7"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Date: Wed, 30 Sep 2020 10:28:01 +0300
In-Reply-To: <kfirxvib.fe0473da-51f1-4bd7-91fe-290064021626@we.are.superhuman.com>
Cc: Christian Huitema <huitema@huitema.net>, network-tokens@ietf.org, =?utf-8?B?5pu555WF?= <caoc15@chinaunicom.cn>, zhangs366@chinaunicom.cn, architecture-discuss@iab.org, apn <apn@ietf.org>, pengshuping <pengshuping@huawei.com>
To: Yiannis Yiakoumis <yiannis@selfienetworks.com>
References: <2020092211271508522412@chinaunicom.cn> <4FEADB2A-A062-44B4-8D36-3651EBDD1ACD@eggert.org> <a8542256-b0e7-f6d7-abb1-e2f379215849@huitema.net> <kfirxvib.fe0473da-51f1-4bd7-91fe-290064021626@we.are.superhuman.com>
X-MailScanner-ID: CF17961795C.A4A14
X-MailScanner: Found to be clean
X-MailScanner-From: lars@eggert.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/apn/d6SXa3cY3Z81hLgEHZiUNL8vaJM>
Subject: Re: [Apn] [Network-tokens] [arch-d] Questions for APN: Q#5
X-BeenThere: apn@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Application-aware Networking <apn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apn>, <mailto:apn-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/apn/>
List-Post: <mailto:apn@ietf.org>
List-Help: <mailto:apn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apn>, <mailto:apn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Sep 2020 07:28:18 -0000

Hi,

On 2020-9-26, at 2:22, Yiannis Yiakoumis <yiannis@selfienetworks.com> wrote:
> One of the first successful proof-points for SDN was Google claiming that they moved their WAN utilization to ~100%, instead of over-provisioning. It saved them lots of money. Two of the design principles that led them there were
> i) moving from "all packets are equally important" to "allocate resources based on application-level priorities" and
> ii) moving from "TCP flows regulated by "fair share" mechanisms" to "measure demands, and shape flows at the endpoints".

I think these claims were made for Google's private B4 network, right? AFAIK that is a *very* different network from the public Internet. From what I recall, each transfer over B4 is scheduled over the course of a day based on various flow properties that are required to be specified, following some giant minmax-like computation.

> I can imagine offering low-latency SLA for 1% of the traffic (say video calls), is much cheaper and easier than doing this for all Internet traffic (with the cost varying whether you are in Europe/US or an emerging market, rural or urban, a WISP, a low-orbit satellite network, etc). Could anyone from operator-land comment on the economics of oversubscription/overprovision/SLAs in the mobile world?

Sure. But that could be done with existing mechanisms, like DSCP marking. Remarking/bleaching does happen as traffic gets routed between networks, but since the stated APN use case here is within an operator network, that is under that operator's control.

> (btw: we already have SLAs today --- VoLTE is IP traffic routed through dedicated radio and wired resources and has materially better network quality and reliability than plain VoIP, and when you sign-up for a broadband connection you can get 10Mbps/100Mbps/1Gbps etc).

Yup. And that happens without APN in the picture.

> If over-provisioning wins (in 10 years) it will likely be the outcome of the network community's  failure to find a good solution for traffic differentiation, rather than a verdict that these use cases were not important enough.

The problem isn't that we don't have good solutions for traffic differentiation. We have tons. The problem is that none of the existing ones have seen much deployment - but not because they don't work, because of other issues. I don't see APN to offer materially different/better deployment incentives than what we already have, and so IMO it would share the same fate.

Thanks,
Lars

> FWIW: there are many issues to debate around fine-grained traffic differentiation beyond overprovisioning (like security, scalability, privacy, net neutrality), and there are different approaches one could take (APN and network tokens have different design principles and priorities on these trade-offs).