[Ecn-sane] [Bloat] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

[Sebastian Moeller]

Hi Dave,

On March 16, 2019 12:43:58 AM GMT+01:00, "David P. Reed" <dpreed at deepplum.com> wrote:
>
>My point is that the argument for doing such balancing is that somehow
>ISPs at the entry points (representing somehow the goals of source and
>destination of each flow) will classify their flows correctly based on
>some criterion, and not select the option that allows them to "beat"
>all the others, which then causes them be "game theoreitically"
>incented to screw up the labeling.

One more argument for splitting the 6 dscp bits, one half for the ISP one half for end to end signalling...
I do neither expect ISPs to honor the intent bits (with the possible exception of the LE patter, there e2e and ISP goals seem aligned) and I also do not see any approach gain traction that completely takes the dscp bits away from the intermediate transports, whether one likes it or not, these effectively are under transport control and are actually used, so hoping the current owner giving all of them back seems overly optimistic. Hence the 50/50 split.


> 
>The business argument that the users at both ends will choose the rignt
>labels is that they are responsive to price signals in a very sensitive
>way that will get them to mark things correctly.

Right or wrong, or how to interpret the different pattern is a question that only becomes relevant once the patterns are signalled robustly end to end...

 (that includes, by the
>way, the Internet Access Providers, if they take over the labeling job
>and force their choice on their users, because they become the
>"endpoint")

Not with the split proposal, and yes end users depend on their ISP doing reasonable traffic management, but that seems orthogonal to dscp bit patterns to me.

> 
>So if pricing mechanisms don't work to incent labeling correctly, it
>does not matter that there exists an optimum that can be achieved by an
>Oracle who fully decides the settings on all packets of all protocols
>ever to be invented.
> 
>And that's why I brought up the issue of pricing and economics, which
>sadly really affect any kind of queue management.

Sure in the context of hoping the ISPs and the wider internet respecting endpoint set dscps that seems all applicable.

> 
>That's why pricing becomes a practical issue, and issues of "utility"
>to the users become important.
> 
>Now the other thing that is crucial is that the optimal state almost
>all of the time of every link in the network is that a utilization far
>from max capacity. The reason for this is the fact that the Internet
>(like almost all networks) is bursty and fractal. The law of large
>numbers doesn't smooth traffic volume over any timescale (that's the
>sense of fractalness here). There is no statistical smoothing of load -
>there are rare high peaks on some links but most links are
>underutilized, *if you want all the protocols currently used in the
>Internet to make users happy with minimal time-to-task-completion*
>(response time at the scale that matters for the particular user's
>needs at that moment).
> 
>So if most links are uncongested most of the time (and they should be
>if the folks maintaining the subnets are all doing their job by growing
>links that are congested to handle more traffic), then congestion
>management is only a peak load problem, and only affects things a small
>percentage of the time.

I concur with Jonathan, access links often run much closer to their limit than core networks, and the whole bufferbloat project demonstrated that a capable AQM system with mild tiering can make a saturated link still acceptable to use even for low latency applications...
But for ingress shaping it would be really great to have some trustworthy way of deducing the sender's intent, and dscps seem like a natural fit.

Best Regards
          Sebastian


> 
>This is very, very different from the typical "benchmark" case, which
>focuses only on dealing with peak loads, which are transient in the
>real world. Most "benchmarks" make the strange and unrealistic
>assumption that overload is steady state, and that users themselves
>don't give up and stop using an overloaded system.



> 
> 
>-----Original Message-----
>From: "Jonathan Morton" <chromatix99 at gmail.com>
>Sent: Friday, March 15, 2019 4:13pm
>To: "David P. Reed" <dpreed at deepplum.com>
>Cc: "Mikael Abrahamsson" <swmike at swm.pp.se>,
>ecn-sane at lists.bufferbloat.net, "bloat" <bloat at lists.bufferbloat.net>
>Subject: Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation
>and experimentation of TCP Prague/L4S hackaton at IETF104
>
>
>
>> On 15 Mar, 2019, at 9:44 pm, David P. Reed <dpreed at deepplum.com>
>wrote:
>> 
>> pricing (even dynamic pricing) of different qualities of service is
>unstable
>
>An interesting result, but I should note that the four-way optimisation
>system I described doesn't rely on pricing, only a sufficiently correct
>implementation of those optimisations at enough bottlenecks to make it
>worthwhile for applications to mark their traffic appropriately. The
>technology exists to do so, but is not standardised in a way that makes
>it usable.
>
> - Jonathan Morton

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.