From: Eric Dumazet <eric.dumazet@gmail.com>
To: Justin McCann <jneilm@gmail.com>
Cc: bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] What is fairness, anyway? was: Re: finally... winning on wired!
Date: Sun, 05 Feb 2012 19:21:20 +0100 [thread overview]
Message-ID: <1328466080.14474.25.camel@edumazet-laptop> (raw)
In-Reply-To: <CAFkTFa8cKedGjZBYwvfc-TJbAzEoEaQ5OXktc3EmiWHjhGsXtg@mail.gmail.com>
Le dimanche 05 février 2012 à 12:53 -0500, Justin McCann a écrit :
> I was thinking of suggesting this (delaying ACKs to avoid cwnd
> increase), but doesn't that simply increase the RTT and/or RTT
> variance, and basically do the same thing we're trying to avoid? I
> suppose you could delay a bit, and then drop some earlier ACKs in case
> the sender only increases cwnd per ACK (and not by the number of
> segments the ACK covers), but that per-ACK behavior just seems like a
> bug to me.
I dont think it has anything with delaying acks. Acks are immediately
sent as soon as the incoming packets are delivered to tcp stack.
Check my script, their is no filter on ACK at all.
ingress AQM delays delivering of packets of big flows, _if_ some other
flows are also present and want their part of the bandwidth.
Eventually SFQ drops packets from those big flows, and senders
automatically decrease their congestion window.
I use this kind of ingress AQM on production proxies and it actually
works.
next prev parent reply other threads:[~2012-02-05 18:21 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-02 0:40 [Bloat] " Dave Taht
2012-01-02 5:22 ` Eric Dumazet
2012-01-02 8:07 ` Dave Taht
2012-01-02 21:31 ` Dave Taht
2012-01-02 22:14 ` Albert Rafetseder
2012-01-02 22:33 ` Dave Taht
2012-01-04 15:25 ` [Bloat] What is fairness, anyway? was: " Jim Gettys
2012-01-04 16:16 ` Dave Taht
2012-01-04 17:23 ` Jim Gettys
2012-01-04 17:36 ` Justin McCann
2012-01-04 17:40 ` Eric Dumazet
[not found] ` <CAFkTFa89mOmbcOV1PWX3my04rK4NsEvyakcQV2j54qa0gzAViQ@mail.g mail.com>
2012-01-05 17:52 ` Bob Briscoe
2012-01-06 17:42 ` Jim Gettys
2012-01-06 18:09 ` Dave Taht
2012-01-06 19:57 ` Eric Dumazet
2012-01-06 20:34 ` Jonathan Morton
2012-01-07 19:42 ` Bob Briscoe
2012-01-07 22:16 ` Wesley Eddy
2012-01-08 0:40 ` Dave Taht
[not found] ` <CAA93jw7xKwdUeT7wFNoiM8RQp1--==Eazdo0ucc44vz+L1U06g@mail.g mail.com>
2012-01-09 5:38 ` Bob Briscoe
2012-01-11 7:26 ` Dave Taht
[not found] ` <CAA93jw4KJdYwrAuk7-yHDYCGBh1s6mE47eAYu2_LRfY45-qZ2g@mail.g mail.com>
2012-01-14 11:06 ` Bob Briscoe
2012-01-13 21:45 ` Dan Siemon
2012-01-14 15:55 ` Dave Taht
2012-01-04 16:22 ` Eric Dumazet
2012-02-05 0:24 ` George B.
2012-02-05 0:43 ` Jonathan Morton
2012-02-05 1:57 ` George B.
2012-02-05 2:05 ` john thompson
2012-02-05 7:39 ` Eric Dumazet
[not found] ` <CAA93jw68yntHkhETQ1a9-Azu7UXEuU9f5fgOsB25hvA240iApg@mail.gmail.com>
2012-02-05 14:24 ` Dave Taht
2012-02-05 17:53 ` Justin McCann
2012-02-05 18:21 ` Eric Dumazet [this message]
2012-01-14 16:35 Jesper Dangaard Brouer
2012-01-15 9:49 ` Dave Taht
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=1328466080.14474.25.camel@edumazet-laptop \
--to=eric.dumazet@gmail.com \
--cc=bloat@lists.bufferbloat.net \
--cc=jneilm@gmail.com \
/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