Re: [icnrg] arguments for Edge

Phillip Hallam-Baker <phill@hallambaker.com> Sat, 03 July 2021 16:09 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: icnrg@ietfa.amsl.com
Delivered-To: icnrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 012A43A1A8B; Sat, 3 Jul 2021 09:09:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.402
X-Spam-Level:
X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.248, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 6Ks_AxYX3HQG; Sat, 3 Jul 2021 09:09:03 -0700 (PDT)
Received: from mail-yb1-f170.google.com (mail-yb1-f170.google.com [209.85.219.170]) (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 085F53A1A8C; Sat, 3 Jul 2021 09:09:02 -0700 (PDT)
Received: by mail-yb1-f170.google.com with SMTP id g19so21515850ybe.11; Sat, 03 Jul 2021 09:09:02 -0700 (PDT)
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:in-reply-to:from:date :message-id:subject:to:cc; bh=NfdevZYT4/mmYjvP/F6j/X7+z1gtq1k6XNlqG78/Pzk=; b=of4rl4PkftOOXBNCbnQLZcFHuWdDcWegS+wXpR1DXFTcFHk+mIlTfa/CFIqpkfm2Ir 0zMu52cNn3TQc4Y8cQc8fwQPAHD+Mgevn8sPRbZ7qF5n1cifjjEaFoRwPGayo4yQuBKk FM0egVCmxKPcJNH+RvN7w8XHi/3xoR7zxu3qUnG9N9ZWvGPgSPd+YVS7ILgn4sGd47Nu f6X8hQS9newq+RIQE7Zro1zdzT+mdmbeyZHkRnJfCuLKfqLQARSpY2nkUWt5LyZl57E/ 3MfzszVASjom/HOWmb6dvmXvquMTKCJv0oUrkKF2aPNWmZp6MnHzVP7KQzjgKr7dhUaf N2hA==
X-Gm-Message-State: AOAM533cl6ro7/eNvtuFFAEZp7PkzQ+EltFzYC0MbIUMcAHVKJu0q8JY OzCoLy+BoVb97QrVDSveErUv4Xh6zr0F4IVt5kU=
X-Google-Smtp-Source: ABdhPJy7GiGo/BKhqdvU8PhjfWL+G1Q9U6uHVTW/UG+ZBA8LYfuermEsF9QblrvbHBoQ3VPepBXkXp3JN14fGztQdkU=
X-Received: by 2002:a25:37c8:: with SMTP id e191mr6124662yba.172.1625328541483; Sat, 03 Jul 2021 09:09:01 -0700 (PDT)
MIME-Version: 1.0
References: <5907c434e2919aba66d5f4729f39571f@tum.de> <3dbaa780606f9b0aa4bdffd01fc9287f@tum.de> <CAMm+Lwgdcx_ak4HqJYxjKbE7tZ7eT4AEPX=hEt+oQDaStBMwcw@mail.gmail.com> <e7f4ea77f1f22820f15bf58dc9396db7@tum.de>
In-Reply-To: <e7f4ea77f1f22820f15bf58dc9396db7@tum.de>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Sat, 3 Jul 2021 12:08:31 -0400
Message-ID: <CAMm+Lwgq_LEj7UCtLhEsrQxE9+gYa3DKkXbN8k5bUWwnv5uVnQ@mail.gmail.com>
To: Aaron Ding <aaron.ding@tum.de>
Cc: dave.taht@gmail.com, IETF QUIC WG <quic@ietf.org>, icnrg@irtf.org, t2trg@irtf.org
Content-Type: multipart/alternative; boundary="0000000000005bc65805c63a4a6d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/icnrg/nX921f7JOf54O3pp0BKEF47XOII>
Subject: Re: [icnrg] arguments for Edge
X-BeenThere: icnrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Information-Centric Networking research group discussion list <icnrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/icnrg>, <mailto:icnrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/icnrg/>
List-Post: <mailto:icnrg@irtf.org>
List-Help: <mailto:icnrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/icnrg>, <mailto:icnrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Sat, 03 Jul 2021 16:09:08 -0000

I haven't really thought about routing since doing my undergrad thesis 35
years ago. And that wasn't on Internet routing. Since I have been focused
on the application layer and above, I haven't really thought about routing
as something which is mutable. So I learned how it worked, and that is it.

Having had occasion to do a writeup on BGP etc for a client recently, it
occurs to me that there is more that could be done if we were to relearn
some of the original principles of the Internet that Einar Stefferud used
to do a very good presentation on.

The Internet is a network of networks and that is NOT the same as a
network. So the Internet needs to be really really simple. Just take a
packet, do a lookup, shove it down a pipe.

But on the way, we have acquired a number of assumptions that are actually
false:

1) The End to End principle should only apply across the origin and final
destination.
2) Communications should be Internet Protocol start to finish.
3) Every packet needs a source address.
4) DNS is the only naming system we need.
5) ASNs are just an optimization to compress routing.
6) Multicast proves nothing can be done at the routing level because it
can't be deployed.

For the past two and a half years, I have been working on re-engineering
the security side of the Internet and have come up with an architecture and
implementation that addresses what I see as the biggest, most urgent
security problem today: securing Data At Rest. To solve this problem, I had
to solve the problem of how to manage private keys which is actually the
real roadblock to applying PKI to user side security.

There is one really big security issue I haven't addressed in the Mesh and
it is going to be an increasingly big one as we face nation state level
attacks: Denial of Service. To date we have only come up with mitigations.

If we are going to come up with a DoS defense that is effective against
nation state level actors, we are going to need to change the way routing
is done.


What I would like is some sort of forum that is more like a room in 545
Tech square with a lot of whiteboards and conversation under Chatham house
rules and 'there are no stupid proposals' rules.

Also, I think we need to go back to look at buffer bloat and ask how it
actually occurs and whether it is a routing level or a TCP level issue. I
have a feeling there is a bit more going on there.



On Sat, Jul 3, 2021 at 3:15 AM Aaron Ding <aaron.ding@tum.de> wrote:

>
> Nice deduction and bufferbloat hint.
>
> For colleagues interested, this 'Revisit Edge' is now on IEEE Internet
> Computing:
> https://ieeexplore.ieee.org/document/9470987
>
> Aaron
>
> On 27.06.2021 13:10, Dave Taht wrote:
> > I think the arguments for re-invigorating the edge are stronger than
> > ever.
> >
> > But first up, we gotta fix the bufferbloat everywhere.
> On 27.06.2021 17:20, Phillip Hallam-Baker wrote:
> > The paper states typical latency is 30ms
> >
> > Thus we are limited to 15 round trips per second.
> >
> > I have a 960Gbs = 120 GBs Internet connection
> >
> > Assuming 1260 byte packets, that means 95238 packets a second
> >
> > So we must have an average of 3174 packets unacknowledged at 30ms
> > latency
> >
> > Get latency down to 1ms and the number of unacknowledged packets goes
> > down
> > to 100.
> >
> > On Sun, Jun 27, 2021 at 5:15 AM Aaron Ding wrote:
> >>
> >> Is the motive for Edge (i.e., latency) diminishing since its first
> >> concepts were formulated more than a decade ago?
> >>
> >> A recent work to share on "Revisiting the Arguments for Edge Computing
> >> Research":
> >> https://arxiv.org/pdf/2106.12224.pdf
>
>