[tsvwg] Fwd: bittorrent & ecn mis-marking

Dave Taht <dave.taht@gmail.com> Sun, 07 March 2021 12:53 UTC

Return-Path: <dave.taht@gmail.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id E26E03A149B for <tsvwg@ietfa.amsl.com>; Sun, 7 Mar 2021 04:53:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.138
X-Spam-Status: No, score=0.138 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, LOTS_OF_MONEY=0.001, MONEY_NOHTML=2.235, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id ShvBWhN9V-CK for <tsvwg@ietfa.amsl.com>; Sun, 7 Mar 2021 04:53:34 -0800 (PST)
Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CC5A3A149A for <tsvwg@ietf.org>; Sun, 7 Mar 2021 04:53:34 -0800 (PST)
Received: by mail-io1-xd32.google.com with SMTP id a7so6991445iok.12 for <tsvwg@ietf.org>; Sun, 07 Mar 2021 04:53:34 -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 :content-transfer-encoding; bh=OloXr0i10+2n24ia/7ZiTns4NlQAB+6yDKxlz6SXQ7w=; b=bcy6jzMmo2sfZEQVnLr6p4CObRlTkxqNg9o6B1GBgIongVRRtvYMxRTZJknHEQHQkI zF+F314erKx+ppSv4FMnY4+7jvw+NQooY79xh4Nx6bcHMWFv0TSDCor+WVEo9TcF3j5Q oL8zdzmI0zJkTzRGbGzqpbc98kWMrV4sO6nhsvYO0qc4AtecTodTU17Q5jxo4rSwHe/l u7APD2mU8CaNcHJtq9pxzTXU3gDnmu6WjBc5OdPd7j1SyV6eSssiFbm50yREoIuWikRE 0zWA2MD4hBc8XZIsq4IsDt29fODIru8buvtvYnTPzufs47UUsJBd4rcwE6vGOGPo7zlz G1zA==
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:content-transfer-encoding; bh=OloXr0i10+2n24ia/7ZiTns4NlQAB+6yDKxlz6SXQ7w=; b=BlVXens6XTvp+2ZWpY1Kh4XLyrXskgkEQP/x6bMy5TxAcM2FTT8FF1KHnUd1HIkvDs dRajrNYEVAB4hj6t9sO7c/3BnB5mFO/WP5mzfRl59UBpGeLX2vUDKecvqxQfntimr+MZ 2cZ5cyo25yFx1U0RlfeJVxZciP92cPYNWJg4SNU3WTV0k1FmA4N1iZ1MuKmLChZnruXf 3WRVLtNBcmAqhVPJuSbW+DZRwn3SbsriCo+z8sVhPz3gR7SzZ5B15WvxB0J5cVBGh40R JBOqTPPFXoJMBnrTciqtFwfa+LvhFpqTrnlrcPKxoJePRkbbBhR7ikJvU6iyu8b0iT7/ S8fA==
X-Gm-Message-State: AOAM532R4371007ZFJupQRTVpQ5Va14rn83m4bmO1JLGeE4HznZlB/FO yM+CzQBmu4EQw5Tf8HSs/HH3tjQVEw1OKIEcw8MQKVRyiLA=
X-Google-Smtp-Source: ABdhPJyUiZVRaveAzAaLuVQw9u3FdNbjdZP+gD3OWDfM6dq6Gz6tSCMEsfFilEG5MW6ptKQb210mgeKGkqnd+Hfvn7U=
X-Received: by 2002:a5d:9641:: with SMTP id d1mr14751502ios.123.1615121613099; Sun, 07 Mar 2021 04:53:33 -0800 (PST)
MIME-Version: 1.0
References: <CAA93jw6ccfisQa0cDsy+3D_z-16+dYyATLLQAQe_J4xydoDR4w@mail.gmail.com> <CAA93jw4TTOMyCsCDXp6krswkooeXaramTegmMWuRJ4jvoi26gA@mail.gmail.com>
In-Reply-To: <CAA93jw4TTOMyCsCDXp6krswkooeXaramTegmMWuRJ4jvoi26gA@mail.gmail.com>
From: Dave Taht <dave.taht@gmail.com>
Date: Sun, 07 Mar 2021 04:53:21 -0800
Message-ID: <CAA93jw6gfq76VmOLjppukOKCAP0tnsJ2-AieQo1pR=KaUUcacQ@mail.gmail.com>
To: Pete Heist <pete@heistp.net>, tsvwg IETF list <tsvwg@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/o86dU9DrSTvxpNwDnPUYYMuhTV0>
Subject: [tsvwg] Fwd: bittorrent & ecn mis-marking
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 07 Mar 2021 12:53:37 -0000

Pete had asked about this very fragmentary piece of  data I'd had.

I tried very hard to reach anyone relevant at this isp and failed but
perhaps someone could do a bt probe to see if they are still screwing

Now that I remember the date, I should be able to find the packet
captures, but merely trying the same stuff I did would help.

---------- Forwarded message ---------
From: Dave Taht <dave.taht@gmail.com>
Date: Sun, Dec 15, 2019 at 3:09 PM
Subject: Re: bittorrent & ecn
To: ECN-Sane <ecn-sane@lists.bufferbloat.net>

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 proto 48
ip route add unreach proto 48
ip route add unreach proto 48
ip route add unreach proto 48
ip route add unreach proto 48

# around here I just lost it on finding where it was coming from...

ip route add unreach proto 48
ip route add unreach proto 48
# some of these actually could be legit
ip route add unreach proto 48
ip route add unreach 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
Tel: 1-831-435-0729

"For a successful technology, reality must take precedence over public
relations, for Mother Nature cannot be fooled" - Richard Feynman

dave@taht.net <Dave Täht> CTO, TekLibre, LLC Tel: 1-831-435-0729