[Ecn-sane] bittorrent & ecn

[Dave Taht]

On Sun, Dec 15, 2019 at 11:26 PM Sebastian Moeller <moeller0 at gmx.de> wrote:
>
> 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.

Well, I missed that meeting, and it's not fixed.

> Best Regards
> Sebastian
>
> On December 16, 2019 12:09:55 AM GMT+01:00, Dave Taht <dave.taht at gmail.com> 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 <dave.taht at gmail.com> 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
>>
>>
>>
>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.



-- 
Make Music, Not War

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-435-0729