Re: [Bloat] [Cerowrt-devel] tp-link request for SQM

On Thu, Dec 9, 2021, 19:23 Sebastian Moeller wrote: > Hi Luca, > > > > On Dec 9, 2021, at 18:38, Luca Muscariello wrote: > > > > Hi Sebastian > > > > On Thu, Dec 9, 2021, 17:09 Sebastian Moeller wrote: > > Hi Luca > > > &

Re: [Bloat] [Cerowrt-devel] tp-link request for SQM

Hi Sebastian On Thu, Dec 9, 2021, 17:09 Sebastian Moeller wrote: > Hi Luca > > > On Dec 3, 2021, at 15:58, Luca Muscariello wrote: > > > > > > > > On Fri, Dec 3, 2021 at 3:35 PM Sebastian Moeller > wrote: > > Hi Dave, > > &

Re: [Bloat] [Cerowrt-devel] tp-link request for SQM

On Fri, Dec 3, 2021 at 3:35 PM Sebastian Moeller wrote: > Hi Dave, > > > > On Dec 3, 2021, at 15:18, Dave Taht wrote: > > > > On Fri, Dec 3, 2021 at 4:00 AM Luca Muscariello > wrote: > >> > >> Test using a tp-link AP EAP 245 > >>

Re: [Bloat] tp-link request for SQM

Test using a tp-link AP EAP 245 https://www.waveform.com/tools/bufferbloat?test-id=bbcc5ef5-e677-4f27-aa04-1849db81d0f5 On Thu, Dec 2, 2021 at 7:48 PM Dave Taht wrote: > tp-link, is, so far as I know, the last major home router vendor NOT > shipping a SQM system. Perhaps this could be modded

Re: [Bloat] [Make-wifi-fast] [Starlink] [Cerowrt-devel] Due Aug 2: Internet Quality workshop CFP for the internet architecture board

For those who might be interested in Little's law there is a nice paper by John Little on the occasion of the 50th anniversary of the result. https://www.informs.org/Blogs/Operations-Research-Forum/Little-s-Law-as-Viewed-on-its-50th-Anniversary

Re: [Bloat] testing latency under load on webrtc with galene?

Dave, we have done extensive WebRTC (and several other online meeting apps) testing lately and this paper https://ieeexplore.ieee.org/document/9153228 reports a methodology for WebRTC based on Chromium and Selenium Grid and as test orchestrator Jitsi Torture. I would avoid feeding clients with

Re: [Bloat] BBR implementations, knobs to turn?

Hi Erick, one question about the PGW: is it a policer or a shaper that you have installed? Also, have you tried to run a ping session before and in parallel to the curl sessions? Luca On Thu, Nov 19, 2020 at 2:15 PM wrote: > Update: > The 5G router was connected to a new base station. Now

Re: [Bloat] CAKE in openwrt high CPU

On Thu, Sep 3, 2020 at 4:32 PM Toke Høiland-Jørgensen wrote: > > Luca Muscariello writes: > > > On Thu, Sep 3, 2020 at 3:19 PM Mikael Abrahamsson via Bloat > > wrote: > >> > >> On Tue, 1 Sep 2020, Toke Høiland-Jørgensen wrote: > >> > >&

Re: [Bloat] CAKE in openwrt high CPU

On Thu, Sep 3, 2020 at 3:19 PM Mikael Abrahamsson via Bloat wrote: > > On Tue, 1 Sep 2020, Toke Høiland-Jørgensen wrote: > > > Yup, the number of cores is only going to go up, so for CAKE to stay > > relevant it'll need to be able to take advantage of this eventually :) > >

Re: [Bloat] [Make-wifi-fast] the future belongs to pacing

It is not surprising that BBR comes from Van who's also designed and implemented pathchar. I liked reading the paper when it was published and it has the merit to be simple to read for a large audience. I agree very much on the title as bang-bang congestion control (not only AIMD) could be

Re: [Bloat] [tsvwg] my backlogged comments on the ECT(1) interim call

o? > placeholder > > > and I may have misunderstood the part about video elasticity, but my > > > interpretation at the time was that Stuart was claiming that video was > > > elastic in that it would adjust downward to avoid overflowing a loaded > > > link, and I tho

