From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x22f.google.com (mail-oi1-x22f.google.com [IPv6:2607:f8b0:4864:20::22f]) (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 4E25F3B29E for ; Mon, 26 Nov 2018 14:28:25 -0500 (EST) Received: by mail-oi1-x22f.google.com with SMTP id w13so16936138oiw.9 for ; Mon, 26 Nov 2018 11:28:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ldjt0wRLXVy6VQ4nGrd3Dlbwc+of2N9Vvv7c/qJLakQ=; b=fQ4hOwDvrX9YU7ASSvxNWn/j7CePQjsCmzXxJfVwt9e9haFREZ74FN3nP4CWpf85X9 mJt+ov0BSBflup1SlFOfYD/EYSM+xWQLkYRxwc66lSCqNAG8CN2d63pee8LxTPU68CbK g+Krg33vsIFjq5X1LVvLkdFQeJLYX2NgyZgcO0594IlgBYVZrwPywVIlgylgGrZiTv2U j4IFakBPDZU7+HNsmJ16BY5dbj4KmfSxZkzh0ujLxWMlizWPTSo9r+8O/4XZZqPd2dnK Qe16BEhNyE9wB3QQmeNr4i+zFjo1vURNVkR7Zd9NSu2ssZJbGTX1lFDKafZU86Ru1Zvg gQUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ldjt0wRLXVy6VQ4nGrd3Dlbwc+of2N9Vvv7c/qJLakQ=; b=i2LeNB7OlcCFjxDg5J9QyZYTCp+tI+n+nJwZAQ3kd3Czkv5AH3cIlGdhhLS/oKgltd xl056OHV7Ok7J6+qA9xCR3/s8FWuKVjFGWiYXmWt0E6Ke4rGQe2HqqpbzaFb0o7X2g5E S9/CS9+dym4vMXCeuDWkkLgjaz5IKgxlgdjAhiaUG3x4DPtjDcocXfOz++rDh9CI8lgR Ferg30hLBsowfaWbwRLnJXsm0p5IGVYyAZzO6/U5A8WSqf6PXWnW/I1ZdHQ+E//lw/uE kTTa4L/6vee/2EZB2pI7n0G8o+7m9ZYtpOgGcBnjP/H0pCGu7adltMizKVpCArUK4K1c sYQQ== X-Gm-Message-State: AGRZ1gIAGhsBRndYLRGRFimi1Oxuc55zil0aR5p1uGXGwOOqyWkwkJp5 fW7yoCwBy3mDzrfgdWX3IQpjBPGiLnUyjcb9wz7OLjy4kUg= X-Google-Smtp-Source: AJdET5fwJFtOWu66ElwA1HIK90H8kEQu9uYQvhcfTT86kUdqx/bXkGyZt9fQyc4Ce8rWsR6UeO0yiiFGejpbaGPI0PI= X-Received: by 2002:aca:3d42:: with SMTP id k63mr16660967oia.95.1543260504309; Mon, 26 Nov 2018 11:28:24 -0800 (PST) MIME-Version: 1.0 References: <65EAC6C1-4688-46B6-A575-A6C7F2C066C5@heistp.net> In-Reply-To: <65EAC6C1-4688-46B6-A575-A6C7F2C066C5@heistp.net> From: Neal Cardwell Date: Mon, 26 Nov 2018 14:28:07 -0500 Message-ID: To: pete@heistp.net Cc: bloat , Dave Taht Content-Type: multipart/alternative; boundary="000000000000284ca7057b965654" Subject: Re: [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:28:25 -0000 --000000000000284ca7057b965654 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 wrote: > 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 mor= e 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 f= ew > 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 n= ew > map data while position updates or chat happen at the same time. Standalo= ne > 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 sequen= ce > 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 no= t > 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 lik= e > - 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, y= ou 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 be= ginning 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, bu= t > 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=99= s 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 ca= n have, > you could time packets so that they get priority just at the right time a= nd > 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. > > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat > --000000000000284ca7057b965654 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I believe Dave Taht has pointed out, essentially, that the= "codel" part of fq_codel can be useful in cases where the defini= tion of "flow" is not visible to fq_codel, so that "fq"= part is inactive. For example, if there is VPN traffic, where the individu= al flows are not separable by fq_codel, then it can help to have "code= l" AQM for the aggregate of encrypted VPN traffic. I imagine this rati= onale could apply where there is any kind of encapsulation or encryption th= at makes the notion of "flow" opaque to fq_codel.

<= div>neal


On Mon, Nov 26, 2018 at 2:08 PM Pete Heist <pete@heistp.net> wrote:
In Toke=E2=80=99s thesis defense, there was an interesting exchan= ge with examination committee member Michael (apologies for not catching th= e last name) regarding how the CoDel part of fq_codel helps in the real wor= ld:

https://www.youtube.com/watch?v= =3Dupvx6rpSLSw&t=3D2h16m20s

My attempt at a tran= script is at the end of this message. (I probably won=E2=80=99t attempt a f= ull defense transcript, but if someone wants more of a particular section I= can try. :)

So I just thought to continue the dis= cussion- when does the CoDel part of fq_codel actually help in the real wor= ld? 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 ne= w map data while position updates or chat happen at the same time. Standalo= ne programs could use HTTP/2.0 this way, or for web apps, the browser may m= ultiplex concurrent uses of XHR over a single TCP connection. I don=E2=80= =99t know of any examples.

2) SSH with port forwar= ding while using an interactive terminal together with a bulk transfer?

