[Ecn-sane] bittorrent & ecn

Mon Dec 16 02:09:46 EST 2019

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 <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
>
>
>
>-- 
>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 at lists.bufferbloat.net
>https://lists.bufferbloat.net/listinfo/ecn-sane

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/ecn-sane/attachments/20191216/816cdeca/attachment.html>