Re: What is the long term plan for Internet evolution?

[Phillip Hallam-Baker <[e-mail]>]

On Tue, Jun 29, 2021 at 4:46 PM Nick Hilliard <[e-mail]> wrote:

> Phillip Hallam-Baker wrote on 29/06/2021 19:44:
> > telemetry. The reason we run application services over HTTP is really a
> > matter of inertia and the fact that there are simply not enough ports
> > for static port assignments to be viable.
>
> nothing to do with the availability ports. It's that http provides a
> generic transport layer for transmitting any sort of data with low-brow
> signaling to hint at the data format.  It's inelegant in the way that
> any evolved generic protocol is inelegant, but mostly it works like many
> things that evolve to fit a purpose.  DNA coding is inelegant too.
>

Looking at the features from HTTP I use in my Web Services, these are:

1) Multiplexing multiple services onto one host via the URI
2) Sometimes the Content-Type header

And the 99% of Web apps developers are also using the fact that there is
built in support for HTTP/REST or SOAP/WS-* in their tools that they can
make use of without knowing they are doing it.


> IPv6 is slowly deploying but that is only because the pain of IPv4
> > address exhaustion is starting to become serious.
> I've long given up any expectation that ipv6 will outlive ipv4.
>
> You may be fighting a losing battle here.  Protocols and applications
> have evolved together and they work, so any attempt to change is
> battling evolution and that's an uphill job.  Likely, the only way out
> of this is revolution, i.e. when the internet is supplanted by something
> so cool that we nearly won't even bother using the internet any more
> because it's so meh and old hat, like the POTS.
>

The big pain points I see for the current stack are:

1) NAT traversal doesn't work for inbound HTTP. Yes there are features that
kinda sorta work in the tools but they try to do too much and explain too
little.

2) Security is still an afterthought. There is no model for how services
are authenticated. And the Web browser vendors have basically downgraded
the WebPKI so it isn't a solution any longer.

3) HTTP doesn't support the interaction patterns required for either
transactions or telemetry so this is something that has to be built on top.


The last is something I only got to grips with myself a few months ago as i
looked at the communication patterns I really wanted, consider a Web
service transaction, the communication trace is:

< C:Request, S:Response>

That is what a transaction is, right. Nope. Many of my transactions have
people in the middle of them making decisions or big compute loads. So in
the HTTP world we end up with

< C:Request, S:Ack, [C:Poll, S:Pending,] * C:Poll, S: Response>

That is plain ugly. The pattern I really want is:

< C:Request, S:Ack, S: Response>

There is no need to poll, just respond when finished. That might be
seconds, minutes, days or even years.


For telemetry, the pattern I want is

< C:Config, S:Data, S:Data, S:Data, S:Data, S:Data, C:Config, S:Data,
S:Data, ...>

Again, this just doesn't fit onto the TCP or HTTP communication patterns
and it is not really something QUIC is designed for. Sure we could make do.
But I choose not to.


These are the questions that I plan to spend the next five to ten years
working on. If I am successful at getting people to look at these problems
and deploy systems that adopt a re-engineered approach that will become the
next Internet.

If IETF or IRTF says this is something they are interested in doing and
being a part of that type of effort, I guess it will probably happen here.
If they say 'hell no we aren't interested' it will go somewhere else. Over
the course of my career I have played a role in helping to start or
substantially repurpose almost as many industry and standards groups as
protocols.

>From what I am hearing offline, I am certainly not the only person
interested in doing something new.

Oh and maybe I should have mentioned that I have running code.