From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (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 87D073B2BC; Sat, 4 Jun 2016 17:21:39 -0400 (EDT) Received: by mail-io0-x230.google.com with SMTP id t40so110940690ioi.0; Sat, 04 Jun 2016 14:21:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=iGRRllrTpqufrthMgQg+yX/Or8EKzXfU68KJJfk8q4M=; b=TAXaU4Dj+kedHve23oyYwLW7kph6OSZAkgq0SwYiAhgwXMOaJ/DC2OlErfIYpYwY83 TuUJCp+jkExKUlzIJKHZ49toqT7VydLip862SLGsgjV6NpQtdiYEojZbbwJx/KDm/Bea zvGga/tKXfLL1aN4eY3Pqve74FnMv5BkRxzPbvm8yjKe6Lf7OsJKLVolWdoBq25g8Ufe g2DCNQ0ajRj4vLAaCfI85mlwvb0Nz0eTZsWkojxv4v1qUV2XvQ6pNcnM6YhIeMWIzOvD 0B6WyhmjxicYFaLveejwitOWZjSvTaOGB/iKSFQtB77qIRxADh4Pj1j+CIo37zCw56QG EPug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=iGRRllrTpqufrthMgQg+yX/Or8EKzXfU68KJJfk8q4M=; b=SRBH2DG4htBDlTHQhg+/Hq9PrYV0WUPu9beRUeULN1rKbF7KzxIb7kjfk9CwZdhHG7 EYOFFKlEe+rBRSB2hhqp+hObvjGXsbqHhvcKaUIZQjusVxXR93icGKmE01BA+wVTYuQS 7vUO4Orcu64wIg53rPx83f9mMc36v4SkV0ipdOncmnT0SZFGJA6Qby0tmS40opcRiPLO expODvNpoksoP6qBLIXpNFHsFoE0ZOR1xJ/DKwh1Jq6APuee+T71kraQrOQS5YxD2BeN o9waHxlOZ6S6ujjXqd/g9o1Vo4OZou2Nvig+NA7rArxZqjqdfDxusI+Qk3wrk+kfdGxc iv9Q== X-Gm-Message-State: ALyK8tIhYFXqbCSobydLNomV365NEO4qQtu8eg4y7KgtIjdsn2dSZydn/2FETwloyF9rtg== X-Received: by 10.107.12.16 with SMTP id w16mr14897176ioi.114.1465075299029; Sat, 04 Jun 2016 14:21:39 -0700 (PDT) Received: from ?IPv6:2601:404:381:a21:f4bb:d1bc:160a:c961? ([2601:404:381:a21:f4bb:d1bc:160a:c961]) by smtp.gmail.com with ESMTPSA id a67sm5602780ioe.0.2016.06.04.14.21.38 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 04 Jun 2016 14:21:38 -0700 (PDT) To: Alan Jenkins References: Cc: Jonathan Morton , Andrew McGregor , cake@lists.bufferbloat.net, "codel@lists.bufferbloat.net" From: Noah Causin Message-ID: <4842e22b-0944-4cdc-8982-8fa8cc287aec@gmail.com> Date: Sat, 4 Jun 2016 17:21:37 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Codel] [Cake] Proposing COBALTLike the issues with streaming video, which are potentially addressed by the fq qdisc. I wonder how much it would help for torrents. (Avoiding bursting the entire congestion window at the start of chunk 2, using pacing). X-BeenThere: codel@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: CoDel AQM discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2016 21:21:39 -0000 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 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 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