Re: [Bloat] [tsvwg] my backlogged comments on the ECT(1) interim call

apply a circuit-breaker/policer in the network to > perform admission control, but I don't see the link to L4S. Have I missed > something ? > > Gorry > On 28/04/2020 20:04, Luca Muscariello wrote: > > Hi Jake, > > Thanks for the notes. Very useful. > The other issue wi

Re: [Bloat] my backlogged comments on the ECT(1) interim call

it also will not go below a certain rate, and perhaps that quality can stay > relatively good in spite of high network loss? > > > > Best regards, > > Jake > > > > *From: *Luca Muscariello > *Date: *Tuesday, April 28, 2020 at 1:54 AM > *To: *Dave Taht > *Cc: *ts

Re: [Bloat] my backlogged comments on the ECT(1) interim call

Hi Dave and list members, It was difficult to follow the discussion at the meeting yesterday. Who said what in the first place. There have been a lot of non-technical comments such as: this solution is better than another in my opinion. "better" has often been used as when evaluating the taste

Re: [Bloat] [Ecn-sane] 2019-12-31 docsis strict priority dual queue patent granted

A Bloom filter based classifier for Bottlenecked vs non bottlenecked flows was done in here in 2005. https://team.inria.fr/rap/files/2013/12/KMOR05a.pdf And associated patent granted since 2011 https://patents.google.com/patent/US7933204B2/en?oq=US7933204B2+United+States++ Luca On Thu, Jan

Re: [Bloat] Bufferbloat on 4G Connexion

On Thu, Oct 24, 2019 at 11:34 AM Toke Høiland-Jørgensen wrote: > Luca Muscariello writes: > > > On Wed, Oct 23, 2019 at 2:27 PM Toke Høiland-Jørgensen > > wrote: > > > >> Rich Brown writes: > >> > >> >> On Oct 23, 2019, at 5:54 AM, >

Re: [Bloat] Bufferbloat on 4G Connexion

On Wed, Oct 23, 2019 at 2:27 PM Toke Høiland-Jørgensen wrote: > Rich Brown writes: > > >> On Oct 23, 2019, at 5:54 AM, erik.tarald...@telenor.com>> wrote: > >> > >> If you could influence the 4G vendors to de-bloat their equipment, > >> would you recommend BQL, L4S or codel/cake? > > > > I've

Re: [Bloat] buffer sizing meeting notes

