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?
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.
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.
Brian
_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
