From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (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 3220F3B2BC; Sat, 4 Jun 2016 16:04:27 -0400 (EDT) Received: by mail-it0-x232.google.com with SMTP id a64so5109214itd.0; Sat, 04 Jun 2016 13:04:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc :content-transfer-encoding; bh=DufHoh6riktL7V7Dcbn+oDHsBltCl0Npr9EPkihba8A=; b=XDQDonAxaSsmI+AeT8qofpo4LV0cz0s53RE884uRQM1cAPSe24n7hEUcxeIC238rNY oJ96cTSTFJtA+mVcQEg6dQ3VIKqnNGEcbbMQGk8HtNUJGNWI6o+6qasVG8SMGLGyUBhO Sko9dy0/hRVXuUqCi61aZ0Xma6fdQ5013khdrc3LCWzFoEYva/J1iBilF++ekfsH/DOT XWEM0MdSuNNYNiPI7rrj2guL8+8+4ixb5Vq/NI0RlOlwCVxmKXnYQE/BSUYFfvTYaR3T kAZYgJ35b0p0ltkkBnBnEOM0oe8qSLlgyftnC3LXHUz97z5UCV/+QogLaNjSTpYOo2JB GmCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-transfer-encoding; bh=DufHoh6riktL7V7Dcbn+oDHsBltCl0Npr9EPkihba8A=; b=ZS92J/NHSXb9TFdFBM9J65MZDd5d9Wid0LIo/ngaBRNtMcptQcqdSOn8kbNlSepQa6 sgyLStmgNzf/pyIS7efWiOo98y82Kg6JA8lXSCQhkxFgEK/RIrwXmnn/VqtvLX8XusY8 Gnyugk5U8sjTEgnfL7ppj4EkUx2Y4t6EC/NdmPokcI0KOelFtYdWcU1xEXh6nIqcidXj rY6Oh3Wr140QTHY0hHo8idefb5kio9gUUuRrGs/oMdZwe8fk9dALhSx/TbIZkyW1Zl6f 968XiMd/z8A/Q+nakgHSlJdWth8Mo/q/dOacDWf8czWIxEorlR814o6jmDkpBxONzWl6 67BA== X-Gm-Message-State: ALyK8tJuvJrLRvsRItI+AHoVCnQuJMEnsXF+wGKlAy7AtNfDEmZ8yDgD2kiIYW/siOUm7JHWPvAa2rQ4oLQSbg== X-Received: by 10.36.2.71 with SMTP id 68mr7892428itu.38.1465070666488; Sat, 04 Jun 2016 13:04:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.243.8 with HTTP; Sat, 4 Jun 2016 13:04:25 -0700 (PDT) From: Alan Jenkins Date: Sat, 4 Jun 2016 21:04:25 +0100 Message-ID: To: Noah Causin Cc: Jonathan Morton , Andrew McGregor , cake@lists.bufferbloat.net, "codel@lists.bufferbloat.net" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Cake] [Codel] 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: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2016 20:04:27 -0000 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=E2=80=99m 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=E2=80=99m using a rather high memory limi= t 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=E2=80=99= t rule out >> the possibility that it=E2=80=99s a different Reno relative, such as Wes= twood+ or >> Compound. >> >> There=E2=80=99s often more than one CWR per RTT. This isn=E2=80=99t a c= onsistent >> characteristic; some connections have normal-looking CWRs while others >> issue them every three packets, as if they=E2=80=99re fishing for =E2=80= =9Cmore accurate=E2=80=9D >> ECN feedback. It might vary by host; I didn=E2=80=99t keep track of tha= t. But >> this can=E2=80=99t 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 b= y >> my ISP. It=E2=80=99s possible the ECE flag is wiped and the CWRs are fak= ed, but >> there=E2=80=99s no legitimate reason to do that. The CWRs ultimately ma= ke 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 manag= ed >> queue with similar throughput. It=E2=80=99s not immediately obvious whe= ther >> that=E2=80=99s due to a functioning congestion response or simply the AQ= M clearing >> out the queue the hard way. It=E2=80=99ll be interesting to see what ef= fect >> COBALT has here, when I get it to actually work. >> >> As for who these servers are: Valve Software=E2=80=99s Steam platform. = I did say >> they were large and popular. >> >> - Jonathan Morton