Re: [aqm] [tcpPrague] L4S status update

>
> “Economic domain” only works if there is a financial cost borne by the
> causer of the congestion.  Good luck making that work, in a world where IoT
> device manufacturers don’t bear the costs of DDoSes launched through them.

I said that.   If *everybody* was charged for the downstream congestion
that they caused, everything would be fair and equitable.  The owner of the
IoT devices would receive a humungo bill and would have free choice to
preserve the device and contribute to financing the target's capacity
upgrade or to have the IoT device repaired.  Assuming that the cost
feedback is real time and various other details, my option #1 leads to a
provably optimal economic solution.    However, as we both noted, it is not
deployable.

Deploying FQ (and various virtual FQ systems, such as AFD) locks out all of
these solutions due to replacing "per packet fairness" at the network layer
(which enables the signaling between flows) with some sort of flow
isolation.   The flow isolation means more control by the network at the
expense of less signalling between flows.

Clearly the Internet already has some of each: we can't easily go 100% in
either direction but which do we want more of?   How can we partially
deploy optimal systems, which are particularly nonoptimal under partial
deployment?

For me the deciding point was realising that 1) at the last mile all flows
are local to the consumer: the competition is self inflicted.  In this
environment is straightforward to make DSCP/TOS controlled SFQ sort of
solutions optimal from the user's perspective.   Generally you want all
small flow to take away from large flows, with perhaps a few large flows
that are deprioritized.   This is where WiFI and DOCIS, etc need to focus.
And 2) congestion not at the edge almost always reflects a problem that can
only be fixed by adding more capacity.   Even with omniscient capacity
allocation all schemes lead to "Somebody can't watch HD video* during
primetime."

If you size the network to (almost always) support HD during prime time,
the core does not need sophisticated TE.   Yes something is needed during
transient overloads

*In some areas substitute other services for HD video.

Thanks,
--MM--
The best way to predict the future is to create it.  - Alan Kay

Privacy matters!  We know from recent events that people are using our
services to speak in defiance of unjust governments.   We treat privacy and
security as matters of life and death, because for some users, they are.

On Tue, Nov 29, 2016 at 4:41 AM, David Collier-Brown <davec-b@rogers.com>
wrote:

> On 28/11/16 10:42 PM, Jonathan Morton wrote:
>
>> On 29 Nov, 2016, at 04:55, Matt Mathis <mattmathis@google.com> wrote:
>>>
>>> Bob's point is that fq_anything forfeits any mechanism for an
>>> application or user to imply the value of the traffic by how much
>>> congestion they are willing to inflict on other traffic.
>>>
>> Yes, it does.
>>
>> I actually consider that a good thing, because most applications will,
>> given the choice, choose to inflict more congestion on other traffic in
>> order to boost their own performance.  There are honourable exceptions, but
>> it’s not a behaviour we can solely rely on.
>>
>> For example, Steam uses between four and eight parallel TCP streams (I
>> can’t figure out what the number depends on) to receive game updates, when
>> one or two would already saturate most domestic Internet connections.  This
>> magnifies the impact on other things the user might be doing with that
>> connection, such as - ironically enough - playing multiplayer games.  You’d
>> think Valve, of all companies, would keep that in mind.
>>
>
> Valve is like a lot of companies in "exciting" areas, and doesn't stop to
> think. Like a lot of other game companies just throw resources at problems,
> willy-nilly. The excessive tuning of Steam is typical.
>
> The gamers know better, but treat the problem as a game and think up cool
> workarounds (;-))
>
> Neither of them falls into any kind of economic domain.
>
> --dave (at WorldGaming) c-b
>
> --
> David Collier-Brown,         | Always do right. This will gratify
> System Programmer and Author | some people and astonish the rest
> davecb@spamcop.net           |                      -- Mark Twain
>
>
> _______________________________________________
> aqm mailing list
> aqm@ietf.org
> https://www.ietf.org/mailman/listinfo/aqm
>