From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (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 A91753B2A4 for ; Sun, 21 May 2017 10:04:10 -0400 (EDT) Received: by mail-lf0-x235.google.com with SMTP id 99so19203797lfu.1 for ; Sun, 21 May 2017 07:04:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mJICryMqFl9egvQw60t9OWa2u2fu/pXsPUBI3FMuekQ=; b=C0OjvJFO/eUo5FqfBKX2dqCmQZL+UbhlQLJnHd3YD4Yi4XD6MgzSSs0SpLQOAAn/UL R5yOhCmTLVQpYdyckuIVRJabDv0nK2nPgokiaHfO4bcVVB9buCTyIiP7Xd63dS9ZjgmC 0M0eMU+1BVANsvbxcS+M414GPilWt7rEdBEuDYcncZabVm1pVdyomgtDBl1yBJ1fgtGQ Fiif4oAI+0HBxDPDNMa6BIDK5peOY2A280ym276UW13BY2x9hLKacRTdg741jhp7xQT1 RSA488TgyYFFTnVtwc/ctAOtQDWVmB9dsbPvUg+UaSbz32FdCXeO01uS/Xl8YMg5prfi db5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mJICryMqFl9egvQw60t9OWa2u2fu/pXsPUBI3FMuekQ=; b=WT+CuxnlH0GbZT7EC5YHeEucTH+YID1HckO87O8Gd7h8mjEWFLYUDgeQ0yVtnzHWYO 7g2Ap+9pm7wnuSUVeFd6Lh3Q1Vt8+w+YzTHisi9qOFm64+ZfqHzRMuB35W5FlxrCMqh1 GjwC25D49my6sHm5fE1KIZVAMgy/e6JLoCYkNVBiCIpQv4GQp0cMk4jqK+VEaTXcwJvE pGL+zgpTEXAtWRtONBRsxbR5XXuk5EeIxh6pD1m/CyEFoat6fPjF/8WGfuZzTsfa0Hdq ksv1BLU/fsYIbAcaYsXjPhKpICkcl5Qs5oCRLW+ipSXH4CaCAHtZmh3MpYyBesUqqKyS 54tQ== X-Gm-Message-State: AODbwcCKYiWmJVTtVZjtdD4uuY3o2nMBiIOXEYPQ0b/3aVd8lBjKyyBa XcVKN93Se6SOfHAPoXAFldBHb1UtFg== X-Received: by 10.46.9.69 with SMTP id 66mr4613183ljj.10.1495375449012; Sun, 21 May 2017 07:04:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.19.220 with HTTP; Sun, 21 May 2017 07:04:08 -0700 (PDT) Received: by 10.25.19.220 with HTTP; Sun, 21 May 2017 07:04:08 -0700 (PDT) In-Reply-To: References: From: Benjamin Cronce Date: Sun, 21 May 2017 09:04:08 -0500 Message-ID: To: cloneman Cc: bloat Content-Type: multipart/alternative; boundary="94eb2c05eb1871c2f10550093aa6" 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 14:04:11 -0000 --94eb2c05eb1871c2f10550093aa6 Content-Type: text/plain; charset="UTF-8" (1500 segment*2)/5ms=4.8Mb/sec minimum per connection. 20 connections is 96Mb/sec On May 21, 2017 8:08 AM, "cloneman" wrote: > 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 >>> >>> >> --94eb2c05eb1871c2f10550093aa6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
(1500 segment*2)/5ms=3D4.8Mb/sec minimum per connection. = 20 connections is 96Mb/sec

On May 21, 2017 8:08 AM, "cloneman" <cloneman@gmail.com> wrote:
thanks for t= he 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" <bcronce@gmail.com> w= rote:
All current TCP implementations have a minimum window size of two segmen= ts. If you have 20 open connections, then the minimum bandwidth TCP will at= tempt to consume is (2 segments * 20 connection)/latency. If you have very = low latency relative to your bandwidth, the sender will not respond to cong= estion.

On T= hu, Apr 6, 2017 at 9:47 PM, cloneman <cloneman@gmail.com> w= rote:
Hi,=C2=A0

Appologies in advance if this is the = wrong place to ask, I haven't been able to locate an official discussio= n board.=C2=A0

I'm l= ooking for any comments on Steam's game distribution download system - = specifically how it defeats any bufferbloat mitigation system I've used= . =C2=A0

It seems to pus= h past inbound policers, exceeding them by about 40%. That is to say, if yo= u police steam traffic to half of your line rate, enough capacity will rema= in to avoid packet loss, latency, jitter etc. Obviously this is too much ba= ndwidth to reserve.=C2=A0

Without any inbound control, you can expect very heavy packet loss and ji= tter. With fq_codel or sfq and taking the usual recommended 15% off the tab= le, you get improved, but still unacceptable performance in your small flow= s / ping etc.=C2=A0

The = behavior can be observed by downloading any free game on their platform. I&= #39;m trying to figure out how they've accomplished this and how to mit= igate this behavior. It operates with 20 http connections simultaneously, w= hich is normally not an issue (multiple web downloads =C2=A0perform well un= der fq_codel)=C2=A0

Note= : in my testing cable and vdsl below 100mbit were vulnerable to this behavi= or, while fiber was immune.

Basically there are edge cases on the internet that like to push too ma= ny bytes down a line that is dropping or delaying packets. I would like to = see more discussion on this issue.=C2=A0

<= div dir=3D"auto">I haven't tried tweaking any of the parameters / laten= cy targets in fq_codel.=C2=A0


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

--94eb2c05eb1871c2f10550093aa6--