On Mon, May 18, 2015 at 11:14 AM, Sebastian Moeller <moell...@gmx.de> wrote: > 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.
all bits except the CS1 bit are masked out on comcast, it seems. qdisc fq_codel 120: parent 1:12 limit 1001p flows 1024 quantum 1500 target 5.0ms interval 100.0ms ecn Sent 1177316772 bytes 16370274 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 maxpacket 1514 drop_overlimit 0 new_flow_count 2626475 ecn_mark 0 new_flows_len 0 old_flows_len 1 qdisc fq_codel 130: parent 1:13 limit 1001p flows 1024 quantum 300 target 5.0ms interval 100.0ms ecn Sent 234497554050 bytes 187934189 pkt (dropped 3368, overlimits 0 requeues 0) backlog 0b 0p requeues 0 maxpacket 1514 drop_overlimit 0 new_flow_count 32445438 ecn_mark 77 new_flows_len 1 old_flows_len 2 >> >> 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 ) At the moment based on the brutal after effects of watching the dslreports "fiber" test I am leaning towards something more policer-like on inbound so long as dumber rate shapers exist at the isp. > Best Regards > Sebastian > >> >> - Jonathan Morton >> > > _______________________________________________ > Bloat mailing list > bl...@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat -- Dave Täht Open Networking needs **Open Source Hardware** https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67 _______________________________________________ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
