Brian,. See inline.
Dirk -----Original Message----- From: Brian E Carpenter [mailto:brian.e.carpen...@gmail.com] Sent: 20 December 2021 21:03 To: Dirk Trossen <dirk.tros...@huawei.com>; Stewart Bryant <stewart.bry...@gmail.com>; Geoff Huston <g...@apnic.net> Cc: Int-area@ietf.org Subject: Re: [Int-area] Where/How is the features innovation happening? On 20-Dec-21 22:35, Dirk Trossen wrote: > Jumping into this late (due to a few days off), see inline. > > -----Original Message----- > From: Int-area [mailto:int-area-boun...@ietf.org] On Behalf Of Brian E > Carpenter > Sent: 18 December 2021 20:51 > To: Stewart Bryant <stewart.bry...@gmail.com>; Geoff Huston <g...@apnic.net> > Cc: Int-area@ietf.org > Subject: Re: [Int-area] Where/How is the features innovation happening? > > On 18-Dec-21 23:00, Stewart Bryant wrote: > ... >> What is important is that we play the cards we are dealt not the ones we >> were dealt in the last game. In other words we need to design for the >> Internet as it will be, not the Internet we designed before and not the >> Internet that we would wish for but which is not economically viable. > > > I don't think that helps. We don't have an accurate crystal ball, any more > than our predecessors did in the late 1970s. They designed a network that was > peer-to-peer at the network layer *and* that was cheaper to implement and > operate than various alternatives (such as X.25, ISDN, and ATM). Capitalism > took that and ran with it, producing an Internet with increasingly > concentrated services at the application layer but still peer-to-peer at the > packet level; it's just that application services are > peer-to-service-to-peer. I have no idea whether anybody predicted that in the > 1970s, but most people didn't. > [DOT] We may not have a crystal ball, indeed, but there are aspects that > outline a desired path forward, termed 'principles'. To what end those > principles will be used may be a different matter but they do provide a stake > in the ground when moving ahead from them. > > Unless crystal ball technology has improved since the 1970s, I don't see how > we will predict "the Internet as it will be". > [DOT] So if we conclude (somehow) the discussions in previous contributions, > the P2P nature of communication between hosts seemed to have been a crucial > principle that was considered in the addressing (and routing) work?! Whether > it is host->host or host->service->host (as we may see predominantly in > today's communication) is somewhat irrelevant from that principle's > perspective, is it not? > > [DOT] If we now observe an increase in host->service->host communication, we > may wonder how to possibly better support this pattern, not just in the light > of the economically driven centralization of that model but also keeping the > more P2P-driven principle alive in realizing host->service->host > communication? There is work providing answers to this question albeit more > aligned with the predominant centralized service provisioning model (see > https://dl.acm.org/doi/pdf/10.1145/3452296.3472922 for one such answer). > > [DOT] Key question here may be what 'service' is of importance, particularly > to the end user? The draft below provides some answers BUT... > > If we think that services will continue to predominate, we could focus on > that, but it might be a completely wrong guess. > https://datatracker.ietf.org/doc/draft-jiang-service-oriented-ip/ > https://doi.org/10.1109/INFOCOMWKSHPS50562.2020.9162749 > > [DOT] from reading through the draft, the realization of the SAT seem (to me) > to imply a rather significant semantic knowledge at the 'SOIP dispatcher' > role - or am I missing something? No, that's correct, and the idea would need a lot more work to turn it into reality. It could be that the dispatcher would really be a policy engine ("User wants search, policy => DuckDuckGo"). The main point is: what happens if we no longer think of the destination address being the primary invariant for routing a packet? [DOT] I do like your last question as a starting point! The question may then become one on how to formulate the policies (for the SATs). Also, could SATs be rather explicit service identifiers? If one wants to position a dispatching over a group of services, it is merely a service itself, identified through its service identifier but then directing to a more specific service as a result of the (service) chaining process. This would generalize the SATs, also removing the need to agree on them (I read SATs as something that would need IANA assignment but maybe I got this wrong). > Also referencing back to my question on what 'service' constitutes, the draft > seems to span from 'network service' to higher layer services, which links > back into the 'dispatcher complexity' question before. Can we have something > simpler? When you look at the raw HTML of a typical web page today, you quickly realise where the real complexity is today. So I think the real question is where to set the boundary between reasonably simple (like an IP address) and too complex for line speed processing. It's clearly a moving boundary, e.g. RFC8986. [DOT] Indeed, see also my point above on what is being identified. > Also, can there be a stronger combination of (existing) IPv6 routing and > service routing (also for efficiency purposes), e.g., for supporting affinity > of longer-running transactions? I don't know. Carrying a transaction identifier at layer 3 sounds like an attractive idea, but our experience with the IPv6 flow label isn't encouraging. [DOT] I'm thinking along the lines of using service identification for the initial routing to a computational instance realizing the desired service, using but using IP routing for sustaining the affinity throughout. This would move the service initiation onto the IP routing path once the original decision which instance to be used has been made. Brian _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
