[arch-d] Comments on draft-lazanski-consolidation

[Watson Ladd <[e-mail]>]

Dear all,

As someone who works on a team that's implemented all three of the
protocols explicitly listed, it's a bit awkward for me to comment on
the draft. But comment I will.

The brief summary is that I think this draft suffers from trying to do
too much, and if it was split up into section 5 and the rest it would
be much more convincing and productive.

Let me note that aws-us-east-1 having a bad day shouldn't be a news
item. That alone is evidence that there is consolidation in the
provision and location of computer services. But that doesn't really
have a lot to do with protocol changes, and there aren't many examples
of protocols changing in response to consolidation in the draft.

I'm not sure what to make of section 4.2. It discusses the end to end
principle, then says the availability of storage and computation
changes that. NFS has existed for a long time, that doesn't mean the
Internet provides storage. It means servers on the Internet provide
storage. ISPs have always consolidated traffic, at least at the
metropolitan level. They bring it to IXs or their transit links. 5G
isn't changing that. The end to end principle is a principle of
network design, and it isn't the only way to design networks: circuit
switching and store-and-forward networks didn't do it, in part due to
technical limitations. What is the edge to edge principle that this
draft refers to?

There have always been computers on the Internet, providing services
to people. Anyone who has ssh'd into a cluster to run their codes is
using data processing over the Internet. That these services might be
anycasted or spread over multiple sites is not new. It doesn't make
the network intelligent in the way the end-to-end principle argues
against.

All of this change doesn't involve new protocols.

And then the draft discusses ECH, DoH, Privacy Pass as protocols that
could lead to further consolidation. DoH has been discussed
considerably in a variety of fora: I'll simply note that you can pick
your resolver with DNS over UDP as well, and it's not really a
protocol level issue how it was deployed, which the draft
acknowledges. "Centralized" resolvers like 8.8.8.8 existed before DoH.

ECH is I think probably the draft's strongest argument. Any sort of
anonymity service benefits from having more usage, so them that has,
gets. This is why e.g. Tor is prefered over less popular solutions.
It's worth considering these incentives but I think that there is, and
always has been, a variety of shared hosting options. There are some
very real technical difficulties here, and I think all of us would
welcome well thought out proposals. But doing nothing about SNI
leakage is not an option.

Privacy pass I think has been misinterpreted in this draft.. The
multiple server case is really not central, it's a possible deployment
model. The deployment that currently exists and many of the ideas that
have been tossed around are of the single server model: the verifier
only trusts a single server to hand out the token that is then used,
akin to the usher taking a ticket at a movie theater.  Different
deployments use different servers, and there isn't a privacy issue.
The draft is not saying there should be four servers worldwide.

In conclusion I think this draft needs to be split up and each part
further developed and clarified to be a good basis for further
discussion.

Sincerely,
Watson

-- 
Astra mortemque praestare gradatim