3) Does CoDel help the TCP protocol itself somehow? F= or example, does it speed up the round-trip time when acknowledging data se= gments, improving behavior on lossy links? Similarly, does it speed up the = TCP close sequence for saturating flows?

Pete

---

M: In fq_codel what is re= ally the point of CoDel?
T: Yeah, uh, a bit better intra-flow lat= ency...
M: Right, who cares about that?
T: Apparently s= ome people do.
M: No I mean specifically, what types of flows car= e about that?
T: Yeah, so, um, flows that are TCP based or have s= ome kind of- like, elastic flows that still want low latency.
M: = Elastic flows that are TCP based that want low latency...
T: Thin= gs 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 h= ave problems with this.
T: I, I do too... So like, you can implem= ent things this way but equivalently if you have something like fq_codel yo= u could, like, if you have a video streaming application that interleaves c= ontrol=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 lon= g 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 chan= ce 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, y= ou=E2=80=99re not benefitting at all by keeping the queue very small, you a= re 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 buff= ers in the <inaudible> for that to work, right. One benefit you get f= rom CoDel is that - you screw with things like - you have to drop eventuall= y.
M: You should at some point. The chances are bigger that the s= mall flow succeeds (if given a huge queue). And, in web surfing, why does t= hat, uh(?)
T: Yeah, mmm...
M: Because that would be an = example of something where I care about latency but I care about low comple= tion. Other things where I care about latency they often don=E2=80=99t send= very much. <inaudible...> bursts, you have to accommodate them basic= ally. Or you have interactive traffic which is UDP and tries to, often reac= t from queueing delay <inaudible>. I=E2=80=99m beginning to suspect t= hat fq minus CoDel is really the best <inaudible> out there.
T: But if, yeah, if you have enough buffer.
M: Well, the more t= he 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 sai= d yeah.
T: No but like, it goes back to good-queue bad-queue, lik= e, 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 doe= sn=E2=80=99t help in itself.
M: Right yeah. Uh, I have a silly qu= estion 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 fir= st 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 sil= ly 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
M: With the sp= arse 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 th= ere=E2=80=99s this thing where the flow goes in, it=E2=80=99s sparse, it em= pties out and then you put it on the normal round robin implementation befo= re you queue <inaudible> And if you don=E2=80=99t do that than you ca= n 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 importan= t.

______________________________________________= _
Bloat mailing list
Bloat@list= s.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
--000000000000284ca7057b965654--