HI Jonathan,
On May 18, 2015, at 19:17 , Jonathan Morton <chromati...@gmail.com> wrote:
>
>> On 18 May, 2015, at 20:03, Sebastian Moeller <moell...@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
>
_______________________________________________
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel
