I believe Dave Taht has pointed out, essentially, that the "codel" part of fq_codel can be useful in cases where the definition of "flow" is not visible to fq_codel, so that "fq" part is inactive. For example, if there is VPN traffic, where the individual flows are not separable by fq_codel, then it can help to have "codel" AQM for the aggregate of encrypted VPN traffic. I imagine this rationale could apply where there is any kind of encapsulation or encryption that makes the notion of "flow" opaque to fq_codel.
neal On Mon, Nov 26, 2018 at 2:08 PM Pete Heist <p...@heistp.net> wrote: > In Toke’s thesis defense, there was an interesting exchange with > examination committee member Michael (apologies for not catching the last > name) regarding how the CoDel part of fq_codel helps in the real world: > > https://www.youtube.com/watch?v=upvx6rpSLSw&t=2h16m20s > > My attempt at a transcript is at the end of this message. (I probably > won’t attempt a full defense transcript, but if someone wants more of a > particular section I can try. :) > > So I just thought to continue the discussion- when does the CoDel part of > fq_codel actually help in the real world? I’ll speculate with a few > possibilities: > > 1) Multiplexed HTTP/2.0 requests containing both a saturating stream and > interactive traffic. For example, a game that uses HTTP/2.0 to download new > map data while position updates or chat happen at the same time. Standalone > programs could use HTTP/2.0 this way, or for web apps, the browser may > multiplex concurrent uses of XHR over a single TCP connection. I don’t know > of any examples. > > 2) SSH with port forwarding while using an interactive terminal together > with a bulk transfer? > > 3) Does CoDel help the TCP protocol itself somehow? For example, does it > speed up the round-trip time when acknowledging data segments, improving > behavior on lossy links? Similarly, does it speed up the TCP close sequence > for saturating flows? > > Pete > > --- > > M: In fq_codel what is really the point of CoDel? > T: Yeah, uh, a bit better intra-flow latency... > M: Right, who cares about that? > T: Apparently some people do. > M: No I mean specifically, what types of flows care about that? > T: Yeah, so, um, flows that are TCP based or have some kind of- like, > elastic flows that still want low latency. > M: Elastic flows that are TCP based that want low latency... > T: Things where you want to discover the- like, you want to utilize the > full link and sort of probe the bandwidth, but you still want low latency. > M: Can you be more concrete what kind of application is that? > T: I, yeah, I… > M: Give me any application example that’s gonna benefit from the CoDel > part- CoDel bits in fq_codel? Because I have problems with this. > T: I, I do too... So like, you can implement things this way but > equivalently if you have something like fq_codel you could, like, if you > have a video streaming application that interleaves control… > M: <inaudible> that runs on UDP often. > T: Yeah, but I, Netflix… > M: Ok that’s a long way… <inaudible> > T: No, I tend to agree with you that, um… > M: Because the biggest issue in my opinion is, is web traffic- for web > traffic, just giving it a huge queue makes the chance bigger that uh, > <inaudible, ed: because of the slow start> so you may end up with a > (higher) faster completion time by buffering a lot. Uh, you’re not > benefitting at all by keeping the queue very small, you are simply > <inaudible> Right, you’re benefitting altogether by just <inaudible> which > is what the queue does with this nice sparse flow, uh… <inaudible> > T: You have the infinite buffers in the <inaudible> for that to work, > right. One benefit you get from CoDel is that - you screw with things like > - you have to drop eventually. > M: You should at some point. The chances are bigger that the small flow > succeeds (if given a huge queue). And, in web surfing, why does that, uh(?) > T: Yeah, mmm... > M: Because that would be an example of something where I care about > latency but I care about low completion. Other things where I care about > latency they often don’t send very much. <inaudible...> bursts, you have to > accommodate them basically. Or you have interactive traffic which is UDP > and tries to, often react from queueing delay <inaudible>. I’m beginning to > suspect that fq minus CoDel is really the best <inaudible> out there. > T: But if, yeah, if you have enough buffer. > M: Well, the more the better. > T: Yeah, well. > M: Haha, I got you to say yes. [laughter :] That goes in history. I said > the more the better and you said yeah. > T: No but like, it goes back to good-queue bad-queue, like, buffering in > itself has value, you just need to manage it. > M: Ok. > T: Which is also the reason why just having a small queue doesn’t help in > itself. > M: Right yeah. Uh, I have a silly question about fq_codel, a very silly > one and there may be something I missed in the papers, probably I did, but > I'm I was just wondering I mean first of all this is also a bit silly in > that <inaudible> it’s a security thing, and I think that’s kind of a > package by itself silly because fq_codel often probably <inaudible> just in > principle, is that something I could easily attack by creating new flows > for every packet? > T: No because, they, you will… > M: With the sparse flows, and it’s gonna… > T: Yeah, but at some point you’re going to go over the threshold, I, you > could, there there’s this thing where the flow goes in, it’s sparse, it > empties out and then you put it on the normal round robin implementation > before you queue <inaudible> And if you don’t do that than you can have, > you could time packets so that they get priority just at the right time and > you could have lockout. > M: Yes. > T: But now you will just fall back to fq. > M: Ok, it was just a curiousity, it’s probably in the paper. <inaudible> > T: I think we added that in the RFC, um, you really need to, like, this > part is important. > > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat >
_______________________________________________ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
