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

[Dave Taht]

On Mon, May 18, 2015 at 11:14 AM, Sebastian Moeller <moeller0 at gmx.de> wrote:
> 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.

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
> Bloat at 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