Re: [Bloat] Trying to *really* understand Linux pacing

Dear all, I’m now finally done updating the document, based on inputs from various folks in this round - most notably Neal, who went to great lengths to help me understand what I saw in my tests (thank you!). Now the description should be mostly correct (I hope) and pretty complete, and it

Re: [Bloat] Trying to *really* understand Linux pacing

> enlightenment. > > On Wed, Feb 7, 2024 at 6:57 AM Michael Welzl via Bloat > wrote: >> >> Dear de-bloaters of buffers, >> Esteemed experts of low delay and pacing! >> >> I have no longer been satisfied with high-level descriptions of how pacing >

[Bloat] Trying to *really* understand Linux pacing

Dear de-bloaters of buffers, Esteemed experts of low delay and pacing! I have no longer been satisfied with high-level descriptions of how pacing works in Linux, and how it interacts with TSQ (I’ve seen some, in various papers, over the years) - but I wanted to REALLY understand it. So, I have

Re: [Bloat] [iccrg] Musings on the future of Internet Congestion Control

I’ll cut some clutter: >> What you’re doing is jumping ahead. I suggest doing this with research >> rather than an email discussion, but that’s what we’re now already into. > > [SM] Sure, except my day job (snip) that’s ok - I wasn’t trying to tell you off for discussing ideas! - I

Re: [Bloat] [iccrg] Musings on the future of Internet Congestion Control

Hi ! A few answers below - > On Jul 11, 2022, at 9:33 AM, Sebastian Moeller wrote: > > HI Michael, > > >> On Jul 11, 2022, at 08:24, Michael Welzl > <mailto:mich...@ifi.uio.no>> wrote: >> >> Hi Sebastian, >> >> Neither our paper

Re: [Bloat] [iccrg] Musings on the future of Internet Congestion Control

a leap… More below: > On Jul 10, 2022, at 11:29 PM, Sebastian Moeller wrote: > > Hi Michael, > > >> On Jul 10, 2022, at 22:01, Michael Welzl wrote: >> >> Hi ! >> >> >>> On Jul 10, 2022, at 7:27 PM, Sebastian Moeller wrote: >>> &

Re: [Bloat] [iccrg] Musings on the future of Internet Congestion Control

Hi ! > On Jul 10, 2022, at 7:27 PM, Sebastian Moeller wrote: > > Hi Michael, > > so I reread your paper and stewed a bit on it. Many thanks for doing that! :) > I believe that I do not buy some of your premises. you say so, but I don’t really see much disagreement here. Let’s see: >

Re: [Bloat] [iccrg] Musings on the future of Internet Congestion Control

ur paper makes, along with many prior publications). >> On Jun 15, 2022, at 19:49, Dave Taht via Bloat >> wrote: >> >> -- Forwarded message - >> From: Michael Welzl >> Date: Wed, Jun 15, 2022 at 1:02 AM >> Subject: [iccrg] Musings o

Re: [Bloat] the future of tcp - train wreck or evolution?

> On Jun 16, 2022, at 6:39 PM, Dave Taht wrote: > > On Wed, Jun 15, 2022 at 10:48 PM Michael Welzl wrote: >> >> … but I’m excited about slide 15 ! >> >> "Heat, CO2, and radioactive waste are becoming measurable by-products of TCP >> inefficie

Re: [Bloat] the future of tcp - train wreck or evolution?

> On Jun 16, 2022, at 9:22 AM, Sebastian Moeller wrote: > > HI MIchael, > > >> On Jun 16, 2022, at 07:48, Michael Welzl via Bloat >> mailto:bloat@lists.bufferbloat.net>> wrote: >> >> … but I’m excited about slide 15 ! >> >>

Re: [Bloat] the future of tcp - train wreck or evolution?

… but I’m excited about slide 15 ! "Heat, CO2, and radioactive waste are becoming measurable by-products of TCP inefficiency Fix TCP => Save the World!” People don’t yet focus enough on this - and it’s not only relevant in a data center context. See also: Michael Welzl: "No

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

