From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (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 3FA3B3B2A4 for ; Sun, 21 May 2017 09:08:10 -0400 (EDT) Received: by mail-oi0-x231.google.com with SMTP id w10so135281366oif.0 for ; Sun, 21 May 2017 06:08:10 -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:cc; bh=u5KI2PbM5MVjEWmBBWCAbb3FLyQBXSaT/TT/+HaIlys=; b=h4rjcA4nIc0E86UfeBTSnXld01X5Otru3oDP17Tmo9G0ny6z2uHhN129LC8AHaKz7x /oP+YErA7ZIxw96UhySHLB2Rt+X/1XjGy/wlkr3TDvFW7PUruhItqa5M4K4W5wh24JBJ +kiffFvKzWTQeZPIi3/4a/vbkoniiE+n4Q3m4+V9b7wxRIo1wT26bfQBrnnPzF37DWs7 dP87y7gk5+e6mTz0Yws1yV/orPCm5oOgsVjBFYB9UsJd1gQLgHMw4cWyE4uGesH73g7p nvcNf+jQoK82JEmql1fBbuAhzk6BXKBgsYnMDyuyF6PhVkWHHkdgmGya4UXor/yfjrwZ GTiQ== 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:cc; bh=u5KI2PbM5MVjEWmBBWCAbb3FLyQBXSaT/TT/+HaIlys=; b=al/xW60t23wYE+FKkLFK9aSl+Wmhl3q4kzt0gU8LihoeajZHN71SWRuHuKU6dnan0z 91LAO/l3EeBlmWN76ML/CWlMEpM197Z6DRxMarG5vFC7iIyRsxDDrQ3iQxwqeFtNRQmU TGr6WFUVvuz/R7W3B5twofEnCGtBA3eG3KtvL5qeuoZg02Nmexvqx55ufoiR1KW/FYYy iNyhYBAw3NS2cZSTKbFiXbG0AtOWtIJENqIFYcHOYyUW238m3RKGWAxWZgfGOgzz3Rdv GtcYpYTfE3GMi+BVYzWvQXY5OHGcIR7oHKW0YTh8DgrK7EeV9MJrvdzBAFPa96P86OmH Ow9Q== X-Gm-Message-State: AODbwcAcjvMsn1aDTsgpkD0Ioex05+Zyr0iVnc0WdsAwCnJDbVD9hEQe gJGES2ljIkXDdivK2tyL//TvYsArGQ== X-Received: by 10.157.27.233 with SMTP id v38mr11279677otv.162.1495372089661; Sun, 21 May 2017 06:08:09 -0700 (PDT) MIME-Version: 1.0 Sender: dprior@gmail.com Received: by 10.157.33.226 with HTTP; Sun, 21 May 2017 06:08:08 -0700 (PDT) Received: by 10.157.33.226 with HTTP; Sun, 21 May 2017 06:08:08 -0700 (PDT) In-Reply-To: References: From: cloneman Date: Sun, 21 May 2017 09:08:08 -0400 X-Google-Sender-Auth: 8s5YahYe7HKGPGQJFJ6PTaNga4I Message-ID: To: Benjamin Cronce Cc: bloat Content-Type: multipart/alternative; boundary="001a113e1f54361e320550087237" X-Mailman-Approved-At: Thu, 25 May 2017 10:40:33 -0400 Subject: Re: [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: , X-List-Received-Date: Sun, 21 May 2017 13:08:10 -0000 --001a113e1f54361e320550087237 Content-Type: text/plain; charset="UTF-8" thanks for the info. This is a possibility, as I have 5ms latency to their servers with 50mbit of bandwidth. On May 21, 2017 8:49 AM, "Benjamin Cronce" wrote: > All current TCP implementations have a minimum window size of two > segments. If you have 20 open connections, then the minimum bandwidth TCP > will attempt to consume is (2 segments * 20 connection)/latency. If you > have very low latency relative to your bandwidth, the sender will not > respond to congestion. > > On Thu, Apr 6, 2017 at 9:47 PM, cloneman wrote: > >> 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. >> >> >> _______________________________________________ >> Bloat mailing list >> Bloat@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/bloat >> >> > --001a113e1f54361e320550087237 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
thanks for the info. This is a possibility, as I have 5ms= latency to their servers with 50mbit of bandwidth.

On May 21, 2017 8:49 AM, "Benj= amin Cronce" <bcronce@gmail.co= m> wrote:
All current TCP implementations have a minimum window size of= two segments. If you have 20 open connections, then the minimum bandwidth = TCP will attempt to consume is (2 segments * 20 connection)/latency. If you= have very low latency relative to your bandwidth, the sender will not resp= ond to congestion.

On Thu, Apr 6, 2017 at 9:47 PM, cloneman <cloneman@gmail.com&g= t; wrote:
Hi,=C2= =A0

Appologies in advance if t= his is the wrong place to ask, I haven't been able to locate an officia= l discussion board.=C2=A0

I'm looking for any comments on Steam's game distribution downloa= d system - specifically how it defeats any bufferbloat mitigation system I&= #39;ve used. =C2=A0

It s= eems 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 capacit= y 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 the usual recommended 15% = off the table, you get improved, but still unacceptable performance in your= small flows / ping etc.=C2=A0

The behavior can be observed by downloading any free game on their p= latform. I'm trying to figure out how they've accomplished this and= how to mitigate this behavior. It operates with 20 http connections simult= aneously, which is normally not an issue (multiple web downloads =C2=A0perf= orm well under fq_codel)=C2=A0

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 wou= ld like to see more discussion on this issue.=C2=A0
=
I haven't tried tweaking any of the paramet= ers / latency targets in fq_codel.=C2=A0

<= /div>
_______________________________________________
Bloat mailing list
Bloat@list= s.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

--001a113e1f54361e320550087237--