Re: [External] Request for information - Challenges in routing related to semantic addressing

[Jon Crowcroft <[e-mail]>]

i was impressed this paper nade it out of the USA last year:-
https://doi.org/10.1145/3387514.3405875

> Robert,*:
> 
> I would very much hope that there will still be competition in the 
> Internet access,
> even if i also believe this will require more and more regulation given 
> how the
> economics of scale work against a competitive market, but i think more 
> and more
> countries are awakening to that challenge, for example through models of
> non-provider owned access fibers.
> 
> So, when there are multiple access-provider and multiple edge-cloud 
> providers,
> i hope there is enough inter-provider interop requirements to keep IETF 
> relevant,
> but not enough to have the (IMHO) service-killing transit domain in the 
> game.
> 
> Aka: IMHO, the non-profileration of anything but best-effort service into 
> "Internet"
> is really because of transit. If the future dominant paths e.g.: in metro 
> areas
> would become:
> 
> (subscriber/edge-cloudA) -- network-providerA -X- network -providerB -- 
> (subscriber/edge-cloudB)
> 
> Then we might actually have a better chance to grow interdomain services 
> beyond BE
> and make good lemonade out of the lemon that the IETF protocols and 
> Internet model
> is loosing relevance on the global backbone side (at least on total 
> traffic count).
> 
> Cheers
>     Toerless
> 
> On Wed, Mar 03, 2021 at 10:31:07AM +0000, Stewart Bryant wrote:
> >
> >
> > > On 3 Mar 2021, at 10:05, Robert Raszuk <[e-mail]> wrote:
> > >
> > > Hey Stewart,
> > >
> > > If by structural changes you mean that the Internet is shifting to 
> Google's, FB's, MS's etc private backbones ? Of course this will provide 
> path out of this. There is no rough consensus there.
> >
> > Yes.
> >
> > I agree that you do not need consensus on the private backbones 
> although economics or the emergence of a dominant player may define one 
> for us. It is not clear whether the IETF will be in that game, but on its 
> current trajectory I fear that it will not.
> >
> > You do need a degree of convergence in the edge if this is to work 
> efficiently and there are other players such as 3GPP who have a vested 
> interest in solving the problem in a common and efficient way so as to 
> provide the connectivity needed to support the 6G vision.
> >
> > Whether this is one solution or a series of competing solution is 
> unclear. So long as the phone can adapt, and they have proved remarkably 
> adept at doing so, and you can build a continuous path from the network 
> side SDR to the MEC server that is all that is needed, and we fall back 
> to the backbone case where economics and the dominance of the 
> participants is the driver, but commonality is not required.
> >
> > - Stewart
> >
> >
> >
> > >
> > > Ideas are turned into code, being tested and deployed.
> > >
> > > Best,
> > > R.
> > >
> > >
> > > On Wed, Mar 3, 2021 at 11:01 AM Stewart Bryant 
> <[e-mail] <mailto:[e-mail]>> wrote:
> > >
> > >
> > > > On 2 Mar 2021, at 18:21, Tony Li <[e-mail] 
> <mailto:[e-mail]>> wrote:
> > > >
> > > >
> > > > Hi Toerless,
> > > >
> > > >
> > > >> You meantion locator and identifiers as unresolved. Do you think 
> this should be subject to
> > > >> more work in IETF and/or IRTF (routing) ? If so, how ?
> > > >
> > > >
> > > > Not at this point, no.
> > > >
> > > > We are not yet wise enough.
> > > >
> > > > We looked carefully at this. One option was fixing the 
> architecture. The other was a band-aid. We recommended fixing the 
> architecture. The community decided that the band-aid deserved all the 
> effort.
> > > >
> > > > The band-aid has yet to deliver anything meaningful and the 
> architecture is not fixed.  Pretty clearly, the pain level has not 
> reached the threshold where we will act wisely and in our own best 
> interests. If only there was some group that was responsible for the 
> architectural oversight of the network. But alas, there isn???t.
> > > >
> > > >
> > > >> You mention architecture fundamentals and routing / addressing 
> ties. Do you think there
> > > >> such fundamentals that would transcend what i would call different 
> "address semantics",
> > > >> e.g.: unicast, multicast, ICN ? I am asking because if there where 
> such fundamenals of
> > > >> interest, maybe working on them would ease the ability to operate 
> multiple semantics,
> > > >> add and/or extend them.
> > > >
> > > >
> > > > Yes, an architecture has to define all of the uses of the 
> addressing field and explain how routing will make use of the address in 
> each and every case.
> > > >
> > > >
> > > >> You mention protocol field / address overload. I completely agree, 
> but why then have we
> > > >> not attempted to work to easier extend instead of overload packet 
> header / addresses ?
> > > >
> > > >
> > > > Because extensibility at the network layer is seen as Evil.  We 
> decided long ago that it was impossible to have extensible addresses, 
> despite the fact that we had working hardware. Instead, we kludge to add 
> more fields onto the network header, requiring MORE bits to be sucked 
> into hardware, and much more complexity than if we had just made the 
> address field flexible. And we do so in a way that is wholly incompatible 
> with existing hardware AND wastes gigantic amounts of bandwidth.  Good 
> job guys!
> > > >
> > > >
> > > >> E.g.: I look at TSVWG L4S carving out even more semantic out of 2 
> ECN bits and grumble
> > > >> about printing a t-shirt "40 years of IP and all we have for QoS 
> is still 8 bit".
> > > >> (alas, corona times are no fun for t-shirt junkies).
> > > >
> > > >
> > > > And it???s still more than is truly needed. ;-)
> > > >
> > > >
> > > >> Personally, i wish we would never ned to overload semantics of 
> addresses, because we are a) not
> > > >> wasting address space (as you point out) and can b) amend adress 
> space, when needed for new semantics.
> > > >> Now: Why do we not amend our protocols to allow for that ?
> > > >
> > > >
> > > > Because touching the architecture is the third rail.  It is our 
> sacred cow. Pitchforks and torches come out as soon as you talk about 
> fixing IPv6.
> > > >
> > > > Our grandchildren will hate us because we cannot get past our own 
> myopia.  We ossified the inferior and declared it inviolate.
> > > >
> > > > Regards,
> > > > Tony
> > >
> > >
> > > Spot on Tony.
> > >
> > > The question that I have in the back of my mind is whether the 
> de-facto structural changes that are taking place in the Internet will 
> provide a path out of this stranglehold.
> > >
> > > - Stewart
> > >
> > >
> > >
> > > _______________________________________________
> > > routing-discussion mailing list
> > > [e-mail] <mailto:[e-mail]>
> > > https://www.ietf.org/mailman/listinfo/routing-discussion 
> <https://www.ietf.org/mailman/listinfo/routing-discussion>
> >
> 
> > _______________________________________________
> > routing-discussion mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/routing-discussion
> 
> 
> --
> ---
> [e-mail]
> 
> _______________________________________________
> routing-discussion mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/routing-discussion
>