Re: [Network-tokens] [Apn] [arch-d] 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: network-tokens@ietfa.amsl.com
Delivered-To: network-tokens@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A04403A0A87 for <network-tokens@ietfa.amsl.com>; Wed, 30 Sep 2020 11:07:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=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 k4D0CTJddyxG for <network-tokens@ietfa.amsl.com>; Wed, 30 Sep 2020 11:07:47 -0700 (PDT)
Received: from mail-vs1-xe32.google.com (mail-vs1-xe32.google.com [IPv6:2607:f8b0:4864:20::e32]) (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 3A49A3A0A43 for <network-tokens@ietf.org>; Wed, 30 Sep 2020 11:07:47 -0700 (PDT)
Received: by mail-vs1-xe32.google.com with SMTP id 5so1397666vsu.5 for <network-tokens@ietf.org>; Wed, 30 Sep 2020 11:07:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=selfienetworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:from:subject:to:references:date:message-id :cc; bh=WqVs8vXpiRIopOlNcxkzkbmU65NroGjrLbxTvK/wO+E=; b=RDAvtN4chM7QDHU4Ji4xK/mgvAIMd/NU2CLHC8zkPrSYaUT9U+6AtmwVplzla8Lpqt D5cxppVAFqxau5hkyxIoQpO/yGCgPz8UJRLHI57FgB0Y6rP34qxFRe6n7mm0szbsqB9R IikQ/buSHx48dJx4LEeud8+q356+oYWg5TUcZZiM2W7+0itXP0jNpnRnlsej/IQ7kaVB 28Bx3SPYR3klGT8GRvZnzNyxwBPm2nlZ/rVcJpTsqaw+hyd8b5BIrOAF6azXObTGLe/d I0SmnAtG2vq+xkEe3RU7dFQy2So0JpmpwgmcuhClUZqoywknRENtk0d4c5Ai+ShyDsy9 VXqQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:from:subject:to :references:date:message-id:cc; bh=WqVs8vXpiRIopOlNcxkzkbmU65NroGjrLbxTvK/wO+E=; b=aJ2oH0ig4I1yGTo1aAOoWmaiz5xqcUH8DW888VaKbodNCCyfaebpzKZ6OWi3Avc0nL ZrnbKDZwNEVVjHBLG9lql+WEyJPVA+roHjCLSqSXwMY3G5zDBlxRtbiW8FOCgTOr+eJj szpvrgUQ4KHysn+kd1Qy05naCOkrLb559Grzp3JQrpnopPdN5x1cRoVD42SC3DC8Oy1z EpmVv0OjGqStpiytsa7BZSJpPur7YngATG6oZKr2MCTeA3iBas6UCWP7bCrgIehNBMTP nQmLETJodCFeyrn0a+pw4P+ztN3z2KyLOenkBZ2Km+wLFcgFG4RJPWmYSiG91ieTk+sr jJGg==
X-Gm-Message-State: AOAM532eKgGjsRE0WoebrqoulYqUMdMrhOH/7UWSOLIJz5++X6ibudQf z/Fde1HJtzgafmaiECq1/ltcTJwfMgdiqw==
X-Google-Smtp-Source: ABdhPJx/2zgU4BVdYQ0rwHMPAlW+hrRHgE07DQvN89dzUNk2rrcOrc2PEH0cPfFVW6RWbuDr0F1pRQ==
X-Received: by 2002:a67:f698:: with SMTP id n24mr2657459vso.23.1601489265855; Wed, 30 Sep 2020 11:07:45 -0700 (PDT)
Received: from localhost (0.92.231.35.bc.googleusercontent.com. [35.231.92.0]) by smtp.gmail.com with ESMTPSA id q8sm389518vsj.20.2020.09.30.11.07.45 for <network-tokens@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 30 Sep 2020 11:07:45 -0700 (PDT)
Mime-Version: 1.0
In-Reply-To: <121369D4-F4C7-44E9-9BFC-FA26A7265E98@eggert.org>
From: Yiannis Yiakoumis <yiannis@selfienetworks.com>
To: Lars Eggert <lars@eggert.org>
X-Superhuman-ID: kfppcgxt.1344815a-a208-41d0-a1ee-ca0f56521104
X-Superhuman-Draft-ID: draft000eb7d5cd59bbec
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>
Date: Wed, 30 Sep 2020 18:07:44 +0000
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-Mailer: Superhuman Desktop (2020-09-30T00:20:32Z)
Content-Type: multipart/alternative; boundary="29f605a4e7bad45f75827fd29306d1a028d9d17ba95e1e95688ae571a174"
Archived-At: <https://mailarchive.ietf.org/arch/msg/network-tokens/YaQVGVYDmu1o4bMqaAcrjeE7kBA>
Subject: Re: [Network-tokens] [Apn] [arch-d] Questions for APN: Q#5
X-BeenThere: network-tokens@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion list for network tokens <network-tokens.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/network-tokens>, <mailto:network-tokens-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/network-tokens/>
List-Post: <mailto:network-tokens@ietf.org>
List-Help: <mailto:network-tokens-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/network-tokens>, <mailto:network-tokens-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Sep 2020 18:07:50 -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).
>> 
>> 
>> 
> 
> 
>