Cake - FQ_codel the next generation
 help / color / mirror / Atom feed
From: Jonathan Morton <chromatix99@gmail.com>
To: Alan Jenkins <alan.christopher.jenkins@gmail.com>
Cc: Noah Causin <n0manletter@gmail.com>,
	Andrew McGregor <andrewmcgr@gmail.com>,
	cake@lists.bufferbloat.net,
	"codel@lists.bufferbloat.net" <codel@lists.bufferbloat.net>
Subject: Re: [Cake] [Codel] Proposing COBALTLike the issues with streaming video, which are potentially addressed by the fq qdisc. I wonder how much it would help for torrents. (Avoiding bursting the entire congestion window at the start of chunk 2, using pacing).
Date: Sun, 5 Jun 2016 01:03:21 +0300	[thread overview]
Message-ID: <2F1AD7A4-EEE8-4519-B2E6-75CD4784D2B2@gmail.com> (raw)
In-Reply-To: <CANmMgnGtPHq0Zi73hYtHu0KkWsMs7h9rJKRE2kE2HO_L5UzS3A@mail.gmail.com>


> On 4 Jun, 2016, at 23:04, Alan Jenkins <alan.christopher.jenkins@gmail.com> wrote:
> 
> Am I right in thinking Steam uses a torrent download?

No; though it is a multi-stream system, it’s basically HTTP (with offset/range) plus some minor special sauce.  Several files can be fetched at once in parallel, and these separate connections are usually to different servers.

It differs from torrent swarms most fundamentally in that there is no uploading; all the content comes from official servers.  This also means that fewer connections are needed to fill a given download pipe (usually just one would do the trick).

We’re at a significant disadvantage because we typically have to apply our AQM *after* the bottleneck link in the downstream direction.  This means we have to somehow prevent senders from sending too many packets in order to avoid inducing delay within the ISP’s dumb buffers, rather than being able to buffer them smartly ourselves as a last resort.  We therefore rely on effective congestion control, with flow-isolation being primarily a means to target the signals more precisely.

Servers which defeat our primary method of doing so (by ignoring the copious signals saying “slow down please”) are ultimately unhelpful.  But at least they are still ack-clocked.

 - Jonathan Morton


      parent reply	other threads:[~2016-06-04 22:03 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-04 20:04 Alan Jenkins
2016-06-04 21:21 ` Noah Causin
2016-06-04 22:03 ` Jonathan Morton [this message]

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

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

  git send-email \
    --in-reply-to=2F1AD7A4-EEE8-4519-B2E6-75CD4784D2B2@gmail.com \
    --to=chromatix99@gmail.com \
    --cc=alan.christopher.jenkins@gmail.com \
    --cc=andrewmcgr@gmail.com \
    --cc=cake@lists.bufferbloat.net \
    --cc=codel@lists.bufferbloat.net \
    --cc=n0manletter@gmail.com \
    /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