Re: [arch-d] A Public Option for the Core

[Joseph Touch <[e-mail]>]

Hi, Toerless,

> On Aug 17, 2020, at 12:46 AM, Toerless Eckert <[e-mail]> wrote:
> 
> Btw, IMHO: Having an application tell the network exactly what it
> wants from the network is quite a challenging task for applications.
> ...
> 
> Hence we thought of a framework where the application would instead
> attribute traffic as to what it is, e.g.: application FOO, wihthin FOO floX,
> e.g.: X = audio/video/...  Aka: Whatever the application developer was able/
> willing to tell.
> 
> Then one can have a trusted layer that would map this information to
> actual network service requirements/advisory information.

That’s an implementation detail inside the endpoint. The *network* should not be doing that inference:

a) because it is typically made to favor the provider, not the user
b) because it’s often incorrect, either because the needed info isn’t available (encryption) or deliberately obscured (running DNS over ports other than 53)

My broader concern is the latter part of the second one: I don’t like the impact of anti-inference strategies on network architecture. It tends to force designers to reinvent the Internet at other layers (inside HTTP, e.g.).

Ultimately, there are only a few things the network can do with a packet: forward it, queue it, or drop it. Having classes of service that don’t map directly to those behaviors is an invitation for unnecessary state and complexity anyway.

Back to neutrality, though, the point is that the *network* should be neutral to the user and use of a service, not that there should be only one service.

Joe