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