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

Yiannis Yiakoumis <yiannis@selfienetworks.com> Wed, 30 September 2020 18:07 UTC

Return-Path: <yiannis@selfienetworks.com>
X-Original-To: architecture-discuss@ietfa.amsl.com
Delivered-To: architecture-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85D293A0A43 for <architecture-discuss@ietfa.amsl.com>; Wed, 30 Sep 2020 11:07:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 (2048-bit key) header.d=selfienetworks-com.20150623.gappssmtp.com
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 aLnRccxqFtnG for <architecture-discuss@ietfa.amsl.com>; Wed, 30 Sep 2020 11:07:48 -0700 (PDT)
Received: from mail-vs1-xe33.google.com (mail-vs1-xe33.google.com [IPv6:2607:f8b0:4864:20::e33]) (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 631C53A0A85 for <architecture-discuss@iab.org>; Wed, 30 Sep 2020 11:07:48 -0700 (PDT)
Received: by mail-vs1-xe33.google.com with SMTP id w25so1384210vsk.9 for <architecture-discuss@iab.org>; Wed, 30 Sep 2020 11:07:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=selfienetworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:subject:to:in-reply-to:references:message-id :cc; bh=L5TtD9z/zNv0cQybtJ1XmSEbUctWznbgltbLjRfyOsU=; b=itaIYDRQ1Ll7FbayXoLg1HsfX8J5mtoKaJvHSv/Hpz8PxNOg8UFf6+UzM50Uvg/Kti /40yFDOzXnGhcyJpAhb37+mImks8GyuRSEe6OrN3IRSr28x/sCMCxYJj+50TEFa29by2 ExZPp0B7POxYJfUHXrX/GfRmh3HifIgeQev7MfJIPOHHcmkWPVRblVQg6xHcN6ccB0gS gYbe2vfpQKastoQnsOh4EoBPnzAsmnTD7pVuRlieMPBbpRXKm+z9Y+cT8l1fagDhIA5/ 1eiGzc7sSaUnbO2djq9nPAdUUy6h7Euob6mJsSU7hfD6mIShdD//CvXI+W+VEBOuQsuL CKQQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:subject:to:in-reply-to :references:message-id:cc; bh=L5TtD9z/zNv0cQybtJ1XmSEbUctWznbgltbLjRfyOsU=; b=WvExC9itYpRiETlaZJ+LeH7ofDA+GP4AxeBvqpPPR9Wdnc07BYtvvN+0FQkAlueuTy LWWfxU+/8hPiTu+TH7EPT/QWBPE6lcPDntfSPLaVJ2u4sNRt8wMyXDyTi5sKYLsjpmKn /1ubquUSckNdKd7aUl83Cvee8rej607AY1GdsY9d+MFDHjgZ29YSrU50iCE6+vghyEJf dT+JPPX9z7OoLTJaEJ5asWiYOtbNrOyBfPVBE5J/xKQ4BnKtkc2y7Ty40AlxsiTWnn+p v7A1D+oH1fauDH0SPC0+H358z7yXjtrL2G1yt+zhUNrS00dsRIkE8YicQHniMq5sDhAk szJQ==
X-Gm-Message-State: AOAM532P6A8ySZcPNNMITjpZI9UIPbvOtm8iuGtbc4Zj2g3zk8nwNWzY 0sZ0Q2aDXOrd0c6HzhP9cvwS+HT0TvKhOg==
X-Google-Smtp-Source: ABdhPJxXNqCPptnQDO6XMgYAepXMJa9wJR6qJ4ElocelmhnQzTdt4oWlm2qfiFT3BPCHSXgH4NmvNg==
X-Received: by 2002:a67:79d4:: with SMTP id u203mr2095415vsc.35.1601489266955; Wed, 30 Sep 2020 11:07:46 -0700 (PDT)
Received: from localhost (0.92.231.35.bc.googleusercontent.com. [35.231.92.0]) by smtp.gmail.com with ESMTPSA id e16sm380514vsr.16.2020.09.30.11.07.46 for <architecture-discuss@iab.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 30 Sep 2020 11:07:46 -0700 (PDT)
Mime-Version: 1.0
From: Yiannis Yiakoumis <yiannis@selfienetworks.com>
Date: Wed, 30 Sep 2020 18:07:44 +0000
To: Lars Eggert <lars@eggert.org>
X-Mailer: Superhuman Desktop (2020-09-30T00:20:32Z)
In-Reply-To: <121369D4-F4C7-44E9-9BFC-FA26A7265E98@eggert.org>
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> <121369D4-F4C7-44E9-9BFC-FA26A7265E98@eggert.org>
Message-ID: <kfpoveig.b33d3bb7-44af-4609-b592-1b67e085b0e9@we.are.superhuman.com>
Cc: Christian Huitema <huitema@huitema.net>, network-tokens@ietf.org, 曹畅 <caoc15@chinaunicom.cn>, zhangs366@chinaunicom.cn, architecture-discuss@iab.org, apn <apn@ietf.org>, pengshuping <pengshuping@huawei.com>
X-Superhuman-ID: kfppcgxt.1344815a-a208-41d0-a1ee-ca0f56521104
X-Superhuman-Draft-ID: draft000eb7d5cd59bbec
Content-Type: multipart/alternative; boundary="b9cfd9bf1b445ca1c3af4ec42b4db659f3424ea694cde83dd143378fd615"
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/7ayhysAZNa6CeIncwjvtSZFKE3Y>
Subject: Re: [arch-d] [Network-tokens] [Apn] Questions for APN: Q#5
X-BeenThere: architecture-discuss@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: open discussion forum for long/wide-range architectural issues <architecture-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/architecture-discuss/>
List-Post: <mailto:architecture-discuss@ietf.org>
List-Help: <mailto:architecture-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Sep 2020 18:07:51 -0000

Hi Lars,

On Wed, Sep 30, 2020 at 12:28 AM, Lars Eggert < lars@eggert.org > wrote:

> 
> 
> 
> Hi,
> 
> 
> 
> 
> On 2020-9-26, at 2:22, Yiannis Yiakoumis < yiannis@ selfienetworks. com (
> 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.
> 
> 
> 
> 

Yes, this is for B4. While the network is different, the idea that you can build a much more cost/performance efficient WAN still stands.

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

DSCP marking works within a single administrative domain where you have full control of endpoints and the network. The moment you want to incorporate end user devices and or third-party servers that sit out of the network, it doesn't work well. My comments are not per APN usecases per se, but rather the bigger traffic differentiation picture. (if I understand correctly, APN tries to limit things within an administrative domain to avoid having to deal with trust, security, neutrality, etc).

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

This happens by having vertical integration for a specific use case (phone app, phone driver, network control plane, network data plane ). I would really like to get VoLTE's reliability into my Zoom/FaceTime/WhatsApp calls, but it is not possible.

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

I would disagree here. We do have several traffic differentiation deployments that use DPI and application signatures to map traffic into SLAs at a fine granularity. It is largely inefficient cost and performance-wise, error-prone, and violates privacy and neutrality in certain occasions. But that's the one solution mostly used, for the lack of better alternatives.

Best,

Yiannis

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