From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from homiemail-a82.g.dreamhost.com (sub5.mail.dreamhost.com [208.113.200.129]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 31B733B29E for ; Thu, 27 Apr 2017 00:19:39 -0400 (EDT) Received: from homiemail-a82.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a82.g.dreamhost.com (Postfix) with ESMTP id 692496008D2B for ; Wed, 26 Apr 2017 21:19:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=flamingpc.com; h= mime-version:from:date:message-id:subject:to:content-type; s= flamingpc.com; bh=IJhsNUG5nvA1FJ49+gCS5GAOJdI=; b=XqBQVzlxxWIYHy HjBwdCNkthVPTcAWrU4Kd7lF0DJuvtjtu2EcIBf0xjhnLMpw0VcsDF1pzB0KmUnW +pZWzhu2Vd34BvDxuzUVPNbrszh8Ff6iGCm4W3uqc2pWZUWIzrBbBySTILlGpINJ NcbozHEepStZQIv1x+zhq1qoTEiIM= Received: from mail-oi0-f42.google.com (mail-oi0-f42.google.com [209.85.218.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: fpc_mail@flamingpc.com) by homiemail-a82.g.dreamhost.com (Postfix) with ESMTPSA id A180A6008D26 for ; Wed, 26 Apr 2017 21:19:37 -0700 (PDT) Received: by mail-oi0-f42.google.com with SMTP id y11so24650155oie.0 for ; Wed, 26 Apr 2017 21:19:37 -0700 (PDT) X-Gm-Message-State: AN3rC/7K77FseO9y5csAjP3tvodp/jNehZuxWZkXM4rASym4YvmAOJd4 1uUlNHIBrgBF8PdyQvjbGq0JcQRUzw== X-Received: by 10.202.191.68 with SMTP id p65mr1723398oif.152.1493266777082; Wed, 26 Apr 2017 21:19:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.33.131 with HTTP; Wed, 26 Apr 2017 21:19:36 -0700 (PDT) From: cloneman Date: Thu, 27 Apr 2017 00:19:36 -0400 X-Gmail-Original-Message-ID: Message-ID: To: bloat@lists.bufferbloat.net Content-Type: multipart/alternative; boundary=001a113dd48acd9465054e1e430b Subject: [Bloat] Steam's download CDNs - breaking bufferbloat and inbound policers X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 04:19:39 -0000 --001a113dd48acd9465054e1e430b Content-Type: text/plain; charset=UTF-8 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. --001a113dd48acd9465054e1e430b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,=C2= =A0
Apolog= ies 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. =C2=A0

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

Without any inbound control, you can expect very heavy packet los= s 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 sm= all flows / ping etc.=C2=A0

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

Note: in my testing c= able and vdsl below 100mbit were vulnerable to this behavior, while fiber w= as immune.

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

I haven't tried tweaking any of the parameters / latency targets = in fq_codel.=C2=A0
--001a113dd48acd9465054e1e430b--