Re: PSA pt 1: for better videoconferencing at home on slow links

Michael Thomas <mike@mtcc.com> Sat, 25 April 2020 18:10 UTC

Return-Path: <mike@fresheez.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 426913A114B for <ietf@ietfa.amsl.com>; Sat, 25 Apr 2020 11:10:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.65
X-Spam-Level:
X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mtcc-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S3f0PVDXDtVw for <ietf@ietfa.amsl.com>; Sat, 25 Apr 2020 11:10:13 -0700 (PDT)
Received: from mail-pg1-x533.google.com (mail-pg1-x533.google.com [IPv6:2607:f8b0:4864:20::533]) (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 047423A114A for <ietf@ietf.org>; Sat, 25 Apr 2020 11:10:12 -0700 (PDT)
Received: by mail-pg1-x533.google.com with SMTP id q18so6276507pgm.11 for <ietf@ietf.org>; Sat, 25 Apr 2020 11:10:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=KjDsbfsi8fbqpz4hOmiMzdNquB11bFx20/2VKF4nVN8=; b=VoxQ+nHXioY1wUwmHs3nmh3WO33cACIoum88hPFSah8ccdZ5QsmWr0IbgSDcDWWquA F6n8gEnhMrkfK+qN8Yf3w7OAlFzyvbPdHhOVRdfFp+St5r5IFH7B6+xj/DjkM0bZv48S HvYXkb/js/YXZhXG00JrWubkH88r7B6EMvDbAAT/t26VZ+OW9IEuHihb9H2OCps90Ek8 OTTtmBM6T5lx4yIxsj99oTNSKv6R2QrzxI1N7twpIPMWcByiPQJuUc19imSAWPbGXck9 WI+NQ3XJgowdPgSh1RuFLmqJnrHY1CUp2ldjp5C/poAEBazvKIZNh8A3A0Kq9p270kSQ pUvw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=KjDsbfsi8fbqpz4hOmiMzdNquB11bFx20/2VKF4nVN8=; b=ehFZOVJ21u7Wo6AQHrmnAxRv9kF+LFl/sChYlnxyGvU+lYWMWuq55KtmgSSPfpfTKH U55DCE1GRwd1a73F4Xrnd2bzF9nTg/6crWthb5V0a4oEgaJ+1/g1GkKtWlsMmL0aY1yp F0ZEUh+EeRWX44R9ixjfTWI9WGcPiLLBQNspcKzXOU30RB/1LIvuKvKMmhMT7NmnOo3H /gvqCw1K/U/OAgYdRQf3Ifr1iY2erM5bHch0GQQYgC8b1MlbZe0Tx0B/7bEab5RhOV4m J33edAiDrQlh3nH/KdBCatKVwMnLGpD0sQBApIkJyCIvQPgQ6NqSKYb6sG3K8xOB9HB9 Fbow==
X-Gm-Message-State: AGi0Pua60TBU63fPqq7qTyR50v7Pyu5d45BZ8LjfmfKLtma43ItskFTB K6khv/cXR6mfv3FUBgOCy/C1nD87yMg=
X-Google-Smtp-Source: APiQypJ7QAcIjbCAtzaN7R5eoXEIOyYdUUesC3MH+IYDY0KPR5Ko2amvc59jVERam0eA82vltkCDjw==
X-Received: by 2002:a63:1210:: with SMTP id h16mr14943658pgl.328.1587838211669; Sat, 25 Apr 2020 11:10:11 -0700 (PDT)
Received: from mike-mac.lan ([170.75.129.86]) by smtp.gmail.com with ESMTPSA id p189sm8791455pfp.135.2020.04.25.11.10.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 25 Apr 2020 11:10:10 -0700 (PDT)
Subject: Re: PSA pt 1: for better videoconferencing at home on slow links
To: Dave Taht <dave.taht@gmail.com>, IETF Discussion Mailing List <ietf@ietf.org>
References: <CAA93jw7V40=7H9VRuCKho_ju+gEWoYvmqcwcQ6KsEEDC_CymBA@mail.gmail.com>
From: Michael Thomas <mike@mtcc.com>
Message-ID: <74fe8439-829d-9348-ffaa-4b7ce38bcb93@mtcc.com>
Date: Sat, 25 Apr 2020 11:10:11 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <CAA93jw7V40=7H9VRuCKho_ju+gEWoYvmqcwcQ6KsEEDC_CymBA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/q7TRmebAZ1b623zOWL7JKCtO_0A>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 25 Apr 2020 18:10:14 -0000

On 4/25/20 10:37 AM, Dave Taht wrote:
> for some reason I am not getting any ietf mailing list mail. too many
> useful links in the last one? :/
>
> How bad is your dslreports test (send link privately if you like)

With the previous router iirc, it got a D or an F. no clue about actual 
number. With the openwrt+bufferbloat fix it gets an A.

Maybe your pt 2 contained info on the ISP side of the problem, but it 
was pretty dense :) a) is it a problem (i can't imagine it not being 
one) and b) are they doing anything about it?

I've figured out that out here in the boonies that our provider -- The 
Volcano Telephone Company -- has a pedestal relatively close to us that 
terminates pots, ATM and backhauls the entire thing by fiber to the CO. 
A side thing I figured out is that they used leftover copper pairs for 
to power it which works great when battery backup is needed from the CO.

What that Implies is that there is a router or something akin to it that 
has packet buffering. I assume bufferbloat is L2/L3 agnostic so even my 
little green pedestal in the forest is possibly a source of 
bufferbloat.  Is there any way on my consumer end to check for that? Or 
does the DSLreport speed test already take that into account somehow? My 
provider actually has a speed test which terminates at the CO which is 
probably more accurate, but don't think it has the specific bufferbloat 
test. It's on the fritz right now so i can't check.

>
> For openwrt: you need to install luci-app-sqm on openwrt for a gui and
> the related kernel modules. You need to do a bit of testing.
>
> opkg update
> opkg install luci-ssl luci-app-sqm # I pull in the full ssl gui as well.
Yes, that looks familiar. I was pretty surprised that it wasn't enabled 
by default.

Any reason why? I mean, is this in any way contentious?

Mike