[Bloat] quick review and rant of "Identifying and Handling Non Queue Building Flows in a Bottleneck Link"

[Dave Taht]

On Thu, Nov 1, 2018 at 3:39 AM Michael Welzl <michawe at ifi.uio.no> wrote:
>
> Hi,
>
>
> > On 29 Oct 2018, at 05:02, Dave Taht <dave at taht.net> wrote:
>
> >
> >
> > Dear Greg:
> >
> > I don't feel like commenting much on ietf matters these days
> > but, jeeze,
>
> (snip)
>
> There seems to me to be a disconnect here, the core of which is this comment:
>
>
> > Did I rant already that the vast majority of flows are non-saturating?
>
> That's a bug, not a feature - and you seem to treat it as an unchangeable fact.

It's been the case for 50 years. Until we have one sole source of data
(which given industry consolidation is seemingly increasingly likely),
coming from one big machine (unlikely). The original cablelabs (2012?)
study of this stuff assumed that growth of a web page would be past
6MB by now, it instead is under 3.

> Despite the undebatable importance of bufferbloat and its impact on e2e packet latency, this is only one of the factors playing into the "latency" that I perceive when I click on the link as I surf the Internet.

Doing a breakdown of that latency - most of that seems solved...

Background prefetch
DNS lookup
SSL connection negotiation
The actual transfer.
Screen draw....

I'm still missing your point. Is looking for "sparseness" part of a
CCN-like effort?

In my mind QUIC, when basically nailed up, with its improvements to
tcp (0-rtt crypto, pacing, bbr) is in the end game here, and "if only"
fq existed on the cmts's as I'd had so much hope for after the arris
study

bufferbloat would be basically be over and dealt with.

And most flows would still be short.

> Flow completion time has to do with saturation as well.

FCT was not a subject of that draft.

My (admittedly ranty) points were:

* Mis-representation of how fq_codel actually worked for political purposes,
in particular mischaracterizing the behavior for videoconferencing
over more typical links...

* a complaint that despite all the work on bufferbloat, measured CMTS
buffering was still in the 680ms range at 100mbit. If anyone had
bothered to click on the pfsense discussion, I "subtly" pointed at a
FIOS measurement of 120ms...

Still waiting for that first step from the US cable industry. Things
are getting MUCH better in the past 2 years (see
http://www.dslreports.com/speedtest/results/bufferbloat ) just not (if
you scroll down) in the US.

I don't, incidentally, know why they are getting better... certainly I
have some good numbers on the size of the wifi deployment...

* Pointing out that sch_cake did diffserv, per host and per flow fq,
and docsis framing. Some of which had applicability to the draft.

We have not the slightest intent to bring that to the ietf, but it
does tackle and solve what little there was of a "collision" problem,
thoroughly... the diffserv stuff might help (I routinely give dns a
boost)... feel free to go reflash a router and see if it helps in your
scenarios.

Inbound shaping is cpu intensive, but it works pretty well.

>
> Cheers,
> Michael
>
> _______________________________________________
> Bloat mailing list
> Bloat at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat



-- 

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-205-9740