Our paper has some data - again, fig. 4. That’s an AS level analysis, for the data that we had (which wasn’t huge - a couple thousand paths). For the majority of measurements, the DSCP survived more than 1 AS hop; in case of IPv6, the majority survived more than 2. Cheers, Michael > On Mar

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

t better chances to survive ToS bleaching (maybe > around 80%), if I understand > https://www.sciencedirect.com/science/article/pii/S0140366417312835 > correctly. Diffserv behavior is usually configurable and can be changed > without replacing the network gear. Runa Barik, Michael Welzl, Ahmed Mu

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

Good question! …. on Windows in particular, I’d really like to know this too. The WebRTC Javascript API allows one to influence the DSCP, i.e. browsers normally can do that. Whether that’s true for all OSes, I don’t know. Cheers, Michael > On Mar 16, 2019, at 12:45 AM, David P. Reed wrote:

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

Hi, A few answers below: > On Nov 27, 2018, at 9:10 PM, Dave Taht wrote: > > On Mon, Nov 26, 2018 at 1:56 PM Michael Welzl <mailto:mich...@ifi.uio.no>> wrote: >> >> Hi folks, >> >> That “Michael” dude was me :) >> >> About the st

Re: [Bloat] incremental deployment, transport and L4S (Re: when does the CoDel part of fq_codel help in the real world?)

> On 29 Nov 2018, at 13:52, Jonathan Morton wrote: > >> On 29 Nov, 2018, at 2:06 pm, Michael Welzl wrote: >> >>> That's my proposal. >> >> - and it's an interesting one. Indeed, I wasn't aware that you're thinking >> of a DCTCP-style sign

Re: [Bloat] incremental deployment, transport and L4S (Re: when does the CoDel part of fq_codel help in the real world?)

I'm answering myself with an add-on thought: > On 29 Nov 2018, at 09:08, Michael Welzl wrote: > > > >> On 29 Nov 2018, at 08:46, Mikael Abrahamsson wrote: >> >> On Thu, 29 Nov 2018, Jonathan Morton wrote: >> >>> In my view, that is th

Re: [Bloat] incremental deployment, transport and L4S (Re: when does the CoDel part of fq_codel help in the real world?)

> On 29 Nov 2018, at 11:30, Jonathan Morton wrote: > My alternative use of ECT(1) is more in keeping with the other codepoints represented by those two bits, to allow ECN to provide more fine-grained information about congestion than it presently does. The main challenge

Re: [Bloat] incremental deployment, transport and L4S (Re: when does the CoDel part of fq_codel help in the real world?)

> On 29 Nov 2018, at 08:46, Mikael Abrahamsson wrote: > > On Thu, 29 Nov 2018, Jonathan Morton wrote: > >> You are essentially proposing using ECT(1) to take over an intended function >> of Diffserv. > > Well, I am not proposing anything. I am giving people a heads-up that the L4S >

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

Just a small clarification: >> To me the switch to head dropping essentially killed the tail loss RTO >> problem, eliminated most of the need for ecn. > > I doubt that: TCP will need to retransmit that packet at the head, and that > takes an RTT - all the packets after it will need to wait in

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

Well, I'm concerned about the delay experienced by people when they surf the web... flow completion time, which relates not only to the delay of packets as they are sent from A to B, but also the utilization. Cheers, Michael > On 27 Nov 2018, at 11:50, Mikael Abrahamsson wrote: > > On Tue,

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

Hi folks, That “Michael” dude was me :) About the stuff below, a few comments. First, an impressive effort to dig all of this up - I also thought that this was an interesting conversation to have! However, I would like to point out that thesis defense conversations are meant to be

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

Hi, It seems I overlooked this answer, sorry - some answers below, but also cutting stuff to keep it to the point: > On Nov 1, 2018, at 9:20 PM, Dave Taht wrote: >> Despite the undebatable importance of bufferbloat and its impact on e2e >> packet latency, this is only one of the factors

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

