From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-il1-x132.google.com (mail-il1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (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 F0D493B29E for ; Mon, 16 Dec 2019 02:43:55 -0500 (EST) Received: by mail-il1-x132.google.com with SMTP id f10so4665298ils.8 for ; Sun, 15 Dec 2019 23:43:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=MPeO1w7mlIxtUXd31vD1Yk2df/JFg24xK8uKaWv5+Wo=; b=U1sdK7VmUVA/ZJN4x/ngatWtbe9sR2D3aR6gZQsCLJFx42YbQ5y8+Ob43/tPkSBuFT JItxnxwaiKFeEAW01RNhRIsqaySmyuTkhNTa+HpeIVexZmim30c/pW7X5Lk3QA+odtjV nYe+N2vcTjsa5U7hP6KRPV6UDcHM1U/XqpdU/hXVJAevlQ94ArfO+fAviY+ub2Qx6Jvl 7WiGD9ia4lEnjbUd0sfs9hWqDqGEzX2Ds8cmq+5qQxZ8+aBuY4aq8+5XFUrxp+NSWF7W 0PpNUWMBzmz2otX970WmjA7Y84HExsRPjK0FbO0hRUQKPgMN08D9Sen/YVXPd8Qew+JI 774A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=MPeO1w7mlIxtUXd31vD1Yk2df/JFg24xK8uKaWv5+Wo=; b=CZjK3iievSlg5Cfkc4Vtnx+BNoqNjzrBh+ULeTo7Xnfdk4Eh6GYdzTyToXreVmLaii FhfqEe2fQY8oaxxDPeuc6Ztiyj0A7SDocMfAxBR3+QseeD9yAcR7Ch11AOBkOR0j4/lK XrHlAID9jFoSt4Fl0Z4J1PDg+o1a4sBQZoM2hcUzhPw2BCXR+zPcO6Cwhq1ioq6BJAHX jQ3vuRKG/StyL2ofChR67B/csCsiIEHz8XauL76U4d1C+QvdPnOKKbkfcv/srYYbggrc k9uku0kTIDacBwkMSplii1YEg9n0P0GQnGm17c2e2PQVgASgAtukFg1qWSA+Te35QPsA qHew== X-Gm-Message-State: APjAAAVXlzB0w3pQPVq3TxzTltptwvzrYNZw7eYTGFKYlEvK2lL5xefC kQkYFW2C20p8QXd7bGAHOlVrji37gbzTR7te3JA= X-Google-Smtp-Source: APXvYqyh9k00LL1/wr6F+g793T3ru674U9gqC00mWDIbcuWi6kttwQOuj5pgktGcCl9yhJeSD8pj6B7cUJ/3NnMSgLE= X-Received: by 2002:a05:6e02:5c8:: with SMTP id l8mr11432234ils.287.1576482235329; Sun, 15 Dec 2019 23:43:55 -0800 (PST) MIME-Version: 1.0 References: <7178407D-3FC6-458F-A068-7BEADAD004D5@gmx.de> In-Reply-To: <7178407D-3FC6-458F-A068-7BEADAD004D5@gmx.de> From: Dave Taht Date: Sun, 15 Dec 2019 23:43:43 -0800 Message-ID: To: Sebastian Moeller Cc: ECN-Sane Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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:43:56 -0000 On Sun, Dec 15, 2019 at 11:26 PM Sebastian Moeller 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 setti= ng a TOS value with aeCN side-effects in a middlebox) and they also were sa= id 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 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 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 re= queues 0) >>> backlog 288139b 201p requeues 0 >>> maxpacket 1514 drop_overlimit 1047 new_flow_count 65837164 ecn_mark 70= 963 >>> 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 re= queues 0) >>> backlog 46605b 39p requeues 0 >>> maxpacket 1514 drop_overlimit 1047 new_flow_count 66286036 ecn_mark 74= 965 >>> 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=C3=A4ht >>> 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. --=20 Make Music, Not War Dave T=C3=A4ht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-435-0729