Re: [saag] Ten years after Snowden (2013 - 2023), is IETF keeping its promises?

Phillip Hallam-Baker <phill@hallambaker.com> Fri, 06 January 2023 16:59 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82BB5C14F73A; Fri, 6 Jan 2023 08:59:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.396
X-Spam-Level:
X-Spam-Status: No, score=-1.396 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B-gy_BnnJ5bq; Fri, 6 Jan 2023 08:59:24 -0800 (PST)
Received: from mail-ot1-f46.google.com (mail-ot1-f46.google.com [209.85.210.46]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09D6AC14F718; Fri, 6 Jan 2023 08:59:24 -0800 (PST)
Received: by mail-ot1-f46.google.com with SMTP id y18-20020a0568301d9200b0067082cd4679so1225256oti.4; Fri, 06 Jan 2023 08:59:24 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=aNCtA1CeMLnM2iBIGCCvpW1uVO6EAMCeRxkIcWWnkLU=; b=xwkLLBmTKGhK5n394sIPewtL3+GfyipC+v979JHKh6XMND6Thsbvqf4q5OrvXvaoIc OPSxsnmf4jtGi01e49BnqV0Rugnq2R9K/+PI8QMj2k5gPuFEjyglKakaufrP9awcQnvQ BG5yDvkz9EsWcCWI4ryFDkUfmXYKF0qUSR3O5hJrHSA/qS1PoenpSvdMNX+8DWz8xDtm dAT2tm171hpy49h2XBCLRqk7LOmTALauFJqpzlr+97dRBRhw4HSBzWHuK5/kuczLkJJr 6fN6Zznm1S4B9hrg3Fga6AKvkzLzqXO0kNGmbCAltfeArOIFHbw6RzwAQ5/jegpaqL26 D1lg==
X-Gm-Message-State: AFqh2koLtNFZmhcWht/gZF1nPTdu429inJrAIaj2qZ/nTmr68OZCHwJh nczOfHXCh20LwHUhrFYU/HnpkUHfUChWc1VBK8I=
X-Google-Smtp-Source: AMrXdXsni6eGZZisIJQeU8wXlnYxO1wJDq66hhE1cvC+8yiKCsZZFF41qlY0IUOgLfbeLmEJKOXsJzGl6cbgwA5wB8U=
X-Received: by 2002:a05:6830:1d8:b0:661:cac2:79ca with SMTP id r24-20020a05683001d800b00661cac279camr3576523ota.93.1673024363240; Fri, 06 Jan 2023 08:59:23 -0800 (PST)
MIME-Version: 1.0
References: <3c3230f3783b4ec9a8a9e3bb87cc2a8d@huawei.com> <08C49067-DB4C-41AB-A6F3-B96BDBE0A4BC@yahoo.co.uk> <CAKr6gn0tFXEV-h7LH1_Ts5iQRw_mGEi=TqS7hsyK-SqDFmmY-A@mail.gmail.com> <C09B3D18-2871-491F-B76C-630A2DCA439A@gmail.com> <EFCEFAA6-3638-4CE0-91DD-3E38FE00DF29@gmail.com> <1F71EB99-3657-4A20-8B28-2AFB743A9762@gmail.com>
In-Reply-To: <1F71EB99-3657-4A20-8B28-2AFB743A9762@gmail.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Fri, 06 Jan 2023 11:59:11 -0500
Message-ID: <CAMm+LwgCxHJYWtv+4ZQdr0-MbSE3qXg6wrT=DZLS=X9pKqpMSg@mail.gmail.com>
Subject: Re: [saag] Ten years after Snowden (2013 - 2023), is IETF keeping its promises?
To: Stewart Bryant <stewart.bryant@gmail.com>
Cc: Dino Farinacci <farinacci@gmail.com>, Lloyd W <lloyd.wood=40yahoo.co.uk@dmarc.ietf.org>, IETF Discussion Mailing List <ietf@ietf.org>, pearg@irtf.org, hrpc@irtf.org, John Mattsson <john.mattsson=40ericsson.com@dmarc.ietf.org>, saag <saag@ietf.org>, Antoine FRESSANCOURT <antoine.fressancourt=40huawei.com@dmarc.ietf.org>
Content-Type: multipart/alternative; boundary="000000000000df246405f19b56d2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/CybeNKKOWnO5Fydwi7kGQ-CeBqI>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "IETF-Discussion. This is the most general IETF mailing list, intended for discussion of technical, procedural, operational, and other topics for which no dedicated mailing lists exist." <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Jan 2023 16:59:24 -0000

On Fri, Jan 6, 2023 at 11:29 AM Stewart Bryant <stewart.bryant@gmail.com>
wrote:

> I suppose that you have to question whether IP is the ideal base for
> multicast?
>
> Our networks are no longer mono-protocol and multicast tends to be domain
> specific.
>
> Many of the original uses for multicast are now dominated by unicast
> packet duplication with edge computing making this less of a bandwidth hog,
> so it is not clear what the long term future of multicast is.
>
> - Stewart
>

What protocols are in widespread use besides IPv4 and IPv6?

Are Akamai and the like really rolling their own network protocols to
squeeze the nth degree of performance out of their networks?


I suspect the biggest barrier for deployment of multicast is the steep
learning curve for implementers. I have no idea how I would go about
getting a multicast address group assigned, no idea how I would set up a
test stand, etc. etc. And the information is certainly not easily
accessible. Then as mentioned earlier, multicast is only giving me a
limited UDP functionality that is essentially unidirectional. I have to do
my own work at transport and above and on top of that, the security model
is changed.

And after all that, the return on multicast is only going to be there if I
have a broadcast application with at least a hundred people watching a
stream on a regular basis.

Anything that does multicast is going to end up involving some sort of
voodoo at the point where one packet goes in and multiple packets go out.
That voodoo is not going to be a function of the router core, it is going
to be something higher level poking that core.

So given modern hardware, does it really make such a big difference if that
voodoo is happening in a processor that is in the router chassis itself or
in another box in the same rack connected by a nice fat pipe?