I was thinking about the web. You’re right about all the rest. Cheers Michael Sent from my iPhone > On 1 Nov 2018, at 18:37, David Lang wrote: > > On Thu, 1 Nov 2018, Michael Welzl wrote: > >>> On 29 Oct 2018, at 05:02, Dave Taht wrote: >> >>> Dear Gr

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

Hi, > On 29 Oct 2018, at 05:02, Dave Taht 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

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

Sent from my iPhone > On 4 Apr 2018, at 21:23, Michael Richardson wrote: > > > Dave Taht wrote: >> How dead is posix these days? Ietf does not generally do apis well. > > I disagree. > > IETF has lore says that it doesn't do APIs well, and so it's a

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

3, 2018, 9:14 AM Michael Welzl <mich...@ifi.uio.no> wrote: >> >>> On Apr 3, 2018, at 4:48 PM, Jesper Louis Andersen >>> <jesper.louis.ander...@gmail.com> wrote: >>> >>>> On Tue, Apr 3, 2018 at 4:27 PM Michael Welzl <mich...@ifi.

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

> On Apr 3, 2018, at 4:48 PM, Jesper Louis Andersen > <jesper.louis.ander...@gmail.com> wrote: > > On Tue, Apr 3, 2018 at 4:27 PM Michael Welzl <mich...@ifi.uio.no > <mailto:mich...@ifi.uio.no>> wrote: > please, please, people, take a look at the ietf ta

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

please, please, people, take a look at the ietf taps (“transport services”) working group :-) Sent from my iPhone > On 3 Apr 2018, at 14:35, Mikael Abrahamsson wrote: > >> On Tue, 3 Apr 2018, Jonathan Morton wrote: >> >> notwithstanding). In the end, people have kept

Re: [Bloat] Bufferbloat in high resolution + non-stationarity

I thought that some browsers already use various DSCPs when running WebRTC? > On Nov 30, 2017, at 9:09 PM, Jonathan Morton wrote: > > Cake already supports treating CS1 as less-than-besteffort by default. > Adding more codepoints to that list is easy. > > The trick is

Re: [Bloat] [Cerowrt-devel] DOCSIS 3+ recommendation?

On 20. mar. 2015, at 19.29, David Lang da...@lang.hm wrote: On Sat, 21 Mar 2015, Michael Welzl wrote: On 21. mar. 2015, at 01.03, David Lang da...@lang.hm wrote: On Fri, 20 Mar 2015, Michael Welzl wrote: On 20. mar. 2015, at 17.31, Jonathan Morton chromati...@gmail.com wrote: On 20

Re: [Bloat] [Cerowrt-devel] DOCSIS 3+ recommendation?

On 20. mar. 2015, at 19.25, David Lang da...@lang.hm wrote: On Sat, 21 Mar 2015, Steinar H. Gunderson wrote: On Fri, Mar 20, 2015 at 05:03:16PM -0700, David Lang wrote: 1. If you mark packets as congested if they have ECN and drop them if they don't, programmers will mark everything ECN

Re: [Bloat] please kill the ECN thread from hell here and take it to aqm

On 21. mar. 2015, at 23.57, Dave Taht dave.t...@gmail.com wrote: On Fri, Mar 20, 2015 at 5:15 PM, Michael Welzl mich...@ifi.uio.no wrote: I think it's about time we finally turn it [ecn] on in the real world. Please start with turning it on as fully as possible on *your* networks

Re: [Bloat] [Cerowrt-devel] DOCSIS 3+ recommendation?

On 21. mar. 2015, at 01.03, David Lang da...@lang.hm wrote: On Fri, 20 Mar 2015, Michael Welzl wrote: On 20. mar. 2015, at 17.31, Jonathan Morton chromati...@gmail.com wrote: On 20 Mar, 2015, at 16:54, Michael Welzl mich...@ifi.uio.no wrote: I'd like people to understand that packet loss

Re: [Bloat] [Cerowrt-devel] DOCSIS 3+ recommendation?

