Re: [Int-area] whither multicast?

Jon Crowcroft <jon.crowcroft@cl.cam.ac.uk> Wed, 30 November 2022 10:34 UTC

Return-Path: <crowcroft@gmail.com>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B87BC094EF3 for <int-area@ietfa.amsl.com>; Wed, 30 Nov 2022 02:34:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.395
X-Spam-Level:
X-Spam-Status: No, score=-1.395 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, 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, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 MBvPQpPS8XkB for <int-area@ietfa.amsl.com>; Wed, 30 Nov 2022 02:34:10 -0800 (PST)
Received: from mail-ej1-f53.google.com (mail-ej1-f53.google.com [209.85.218.53]) (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 AEC29C094EF8 for <int-area@ietf.org>; Wed, 30 Nov 2022 02:34:10 -0800 (PST)
Received: by mail-ej1-f53.google.com with SMTP id fy37so40180823ejc.11 for <int-area@ietf.org>; Wed, 30 Nov 2022 02:34:10 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding: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=lUVgQrSqEUbUaIvCa16cwnUFwaKQP+nAXljX8I0+B4Q=; b=q6koynv5Ht4iV2WOaefFpNWqNIVUC1nb8lQMRARDQm1BN0nVEJH844oZmeA0kemMxY ywlYqVe70zpvkacEsHexTUQULRt7l2VuDU1dmgUvVKu6hWZnnQTYu09wpIsEungeivA1 DU2Xt2UsgeNvlGXT/6jiGHu8qgP/m9bRZ6E9C/SJZVrlXGth7pJAQV6GiaNhJJ/2wch9 lJgLg2kKdxh6iV1eh9kGw2YuS3i1yhzJ6DGPSAjqi6X45UNG/czBYTkZdEQUS6CPxu4W wkQUvQzghlmBUy2DTit3/cHDOYiHzOLvvQ0kua1EPGsl+1o4trdV+eVBrR8ipC/C5/zJ ldYg==
X-Gm-Message-State: ANoB5pkSeVxljnTsrDf2WVtTxCHb8APZex6pltsuq4dSk74GyEMmXFib 5/FDngJmmDxv7T1PyZgm1lhhoENMiW+i/4L6m+HB/r4Ic6M=
X-Google-Smtp-Source: AA0mqf5UrO7v+Jqs020Tau/rr6HGD9HTgxFOIwIB4Toonw2M0k6/Spm7Jed9Iqz9mKeNmUYhZ8xgYWsBqs538uL0by4=
X-Received: by 2002:a17:906:f2cb:b0:78d:e645:9f7d with SMTP id gz11-20020a170906f2cb00b0078de6459f7dmr4651413ejb.572.1669804449025; Wed, 30 Nov 2022 02:34:09 -0800 (PST)
MIME-Version: 1.0
References: <370c85345fce475281e985d1d03fb121@huawei.com> <AB24BAC3-6C06-480C-BBE8-11DA80C3072C@gigix.net> <8596.1669774563@hop.toad.com> <a5bc0a086dea4c4e96b0c45ff19cf4d0@huawei.com>
In-Reply-To: <a5bc0a086dea4c4e96b0c45ff19cf4d0@huawei.com>
From: Jon Crowcroft <jon.crowcroft@cl.cam.ac.uk>
Date: Wed, 30 Nov 2022 10:33:57 +0000
Message-ID: <CAEeTejKqqFfbzSaA2f4G3wsNd_xo+5bNJDN6uBw9txNWiW60vA@mail.gmail.com>
To: Dirk Trossen <dirk.trossen@huawei.com>
Cc: John Gilmore <gnu@toad.com>, Luigi Iannone <ggx@gigix.net>, int-area <int-area@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/b2l3hTuqrS_YPmuPbt-DZ12UHGw>
Subject: Re: [Int-area] whither multicast?
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF Internet Area WG Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Nov 2022 10:34:15 -0000

i claim the world has changed since the reasons multicast failed -
within which i include software failures (twice, cisco's
implementation of multicast broke unicast across large sections of the
internet - but this is ancient history) - more recent in network
compute (whether it is P4 in data centers, or just SDN controller
stuff in general, means that three of the major obstacles (in the
Sprint paper by diot et alk: address management, ddos prevention,
billing) are surmountable. actually, if one was to pursue Scion, or
some other accountable internet protocol, then two of these would be
trivial, even for Any Source Multicast (i.e. multicast classic:-)

but i'm still optimisitc about IPv6 too:-)

On Wed, Nov 30, 2022 at 9:49 AM Dirk Trossen <dirk.trossen@huawei.com> wrote:
>
> Hi John,
>
> Thanks for the comments. Please see inline.
>
> Best,
>
> Dirk
>
> -----Original Message-----
> From: Int-area <int-area-bounces@ietf.org> On Behalf Of John Gilmore
> Sent: 30 November 2022 03:16
> To: Luigi Iannone <ggx@gigix.net>
> Cc: int-area <int-area@ietf.org>; gnu@toad.com
> Subject: Re: [Int-area] whither multicast?
>
> > https://arxiv.org/pdf/2211.09029.pdf
>
> The paper is a useful high level review of what multicast promised and why IP multicast has failed so far.  As it says, "The takeaway here is that the woes of previous multicast deployments can be overcome by observing the lessons learned from those deployments..."
> [DOT] Glad to see that you saw useful messages in the paper.
>
> But its cheerful-charlie outlook about its "proposed new multicast semantic" (which exact semantic, isn't clear)
> [DOT] Being called 'cheerful' as a cynical German is quite unusual to me 😉 The attempt was to outline the view that multicast isn't dead or not useful anymore, on the contrary (see other drivers, even outside of where IP multicast would be applied, in Section V). That may count as cheerful already for some though, I admit.
>
> doesn't seem to address any of three major issues in how today's Internet relates to IP
> Multicast:
>
>   *  Should the allocation of hundreds of millions of IPv4 addresses to
>      native multicast be reconsidered?  Only a tiny fraction of them are
>      in use, while unicast is the clear success story of the Internet.
>      Unicast address demand continues to rise, while multicast demand is
>      invisibly small.  IANA has never allocated roughly half of all
>      multicast addresses to anyone for any use (225-231/8 and
>      235-238/8).  The vast bulk, of the tiny fraction that were
>      allocated, are for services now considered obsolete (all but LAN
>      use, e.g. for Neighbor Discovery or MDNS; and all but
>      Source-Specific Multicast, which is limited to 232/8).
> [DOT] To me, this question is a consequence of what is being discussed. If a multicast semantic was to separate WHAT from HOW, questioning the allocation of routing identifiers is indeed valid.
>
>   *  For end-users seeking access to nonlocal IP multicast, over the last
>      few decades, one issue at ISPs continued to get in the way.  Large
>      backbone unicast routers could not reliably be used to forward
>      native multicast traffic, because enabling multicast on those
>      routers tended to make them crash (more often).  When seeking
>      99.9999% uptime for the unicast traffic that pays all the bills,
>      and seeking low network debugging and support costs, having a
>      backbone router crash for even ten minutes a year from running a
>      niche service, caused ISPs too much trouble.  So when multicast was
>      supported at all, it tended to be supported on side-machines that
>      were not in the main pipelines of the ISP, were not as highly
>      capable as the mainline routers, and required custom tunnel
>      configuration from each end-user -- a non-starter for mass market
>      use.
>
>   *  And with few or no ISPs supporting multicast by default, no end-user
>      applications that tried to use it ever caught on.  So there was
>      very little demand encouraging other ISPs to enable multicast.
> [DOT] Both of these last two issues  are part of the chicken-and-egg problem that often exists in technology. If demand was sufficient, striving for matching the supply would usually happen (and being fortified in realization, so without crashing of parts of the supply chain), while the lacking and inadequate supply of course hampers demand.
>
> [DOT] This raises the question on what may break this vicious cycle. We largely approached this from the 'more and new demand' angle. One may think of multicast efficiencies (and the possible impact on the environmental impact of unicast proliferation), which is outlined towards the end of Section V with some example work; I would welcome more thoughts and contributions for this angle, which may also relate to the soon-to-happen IAB workshop on environmental impact.
>
>
> The paper does not seem to address any of those issues.
> [DOT] Not directly indeed - see above - but it's positioned as a working paper in the hope to incorporate wider thinking into a revision, so your comments are certainly useful achieving that hopefully.
>
>         John Gilmore
>
>
> _______________________________________________
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area