On Tue, Jun 29, 2021 at 4:46 PM Nick Hilliard <nick@xxxxxxxxxx> 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.