a conservative calculation, and the RTO being way too large often just doesn't matter much (thanks to DupACKs). Anyway, sometimes it can - and then a dropped packet can be pretty bad. Cheers Michael On Mar 20, 2015, Michael Welzl mich...@ifi.uio.no wrote: On 20. mar. 2015, at 17.31, Jonathan Morton

Re: [Bloat] [Cerowrt-devel] DOCSIS 3+ recommendation?

Folks, I think I have just seen this statement a little too often: That’s right, Jim. The “some packet loss is good” part is from what I have seen the hardest thing for people to understand. People have been trained to believe that any packet loss is terrible (..) I understand the wrong

Re: [Bloat] [Cerowrt-devel] DOCSIS 3+ recommendation?

Sent from my iPhone On 20. mars 2015, at 16:31, Jim Gettys j...@freedesktop.org wrote: On Fri, Mar 20, 2015 at 10:54 AM, Michael Welzl mich...@ifi.uio.no wrote: Folks, I think I have just seen this statement a little too often: That’s right, Jim. The “some packet loss is good

Re: [Bloat] [Cerowrt-devel] DOCSIS 3+ recommendation?

On 20. mar. 2015, at 17.31, Jonathan Morton chromati...@gmail.com wrote: On 20 Mar, 2015, at 16:54, Michael Welzl mich...@ifi.uio.no wrote: I'd like people to understand that packet loss often also comes with delay - for having to retransmit. Or, turning it upside down, it’s always

Re: [Bloat] RED against bufferbloat

On 25. feb. 2015, at 20.04, David Lang da...@lang.hm wrote: On Wed, 25 Feb 2015, Michael Welzl wrote: 2) Not everyone will always want FQ everywhere. There are potential disadvantanges (e.g. the often mentioned with-a-VPN-I'm-only-1-flow problem). What's necessary is to quantify them

Re: [Bloat] RED against bufferbloat

On 25 Feb 2015, at 10:31, Alex Elsayed eternal...@gmail.com wrote: Michael Welzl wrote: Two points, below... On 25 Feb 2015, at 09:42, Alex Elsayed eternal...@gmail.commailto:eternaleye- re5jqeeqqe8avxtiumw...@public.gmane.org wrote: snip Why exactly did you think we should have

Re: [Bloat] RED against bufferbloat

On 25 Feb 2015, at 11:24, t...@toke.dk wrote: Michael Welzl mich...@ifi.uio.no writes: but that's FQ (or FQ_CoDel's changed FQ variant), much more than the AQM mechanism in use (as we have also seen presented by Toke at the last ICCRG meeting). Well, actually, that presentation did

Re: [Bloat] RED against bufferbloat