On Sat, Aug 24, 2019 at 9:59 AM Sebastian Moeller wrote: > Another nugget from the notes ( > http://yuba.stanford.edu/~bspang/buffer-sizing-meeting/notes/): > > This looks like an argument for fq_codel/cake's use of time instead of > queue length, OR an argument for fq, because in a

Re: [Bloat] [Ecn-sane] three new internet drafts regarding SCE

Remote attendance is free of charge but you have to register to be able to access. https://www.ietf.org/registration/ietf105/remotereg.py On Wed, Jul 17, 2019 at 3:13 PM Dave Taht wrote: > IETF 105 runs from July 20-27th in Montreal. > > https://datatracker.ietf.org/meeting/105/agenda/ > >

Re: [Bloat] datapoint from one vendor regarding bloat

Defs https://tools.ietf.org/html/rfc2697 On Thu 11 Apr 2019 at 19:54, Jonathan Morton wrote: > > On 11 Apr, 2019, at 1:38 pm, Mikael Abrahamsson > wrote: > > > > The mbs defines the MBS for the PIR bucket and the cbs defines the CBS > for the CIR bucket > > What do these lumps of jargon

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

for the application. If working from home, the quality of peering of an SP to cloud providers is key. I'd say that the Cloud and the decline of transit networks have facilitated DSCP e2e. On Sat, Mar 23, 2019 at 7:40 PM Mikael Abrahamsson wrote: > On Sat, 23 Mar 2019, Luca Muscariello wr

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

WebEx, WebRTC they use it. QoS works. To answer the question in the title of Michael’s paper. It the app runs in the cloud and the cloud has direct peering links to your branch office or SP most likely DSCP works. And going back to Roland’s proposal, it seems the most natural approach instead of

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

+1 On Sat, Mar 23, 2019 at 9:02 AM Roland Bless wrote: > Hi, > > On 22.03.19 at 19:28 Victor Hou wrote: > > > Broadcom has been deeply involved in developing the Low Latency DOCSIS > > cable industry specification that Bob Briscoe mentioned. We concur with > > the L4S use of ECT(1). L4S can

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

To me there is substantial difference from something like fq_codel or fq_pie where service differentiation is largely implicit and approches largely based on explicit marking. Approaches based on marking face technical and non technical challenges that have been largely mentioned in these lists.

Re: [Bloat] netdevconf "vikings"

One of the two vikings, Toke, had the whole PhD thesis filled with citations from Toy Story. Not to mean that is less glorious... but... On Tue, Feb 5, 2019 at 10:07 AM Toke Høiland-Jørgensen wrote: > Dave Taht writes: > > > speaking of toke and jesper: > > > > "Two networking Vikings, masters

Re: [Bloat] #brexit bloat

LOL! On Thu 31 Jan 2019 at 15:07, Dave Taht wrote: > https://twitter.com/yorksranter/status/1082601273315217408 > > -- > > Dave Täht > CTO, TekLibre, LLC > http://www.teklibre.com > Tel: 1-831-205-9740 > ___ > Bloat mailing list >

Re: [Bloat] [Cake] paper: per flow fairness in a data center network

I disagree on the claims that DC switches do not implement anything. They do, from quite some time now. https://www.cisco.com/c/en/us/products/collateral/switches/nexus-9000-series-switches/white-paper-c11-738488.html On Thu, Dec 6, 2018 at 4:19 AM Dave Taht wrote: > While I strongly agree

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

output, however > this build up can e.g. happen in one RTT, while the standing queue can > survive seconds or minutes (in reality, and indefinitely in theory). > Though, I found that this correlation is often not modeled in > queue-theoretical models. > > Best, Mario > > > Am

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

ngestion control mechanisms > that have steady state throughput of the kind R = f(d, p), for some > function f, delay d and feedback p, if the feedback is based on purely > end to end delay measurements, you can either have fairness or a fixed > delay, but not both simultaneously > &q

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

) wrote: > Hi Luca, > > Am 27.11.18 um 10:24 schrieb Luca Muscariello: > > A congestion controlled protocol such as TCP or others, including QUIC, > > LEDBAT and so on > > need at least the BDP in the transmission queue to get full link > > efficiency,

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

On Wed, Nov 28, 2018 at 11:40 AM Dave Taht wrote: > On Wed, Nov 28, 2018 at 1:56 AM Luca Muscariello > wrote: > > > > Dave, > > > > The single BDP inflight is a rule of thumb that does not account for > fluctuations of the RTT. > > And I am not talking ab

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

ore than BDP of > discussion here, and what > we need is sqrt(bdp) to deal with all the different conversational flows. > :) > > On Tue, Nov 27, 2018 at 1:24 AM Luca Muscariello > wrote: > > > > I think that this is a very good comment to the discussion at the > de

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

rize a table > of the competing viewpoints, as there's far more than BDP of > discussion here, and what > we need is sqrt(bdp) to deal with all the different conversational flows. > :) > > On Tue, Nov 27, 2018 at 1:24 AM Luca Muscariello > wrote: > > > > I think that

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

On Tue, Nov 27, 2018 at 2:49 PM Mikael Abrahamsson wrote: > On Tue, 27 Nov 2018, Luca Muscariello wrote: > > > If you, Mikael don't want more than 10ms buffer, how do you achieve that? > > class class-default >random-detect 10 ms 2000 ms > > That's the

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

Another bit to this. A router queue is supposed to serve packets no matter what is running at the controlled end-point, BBR, Cubic or else. So, delay-based congestion controller still get hurt in today Internet unless they can get their portion of buffer at the line card. FQ creates incentives for

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

in the paper. On Tue 27 Nov 2018 at 12:53, Bless, Roland (TM) wrote: > Hi Luca, > > Am 27.11.18 um 12:01 schrieb Luca Muscariello: > > A BDP is not a large buffer. I'm not unveiling a secret. > > That depends on speed and RTT (note that typically there are > several flows wit

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

Nov 2018, Luca Muscariello wrote: > > > link fully utilized is defined as Q>0 unless you don't include the > > packet currently being transmitted. I do, so the TXtteer is never idle. > > But that's a detail. > > As someone who works with moving packets, it's perplexing t

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

