From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id ACC343B29E for ; Mon, 16 Dec 2019 02:26:11 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1576481170; bh=v9/7N1x03y8Nyp6NSO7NoOlqY77BCondp51KgtW5Oa0=; h=X-UI-Sender-Class:Date:In-Reply-To:References:Subject:To:From; b=fZ9EusjoQjF+sCxu3WteLAGIf4xo/ChInsAjbx5rT+JC5Gf4PjsmH9/DcujAsiP9O QePhJA/OW30IPDq2YgiXeNr9ontE2IPtYJv7v0sJXxP2uPEqbw1T0igO77q+cUMcQU vt+kwthd06uhTtIHJDQNydCCJVpn+0YCllwdqpXY= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [10.76.54.86] ([80.187.114.137]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MC30P-1iYkxg40Hl-00CUUp; Mon, 16 Dec 2019 08:26:10 +0100 Date: Mon, 16 Dec 2019 08:09:46 +0100 User-Agent: K-9 Mail for Android In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----QJRPX1O4LKTI71H9FBY8916ZXOIWQV" Content-Transfer-Encoding: 7bit To: ecn-sane@lists.bufferbloat.net, Dave Taht , ECN-Sane From: Sebastian Moeller Message-ID: <7178407D-3FC6-458F-A068-7BEADAD004D5@gmx.de> X-Provags-ID: V03:K1:AStsMNEQ1f5ETQnirSUGCcOUYF6+1oJC2hYFxjt8I0FdXWyxUY1 ZWHJTWgVznIPFjUq+nNH2D8Qe/zr/xNZDnrwvpmrlMAAgMjoXmEiTLblOVQc8Io/mh+W4hP fX57wGMI4NFpq8KW9pANWim5l6E8YqPbIJpurSY6gqnX/0TDbkSufFnPiZTGNShqGnfH92n AFTG1vOEAVKPft/sbtaoA== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:BO1HnX+YevQ=:RKAPmpQK1VtdZI4b9HeWi0 Q9iFeK31Zrn/hNbx4lqM5tW390tcjbdi1n02qfaPxBq75F9NHyB/ve4wYM6A/r0vBxxU6tZfh w40s9Cdd2VPOt5ShGzK9R2zU9nmqE+aufE9oyjDxbsekXiX/orW7aDyfbBOQanZTmkVwE5BNn Y0+rfXUkiNo22x2qGimQyeDp6LZN/dOCyIlOOIvhPLk9SYjAVqmxAJqR0+A6d3iMLIpV+DId3 NVNKPBxDBNYz+KMoIGjZk74HMIuPLdaIJYjw8mCZttPvuott/xGrLGDdKHVpezCm9f3JWbc4t QMrBKGAKJWmo31M7QQw8nuvweA0dSRMMe1fmkC2CE/5hoFZ1oGWVCXEF9O1g+Luu4eoQgufQO 1wPswXp0PDWrmB1RY/edeBm4gxz0imKEGsMFJHwAR7kDX2WJ/fZer8EJDeJOkLbITSd/K83xX ypA3DYBydGf1q0yVAdJrWApC18csN03EoiS0WUoUQ4a9cy+/IG5qA9+tRq9vmTK1UNTvGAuTH yCMtmIO6LrxREjC8PCA/5YmxPNrQ5tOErEQ8N1LrHqUxGgsPK5zW8pfQ82mGCC23p2nmaFDTM AdnhTL+NEUGzz/j+ZJayKGh/4lZcW2/a8Unodrt+Id6AoSJLixazSBn6lsojSj68zAVh4TY2+ ir4tEctFFn9TKXUwJaDScoLGcAbGtjQ2HQVSQVpq1yfdhjpEaQTabdTunAcuk0IjhLL4KqNs3 55BOc2WYqG5FFTmGh/75M6TtsP4kLGWYnB3GyCnHTKgHmyV3dpWQCiZX4s8NgQ/hstNbGnCg/ 4Wlm/kz3Xa7E1P9irADCwZCQt3u8HW40fzWFexU6HO7bCmx8VpKYJ9EYVjTMl8XJmXv26HUV0 Z6y9y+92+RT/xJb4jhX7niW4iJ+tZGqnlFQbGMI76LbWe1r9RDcYcnGBWH31vZAngXhkisSLc iCRJEdQDjLl28iap5XW53Hp1X+hEEIzwSJv8QwqiqcGQq330ITk26eM6E//nfTPtz2tHpSay+ YladB5S3aJex7mDBYw/e6b67yD1z4QhpF7eH2TTf5VUj1D5kQs60XXbNtnB7deJbMK0nZUZ76 b5N29+qwm6lJddEAGfhRc+xA5vjm21N7SFap95PWBGrn/KYqji3AqE9fVquhuujhSxkYCvZ4E UbvFF40bvWZpQ4R2Xgm3m8iOuA9ZHKPLUwP+YVtwuPponWHWS6qI5YMCVpdpq79aMFIhmD61J NatL0dUqNebJx2N8bJzWO3q7Clxue0b48GcTPNEF6hlCk/BCeUKzpuwWLJqk= Subject: Re: [Ecn-sane] bittorrent & ecn X-BeenThere: ecn-sane@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion of explicit congestion notification's impact on the Internet List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2019 07:26:12 -0000 ------QJRPX1O4LKTI71H9FBY8916ZXOIWQV Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 setti= ng a TOS value with aeCN side-effects in a middlebox) and they also were sa= id to have fixed the issue=2E 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=2E=2E=2E on UDP traffic=2E=2E= =2E when >torrent doesn't support that!!! > >I think one mystery has been solved=2E At least one major argentinian >ISP (Telecom Argentina S=2EA=2E > ) is mis-marking a ton of packets (both udp and tcp) as ecn-capable >when they aren't=2E > >This mystery goes back a couple years! actually, where an enormous >amount of CE was seen from argentina in some ietf preso or another=2E >Something like 25%! > >So I went a little nuts on blocking that from the bgp data I could >find on them and their partners=2E=2E=2E > >ip route add unreach 181=2E30=2E128=2E0/19 proto 48 >ip route add unreach 181=2E28=2E0=2E0/14 proto 48 >ip route add unreach 24=2E232=2E0=2E0/16 proto 48 >ip route add unreach 190=2E192=2E32=2E246/32 proto 48 >ip route add unreach 166=2E137=2E40=2E133/32 proto 48 > ># around here I just lost it on finding where it was coming from=2E=2E=2E > >ip route add unreach 186=2E137=2E29=2E0/24 proto 48 >ip route add unreach 186=2E137=2E0=2E0/16 proto 48 ># some of these actually could be legit >ip route add unreach 190=2E19=2E0=2E0/16 proto 48 >ip route add unreach 195=2E88=2E0=2E0/16 proto 48 > >and ecn marking rates are now pretty tiny=2E 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=2E=2E=2E (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=2E=2E=2E )) > >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=2E (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=2E >> >> Yep=2E ecn gets used=2E 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=2E0ms interval 100=2E0ms 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=2E0ms interval 100=2E0ms 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=2E In fact, I hardly >> noticed=2E My streaming radio glitched once=2E Web was fine, but gmail >> took a while longer to load all the resources=2E Taking a packet >capture >> now=2E >> >> 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=2E >> >> 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=2E I guess I'll look at that next=2E >> >> Dear RIAA: I promise to delete the files when I'm done, and I'm only >> capturing headers on the capture=2E I'd rather someone with the >> protection of a major university followup on this line of >research=2E=2E=2E=2E >> >> >> -- >> Make Music, Not War >> >> Dave T=C3=A4ht >> CTO, TekLibre, LLC >> http://www=2Eteklibre=2Ecom >> Tel: 1-831-435-0729 > > > >--=20 >Make Music, Not War > >Dave T=C3=A4ht >CTO, TekLibre, LLC >http://www=2Eteklibre=2Ecom >Tel: 1-831-435-0729 >_______________________________________________ >Ecn-sane mailing list >Ecn-sane@lists=2Ebufferbloat=2Enet >https://lists=2Ebufferbloat=2Enet/listinfo/ecn-sane --=20 Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E ------QJRPX1O4LKTI71H9FBY8916ZXOIWQV Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Dave,

Bob mentioned at the last IETF mee= ting, that IIRC Cablelabs/Greg followed up with that Argentinian ISP and t= hey confirmed the mismarking (from setting a TOS value with aeCN side-effec= ts in a middlebox) and they also were said to have fixed the issue=2E
Best Regards
Sebastian

On De= cember 16, 2019 12:09:55 AM GMT+01:00, Dave Taht <dave=2Etaht@gmail=2Eco= m> 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=2E=2E=2E =
on UDP traffic=2E=2E=2E when
torrent doesn't support that!!!

I th=
ink one mystery has been solved=2E At least one major argentinian
ISP (T=
elecom Argentina S=2EA=2E
 ) is mis-marking a ton of packets (both udp a=
nd tcp) as ecn-capable
when they aren't=2E

This mystery goes back=
 a couple years! actually, where an enormous
amount of CE was seen from =
argentina in some ietf preso or another=2E
Something like 25%!

So=
 I went a little nuts on blocking that from the bgp data I could
find on=
 them and their partners=2E=2E=2E

ip route add unreach 181=2E30=2E12=
8=2E0/19 proto 48
ip route add unreach 181=2E28=2E0=2E0/14 proto 48
i=
p route add unreach 24=2E232=2E0=2E0/16 proto 48
ip route add unreach 19=
0=2E192=2E32=2E246/32 proto 48
ip route add unreach 166=2E137=2E40=2E133=
/32 proto 48

# around here I just lost it on finding where it was co=
ming from=2E=2E=2E

ip route add unreach 186=2E137=2E29=2E0/24 proto =
48
ip route add unreach 186=2E137=2E0=2E0/16 proto 48
# some of these=
 actually could be legit
ip route add unreach 190=2E19=2E0=2E0/16 proto =
48
ip route add unreach 195=2E88=2E0=2E0/16 proto 48

and ecn mark=
ing rates are now pretty tiny=2E I haven't managed to to
look at actual =
syn negotiations and cwrs yet, and I should come up
with something bette=
r than this (iptables rules=2E=2E=2E (the proto 48 is so
it gets injecte=
d into my babel route tables, cause mismarking yer tcp
as ecn capable is=
 a bad idea also=2E=2E=2E ))

Anybody got contacts in argentina?
<=
br>On Sun, Dec 15, 2019 at 6:56 AM Dave Taht <dave=2Etaht@gmail=2Ecom>=
; wrote:
>
 I was=
 kind of wondering if ecn would be used by bittorrent clients and
 serve=
rs=2E (it's not supported by utp, I think, but when you use tcp, it
 use=
s default tcp options) So I loaded up (FOR SCIENCE!) 100+ common
 torren=
ts with no limits on connections with an inbound fq_codel based
 shaper =
in place and ecn enabled on the torrent client=2E

 Yep=2E ecn gets u=
sed=2E How many torrent servers negotiate it? How many
 clients? (I imag=
ine the entire apple universe does now)

 qdisc fq_codel 130: parent =
1:13 limit 1001p flows 1024 quantum 300
 target 5=2E0ms interval 100=2E0=
ms ecn
 Sent 669116971742 bytes 525750376 pkt (dropped 750412, overlimit=
s 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 l=
imit 1001p flows 1024 quantum 300
 target 5=2E0ms interval 100=2E0ms ecn=

 Sent 671021262523 bytes 527225759 pkt (dropped 792750, overlimits 0 re=
queues 0)
 backlog 46605b 39p requeues 0
 maxpacket 1514 drop_overlim=
it 1047 new_flow_count 66286036 ecn_mark 74965
 new_flows_len 0 old_flow=
s_len 29

 Remarkably my connection stayed pretty darn usable=2E In f=
act, I hardly
 noticed=2E My streaming radio glitched once=2E Web was fi=
ne, but gmail
 took a while longer to load all the resources=2E Taking a=
 packet capture
 now=2E

 This is theoretically the most expensive=
 bit of research I've ever
 done for the bufferbloat project, in a matte=
r of hours I'll have
 violated copyright ~800 times, which is about 200m=
 dollars at 250k
 per=2E

 Folk are encouraged to use vpns for tor=
rents nowadays, but I can't see
 how that would work with libutp and a m=
ax rtt of 100ms before it
 starts to back off=2E I guess I'll look at th=
at next=2E

 Dear RIAA: I promise to delete the files when I'm done, =
and I'm only
 capturing headers on the capture=2E I'd rather someone wit=
h the
 protection of a major university followup on this line of researc=
h=2E=2E=2E=2E


 --
 Make Music, Not War

 Dave T=C3=A4ht=

 CTO, TekLibre, LLC
 http://=
www=2Eteklibre=2Ecom
 Tel: 1-831-435-0729



--
Sent from my Android device with K-9 Mail= =2E Please excuse my brevity=2E ------QJRPX1O4LKTI71H9FBY8916ZXOIWQV--