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

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 29 Jun 2021 14:44:16 -0400

The Internet is a little over 40 years old. It has grown from a research
network connecting ten institutions to a global infrastructure connecting
tens of billions of devices.

My main frustration with the state of IETF today is that many if not most
of the serious challenges we face today are issues we had identified as
problems 20 years ago. They didn't get addressed then because any change
would 'take at least five years to deploy'. So here we are still looking at
the same set of problems.

In the security area, only TLS and PKIX can be considered to have achieved
Internet scale success. Use of OpenPGP, S/MIME, IPSEC, DNSSEC, DPRIV, DANE
is significant by the standards of 1995 but nowhere near ubiquitous.

Users are still second class citizens in the Internet infrastructure.
Institutions get names, machines get names. People get accounts that are
second class identifiers bound to the name of a host or an organization.
Alice cannot have autonomy as [email-masked] unless she actually owns
example.com. And nobody can own example.com because DNS names are rented
not sold. And no, anyone claiming $250,000 for a TLD is anything more than
a shakedown is gaslighting.

IPv6 is slowly deploying but that is only because the pain of IPv4 address
exhaustion is starting to become serious. Meanwhile all our applications
now run over HTTP and not because HTTP is designed to do any of the things
that are needed for application transactions or 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.

Everyone can see that HTTP/2 and QUIC are an improvement on HTTP/1.1 over
TCP, at least for the intended application of browsing the Web. They get
the attention because the Web is the biggest, most successful part of the
Internet. But what about the parts of the infrastructure that don't work so
well. How do we get to fix some of those?

We do not need an Internet/2.0. Most of the basic architecture of the
Internet still applies. And especially if people actually talk to Dave
Clark et. al. rather than accepting the rigid ideological interpretations
of their work from 40 years ago as being inscribed on tablets of stone. But
we do need the Internet to evolve from its current state as a 30 year old
advanced engineering prototype.

What we need to do in my view is to apply a term that was fashionable back
in the mid 90s when the Web came to MIT: Re-engineering. We have
re-engineered HTTP and TCP, how about taking a look at the rest of the
stack?

I have spent the past two and a half years doing exactly that and I think I
have come up with quite a few areas where we can improve things. But I am
probably not the only person doing that (well I hope not) and I am
certainly not the only person with ideas.

PHB

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 29 Jun 2021 21:46:24 +0100

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.

> 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.

Nick

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 29 Jun 2021 17:30:40 -0400

> 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.

> 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.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 30 Jun 2021 11:12:21 +1200

> What we need to do in my view is to apply a term that was fashionable back in the mid 90s when the Web came to MIT: Re-engineering. We have re-engineered HTTP and TCP, how about taking a look at the rest of the stack?

I think we are actually reasonably good at re-engineering. What we are no 
good at is de-engineering. In fact, operational *inertia* informs a lot of IETF work.

The dinosaurs got rid of pulse-code dialling and have in many countries almost got rid of land lines. Guess what, they aren't dinosaurs any more, they are fully fledged and mobile eagles. We can't even get rid of an obsolete, saturated numbering system (aka IPv4).

Maybe we need a de-engineering research group?

Regards
   Brian Carpenter

