Hi Dave, Bob mentioned at the last IETF meeting, that IIRC Cablelabs/Greg followed up with that Argentinian ISP and they confirmed the mismarking (from setting a TOS value with aeCN side-effects in a middlebox) and they also were said to have fixed the issue. Best Regards Sebastian On December 16, 2019 12:09:55 AM GMT+01:00, Dave Taht wrote: >OK, so I got caught up on sleep and had a chance to look at the packet >captures, which were dominated by ecn marks... on UDP traffic... when >torrent doesn't support that!!! > >I think one mystery has been solved. At least one major argentinian >ISP (Telecom Argentina S.A. > ) is mis-marking a ton of packets (both udp and tcp) as ecn-capable >when they aren't. > >This mystery goes back a couple years! actually, where an enormous >amount of CE was seen from argentina in some ietf preso or another. >Something like 25%! > >So I went a little nuts on blocking that from the bgp data I could >find on them and their partners... > >ip route add unreach 181.30.128.0/19 proto 48 >ip route add unreach 181.28.0.0/14 proto 48 >ip route add unreach 24.232.0.0/16 proto 48 >ip route add unreach 190.192.32.246/32 proto 48 >ip route add unreach 166.137.40.133/32 proto 48 > ># around here I just lost it on finding where it was coming from... > >ip route add unreach 186.137.29.0/24 proto 48 >ip route add unreach 186.137.0.0/16 proto 48 ># some of these actually could be legit >ip route add unreach 190.19.0.0/16 proto 48 >ip route add unreach 195.88.0.0/16 proto 48 > >and ecn marking rates are now pretty tiny. I haven't managed to to >look at actual syn negotiations and cwrs yet, and I should come up >with something better than this (iptables rules... (the proto 48 is so >it gets injected into my babel route tables, cause mismarking yer tcp >as ecn capable is a bad idea also... )) > >Anybody got contacts in argentina? > >On Sun, Dec 15, 2019 at 6:56 AM Dave Taht wrote: >> >> I was kind of wondering if ecn would be used by bittorrent clients >and >> servers. (it's not supported by utp, I think, but when you use tcp, >it >> uses default tcp options) So I loaded up (FOR SCIENCE!) 100+ common >> torrents with no limits on connections with an inbound fq_codel based >> shaper in place and ecn enabled on the torrent client. >> >> Yep. ecn gets used. How many torrent servers negotiate it? How many >> clients? (I imagine the entire apple universe does now) >> >> qdisc fq_codel 130: parent 1:13 limit 1001p flows 1024 quantum 300 >> target 5.0ms interval 100.0ms ecn >> Sent 669116971742 bytes 525750376 pkt (dropped 750412, overlimits 0 >requeues 0) >> backlog 288139b 201p requeues 0 >> maxpacket 1514 drop_overlimit 1047 new_flow_count 65837164 ecn_mark >70963 >> new_flows_len 0 old_flows_len 73 >> >> sleep 60 >> >> qdisc fq_codel 130: parent 1:13 limit 1001p flows 1024 quantum 300 >> target 5.0ms interval 100.0ms ecn >> Sent 671021262523 bytes 527225759 pkt (dropped 792750, overlimits 0 >requeues 0) >> backlog 46605b 39p requeues 0 >> maxpacket 1514 drop_overlimit 1047 new_flow_count 66286036 ecn_mark >74965 >> new_flows_len 0 old_flows_len 29 >> >> Remarkably my connection stayed pretty darn usable. In fact, I hardly >> noticed. My streaming radio glitched once. Web was fine, but gmail >> took a while longer to load all the resources. Taking a packet >capture >> now. >> >> This is theoretically the most expensive bit of research I've ever >> done for the bufferbloat project, in a matter of hours I'll have >> violated copyright ~800 times, which is about 200m dollars at 250k >> per. >> >> Folk are encouraged to use vpns for torrents nowadays, but I can't >see >> how that would work with libutp and a max rtt of 100ms before it >> starts to back off. I guess I'll look at that next. >> >> Dear RIAA: I promise to delete the files when I'm done, and I'm only >> capturing headers on the capture. I'd rather someone with the >> protection of a major university followup on this line of >research.... >> >> >> -- >> Make Music, Not War >> >> Dave Täht >> CTO, TekLibre, LLC >> http://www.teklibre.com >> Tel: 1-831-435-0729 > > > >-- >Make Music, Not War > >Dave Täht >CTO, TekLibre, LLC >http://www.teklibre.com >Tel: 1-831-435-0729 >_______________________________________________ >Ecn-sane mailing list >Ecn-sane@lists.bufferbloat.net >https://lists.bufferbloat.net/listinfo/ecn-sane -- Sent from my Android device with K-9 Mail. Please excuse my brevity.