* [Ecn-sane] bittorrent & ecn @ 2019-12-15 14:56 Dave Taht 2019-12-15 23:09 ` Dave Taht 0 siblings, 1 reply; 4+ messages in thread From: Dave Taht @ 2019-12-15 14:56 UTC (permalink / raw) To: ECN-Sane 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Ecn-sane] bittorrent & ecn 2019-12-15 14:56 [Ecn-sane] bittorrent & ecn Dave Taht @ 2019-12-15 23:09 ` Dave Taht 2019-12-16 7:09 ` Sebastian Moeller 0 siblings, 1 reply; 4+ messages in thread From: Dave Taht @ 2019-12-15 23:09 UTC (permalink / raw) To: ECN-Sane 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@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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Ecn-sane] bittorrent & ecn 2019-12-15 23:09 ` Dave Taht @ 2019-12-16 7:09 ` Sebastian Moeller 2019-12-16 7:43 ` Dave Taht 0 siblings, 1 reply; 4+ messages in thread From: Sebastian Moeller @ 2019-12-16 7:09 UTC (permalink / raw) To: ecn-sane, Dave Taht, ECN-Sane [-- Attachment #1: Type: text/plain, Size: 4614 bytes --] 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@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@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@lists.bufferbloat.net >https://lists.bufferbloat.net/listinfo/ecn-sane -- Sent from my Android device with K-9 Mail. Please excuse my brevity. [-- Attachment #2: Type: text/html, Size: 4805 bytes --] ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Ecn-sane] bittorrent & ecn 2019-12-16 7:09 ` Sebastian Moeller @ 2019-12-16 7:43 ` Dave Taht 0 siblings, 0 replies; 4+ messages in thread From: Dave Taht @ 2019-12-16 7:43 UTC (permalink / raw) To: Sebastian Moeller; +Cc: ECN-Sane On Sun, Dec 15, 2019 at 11:26 PM Sebastian Moeller <moeller0@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@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@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 ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2019-12-16 7:43 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-12-15 14:56 [Ecn-sane] bittorrent & ecn Dave Taht 2019-12-15 23:09 ` Dave Taht 2019-12-16 7:09 ` Sebastian Moeller 2019-12-16 7:43 ` Dave Taht
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox