Re: [Bloat] when does the CoDel part of fq_codel help in the real world?

[Dave Taht <dave@taht.net>]

Pete Heist <pete@heistp.net> writes:

>     On Nov 27, 2018, at 9:10 PM, Dave Taht <dave.taht@gmail.com>
>     wrote:
>     
>     EVEN with http 2.0/ I would be extremely surprised to learn that
>     many
>     websites fit it all into one tcp transaction.
>     
>     There are very few other examples of TCP traffic requiring a low
>     latency response.
>     
>
> This is the crux of what I was looking for originally- some of these
> examples along with what the impact is on TCP itself, and what that

One thing I USED to use a lot - and am trying to use again - is that
you can run emacs on multiple people's displays over X11 over TCP.

We used to have interactive apps like that for X, whiteboards, and the
like, and as best as I recall they worked *better* than doing it over
the web.... 

emacs over tcp works amazingly well coast to coast now, over wireguard
or ssh, with or without ecn enabled, over cubic. I've been meaning to
try bbr for a while now.

open-frame-other-display still works! if X could gain a mosh like and/or
quic-like underling transport it could make a comeback...

:crickets:

> actually means for people. I got that and then some. So for future
> readers, here’s an attempt to crudely summarize how CoDel
> (specifically as used in fq_codel) helps:
>
> For some TCP CC algorithms (probably still most, as of this writing):
> - reduces TCP RTT at saturation, improving interactivity for single
> flows with mixed bulk/interactive traffic like HTTP/2.0 or SSH
> - smooths data delivery (thus meeting user’s expectations) by avoiding
> queue overflow (and tail-drop) in larger queues
> - increases throughput efficiency with ECN (won’t tackle this further
> here!)
> - reduces memory requirements for TCP buffers
>
> Regardless of TCP CC algorithm:
> - reduces latency for “non-flow” traffic, such as that for some
> encrypted VPNs

We could use to put together a document of the size and scope of

http://www2.rdrop.com/~paulmck/scalability/paper/sfq.2002.06.04.pdf

someday.

That paper went into crc as a suitable hash function, btw... I'd like to
find a better hash... someday.

fq_codel itself is still awaiting the definitive paper with all the
plusses and minuses and measurements and "future work" - toke's recent
work taking apart the drop probability is only a piece of that elephant
- there's computational cost, of QFQ vs fq_codel (to this *day* I'd like
a QFQ + codel version), the sparse flow optimization (which could really
use a few less syllables to describe) vs straight DRR under more normal
traffic rather than traffic that attempts to highlight its usefulness,
with the common 300 byte quantum and 1514. There's the P4 work and FPGA
versions... I'd really like to revisit our LPCC paper and the fractal
self similar traffic paper. and the list goes on and on....

anybody else 'roun here need a MSC or PHD?


>
>
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat