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

[Sebastian Moeller]

HI Jonathan,

On May 18, 2015, at 19:17 , Jonathan Morton <chromatix99 at gmail.com> wrote:

> 
>> On 18 May, 2015, at 20:03, Sebastian Moeller <moeller0 at 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.

	I do not know any further details, but I think Dave noted that originally, maybe he knows what was mislabeled.

> 
> 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.

	In theory that sounds sweet, in practice this is hard I believe, as there is not simple “mark” of bitttotrrent traffic, the TOS bits might be the best we have (if bittorrent would actually mark itself CS1) and we already discussed how unsatisfactory this solution is.

>  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.

	For this to be of practical issue we first need to solve the question how to detect incoming bit torrent packets, so we have a need for remarking facilities ;)
If I recall correctly the nf_tables developers are working hard ATM to get nf_tables working on ingress as well. There are a few threads on netdev e.g. http://marc.info/?l=netfilter-devel&m=143153372615155&w=2 about nf_tables on ingress. (I noticed in that discussion that our need to use traffic-shapers (instead of policers) on the ingress does seem to be on the developers radar, but I could be wrong )

Best Regards
	Sebastian

> 
> - Jonathan Morton
>