From: Dave Taht <dave.taht@gmail.com>
To: "cerowrt-devel@lists.bufferbloat.net"
<cerowrt-devel@lists.bufferbloat.net>
Subject: [Cerowrt-devel] Fwd: [proto-quic] Bad router QoS settings can disrupt QUIC
Date: Thu, 23 Apr 2015 13:59:45 -0700 [thread overview]
Message-ID: <CAA93jw6XbrhcwAnyhLRUxfgmkGXg0wAxCJ94QS=LpYxwBRTebA@mail.gmail.com> (raw)
In-Reply-To: <36c42052-1ce6-4e94-b4ab-6b9186fa3d1e@chromium.org>
---------- Forwarded message ----------
From: Nelson Minar <nelson@monkey.org>
Date: Thu, Apr 23, 2015 at 11:57 AM
Subject: [proto-quic] Bad router QoS settings can disrupt QUIC
To: proto-quic@chromium.org
I just fixed a problem where Google Chrome wasn't working well with
Google sites and wanted to share my experience in case it helps
anyone.
The problem was that Google sites were loading very slowly in Chrome
using QUIC. HTTP requests everywhere were working fine, but Google
search and Google Groups using QUIC were super-slow. I think the
problem was my router's QoS settings. The default QoS config for this
firmware has a rule which is "unidentified UDP protocols are labeled
Crawl and limited to 5% of bandwidth". QUIC was unidentified. Removing
that rule fixed the problem.
The QoS rule in the router is definitely stupid but it may not be
entirely uncommon. I had the rule as a default from Tomato v1.32
(Toastman). I think some of the newer Tomato/Shibby builds have a rule
like this as well. QoS is off by default in Tomato, but if you turn it
on you get this Crawl classification. And while Tomato is hackerware
and people who use it should know better, I suspect many of its QoS
ideas have made their way into commercial products. Newer ASUS
routers, for instance, have a Tomato-derived firmware installed.
Every time I see a new UDP protocol on the Internet I worry what all
may break. I love UDP but a whole lot of Internet infrastructure these
days is optimized only for TCP (or worse, HTTP). I don't think QUIC is
a bad idea at all, I'm just curious what UDP misconfigurations it will
uncover.
--
You received this message because you are subscribed to the Google
Groups "QUIC Prototype Protocol Discussion group" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to proto-quic+unsubscribe@chromium.org.
To post to this group, send email to proto-quic@chromium.org.
For more options, visit https://groups.google.com/a/chromium.org/d/optout.
--
Dave Täht
Open Networking needs **Open Source Hardware**
https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67
parent reply other threads:[~2015-04-23 20:59 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <36c42052-1ce6-4e94-b4ab-6b9186fa3d1e@chromium.org>]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/cerowrt-devel.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAA93jw6XbrhcwAnyhLRUxfgmkGXg0wAxCJ94QS=LpYxwBRTebA@mail.gmail.com' \
--to=dave.taht@gmail.com \
--cc=cerowrt-devel@lists.bufferbloat.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox