Thank you all for the responses! I was asked a related question by my local WISP, who wanted to know if there would be any reason that fq_codel or Cake would be an improvement over sfq specifically for some "noisy links” (loose translation from Czech) in a backhaul that have some loss but also experience saturation. I conservatively answered no, but that may not be correct, in case the reduced TCP RTT could help with loss recovery or other behaviors, as Jon pointed out. I suspect more research would be needed to quantify this. Neal’s/Dave's point about “non-flow" traffic is well taken also.
> On Nov 26, 2018, at 11:13 PM, Toke Høiland-Jørgensen <t...@toke.dk> wrote: > > Michael Welzl <mich...@ifi.uio.no> writes: > >> However, I would like to point out that thesis defense conversations >> are meant to be provocative, by design - when I said that CoDel >> doesn’t usually help and long queues would be the right thing for all >> applications, I certainly didn’t REALLY REALLY mean that. > > Just as I don't REALLY REALLY mean that bigger buffers are always better > as you so sneakily tricked me into blurting out ;) I think most of us knew that “yeah” wasn’t a confirmation. Yeah can be used in a dozen different ways depending on context and intonation, but it did give some comic relief. :) >> BTW, Anna Brunstrom was also very quick to also give me the HTTP/2.0 >> example in the break after the defense. > > Yup, was thinking of HTTP/2 when I said "control data on the same > connection as the payload". Can see from Pete's transcript that it > didn't come across terribly clearly, though :P Ah, sorry for missing that part! I thought there was more there but didn’t want to write something unless I was sure I heard it. >> I’ll use the opportunity to tell folks that I was also pretty >> impressed with Toke’s thesis as well as his performance at the >> defense. I’ll second that. I’m enjoying digesting the thesis, as well as the results of airtime fairness in a real world deployment. :) _______________________________________________ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
