General list for discussing Bufferbloat
 help / color / mirror / Atom feed
From: Eric Dumazet <eric.dumazet@gmail.com>
To: renaud sallantin <renaud.sallantin@gmail.com>
Cc: "Steinar H. Gunderson" <sesse@samfundet.no>,
	bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] AQM creeping into L2 equipment
Date: Fri, 21 Mar 2014 10:51:51 -0700	[thread overview]
Message-ID: <1395424311.8701.20.camel@edumazet-glaptop2.roam.corp.google.com> (raw)
In-Reply-To: <CAAvOmMvPpmuW1chTdX86s5sQv6X_c622k8YrjW+hN8e5JV+dzA@mail.gmail.com>

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.

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.

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

(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.

>      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 = cwnd * mss / srtt

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...



  parent reply	other threads:[~2014-03-21 17:51 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-18 14:52 Steinar H. Gunderson
2014-03-18 17:17 ` Dave Taht
2014-03-18 17:53   ` Steinar H. Gunderson
2014-03-19 22:22     ` Steinar H. Gunderson
2014-03-18 18:05   ` Fred Baker (fred)
2014-03-18 18:54     ` Dave Taht
2014-03-20 16:20       ` Toke Høiland-Jørgensen
2014-03-20 16:29         ` Dave Taht
2014-03-20 16:44           ` Toke Høiland-Jørgensen
2014-03-20 17:14             ` Dave Taht
2014-03-20 19:34               ` Aaron Wood
2014-03-20 20:23                 ` Dave Taht
2014-03-20 23:41                   ` Eric Dumazet
2014-03-20 23:45                     ` Steinar H. Gunderson
2014-03-20 23:54                       ` Steinar H. Gunderson
     [not found]                     ` <CAAvOmMtt1RCpBfT1MPNh-2FRhQ1GN4xYbfNPLYJwfP6CaP5vow@mail.gmail.com>
2014-03-21 15:06                       ` Eric Dumazet
     [not found]                         ` <CAAvOmMvPpmuW1chTdX86s5sQv6X_c622k8YrjW+hN8e5JV+dzA@mail.gmail.com>
2014-03-21 17:51                           ` Eric Dumazet [this message]
2014-03-21 18:08                             ` Dave Taht
2014-03-21 22:00                               ` Eric Dumazet
2014-03-21 22:13                                 ` Dave Taht
2014-03-23 19:27                                   ` Eric Dumazet
2014-03-21 13:41               ` Toke Høiland-Jørgensen
2014-03-21 15:39                 ` Dave Taht
2014-03-21 16:42                   ` Steinar H. Gunderson
2014-03-21 18:34                     ` Toke Høiland-Jørgensen
2014-03-24 23:16                     ` David Lang
2014-03-20 18:16       ` [Bloat] AQM creeping into L2 equipment / 10G not-for-profit playground at tetaneutral.net Laurent GUERBY
2014-03-18 18:57     ` [Bloat] AQM creeping into L2 equipment Dave Taht
2014-03-18 21:06       ` Steinar H. Gunderson
2014-03-19 13:11 ` Nikolay Shopik

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/bloat.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1395424311.8701.20.camel@edumazet-glaptop2.roam.corp.google.com \
    --to=eric.dumazet@gmail.com \
    --cc=bloat@lists.bufferbloat.net \
    --cc=renaud.sallantin@gmail.com \
    --cc=sesse@samfundet.no \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox