From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id CC5A43B2A4 for ; Thu, 6 Apr 2017 22:47:58 -0400 (EDT) Received: by mail-oi0-x22b.google.com with SMTP id b187so72661090oif.0 for ; Thu, 06 Apr 2017 19:47:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=vQiclSmGKzk57sT3A7jEmOPOnK3Ae5b7qUQih99tV64=; b=msDUjs+2krzYQ3G2+97mqk53K759soUHm68JMXSFZZACKhDQQiPY4yV/WnQSAGexfz W+46jm9rfy81Q9QNfeZdqoveSQTCbTpsiiwvgnW+eUaCXTLr6XE8/L2JS7BGBN1uS91l x350qGP2bufoBJbcPTr+gkXn0QsrSMF8aYpTYf2dFDEY9qLosvjwP/fuHEeWbGdntv9R JHVGNRZH49v1hgnrnV0vml/YHlL+4y3+2Usj/ZfJiX18/qxpghuZR9udTbgk51hlW/FG SGmBwIrRxmgRRLLOQF3qQ+QH7wxTh9tA9AzfG/ckbQgw/BTUuBPAdQliLiDN+m06FfnM TV2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=vQiclSmGKzk57sT3A7jEmOPOnK3Ae5b7qUQih99tV64=; b=WGrFS16R+cT/AzAFfVgfc8qyF7SM2s63tmBD+f5hH2A0yim/iXaaKW91zUhdcF8ueR AHxJkWjjdRi1n//sOqze4bXCYrdmv8vIlBFITpyRaqVcA4G4aBI03Bxj4cJ50UetM0cL WIei+H5PFwA3jqXrWvw46q8rCWmD7wIuuXiaslv9FY9dd6/bELfbbAOOHRZ4Rjv07d9N 3gSw6NQS3q5xtrDcCw1a+iC0xqJPn5c96nwCmisqPbDtmnBTxVaJR1SkkKbHS8J1I7Q4 Pcjkox/cyuv1zC53BhY0n6nkvkUTdi2o/KE1KcvyXELCzboiYPqS6OXkUKZRrYKJc48s qugQ== X-Gm-Message-State: AFeK/H3h5L5E0CPRzz8rtOyKwhUnnlVOhczitxHsDE6r574JKH5nB/c+SPfVBMILIOdYpvPekHyKugtYo2DzAw== X-Received: by 10.157.40.214 with SMTP id s80mr4059408ota.93.1491533278083; Thu, 06 Apr 2017 19:47:58 -0700 (PDT) MIME-Version: 1.0 Sender: dprior@gmail.com Received: by 10.157.38.175 with HTTP; Thu, 6 Apr 2017 19:47:57 -0700 (PDT) Received: by 10.157.38.175 with HTTP; Thu, 6 Apr 2017 19:47:57 -0700 (PDT) In-Reply-To: References: From: cloneman X-Google-Sender-Auth: hH_VjUBpn_s0ydvCa_bpLJrWYFE Message-ID: To: bloat@lists.bufferbloat.net Content-Type: multipart/alternative; boundary=001a113e072c35fe9d054c8aa757 X-Mailman-Approved-At: Sat, 20 May 2017 18:38:41 -0400 Subject: [Bloat] Steam's distribution service - exceeding inbound policiers and bufferbloat 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: , Date: Fri, 07 Apr 2017 02:47:58 -0000 X-Original-Date: Thu, 6 Apr 2017 22:47:57 -0400 X-List-Received-Date: Fri, 07 Apr 2017 02:47:58 -0000 --001a113e072c35fe9d054c8aa757 Content-Type: text/plain; charset=UTF-8 Hi, Appologies in advance if this is the wrong place to ask, I haven't been able to locate an official discussion board. I'm looking for any comments on Steam's game distribution download system - specifically how it defeats any bufferbloat mitigation system I've used. It seems to push past inbound policers, exceeding them by about 40%. That is to say, if you police steam traffic to half of your line rate, enough capacity will remain to avoid packet loss, latency, jitter etc. Obviously this is too much bandwidth to reserve. 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 (multiple web downloads perform well under fq_codel) Note: in my testing cable and vdsl below 100mbit were vulnerable to this behavior, while fiber was immune. Basically there are edge cases on the internet that like to push too many bytes down a line that is dropping or delaying packets. I would like to see more discussion on this issue. I haven't tried tweaking any of the parameters / latency targets in fq_codel. --001a113e072c35fe9d054c8aa757 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

Ap= pologies in advance if this is the wrong place to ask, I haven't been a= ble to locate an official discussion board.=C2=A0
I'm looking for any comments on Steam's g= ame distribution download system - specifically how it defeats any bufferbl= oat mitigation system I've used. =C2=A0

It seems to push past inbound policers, exceeding them = by about 40%. That is to say, if you police steam traffic to half of your l= ine rate, enough capacity will remain to avoid packet loss, latency, jitter= etc. Obviously this is too much bandwidth to reserve.=C2=A0

Without any inbound control, you can = expect very heavy packet loss and jitter. With fq_codel or sfq and taking t= he usual recommended 15% off the table, you get improved, but still unaccep= table performance in your small 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 accomplished this and how to mitigate this behavior. It operates with 2= 0 http connections simultaneously, which is normally not an issue (multiple= web downloads =C2=A0perform well under fq_codel)=C2=A0

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

Basically there are edge cases on t= he internet that like to push too many bytes down a line that is dropping o= r delaying packets. I would like to see more discussion on this issue.=C2= =A0

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

--001a113e072c35fe9d054c8aa757--