Re: [Apn] [Network-tokens] [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: 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 D29643A0A85 for <apn@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 9QFEXHSECG2h for <apn@ietfa.amsl.com>; Wed, 30 Sep 2020 11:07:48 -0700 (PDT)
Received: from mail-vs1-xe2c.google.com (mail-vs1-xe2c.google.com [IPv6:2607:f8b0:4864:20::e2c]) (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 AFDFC3A0A86 for <apn@ietf.org>; Wed, 30 Sep 2020 11:07:48 -0700 (PDT)
Received: by mail-vs1-xe2c.google.com with SMTP id y194so1398162vsc.4 for <apn@ietf.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:in-reply-to:date:cc:references:from:message-id:subject :to; bh=VKQFduxcZiXuNElSMlGqWleVoisGSOSKJeCnUoW3IK8=; b=UuKcAMi7aanpdoyMfsyqgF82uTXVeWUD9BgTZg7wvDDTFPQby30UDTB3c0SnJwhSKE Joz7K8B5iSfNaFixdDRtnzQuM+NEtEzm4yvQKyteYf08IElc8g1gHHCw7AdoU6gHwJRA go//ZJx2afwK69Ka4eN8ix0F82PNnXc4SdyTZynZrR7YCFA0ZwXeOlPzwpkX15kmwHN2 Y8uzWkbZYsri13LLiQHd/DWpO8k7uOVwVhkfljb4wpxp/ujeF+QpY0lHJBjaN2UXYH6D 2SWjRJbwBxt37P4VUhy6t4P1f/7rVL/ea2W/2jrWog1l2dkxjKMUM+btFjo/Jr2EAdV9 +u0g==
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:date:cc:references:from :message-id:subject:to; bh=VKQFduxcZiXuNElSMlGqWleVoisGSOSKJeCnUoW3IK8=; b=LwIWFGPTwxLyqzf/0XSXdCEGDdH6CCbPt/9mxu+yL3HE6tv4mTTBhZl/IHZ7EPCyhS GYULCbXNusIhdNRQeJVMZrypIF+8QgQS3F3yDtgOn+NavairBCrvgYKTsgwIpdx0MkWo EWTwcWiGNDvOa+umTOd7BgMKNdUxBWEoLc6PgzinpGoblVAO6RU2eyLOPSNEuHFFAGw+ mVfNSjDU+IWYfu1o2inntJwDj6wUBee2mPlHaUDWAyasEawaxq/zDQ9qG/4s7bm5HCgt WBuQFRa5ti3iprqvUeqmiosw0lsUsOFtMFrKmONWnck27lzfP9+vPBoNR2AN55vJG5Dj BHbA==
X-Gm-Message-State: AOAM533JZsoNxEIbnx4ZXzTHsX3ZT8qf4esr+u1cJcQ7IDYD5bMCOjNU WUD9mPOA8wOsr8ofL8KwdOspYzc0DcibpQ==
X-Google-Smtp-Source: ABdhPJwjSq5/v4XUeS81LnHNrvjZC1jwMRNO81MvdPe4xBa2tg+V6zmilalbOLWNSTu1T+DqrnuvEw==
X-Received: by 2002:a67:e2c3:: with SMTP id i3mr2574527vsm.13.1601489267317; Wed, 30 Sep 2020 11:07:47 -0700 (PDT)
Received: from localhost (0.92.231.35.bc.googleusercontent.com. [35.231.92.0]) by smtp.gmail.com with ESMTPSA id t15sm378220vso.27.2020.09.30.11.07.47 for <apn@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 30 Sep 2020 11:07:47 -0700 (PDT)
Mime-Version: 1.0
X-Superhuman-Draft-ID: draft000eb7d5cd59bbec
In-Reply-To: <121369D4-F4C7-44E9-9BFC-FA26A7265E98@eggert.org>
Date: Wed, 30 Sep 2020 18:07:44 +0000
Cc: "Christian Huitema" <huitema@huitema.net>, network-tokens@ietf.org, =?UTF-8?q?=E6=9B=B9=E7=95=85?= <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)
X-Superhuman-ID: kfppcgxt.1344815a-a208-41d0-a1ee-ca0f56521104
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>
From: "Yiannis Yiakoumis" <yiannis@selfienetworks.com>
Message-ID: <kfpoveig.b33d3bb7-44af-4609-b592-1b67e085b0e9@we.are.superhuman.com>
To: "Lars Eggert" <lars@eggert.org>
Content-Type: multipart/alternative; boundary=c41069d3cfd51ac41a275d48f4180cd75a29ee94966175a6f2c3995a6fde
Archived-At: <https://mailarchive.ietf.org/arch/msg/apn/oEzT_RcrzhLWiwzXaR614hrCBdk>
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 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).
>> 
>> 
>> 
> 
> 
>