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

[Neal Cardwell <ncardwell@google.com>]

[-- Attachment #1: Type: text/plain, Size: 6369 bytes --]

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 <pete@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
>

[-- Attachment #2: Type: text/html, Size: 7373 bytes --]