From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 79B3921F259 for ; Fri, 21 Mar 2014 11:08:19 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id f8so755368wiw.12 for ; Fri, 21 Mar 2014 11:08:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=0ixKYpRuSPD29XsjER7qFu1uDmDkQuTzezTpuIXUnP8=; b=NJr1TUxQ/2v5WXcMXla1hveDUWkgpZsjcpb0elyNe3Hs+dErUIQGkgxwlTwfBp536n Tp1mw0uuqRP515hxSgilE3oa9Qe+jMDcNOL3XNdPyxkicIVU1NQF7vFYRxUVnSO/ecux mxPM0CqJ2KMS2T951/JAYaoKtubst4++o6G9MAekB92+7N4evJKz9uU4u8GXbKl+HqME zX5heCZaUMoUWXcKIq2k4slESc04v3LSxaQbucJd7TpPiJ+5bm52TwdARHTuHXA6ypMV Yrku/kddqSrDae6CtNkGFSkhjFUTC+QnOaR3MDrJc2ewMuQ0Kp1lrnofE0HGdwRMz/zT x/PA== MIME-Version: 1.0 X-Received: by 10.180.126.38 with SMTP id mv6mr3530089wib.46.1395425297697; Fri, 21 Mar 2014 11:08:17 -0700 (PDT) Received: by 10.216.8.1 with HTTP; Fri, 21 Mar 2014 11:08:17 -0700 (PDT) In-Reply-To: <1395424311.8701.20.camel@edumazet-glaptop2.roam.corp.google.com> References: <20140318145221.GA31327@sesse.net> <07BD4518-2A7E-4F43-8978-791E3B2BDA2A@cisco.com> <87eh1wc05c.fsf@toke.dk> <87a9ckbz1q.fsf@toke.dk> <1395358884.9114.102.camel@edumazet-glaptop2.roam.corp.google.com> <1395414379.6441.17.camel@edumazet-glaptop2.roam.corp.google.com> <1395424311.8701.20.camel@edumazet-glaptop2.roam.corp.google.com> Date: Fri, 21 Mar 2014 18:08:17 +0000 Message-ID: From: Dave Taht To: Eric Dumazet Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Steinar H. Gunderson" , bloat Subject: Re: [Bloat] AQM creeping into L2 equipment X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Mar 2014 18:08:19 -0000 On Fri, Mar 21, 2014 at 5:51 PM, Eric Dumazet wrot= e: > On Fri, 2014-03-21 at 16:53 +0100, renaud sallantin wrote: >> For our tests, we needed to adjust the "tcp_initial_quantum" in the >> FQ, >> but as you said, it is just a FQ parameter. >> > > Yep, default ones are a compromise between performance and pacing > accuracy. At 40Gbps speeds, it is a bit challenging. At sub 10Mbit speeds it is also challenging. > The consensus is that IW10 is adopted, meaning that we can send 10 MSS > at whatever speed we want without knowing anything of the network > conditions. And I do wish that research and decision included measurements of the effects on DSL (sub 1mbit) and cable modem (sub 10mbit) uplinks and uploads, and tcp using traffic like bittorrent, ssh, rsync, cifs, etc. > > If people want to play with other values, they have to change the route > settings of their linux box, and fq parameters if they want. > > > ip ro change default via 192.168.1.254 dev eth0 initcwnd 20 This is likely to have brutal effects on slow uplinks and uploads without pacing enabled. to get results semi comparable to (for example) OSX, a initcwnd 3 should be used. I DO have very high hopes for pacing in these cases at various iw settings in the case of slow uplinks and uploads, I am concerned about the effects on wifi and other burst-prefering macs. I look forward to more benchmarks. I'm not in a position to do much with kernels later than 3.10 at the moment... > (As a matter of fact it seems some providers use higher values than > IW10) > >> The "patch" we added, and once again, it was just a few lines, >> enabled to set, via a sysctl parameter, the initial pacing value, >> regardless of the RTT. >> This can be valuable for different reasons: >> o In case of long RTT, not set the pacing value is going to >> introduce an un-necessary delay >> (we aims to use this mechanism for satcom, so the delay could be >> greater than 500ms) > > If you have a 500ms rtt, then you also want a bigger IW. Sending 10 MSS > in the first RTT is going to be slow, no matter how you pace them. > The first ACK wont come before 500 ms. In the case of a satellite link (>800ms RTT) with competing traffic, it is my hope that (n)fq_codel will further mitigate the large iws common today. A fairly common satellite uplink/downlink is 500kbit/8mbit. >> o In case of a wrong RTT measurement, i.e. an RTT measurement >> that is higher that the real RTT (because of congestion for example), >> you are going to have a wrong pacing evaluation... > > Well, if you have big rtt because of congestion, you exactly want to > reduce the rate... > > rate =3D cwnd * mss / srtt A nice thing about fq_codel inbetween on the congested link is that your first RTT on a new flow is generally very close to your actual physical RTT between links even when congested. > And fq/pacing uses srtt, not rtt, so a single wrong rtt doesn't have a > big impact (unless it is the first sample, as it will serve as the ewma > initial value) > > You can not predict the network conditions just by studying the > SYN/SYNACK/ACK initial messages. It gives a guess, but it is hard to > send everything you want in a single RTT at 'optimal speed' > > Thats why it was so hard to decide the IW if you want an universal > value. > It depends on the state of the Internet, and it changes every day or > so... I kind of wish there was a way to propagate saner IW settings throughout a home network - where you can use a big IW internally, but downgrade to lower values on exit to the real world. Again, if pacing actually works maybe indeed larger iws are truly feasible.= .. (If I sound grumpy - I just wish I had time to play with this new stuff instead of what I'm doing right now - it's promising as heck) > > --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html