From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 0D48221F357 for ; Thu, 12 Mar 2015 11:05:18 -0700 (PDT) Received: by qgfi50 with SMTP id i50so20100775qgf.9 for ; Thu, 12 Mar 2015 11:05:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=rtlRN3VPWey2pHgxg2fxu2DiAVRZoalWGbHUvMNsTq0=; b=e2pK+r7gs72t/5BOm+LvTkVO/l+dj+/Br+/KLlAHgZDipXHh3n8bHYgyMUs20Qtq1B jiMEQRMGG5OxGeRIFJtWpI86HtB29cTPSLVKW+dgvJ0P8J4+kDg1mXmEiCXChX3upc3C u1awGZJpb/qA2KCi9Ptv4xxUgGOZdbpeP3iyZGHlugx6N2j/piwvnUCH9ZxCxwOLi8/v gAS6EgY+nGEI1uaTMat6TgOV723LJec4368JhgzTqD6a09Y8DpCp+GYSkrzoL88ABMEF tpT6vy11IA09/AUSBWPzcXqMEA5AvITg78qvchhSjxOHaRH/yvI2rlSlWYsNn9Doz49l b+Ng== X-Received: by 10.55.27.198 with SMTP id m67mr60402927qkh.11.1426183517415; Thu, 12 Mar 2015 11:05:17 -0700 (PDT) Received: from richs-mbp-10249.home.lan (pool-71-173-64-230.ptldme.east.myfairpoint.net. [71.173.64.230]) by mx.google.com with ESMTPSA id 4sm5232536qky.7.2015.03.12.11.05.16 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Mar 2015 11:05:16 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_B9D02386-F919-4C89-A426-C7B06ADE73A5"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Rich Brown In-Reply-To: Date: Thu, 12 Mar 2015 14:05:14 -0400 Message-Id: <33718F69-B821-4376-A558-B231B6FAE30E@gmail.com> References: To: Kartik Agaram X-Mailer: Apple Mail (2.1878.6) Cc: Jordan Peacock , bloat@lists.bufferbloat.net Subject: Re: [Bloat] http/2 X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 18:05:47 -0000 --Apple-Mail=_B9D02386-F919-4C89-A426-C7B06ADE73A5 Content-Type: multipart/alternative; boundary="Apple-Mail=_F0F1E4C3-557E-4E40-BD39-8E23914DE828" --Apple-Mail=_F0F1E4C3-557E-4E40-BD39-8E23914DE828 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Kartik, Thanks for the questions. > Has HTTP/2[1] been discussed on this list?[2] I've been thinking about = bufferbloat as I read the spec, and had a couple of questions that = weren't answered in the FAQ[3]: >=20 > 1. HTTP/2 reduces the number of connections per webpage. Assume for a = second that all players instantaneously adopt HTTP/2 and so reduce their = buffer sizes everywhere. Latencies will improve and there'll be less = congestion. Now back to the real world with people building websites, = trying to improve performance of websites and devices all over the = place. Will bufferbloat stay eradicated, or will the gains be temporary? A Bufferbloat algorithm (fq_codel, or other SQM (smart queue = management)) is required to minimize the number of buffers queued at = *any* bottleneck in a network. This occurs frequently at the home = router/edge of the network, but can appear anywhere. Wherever a queue = begins to build up in a network, optimal performance demands some kind = of SQM HTTP/2 may well help by requesting fewer connections, but the SQM in the = router will still be in effect. If the smaller number of HTTP/2 requests = from the browser don't create a queue, then SQM won't even become = active. But if the browser traffic does manage to generate a queue, the = router's SQM will keep it under control. I want to emphasize that point: SQM doesn't force any fixed allocations = of bandwidth, packet rate, etc. It actually measures the queue length = (in msec) for each traffic flow. If all the packets are whistling = through without any congestion, every sender will get the full rate of = the link. SQM only becomes active when there *is* congestion, and it = throttles those flows that are sending the most traffic (to preserve the = link capacity for the "little flows" that are time sensitive.=20 > 2. More generally, is there any technical way for bufferbloat to stay = solved? Or is it an inevitable tragedy of the commons dynamic that we = just have to live with and make temporary dents in? Yes, it will stay solved. No, there's no tragedy of the commons. (Great = question, though.) The SQM algorithm only examines packets within a = single router, so multiple routers are essentially independent. There's = no central communication required - it's all local to a router. In fact, the "tragedy" of solving bufferbloat is that it needs to be = solved *everywhere*. That is to say that *every* router, cell phone, = DSLAM, Cable modem (home and head-end), personal computer OS, and other = piece of equipment on the planet needs to be updated. This is the hard = part. > 3. Has there been discussion of solving bufferbloat at the TCP layer, = by making buffers harder to fill up? I'm thinking of heuristics like = disallowing a single site from using 80% of the buffer, thereby leaving = some slack available for other bursty requirements. I am personally not hopeful for this kind of approach. a) The TCP = algorithm in hosts isn't easily made aware of congestion elsewhere in = the network, so it can't react to that congestion; b) there aren't a lot = of tested proposals (beyond dropping packets) to make things better; c) = it suffers from exactly the same problem as solving bufferbloat - it = needs to be rolled out in every piece of gear. (We can't even attract = the attention of vendors (Apple, Microsoft, most routing gear, etc). to = implement the solved algorithms to improve bufferbloat. Sigh.) > I'm sure these questions are quite naive. Pointers to further reading = greatly appreciated. >=20 > Kartik > http://akkartik.name/about >=20 > [1] = https://insouciant.org/tech/http-slash-2-considerations-and-tradeoffs >=20 > [2] Google search on "site:https://lists.bufferbloat.net" didn't turn = up anything, and I get "permission denied" when trying to access the = downloadable archives at https://lists.bufferbloat.net/pipermail/bloat. >=20 > [3] https://gettys.wordpress.com/bufferbloat-faq > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat --Apple-Mail=_F0F1E4C3-557E-4E40-BD39-8E23914DE828 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Kartik,

