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

[Christian Huitema <[e-mail]>]

On 8/17/2020 7:47 AM, Joseph Touch wrote:
> Hi, Toerless,
>
>> On Aug 17, 2020, at 12:46 AM, Toerless Eckert <[e-mail]
>> <mailto:[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)

At the bottom are issues of knowledge and trust. As Toerless points out,
knowledge itself is hard. Application developers have a hard time
understanding the network service that they actually want. Even examples
that appear trivial, like video, are not: the video refresh rate and the
desired definition depends on whether the video is displayed as a post
stamp, as a square in a grid, or full screen, not to mention adaptive
coding to actual images. Asking applications to label their traffic
leads to compromises.

From the provider point of view, trusting the labels set by applications
is fraught with a different kind of compromise. What if every
application pretended to be a real time service requiring super high
quality of service? What prevents the application from lying? Would that
lead to collapse? Those fears are very much there, which is why network
providers tend to rely on DPI, and not use application labels much.

In theory, labels could be trusted if the users were paying for the
extra service. In practice, paying for extra service happens very
rarely. First, there is the knowledge issue, why would applications
incur extra costs without knowing why? Then, there is the
interconnection issue. Most network paths involve several network
providers. The one with a business relation with the user might be paid
for the extra service, but what about the others? That would require an
agreed framework allowing for example traffic providers to charge the
ISP for the labelled traffic that they emit. Good luck with that.

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

Or to encrypt everything, which is very much the current trend. And to
add padding and cover traffic to try defeat fingerprinting. And possibly
to deploy end-to-end FEC.


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

I don't know that. Given the knowledge and trust issue,
one-size-fits-all looks actually very practical. That does mean a
compromise, because the network should allow those applications that
want low latency to get it, but should not limit the bandwidth that
applications can use if it is available. That probably requires more
research and development in active queue management, and in congestion
control algorithms that can cooperate with active queue management and
deliver the profile that fits the application.

-- Christian Huitema