ess, Roland (TM) wrote: > Hi, > > Am 27.11.18 um 11:29 schrieb Luca Muscariello: > > I have never said that you need to fill the buffer to the max size to > > get full capacity, which is an absurdity. > > Yes, it's absurd, but that's what today's loss-based CC algori

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

) wrote: > Hi Luca, > > Am 27.11.18 um 10:24 schrieb Luca Muscariello: > > A congestion controlled protocol such as TCP or others, including QUIC, > > LEDBAT and so on > > need at least the BDP in the transmission queue to get full link > > efficiency,

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

I think that this is a very good comment to the discussion at the defense about the comparison between SFQ with longest queue drop and FQ_Codel. A congestion controlled protocol such as TCP or others, including QUIC, LEDBAT and so on need at least the BDP in the transmission queue to get full

Re: [Bloat] one benefit of turning off shaping + fq_codel

On Fri 23 Nov 2018 at 18:27, Dave Taht wrote: > On Fri, Nov 23, 2018 at 9:17 AM Luca Muscariello > wrote: > > > > Yes there was some discussion about that. > > Moving things to hardware should fix that. > > > > Evens traffic management in NPU based routers m

Re: [Bloat] one benefit of turning off shaping + fq_codel

Yes there was some discussion about that. Moving things to hardware should fix that. Evens traffic management in NPU based routers makes use of hardware based polling for shaping. These are trade offs one has to face all the time. There has been a discussion at the defense about hardware vs

Re: [Bloat] [Make-wifi-fast] [Cerowrt-devel] closing up my make-wifi-fast lab

t; Bob > > > > > On Mon, Aug 27, 2018 at 12:24 AM Luca Muscariello < > luca.muscarie...@gmail.com> wrote: > >> Jonathan, >> >> Not that giant handwaving though. >> IEEE 802.11ax makes use of "almost TDM" RTS/CTS and scheduling.

Re: [Bloat] [Make-wifi-fast] [Cerowrt-devel] closing up my make-wifi-fast lab

Jonathan, Not that giant handwaving though. IEEE 802.11ax makes use of "almost TDM" RTS/CTS and scheduling. The almost is necessary as it operates in 2.4/5Ghz bands. Similar to what you describe, and is coming very soon in shipping products. RTS/CTS is still a LBT to create a window where TDM

Re: [Bloat] [Make-wifi-fast] Van Jacobson's slides on timing wheels at netdevconf

and C) you can implement any packet scheduler using a timing wheel using virtual times. On Fri, Jul 20, 2018 at 4:09 PM Dave Taht wrote: > > https://www.files.netdevconf.org/d/46def75c2ef345809bbe/files/?p=/Evolving%20from%20AFAP%20%E2%80%93%20Teaching%20NICs%20about%20time.pdf > > Talking

Re: [Bloat] Is bufferbloat a privacy issue?

Good point. Flow isolation gives some kind of “privacy”. But I guess this is not the worse privacy violation one would be concerned about in today Internet. On Thu 19 Jul 2018 at 12:52, Dave Taht wrote: > hahaha. Aside from their last slide not recommending fq, that was an > enjoyable read. fq

Re: [Bloat] Seen in passing: mention of Valve's networking scheme and RFC 5348

I'm aware of this one. The last time I checked Linux patches seemed to be abandoned. Hit ratio could be v v low if you remove UDP encap. Look at IPSEC. On Wed, Apr 4, 2018 at 12:52 PM, Mikael Abrahamsson <swm...@swm.pp.se> wrote: > On Wed, 4 Apr 2018, Luca Muscariello wrote: > >

Re: [Bloat] Seen in passing: mention of Valve's networking scheme and RFC 5348

I'm looking at TAPS too as I'm looking for a general transport API other than TCP/UDP. The kind of transport services we have developed in here https://git.fd.io/cicn/ do not fit in the current API. Full user land implementation, which seems to be accepted nowadays, but not at all a few years

Re: [Bloat] occasionally, there's good news to be had for the Internet.

Next challenge: FQ into silicon... One of the reasons of what Jim describes under the "Here lies madness" section is related to silicon built-in functionalities and the ability to update software in edge-routers. Many chipcos build their board with several CPU offloading mechanisms, e.g. to