On 25 Feb 2015, at 10:29, Sebastian Moeller moell...@gmx.de wrote: Hi Michael, On Feb 25, 2015, at 10:18 , Michael Welzl mich...@ifi.uio.no wrote: Two points, below... [...] Why exactly did you think we should have looked at asymmetric paths? To study what? ( I'm not debating

Re: [Bloat] I feel an urge to update this

fwiw: http://tools.ietf.org/id/draft-sallantin-iccrg-initial-spreading-01.txt Sent from my iPhone On 20. sep. 2014, at 17:55, Jonathan Morton chromati...@gmail.com wrote: On 20 Sep, 2014, at 12:03 pm, Steinar H. Gunderson wrote: On Sat, Sep 20, 2014 at 02:33:06AM +0300, Dave Taht

Re: [Bloat] sigcomm wifi

The conditions are probably different in each direction. The AP is more likely to be sending large packets (DNS response, HTTP payload) while the client is more likely to send small packets (DNS request, TCP SYN, HTTP GET). The AP is also likely to want to aggregate a TCP SYN/ACK with

Re: [Bloat] sigcomm wifi

On 24. aug. 2014, at 07:14, David Lang wrote: On Sat, 23 Aug 2014, Hal Murray wrote: Yep... I remember a neat paper from colleagues at Trento University that piggybacked TCP's ACKs on link layer ACKs, thereby avoiding the collisions between TCP's ACKs and other data packets - really nice.

Re: [Bloat] sigcomm wifi

Yep... I remember a neat paper from colleagues at Trento University that piggybacked TCP's ACKs on link layer ACKs, thereby avoiding the collisions between TCP's ACKs and other data packets - really nice. Not sure if it wasn't just simulations, though. that's a neat hack, but I don't see

Re: [Bloat] sigcomm wifi

On 25. aug. 2014, at 10:19, Sebastian Moeller wrote: Hi Michael, On Aug 25, 2014, at 10:01 , Michael Welzl mich...@ifi.uio.no wrote: [...] This is a case where a local proxy server can actually make a big difference to you. The connections between your mobile devices and the local

Re: [Bloat] sigcomm wifi

On 21. aug. 2014, at 10:30, David Lang da...@lang.hm wrote: On Thu, 21 Aug 2014, Michael Welzl wrote: On 21. aug. 2014, at 08:52, Eggert, Lars wrote: On 2014-8-21, at 0:05, Jim Gettys j...@freedesktop.org wrote: ​And what kinds of AP's? All the 1G guarantees you is that your

Re: [Bloat] sigcomm wifi

On 21. aug. 2014, at 08:52, Eggert, Lars wrote: On 2014-8-21, at 0:05, Jim Gettys j...@freedesktop.org wrote: ​And what kinds of AP's? All the 1G guarantees you is that your bottleneck is in the wifi hop, and they can suffer as badly as anything else (particularly consumer home routers).

Re: [Bloat] Remy: Computer-Generated Congestion Control

Dave, About this point that I've seen you make repeatedly: My biggest problem with all the work so far is that it starts with a constant baseline 150ms or 100ms RTT, and then try various algorithms over a wide range of bandwidths, and then elides that base RTT in all future plots. Unless you

Re: [Bloat] Remy: Computer-Generated Congestion Control

On 21. aug. 2014, at 19:04, Dave Taht dave.t...@gmail.com wrote: On Thu, Aug 21, 2014 at 5:21 AM, Michael Welzl mich...@ifi.uio.no wrote: Dave, About this point that I've seen you make repeatedly: My biggest problem with all the work so far is that it starts with a constant baseline

Re: [Bloat] [Cerowrt-devel] fq_codel is two years old

Hi, I completely agree that this service differentiation was wrong from the beginning. The idea of using bits to implement a trade-off that doesn't involve prioritization between users is old (*), and has always been the right approach in my opinion. At least one proposal in this direction is

[Bloat] Two jobs in networks at the University of Oslo

Hi all, These two jobs could be close enough to the interests of some bloaters... Cheers, Michael * Two new academic jobs are available in Networks at the Department of Informatics of the University of Oslo, Norway: - A postdoc position, 2 years, in the project PRISTINE (

[Bloat] CFP Packet Video 2013 - Special Session on Low-Latency Interactive Video

with video codecs in a low-delay, real-time setting • Interactions between applications and RTP flows • Failing to meet real-time schedules: impact, techniques to detect, instrument or diagnose it Organizers: • Michael Welzl, University of Oslo (michawe at ifi.uio.no

Re: [Bloat] the iccrg presos and some meeting notes from tsvarea at ietf

to 6204 perhaps called queue handling and Michael Welzl - iccrg can publish informational RFCs on AQM algorithms - energy seems to be there on that topic Janardhan Iyengar - very important to understand where boundaries of these mechanisms lie. be clear about where AQM mechanisms work well

Re: [Bloat] Skype

). This may happen e.g when a firewall blocks UDP. TCP (possibly in combination with a lossy WiFi connection) is what creates the high latencies. /Ingemar -- Message: 2 Date: Sun, 18 Nov 2012 15:57:53 +0100 From: Michael Welzl mich...@ifi.uio.no To: bloat bloat

[Bloat] Skype

Hi, I have repeatedly noticed that Skype sometimes, in a long conversation involving video, can create massive audio delays (in the order of multiple seconds). This has happened to me in a conversation from a hotel room in the US to my home in Oslo (where, apologies, I haven't yet looked