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 <n0manlet...@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 <andrewm...@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
_______________________________________________
Codel mailing list
Codel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/codel
