My concern with fq_codel is that by putting single flows into single Codel
instances you hit the problem with Codel where it limits bandwidth on
higher RTT paths.
Simon
Sent with AquaMail for Android
http://www.aqua-mail.com
On June 9, 2015 9:32:15 AM Jonathan Morton <chromati...@gmail.com> wrote:
> On 9 Jun, 2015, at 19:11, Steven Blake <slbl...@petri-meat.com> wrote:
>
> On a 10 GE link
> serving 2.5 MPPs on average, CoDel would only drop 0.013% of packets
> after 1000 drops (which would occur after 6.18 secs). This doesn't seem
> to be very effective.
Question: have you worked out what drop rate is required to achieve control
of a TCP at that speed? There are well-known formulae for standard TCPs,
particularly Reno. You might be surprised by the result.
Fundamentally, Codel operates on the principle that one mark/drop per RTT
per flow is sufficient to control a TCP, or a flow which behaves like a
TCP; *not* a particular percentage of packets. This is because TCPs are
generally required to perform multiplicative decrease upon a *single*
congestion event. The increasing count over time is meant to adapt to
higher flow counts and lower RTTs. Other types of flows tend to be sparse
and unresponsive in general, and must be controlled using some harder
mechanism if necessary.
One such mechanism is to combine Codel with an FQ system, which is exactly
what fq_codel in Linux does. Fq_codel has been tested successfully at
10Gbps. Codel then operates separately for each flow, and unresponsive
flows are isolated.
- Jonathan Morton
_______________________________________________
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm
_______________________________________________
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm
