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

[Toerless Eckert <[e-mail]>]

On Mon, Aug 17, 2020 at 07:47:04AM -0700, Joseph Touch wrote:
> > 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.

See my prior answeer to andrew. Just because something may end
up as an implementation inside an endpoint doesn't mean it couldn't
be good work to standardize the abstract API.

Also, what is a host. A bog with a bunch of containers orchestrated
together via linux bridges ? ;-)

Scott McNealy: The Network is the Computer.

Aka: Just a matter of how we model things.

I know, for a lot of old-time IETF'er, looking inside a physical
box s heresy, but hey, we are even getting TAPS interface RFCs
as standards track documents (horray!).

> The *network* should not be doing that inference:
> 
> a) because it is typically made to favor the provider, not the user

And folks in ISOC may argue that in other countries it will
favour governments. And i think we understand these challenges
and can build solutions accordingly.

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

Sure, IMHO just a technical challenge we can solve. And remember
that in vertically integrated networks (see BrianC limited domains)
visibility by the network is desired:

In a vertial network solution, the application LOVEs to expose the RTP
header so that jitter,latency,loss,reordering per flow can be monitored
hop-by-hop by the network, problems quickly be isolated and fixed.

If an OOT application does not want that service, it can encrypt
everything. Why not.. I am sure the OOT will do exactly the same
unencypted headers within its own DC for troubleshooting, diagnostics.

Aka: the only problem we have in IETF is that we hear mostly from
only one side of the spectrum of relevant options, and thats the
OTT that do want to prohibit anything more than cheapest cost best
effort service, because that type of network service is the basis
of their business model and anything better wold be competitive to
their business.

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

Yes. But even worse  is as i said above the influence mongering
to ensure that no alternative technologies are allowed to be worked
on in the IETF - by making the sham argument about what is or is not
good for "the Internet". Such as when SPUD/PLUS where acted against.

To make a funny analogy: There are use cases that rightfully so go
even much further in their anti-inference/perpass strategy than the OTT,
but they do not go running around the IETF trying to argue their way
is the only way the IETF should go.

Aka: If you want to see the (crrent) final word on protection against
perpass: draft-ietf-ipsecme-iptfs ;-))

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

You forgot FEC insert/delete , duplication&merge, or even more general
network coding). And of course there is a huge variety of differences
in service level objective outcomes by how you forward (QoS routing),
and/or how you queue.

Having worked for decades on per-flow behavior in routers i do think
that the most interesting area to explore is one which does not require
per-flow state but allows to distinguish SLO on a per-packet level.
This would allow us to introduce INtServ like functionality with even
better than DiffServ scalability.

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

Well... I would love to say "exactly right", but:

a) Is there actually any accepted definition of net neutrality
that says exactly this ?

b) Even that definition goes way beyond differentiation in any
other type of market. E.g.: If you are a tier1 OTT like e.g.:
netflix, amazom prime, your ability to get your cache into
pops of access SPs or peering bandwidth etc. is just going to be
a lot better than a tier2 OTT will get. Aka: We already today
have the same type of "volume of the deal" negotiations.

But we have this in any other market as well. German example of course
being: oh, you want to buy 50,000 cars for your employees...
of yourse you get better pricing and/or get them earlier or
get specials we don't offer to other customers.

Aka: How do we argue that selling of packets should be different than
selling of cars ?

Toerless

> Joe
>