Or one could use more queues in SFQ, so that the chance of 2 streams
sharing a queue is small. Even perhaps use a different strategy than
hashing to distribute traffic to queues, although whatever strategy is
used needs to be resistant to DoS attacks. Or one could classify the
VoIP traffic and prioritise that. Another possibility is a heuristic
approach - don't mix long lived bulk data streams in the same bucket as
others.
Simon
On Wed 01 May 2013 05:00:27 PM PDT, Jonathan Morton wrote:
On 1 May, 2013, at 11:26 pm, Simon Barber wrote:
Interesting to note that sfq-codel's reaction to a non conforming flow is of
course to start dropping more aggressively to make it conform, leading to the
high loss rates for whatever is hashed together with a VoIP flow that does not
reduce it's bandwidth.
One downside to SFQ really.
The only real solution, for the scenario where this happens, would be to
somehow identify all the BitTorrent traffic and stuff it into a single bucket,
where it has to compete on equal terms with the single VoIP flow. The big
unanswered question is then: can this realistically be done? Does BitTorrent
traffic get marked as the bulk, low priority traffic it is, for example?
_______________________________________________
Cerowrt-devel mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/cerowrt-devel