On 30-Jun-21 06:44, Phillip Hallam-Baker wrote:
> The Internet is a little over 40 years old. It has grown from a research network connecting ten institutions to a global infrastructure connecting tens of billions of devices.
> 
> My main frustration with the state of IETF today is that many if not most of the serious challenges we face today are issues we had identified as problems 20 years ago. They didn't get addressed then because any change would 'take at least five years to deploy'. So here we are still looking at the same set of problems. 
> 
> In the security area, only TLS and PKIX can be considered to have achieved Internet scale success. Use of OpenPGP, S/MIME, IPSEC, DNSSEC, DPRIV, 
DANE is significant by the standards of 1995 but nowhere near ubiquitous. 
> 
> Users are still second class citizens in the Internet infrastructure. Institutions get names, machines get names. People get accounts that are second class identifiers bound to the name of a host or an organization. Alice cannot have autonomy as [email-masked] <mailto:[email-masked]> 
unless she actually owns example.com <http://example.com>. And nobody can 
own example.com <http://example.com> because DNS names are rented not sold. And no, anyone claiming $250,000 for a TLD is anything more than a shakedown is gaslighting. 
> 
> IPv6 is slowly deploying but that is only because the pain of IPv4 address exhaustion is starting to become serious. Meanwhile all our applications now run over HTTP and not because HTTP is designed to do any of the things that are needed for application transactions or 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.
> 
> Everyone can see that HTTP/2 and QUIC are an improvement on HTTP/1.1 over TCP, at least for the intended application of browsing the Web. They get the attention because the Web is the biggest, most successful part of the Internet. But what about the parts of the infrastructure that don't work so well. How do we get to fix some of those?
> 
> We do not need an Internet/2.0. Most of the basic architecture of the Internet still applies. And especially if people actually talk to Dave Clark et. al. rather than accepting the rigid ideological interpretations of 
their work from 40 years ago as being inscribed on tablets of stone. But we do need the Internet to evolve from its current state as a 30 year old 
advanced engineering prototype. 
> 
> What we need to do in my view is to apply a term that was fashionable back in the mid 90s when the Web came to MIT: Re-engineering. We have 
re-engineered HTTP and TCP, how about taking a look at the rest of the stack?
> 
> I have spent the past two and a half years doing exactly that and I think I have come up with quite a few areas where we can improve things. But 
I am probably not the only person doing that (well I hope not) and I am certainly not the only person with ideas.

---

From: Larry Masinter <[email-masked]>
Date: Tue, 29 Jun 2021 16:18:05 -0700

Building Blocks for HTTP APIs (httpapi) - (ietf.org) <https://datatracker.ietf.org/wg/httpapi/about/> 

Might be a more evolutionary approach.

Perhaps an update to BCP 56 (RFC 3205) might be in order.

--

 <https://LarryMasinter.net> https://LarryMasinter.net  <https://interlisp.org> https://interlisp.org

RFC 2324 

   HTTP 1.1 ([RFC2068 <https://datatracker.ietf.org/doc/html/rfc2068> ]) permits the transfer of web objects from origin

   servers to clients. The web is world-wide.  HTCPCP is based on HTTP.

   This is because HTTP is everywhere. It could not be so pervasive

   without being good. Therefore, HTTP is good. If you want good coffee,

   HTCPCP needs to be good. To make HTCPCP good, it is good to base

   HTCPCP on HTTP.

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 29 Jun 2021 16:24:58 -0700

> Perhaps an update to BCP 56 (RFC 3205) might be in order.

Today's your lucky day, as one is currently in AD Evaluation:
https://datatracker.ietf.org/doc/draft-ietf-httpbis-bcp56bis/

-Ben

---

From: Michael Richardson <[email-masked]>
Date: Tue, 29 Jun 2021 19:51:53 -0400

> seconds, minutes, days or even years.

CoAP supports this.

    > and it is not really something QUIC is designed for. Sure we could make do.

CoAP Observe does this.
CoAP works better without NAT because the NAT closes the subsequent S:Data in
many cases.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Kent Watsen <[email-masked]>
Date: Wed, 30 Jun 2021 00:57:50 +0000

NETCONF Subscribed Notifications (RFC 8639) over HTTP/2 also does this.

K.

> On Jun 29, 2021, at 7:51 PM, Michael Richardson <[email-masked]> wrote:
> 
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 29 Jun 2021 22:14:09 -0400

And I am sure this has been re-invented multiple times over.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 30 Jun 2021 15:07:37 +1200

GRASP does this too. Actually, there isn't even a S:Ack needed. There is a timeout for non-response, however.

Regards
   Brian

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 30 Jun 2021 11:38:08 -0500

Thank you Philip for starting this discussion.
I think we should definitely discuss this.

The issue I wish to add is the upcoming LEO satellite networks like Star
Link, OneWeb, and others.

Behcet