Re: [Bloat] [Cerowrt-devel] DC behaviors today

rimary measure, and the system never > focuses on operating points anywhere near max throughput. > > > > Rant off. > > > On Tuesday, December 12, 2017 1:36pm, "Dave Taht" <d...@taht.net> said: > > > > > Luca Muscariello <luca.muscarie...@gmail.co

Re: [Bloat] [Cerowrt-devel] DC behaviors today

I think everything is about response time, even throughput. If we compare the time to transmit a single packet from A to B, including propagation delay, transmission delay and queuing delay, to the time to move a much larger amount of data from A to B we use throughput in this second case because

Re: [Bloat] benefits of ack filtering

https://www.cisco.com/c/en/us/products/collateral/wireless/aironet-3700-series/white-paper-c11-735947.html On Fri 1 Dec 2017 at 19:43, Dave Taht <d...@taht.net> wrote: > Luca Muscariello <luca.muscarie...@gmail.com> writes: > > > For highly asymmetric links, but als

Re: [Bloat] [Make-wifi-fast] benefits of ack filtering

I think only IPSEC would be a problem for fastACK but not TLS. On Fri, Dec 1, 2017 at 2:13 PM, Кирилл Луконин wrote: > As I noticed from the Meraki document: > > "FastACK also relies on packet inspection, and will not work when > payload is encrypted. However, in our

Re: [Bloat] benefits of ack filtering

If I understand the text right, FastACK runs in the AP and generates an ACK on behalf (or despite) of the TCP client end. Then, it decimates dupACKs. This means that there is a stateful connection tracker in the AP. Not so simple. It's almost, not entirely though, a TCP proxy doing Split TCP.

Re: [Bloat] benefits of ack filtering

For highly asymmetric links, but also shared media like wifi, QUIC might be a better playground for optimisations. Not pervasive as TCP though and maybe off topic in this thread. If the downlink is what one want to optimise, using FEC in the downstream, in conjunction with flow control could be

Re: [Bloat] benefits of ack filtering

Agree and think this is a lucid analysis of the problem(s) and solution(s). But, what can be done to let clients upgrade orders of magnitude faster than today? Move transport in user space inside the app? Else? On Thu, Nov 30, 2017 at 8:48 AM, Jonathan Morton wrote: >

Re: [Bloat] benefits of ack filtering

On Wed, Nov 29, 2017 at 3:31 PM, Mikael Abrahamsson <swm...@swm.pp.se> wrote: > On Wed, 29 Nov 2017, Luca Muscariello wrote: > > Why does it say to do this? What benefit is there to either end system to >>> send 35kPPS of ACKs in order to facilitate a 100 megaby

Re: [Bloat] benefits of ack filtering

Did you check RFC 3449 ? https://tools.ietf.org/html/rfc3449#section-5.2.1 It would be interesting to know what is the minimum ACK rate to achieve full utilisation. Or the how the downlink rate depends on the uplink ACK rate. I'm sure I've seen this dependency in some old paper. On Wed, Nov 29,

Re: [Bloat] emulating non-duplex media in linux qdiscs

Dave, If the objective is to run experiments with some emulated wifi I could suggest a workaround that we are using. It is not based on qdisc only. It is based on ns3 emulation and linux bridges. https://git.fd.io/cicn/tree/emu-radio/README.md?h=vicn/master The radio emulation piece includes

Re: [Bloat] [Make-wifi-fast] the wifi airtime-fair fq_codel stuff on net-next looks mostly good

Air time fairness has a strong theoretical foundation. So I should cite Newton and say that Toke is sitting on giants' schoulders :) In multi rate systems in a shared channel, time is the right resource to share. Then one could discuss about which fairness criterion to use, but that's

Re: [Bloat] [aqm] TSO sizing fixes and the new paced fq scheduler in Linux 3.12

Le 25/09/2013 17:15, Eric Dumazet a écrit : On Tue, 2013-09-24 at 14:25 +0200, James Roberts wrote: No one responded to Luca's Sept 1 comment (on the bloat list) that the new code seems to do tail drop rather than longest queue drop. If this is so, bandwidth sharing will not be fair since FQ