Re: [Codel] [Cake] 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).

Re: [Codel] [Cake] 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).

[Noah Causin]

Steam uses a content-distribution system called Steampipe.

https://developer.valvesoftware.com/wiki/SteamPipe

I think they used to use UDP, but now they use http.  I think it helps 
clients get around restrictive firewalls.

On 6/4/2016 4:04 PM, Alan Jenkins wrote:
> On 04/06/2016, Noah Causin <n0manletter@gmail.com> wrote:
>> I notice that issue with Steam.  Steam uses lots of ECN, which can be
>> nice for saving bandwidth with large games.  The issue I notice is that
>> Steam is the one application that can cause me to have ping spikes of
>> over 100ms
> Am I right in thinking Steam uses a torrent download?  Torrent
> download (e.g. Transmission client) has the same effect on my
> connection with fq_codel.  See my last post on the bloat list and
> Dave's comment on it :).
>
> It amuses me because I used to think a) the main problem with torrents
> was due to ubiquitous upload bloat b) the uTP congestion control
> (LEDBAT) fixes it.  After monitoring uTP v.s. codel you see that's not
> the whole story.
>
> Dave's point was you can fix download bloat more easily on the ISP
> side of the bottleneck.
>
>
>> even though I have thoroughly tested my network using both
>> flent and dslreports.
>> I also notice that I get large sparse delays in the cake stats during
>> steam downloads.  The highest I can remember right now is like 22ms.
>>
>> On 6/4/2016 9:55 AM, Jonathan Morton wrote:
>>>> On 4 Jun, 2016, at 04:01, Andrew McGregor <andrewmcgr@gmail.com> wrote:
>>>>
>>>> ...servers with ECN response turned off even though they negotiate ECN.
>>> It appears that I’m looking at precisely that scenario.
>>>
>>> A random selection of connections from a packet dump show very high
>>> marking rates, which are apparently acknowledged using CWR, but a
>>> subsequent dropped packet (probably due to queue overflow) takes many
>>> seconds to be retransmitted (I’m using a rather high memory limit for
>>> observation purposes).
>>>
>>> Overall the TCP behaviour is approximately normal for NewReno on a dumb
>>> FIFO, and the ECN signalling is completely ignored.  This doesn’t rule out
>>> the possibility that it’s a different Reno relative, such as Westwood+ or
>>> Compound.
>>>
>>> There’s often more than one CWR per RTT.  This isn’t a consistent
>>> characteristic; some connections have normal-looking CWRs while others
>>> issue them every three packets, as if they’re fishing for “more accurate”
>>> ECN feedback.  It might vary by host; I didn’t keep track of that.  But
>>> this can’t be DCTCP; even that should back off in the face of a 100%
>>> marking rate, which is often achieved at my low bandwidth and with very
>>> persistent queues.
>>>
>>> Other servers respond normally to ECN signals, ruling out interference by
>>> my ISP. It’s possible the ECE flag is wiped and the CWRs are faked, but
>>> there’s no legitimate reason to do that.  The CWRs ultimately make no
>>> difference, since at 100% CE marks, every ack has ECE set anyway.
>>>
>>> Turning off ECN negotiation at the client results in a much better managed
>>> queue with similar throughput.  It’s not immediately obvious whether
>>> that’s due to a functioning congestion response or simply the AQM clearing
>>> out the queue the hard way.  It’ll be interesting to see what effect
>>> COBALT has here, when I get it to actually work.
>>>
>>> As for who these servers are: Valve Software’s Steam platform.  I did say
>>> they were large and popular.
>>>
>>>    - Jonathan Morton

Re: [Codel] [Cake] 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).

[Jonathan Morton]

> 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