Thanks for the = questions.

Has HTTP/2[1] been discussed on this list?[2] I've been = thinking about bufferbloat as I read the spec, and had a couple of = questions that weren't answered in the FAQ[3]:

1. = HTTP/2 reduces the number of connections per webpage. Assume for a = second that all players instantaneously adopt HTTP/2 and so reduce their = buffer sizes everywhere. Latencies will improve and there'll be less = congestion. Now back to the real world with people building websites, = trying to improve performance of websites and devices all over the = place. Will bufferbloat stay eradicated, or will the gains be = temporary?

A Bufferbloat = algorithm (fq_codel, or other SQM (smart queue management)) is required = to minimize the number of buffers queued at *any* bottleneck in a = network. This occurs frequently at the home router/edge of the network, = but can appear anywhere. Wherever a queue begins to build up in a = network, optimal performance demands some kind of = SQM

HTTP/2 may well help by requesting fewer = connections, but the SQM in the router will still be in effect. If the = smaller number of HTTP/2 requests from the browser don't create a queue, = then SQM won't even become active. But if the browser traffic does = manage to generate a queue, the router's SQM will keep it under = control.

I want to emphasize that point: SQM = doesn't force any fixed allocations of bandwidth, packet rate, etc. It = actually measures the queue length (in msec) for each traffic flow. If = all the packets are whistling through without any congestion, every = sender will get the full rate of the link. SQM  only becomes active = when there *is* congestion, and it throttles those flows that are = sending the most traffic (to preserve the link capacity for the "little = flows" that are time sensitive. 

2. More generally, is there any = technical way for bufferbloat to stay solved? Or is it an inevitable = tragedy of the commons dynamic that we just have to live with and make = temporary dents in?

Yes, it will = stay solved. No, there's no tragedy of the commons. (Great question, = though.) The SQM algorithm only examines packets within a single router, = so multiple routers are essentially independent. There's no central = communication required - it's all local to a = router.

In fact, the "tragedy" of solving = bufferbloat is that it needs to be solved *everywhere*. That is to say = that *every* router, cell phone, DSLAM, Cable modem (home and head-end), = personal computer OS, and other piece of equipment on the planet needs = to be updated. This is the hard part.

3. Has there been discussion of = solving bufferbloat at the TCP layer, by making buffers harder to fill = up? I'm thinking of heuristics like disallowing a single site from using = 80% of the buffer, thereby leaving some slack available for other bursty = requirements.

I am = personally not hopeful for this kind of approach. a) The TCP algorithm = in hosts isn't easily made aware of congestion elsewhere in the network, = so it can't react to that congestion; b) there aren't a lot of tested = proposals (beyond dropping packets) to make things better; c) it suffers = from exactly the same problem as solving bufferbloat - it needs to be = rolled out in every piece of gear. (We can't even attract the attention = of vendors (Apple, Microsoft, most routing gear, etc). to implement the = solved algorithms to improve bufferbloat. Sigh.)

I'm sure these questions are quite = naive. Pointers to further reading greatly = appreciated.

Kartik
http://akkartik.name/about
[2] Google search on "site:https://lists.bufferbloat.net"= didn't turn up anything, and I get "permission denied" when trying to = access the downloadable archives at https://lists.buffe= rbloat.net/pipermail/bloat.

[3] https://gettys.wordp= ress.com/bufferbloat-faq
_______________________________________________
Bloat mailing = list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
= --Apple-Mail=_F0F1E4C3-557E-4E40-BD39-8E23914DE828-- --Apple-Mail=_B9D02386-F919-4C89-A426-C7B06ADE73A5 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJVAdVaAAoJEH4agC/0z73/XoUIAIJ5P/m60/+ZvTdEaija2RQU Hjo98RdC+5ebZ/S+VocNjtcqDQi/D5+Fp+F7Gw1evq8emGFE1Yf9lyiAqLFNw5Xf Am7YIW2oNewZfswaQIP6plz5hAI8O/FgbhzvqFn2WbAEARLUWHkRG6sN3sX8f13A QiA95KHxpRsVmUHE5WXNP2j+HnTrmEpiqx/jOy6cnt97eryrNHj+r4jQynKtur8j HF0w386UHvIZmoswr3esG2SVoF8KOKMX+cEm8S2PdhzVyvisQoD5h2Z47lySmTbL txzZlt8b30WNJtbb6/FTq8nSV4ts2nKXWy3xIq70L1Hqj4U8gSxm+I/5tyY59QQ= =y8sE -----END PGP SIGNATURE----- --Apple-Mail=_B9D02386-F919-4C89-A426-C7B06ADE73A5--