Re: arguments for Edge
Phillip Hallam-Baker <phill@hallambaker.com> Sat, 03 July 2021 16:09 UTC
Return-Path: <hallam@gmail.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B1953A1A8D for <quic@ietfa.amsl.com>; Sat, 3 Jul 2021 09:09:07 -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 N5nQFNeueJWR for <quic@ietfa.amsl.com>; Sat, 3 Jul 2021 09:09:02 -0700 (PDT)
Received: from mail-yb1-f182.google.com (mail-yb1-f182.google.com [209.85.219.182]) (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 877843A1A8B for <quic@ietf.org>; Sat, 3 Jul 2021 09:09:02 -0700 (PDT)
Received: by mail-yb1-f182.google.com with SMTP id i18so21521032yba.13 for <quic@ietf.org>; 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=t61aDCZLqzihiziwOrYzBit0U3pkVaX8lrhMSVRDTVmZxLlNNAgjQ/1VapSB2Q0GZ3 cxJPBqks2AB+NAJRDbwZNc/0frRgUCEqFCwnnJ9x7af5QgkOMFTD1ECJO8BJRx17KRKS tV8XpNi1R75M6kitFHhf9lKTGXqysFylcG0Xf8vVoKDyvwwck9VquahCdAukhgKlPj1i QZxt2CAHG5H+zsGi/6qG0zUYJm2s9rWrzcT8oQHv8mfvKgnUs27f5mKMK/alHBuBFTGF GH0cbPVK4WM7PfP3KP68yYMI89olcVwNqs/V3lA6rWey22mY2+pZrcb319VzXRs6Vc/8 KhBw==
X-Gm-Message-State: AOAM533TlI228jswu94YVk1xsh9g418RNrTzJEpzpI9VS/3xARrYxag2 evoWUgfBaxhjqwz3Z+V/4FJ435cNf29xCpwBgRE=
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, 03 Jul 2021 12:08:31 -0400
Message-ID: <CAMm+Lwgq_LEj7UCtLhEsrQxE9+gYa3DKkXbN8k5bUWwnv5uVnQ@mail.gmail.com>
Subject: Re: arguments for Edge
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/quic/jTMM5XpOuilMQTVhA9FcoDd32cc>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.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 > >
- ACM SIGCOMM HotNets'21 DL in 30 days Aaron Ding
- Re: arguments for Edge Phillip Hallam-Baker
- arguments for Edge Aaron Ding
- Re: arguments for Edge Dave Taht
- Re: arguments for Edge Aaron Ding
- Re: arguments for Edge Phillip Hallam-Baker