General list for discussing Bufferbloat
 help / color / mirror / Atom feed
From: cloneman <bufferbloat@flamingpc.com>
To: bloat@lists.bufferbloat.net
Subject: [Bloat] Steam's download CDNs - breaking bufferbloat and inbound policers
Date: Thu, 27 Apr 2017 00:19:36 -0400	[thread overview]
Message-ID: <CABQZMoKpGTjoec+Eu=QZSFef1ftFcpbhxcJ9JTy_e6AKfDsAoQ@mail.gmail.com> (raw)

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

Hi,

Apologies in advance if this is the wrong place to ask.

I'm looking for any comments on Steam's game distribution download system -
specifically how it defeats any bufferbloat management system I've used.

It seems to push past inbound policers, exceeding them by about 40%. That
is to say, you must police steam traffic to half your line rate, then
enough capacity will remain to avoid packet loss, latency, etc. Obviously
this is too much bandwidth to reserve for practical use.

Without any inbound control, you can expect very heavy packet loss and
jitter. With fq_codel or sfq and taking the usual recommended 15% off the
table, you get improved, but still unacceptable performance in your small
flows / ping etc.

The behavior can be observed by downloading any free game on their
platform. I'm trying to figure out how they've accomplished this and how to
mitigate this behavior. It operates with 20 http connections
simultaneously, which is normally not an issue (20 multiple web downloads
perform well under fq_codel and 15% reserve bandwidth)

Note: in my testing cable and vdsl below 100mbit were vulnerable to this
behavior, while fiber was immune.

Basically there are edge application cases on the internet that like to
push too many bytes down a line. I would like to see some discussion or
testing of this issue.

I haven't tried tweaking any of the parameters / latency targets in
fq_codel.

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

             reply	other threads:[~2017-04-27  4:19 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-27  4:19 cloneman [this message]
2017-04-27  4:27 ` Jonathan Morton
2017-04-27 18:11 ` Tristan Seligmann

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/bloat.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CABQZMoKpGTjoec+Eu=QZSFef1ftFcpbhxcJ9JTy_e6AKfDsAoQ@mail.gmail.com' \
    --to=bufferbloat@flamingpc.com \
    --cc=bloat@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