Re: [Cerowrt-devel] [Bloat] heisenbug: dslreports 16 flow test vs cablemodems

[Jonathan Morton <chromatix99@gmail.com>]

> On 18 May, 2015, at 20:03, Sebastian Moeller <moeller0@gmx.de> wrote:
> 
>> Adding Diffserv and recommending that LEDBAT applications use the
>> “background” traffic class (CS1 DSCP) solves this problem more
>> elegantly.  The share of bandwidth used by BitTorrent (say) is then
>> independent of the number of flows it uses, and it also makes sense to
>> configure FQ for ideal flow isolation rather than for mitigation.
> 
> I wonder, for this to work well wouldn't we need to allow/honor at least CS1 marks on ingress? I remember there was some discussion about mislabeled traffic on ingress (Comcast I believe), do you see an easy way around that issue?

I don’t know much about the characteristics of this mislabelling.  Presumably though, Comcast is using DSCP remarking in an attempt to manage internal congestion.  If latency-sensitive and/or inelastic traffic is getting marked CS1, that would be a real problem, and Comcast would need leaning on to fix it.  It’s slightly less serious if general best-effort traffic gets CS1 markings.

One solution would be to re-mark the traffic at the CPE on ingress, using local knowledge of what traffic is important and which ports are associated with BitTorrent.  Unfortunately, the ingress qdisc runs before iptables, making that more difficult.  I think it would be necessary to do re-marking using an ingress action before passing it to the qdisc.  Either that, or a pseudo-qdisc which just does the re-marking before handing the packet up the stack.

I’m not sure whether it’s possible to attach two ingress actions to the same interface, though.  If not, the re-marking action module would also need to incorporate act_mirred functionality, or a minimal subset thereof.

 - Jonathan Morton