Re: Limited Domains:

[Tom Herbert <[e-mail]>]

On Thu, Apr 29, 2021, 12:13 AM Dirk Trossen <[e-mail]> wrote:

> Tom,
>
> I read your comment below as considering limited domains useful for
> innovation and we got to think about ways to facilitate their integration
> into the 'more and more of the Internet'? I think that this aspect is
> crucial when looking at the role of LDs.


Yes, to the extent that LDs are not used as a rationale to create regional
dialects of standard protocols that are non-conforming or not interoperable
with nodes outside the domain.

>
>
> If so, however, couldn't a more flexible addressing be one of those ways,
> among others?
>

Sure, as long as conformance with RFC8200 and other standards is
maintained. For instance, I'd like to see every flow get assigned it's own
unique source address to prevent correlations being made by third parties
on the Internet that different flows are sourced from the same user (CGNAT
already does this somewhat).

Tom


> Best,
>
> Dirk
>
> -----Original Message-----
> From: ipv6 [mailto:[e-mail]] On Behalf Of Tom Herbert
> Sent: 29 April 2021 02:42
> To: Toerless Eckert <[e-mail]>
> Cc: 6man WG <[e-mail]>
> Subject: Re: Limited Domains:
>
> On Wed, Apr 28, 2021 at 4:59 PM Toerless Eckert <[e-mail]> wrote:
> >
> > On Wed, Apr 28, 2021 at 10:51:03PM +0200, Tony Przygienda wrote:
> > > yepp, researchers are having fun unencumbered largely by harsh
> > > realities
> >
> > Well, the better researcher attempt to get more of an understanding of
> > the harsh realities by working with whats available to them, which is
> > quite limited - a few P4 platforms. This lack of openness to
> > multi-party innovation is what causes high-speed router platforms to
> > become less and less relevant and devolve into commodities, at least
> > at the level where folks in IETF are interested in them. Obviously the
> > spped&feed hardware level will stay an ongoing motor of innovation and
> > maybe even sales margin, but for the packet layer forwarding, we can
> > close shop if we do not have a strategy to allow new markets/innovation
> to be brought in.
> >
> > Heck, take a look at the challengers in 5G/6G. They are already moving
> > purely into general purpose CPU because those challengers have no way
> > to put innovation into accelerated forwarding hardware due to lack of
> > access, complexity and also being stuck in a world of standards such
> > as GTP that make innovation difficult.
> >
> Toerless,
>
> While I agree with your sentiment, this is really a lament about a segment
> of the market not about anything IETF has done. For instance, no IETF
> standard  requires high performance routers to be implemented in fixed
> ASIC, in fact I believe the technology has evolved to the extent the
> datapath could go through the CPU simultaneously achieving both performance
> and flexibility (my company is working precisely on that).
>
> The hard problem is legacy and the Least Common Denominator effect. On the
> Internet we are bound by the least common denominator of protocols which is
> plain TCP/IPv4 and TCP/IPv6 that generally make it through the Internet.
> UDP is looking a little better, at least because of QUIC which took a
> behemoth to force support. The end result of all this is the ossification
> of the Internet which as you point out stifles innovation and creation of
> new markets. This is actually the appeal of limited domains, it creates
> walled gardens where in which the least common denominator can be raised
> and we can innovate in that sand box, however limited domains don't address
> the underlying issue unless their scope continually expands to cover more
> and more of the Internet.
>
> Tom
>
> > Its totally incomprehensible to me, why engineers who paycheck
> > ultimately depends on hardware that already is way more flexible than
> > what our current protocols use do not try harder to think about better
> > models for third parties to get more value from this hardware. More
> > flexible, programmable packet forwarding options are one core option
> > here. And obviously no sane customer wants something thats not
> > multi-vendor in this space which is where IETF could come in. And no
> sane network operator wants another protocol silo.
> > Which is where IPv4/IPv6 compatibility comes in as a base level
> expectation.
> >
> > > while meanwhile large scale IP forwarding is still governed by the
> > > microcents/bit payload that customers can run their business
> > > profitably at and this is governed in turn by the merciless trifecta
> > > of physical laws of power/cooling/space that did not only not change
> > > in the last 50 years but last 500 and probably much longer even
> > > before Newton laid his cranium under the said apple tree ...
> >
> > When single-family home systems are built from 19" CPU server racks
> > providing compute across FTTH and powered by solar electricity, i
> > think we are also starting to see big shifts in the economics of those
> > core factors. But thats digression.
> >
> > I think we agree that from the protocols we remember, IP/IPv6 has done
> > a pretty good job providing value out of the hardware deployed. But we
> > also know that other protocols like Ethernet and MPLS have shown other
> > sectors where they are doing better. So it seem to me obvious that as
> > developers we should look ahead and see what it is we can best do to
> > crearte more value. And certainly we know our hardware can already do
> > more than what is utilized by the protocols.
> >
> > Cheers
> >     Toerless
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>