From: Jonathan Morton <chromatix99@gmail.com>
To: Dave Taht <dave.taht@gmail.com>
Cc: cake@lists.bufferbloat.net,
Alan Jenkins <alan.christopher.jenkins@gmail.com>,
"codel@lists.bufferbloat.net" <codel@lists.bufferbloat.net>,
"cerowrt-devel@lists.bufferbloat.net"
<cerowrt-devel@lists.bufferbloat.net>
Subject: Re: [Codel] [Cake] openwrt build available with latest cake and fq_pie
Date: Sun, 14 Jun 2015 22:35:27 +0300 [thread overview]
Message-ID: <F67E8E29-8382-40B1-B10E-96FB9927FB04@gmail.com> (raw)
In-Reply-To: <CAA93jw7h=8LvjyOPdXdm7=mLqvmnp1CXw5+XWc_-vFfEaDbY+g@mail.gmail.com>
> On 14 Jun, 2015, at 21:24, Dave Taht <dave.taht@gmail.com> wrote:
>
> Flows, btw, do end quite rapidly in the real world. What was it, 95%
> of all web flows ended inside of IW10?
It might be worth thinking about how heavily loaded a network needs to be for Codel to trigger on such a flow. However, with perfect flow isolation, count will start at 1, making it less relevant to the present thread.
Cake will start triggering on a instantly-arrived burst (call it a packet salvo) after 35ms. Thus, a ten-packet burst will not trigger provided at least 4.5 Mbps is available to that flow. However, on many links that is still a tall order, since if the flows really are that short, there are probably lots of them in parallel.
A paced burst is much more friendly. At a 100ms RTT, IW10 could be delivered at 100pps (1.5 Mbps), extending the range of link speeds on which congestion signalling will not occur by at least 3x (and generally more). Since this greatly reduces the risk of packet loss, it might actually reduce the average time that the sender needs to maintain the connection’s buffers, despite the deliberate 1-RTT delay introduced.
- Jonathan Morton
next prev parent reply other threads:[~2015-06-14 19:35 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAA93jw6R2o+M68rQq07Qm8xBkr1bSvkVriysGdACxRLvmjhsmg@mail.gmail.com>
[not found] ` <CANmMgnGY1qkm9PnfKmHMoB6OYzhD5Cr9WDPPjmG1Tenw=+4E-g@mail.gmail.com>
[not found] ` <CAA93jw4XzLhudtQ=1+L6csv66d_sNgF6VLg8iqMZmPJHyc5ryw@mail.gmail.com>
[not found] ` <0CFA8991-9F5E-4988-82ED-6CA0E4E08676@gmail.com>
2015-06-14 17:38 ` Dave Taht
2015-06-14 18:07 ` Jonathan Morton
2015-06-14 18:24 ` Dave Taht
2015-06-14 19:35 ` Jonathan Morton [this message]
2015-06-14 19:42 ` 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/codel.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=F67E8E29-8382-40B1-B10E-96FB9927FB04@gmail.com \
--to=chromatix99@gmail.com \
--cc=alan.christopher.jenkins@gmail.com \
--cc=cake@lists.bufferbloat.net \
--cc=cerowrt-devel@lists.bufferbloat.net \
--cc=codel@lists.bufferbloat.net \
--cc=dave.taht@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