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

Yiannis Yiakoumis <yiannis@selfienetworks.com> Sat, 03 October 2020 00:56 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 5CE953A176C for <network-tokens@ietfa.amsl.com>; Fri, 2 Oct 2020 17:56:01 -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 VUETPTuhX39H for <network-tokens@ietfa.amsl.com>; Fri, 2 Oct 2020 17:55:59 -0700 (PDT)
Received: from mail-ua1-x932.google.com (mail-ua1-x932.google.com [IPv6:2607:f8b0:4864:20::932]) (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 74D153A176A for <network-tokens@ietf.org>; Fri, 2 Oct 2020 17:55:59 -0700 (PDT)
Received: by mail-ua1-x932.google.com with SMTP id z19so862985uap.2 for <network-tokens@ietf.org>; Fri, 02 Oct 2020 17:55:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=selfienetworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:subject:to:cc:in-reply-to:from:date :message-id; bh=V7Xvc0+Dq7/TeshNddpwTNKp8orS00Ab23EP8Sq7EMw=; b=JlXUaB907jCMz6qWWAnOjlhctJ2qV8DEsjok9wDM6jS9q67N7aiYPKRsagjuIBHlS+ j7s7afHpcmUmN44dJZCH65TCgj6gOo8d2WQAWIVJ2qVoaCnBYffl7GVhNm134Z0I89Z+ qLYVZQV2c19ay7xSz7LqpzH0qg4bp4YJ6meHx4wlfVHB33iyamYj7FrWGol1D5KtUDwq h8tyv68BbeBCf/IfhyoI7G6QwPHlQA+G9ZEi8Nt/eGFJLbkpkrKULq+QjbGN1KHC32Z9 1ek4zG6gla5F09ifk5u+qgMua1YOHnFEj2F07Lr/KzX32Bo2VgX004cy6w2JlthmPco3 SEvQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:subject:to:cc :in-reply-to:from:date:message-id; bh=V7Xvc0+Dq7/TeshNddpwTNKp8orS00Ab23EP8Sq7EMw=; b=e536tUeEXwAMgofazS15V4A7Z6W2/0WcdzpVXMWCRLFAGso9xJJ/Z0v1N+mVvWJEzm SgmbGFxPsWe/5Qo2TK3EJlOabSLBtRmLwkLgEU1dhyAEvlerT+vYcJA89rdFUkALCoL0 FSHRYkiTS/XtmSc3Un882lKUeP0XTSSs2XpW/eqJrcs+KdV+4HSsYp6opWEaisUN+gFp fCmfSeQqcVoNxMe0xDhT1pqRvmCWDez58FBF2MHP/UIUdOCUhIyUr4v711322LXZYyhX By5hSliJ7D+CuZ1J0LnMDQIB7Scezzkg4T8CE9frfDReEmgZ8k3v/TpJQ+bDxcIFng44 0Yiw==
X-Gm-Message-State: AOAM533/+fxfMTT216QufNp50wEqw5hHD9/jbbZuwhNoTVhQqitmozYa O9gqh9atDFCsSpxjzLqvunZukW/K2/Fuvg==
X-Google-Smtp-Source: ABdhPJwvyH0otip4oAvsDYoOQ0EqR0HN+xQ3+Of/9DJQpsOADNV6rXvhYMGAUMiuLOYRiFnlSVyObg==
X-Received: by 2002:a9f:29c5:: with SMTP id s63mr2839002uas.34.1601686558093; Fri, 02 Oct 2020 17:55:58 -0700 (PDT)
Received: from localhost (0.92.231.35.bc.googleusercontent.com. [35.231.92.0]) by smtp.gmail.com with ESMTPSA id a73sm481800vsd.6.2020.10.02.17.55.57 for <network-tokens@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 02 Oct 2020 17:55:57 -0700 (PDT)
Mime-Version: 1.0
X-Mailer: Superhuman Desktop (2020-10-02T22:06:00Z)
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> <kfpoveig.b33d3bb7-44af-4609-b592-1b67e085b0e9@we.are.superhuman.com> <09f1a2da-00bf-208b-6242-7229cb10622c@huitema.net>
To: Christian Huitema <huitema@huitema.net>
Cc: network-tokens@ietf.org, 曹畅 <caoc15@chinaunicom.cn>, zhangs366@chinaunicom.cn, architecture-discuss@iab.org, apn <apn@ietf.org>, pengshuping <pengshuping@huawei.com>, Lars Eggert <lars@eggert.org>
X-Superhuman-ID: kfsyt57g.cff9e182-e5f8-4bf8-9fc6-33aa043d03ec
X-Superhuman-Draft-ID: draft004992ff0ce33f00
In-Reply-To: <09f1a2da-00bf-208b-6242-7229cb10622c@huitema.net>
From: Yiannis Yiakoumis <yiannis@selfienetworks.com>
Date: Sat, 03 Oct 2020 00:55:56 +0000
Message-ID: <kfsyp7vy.313f6706-237d-4177-9433-8a5445ea04d7@we.are.superhuman.com>
Content-Type: multipart/alternative; boundary="6044bde947cddeb3e9ad40eb30dd511e0fbbef5480f984ee1ffe016ddafc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/network-tokens/Uk6AHRGOEEXaL0fnVm5Qfq8u3ww>
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: Sat, 03 Oct 2020 00:56:01 -0000

Hi Christian,

You are right - I meant to say access network, and the fact that despite the differences between a WAN and access network the main idea that you can use fine-granularity SLAs to improve performance/cost/efficiency remains valid. Apologies for the confusion.

Best,

Yiannis

On Wed, Sep 30, 2020 at 1:58 PM, Christian Huitema < huitema@huitema.net > wrote:

> 
> On 9/30/2020 11:07 AM, Yiannis Yiakoumis wrote:
> 
> 
>> Hi Lars,
>> 
>> 
>> 
>> On Wed, Sep 30 , 2020 at 12:28 AM, Lars Eggert < lars@ eggert. org (
>> 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.
>> 
>> 
> 
> 
> 
> What do you call WAN? Until now, APN was proposed for "limited domains",
> which are typically access networks. WAN would imply going further, to
> long distance networks used for connections between access providers. Is
> that really what you have in mind?
> 
> 
> 
> 
> -- Christian Huitema
> 
> 
> 
>