From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 3C32D3B29E for ; Mon, 26 Nov 2018 14:08:53 -0500 (EST) Received: by mail-wr1-x42f.google.com with SMTP id q18so20127313wrx.9 for ; Mon, 26 Nov 2018 11:08:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heistp.net; s=google; h=from:mime-version:subject:message-id:date:to; bh=F+yABDDkg/6JwhxS1nykKthz6ntSvksR5Yg9IuH+iDM=; b=D/UdYGZ+cRg/y49dvKmXVkENxkQiHGj+TOZxMkOlhHKGbUC4hgmeF+7rv/dEeKy+hs ESSNN8MjAWQb6mUB6cqH4ObHKQqfN9DzBdXHsVAeMXW/L3m1qXsn1hP1yQnQins9MzCX ZOPQ09lwWrdzbj6We0TNTWKbclOjcaBTl346weBb8ruy1q+78tEM4/nmx3L7ckxz8f9N rnn20/km+wFf7Xik+H/tSAf7309miofJvMQB/bAOF8AFzfXeM3L9fa9rRRnKJWvqkWNM Pae1hop+l83UwRsvf2YTbVEaU/Vrt1dcun+55HzfMhHzg+GKwkZyXxanSXXyegh6rO11 7bmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=F+yABDDkg/6JwhxS1nykKthz6ntSvksR5Yg9IuH+iDM=; b=At4xbCsOpA2/2wIt95OoG3SnggZ143akTJsYdUGezUZmFrhzuBa5SCLP0ulBq9JBnw uNn01O3ehxJ5qbbp9vGCCOayWjACvkbH7YLogKUyTPNUfCY18N3yboiIfopbaCKt6IiM EA0CxaoSV2mBcbj80aa486Tz18HgkMLfVyh6RjIoWzocsRuPVl4wMkldmrr8y5L7ttjG zUNt6SEgiLk7iyNbYZhh2cBB32264Fd4cDun+UYmqxTCmymDU44JApqL84FPCXcGbMZ8 Icw7jNAfUsms8fP1GVZCksE5Dh/hjQd7mHz12WNOq4p1j0h1+HOdEmLF5/nneLxNb0sc XHYQ== X-Gm-Message-State: AA+aEWY1GX2LVh/O9jrtnI17Ug0B4gHh+F/53CEYatUpvwu8EcbnPpwT /SgeTz9xSGSiH1UtbKvhzrLlCOIq0OQ= X-Google-Smtp-Source: AFSGD/WnBW7D9+wxia2cd3nUW494wdaLTfWDyBoSpUOdkkKlwXLXBg0cvntmlwBaMXc5TuZy2kuAYA== X-Received: by 2002:adf:f903:: with SMTP id b3mr25749355wrr.82.1543259331818; Mon, 26 Nov 2018 11:08:51 -0800 (PST) Received: from tron.luk.heistp.net (h-1169.lbcfree.net. [185.193.85.130]) by smtp.gmail.com with ESMTPSA id 66sm777269wmn.38.2018.11.26.11.08.50 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Nov 2018 11:08:51 -0800 (PST) From: Pete Heist Content-Type: multipart/alternative; boundary="Apple-Mail=_2C75919F-F5F7-4942-8AF3-0E52448578F9" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Message-Id: <65EAC6C1-4688-46B6-A575-A6C7F2C066C5@heistp.net> Date: Mon, 26 Nov 2018 20:08:49 +0100 To: bloat X-Mailer: Apple Mail (2.3445.9.1) Subject: [Bloat] when does the CoDel part of fq_codel help in the real world? X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2018 19:08:53 -0000 --Apple-Mail=_2C75919F-F5F7-4942-8AF3-0E52448578F9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 In Toke=E2=80=99s 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=3Dupvx6rpSLSw&t=3D2h16m20s = My attempt at a transcript is at the end of this message. (I probably = won=E2=80=99t 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=E2=80=99ll 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=E2=80=99t 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=E2=80=A6 M: Give me any application example that=E2=80=99s 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=E2=80=A6 M: that runs on UDP often. T: Yeah, but I, Netflix=E2=80=A6 M: Ok that=E2=80=99s a long way=E2=80=A6 T: No, I tend to agree with you that, um=E2=80=A6 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, = so you may end up with a = (higher) faster completion time by buffering a lot. Uh, you=E2=80=99re = not benefitting at all by keeping the queue very small, you are simply = Right, you=E2=80=99re benefitting altogether by just = which is what the queue does with this nice sparse flow, = uh=E2=80=A6 T: You have the infinite buffers in the 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=E2=80=99t send very much. bursts, = you have to accommodate them basically. Or you have interactive traffic = which is UDP and tries to, often react from queueing delay . = I=E2=80=99m beginning to suspect that fq minus CoDel is really the best = 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=E2=80=99t = 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 it=E2=80=99s a security thing, and I think = that=E2=80=99s kind of a package by itself silly because fq_codel often = probably just in principle, is that something I could easily = attack by creating new flows for every packet? T: No because, they, you will=E2=80=A6 M: With the sparse flows, and it=E2=80=99s gonna=E2=80=A6 T: Yeah, but at some point you=E2=80=99re going to go over the = threshold, I, you could, there there=E2=80=99s this thing where the flow = goes in, it=E2=80=99s sparse, it empties out and then you put it on the = normal round robin implementation before you queue And if = you don=E2=80=99t 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=E2=80=99s probably in the paper. = T: I think we added that in the RFC, um, you really need to, like, this = part is important. --Apple-Mail=_2C75919F-F5F7-4942-8AF3-0E52448578F9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
In Toke=E2=80=99s 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=3Dupvx6rpSLSw&t=3D2h16m20s<= /a>

My attempt at a = transcript is at the end of this message. (I probably won=E2=80=99t = 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=E2=80=99ll 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=E2=80=99t = 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=E2=80=A6
M: Give me any application example = that=E2=80=99s 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=E2=80=A6
M: <inaudible> that runs on UDP often.
T: Yeah, but I, Netflix=E2=80=A6
M: Ok = that=E2=80=99s a long way=E2=80=A6 <inaudible>
T: No, I tend to agree with you that, um=E2=80=A6
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=E2=80=99re not benefitting at all by keeping the queue very = small, you are simply <inaudible> Right, you=E2=80=99re = benefitting altogether by just <inaudible> which is what the queue = does with this nice sparse flow, uh=E2=80=A6 <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=E2=80=99t 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=E2=80=99m 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=E2=80=99t 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=E2=80=99s a security = thing, and I think that=E2=80=99s 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=E2=80=A6
<= div class=3D"">M: With the sparse flows, and it=E2=80=99s = gonna=E2=80=A6
T: Yeah, but at some point you=E2=80=99= re going to go over the threshold, I, you could, there there=E2=80=99s = this thing where the flow goes in, it=E2=80=99s sparse, it empties out = and then you put it on the normal round robin implementation before you = queue <inaudible> And if you don=E2=80=99t 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=E2=80=99s probably in the = paper. <inaudible>
T: I think we added that = in the RFC, um, you really need to, like, this part is = important.

= --Apple-Mail=_2C75919F-F5F7-4942-8AF3-0E52448578F9--