Re: [tsvwg] tsw/ospa: Internet phone-in-QoS ?

Kyle Rose <krose@krose.org> Wed, 15 April 2020 16:29 UTC

Return-Path: <krose@krose.org>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A0263A0CA9 for <tsvwg@ietfa.amsl.com>; Wed, 15 Apr 2020 09:29:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org
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 oeSrCs5eW7fQ for <tsvwg@ietfa.amsl.com>; Wed, 15 Apr 2020 09:29:16 -0700 (PDT)
Received: from mail-yb1-xb2b.google.com (mail-yb1-xb2b.google.com [IPv6:2607:f8b0:4864:20::b2b]) (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 0875C3A0CAE for <tsvwg@ietf.org>; Wed, 15 Apr 2020 09:29:15 -0700 (PDT)
Received: by mail-yb1-xb2b.google.com with SMTP id o139so294984ybc.11 for <tsvwg@ietf.org>; Wed, 15 Apr 2020 09:29:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wErP+go5i5Keng285YfIwxGc2AnwoStQs3MwF+EQMGY=; b=C75sxvnhK/O30q9uQ52GjzChWmq765qgcUCYOjk8dTZX+XUJ4POQ69IsUtMEUuUs30 AcYfQN/yro1BuW32MAmk4MRmKJgyHJ0TkT2RxCifLo4AP7xlH++duPcD/Cm0aZ69dPV2 HMybMrDLmgpSjImU1op13UQ1O+3HP8r9LQEcQ=
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; bh=wErP+go5i5Keng285YfIwxGc2AnwoStQs3MwF+EQMGY=; b=OD9tPmbjxnAoBDgowuKLxs28lPJwU+rEE8R28MSSTRzj0Qh+XWHfS01tiEYblkCoMD RxUX5zyChH53Vt5Kb9+26j1Q/yEvTF46JC1Xu6zto0hs7MrJXIQaNiz9O+uILqKAXnkf 6BonoZJQdDmsokOR6aQp/YtSdYR201y0/t7Ks8uORQkkjTzS98yihWov7qV885ZMGkij c6Y6wMyurwRjyE9aiZiXOdLatvJKmglx4YYblHFwUAskFvAn507jrvizJxe41uUrGbma QkuNybPFLsw7puCUulvX8lFIw77iqIf22IHzDede/nEXMbNqeRu9sBt8qCokAtAK+RbQ +kfw==
X-Gm-Message-State: AGi0PuaE+Ap2sbJaGFCIxb8ueUXr3VO4rvbMlKFKBqJi2kaJ2z4u9BOK j1uKqgZ5jBZfUUOIzfCipeyH3NGqETQu3tDwUU7o1Q==
X-Google-Smtp-Source: APiQypL1pfMvDwpkuTQV7Hugm0Bgv5iBGS7VpnJ/WcxBKaHuBahnHQWJzSHcJQlHvlUp5S3UljydY3ftmySRd+EhENc=
X-Received: by 2002:a25:ba03:: with SMTP id t3mr9725859ybg.438.1586968154803; Wed, 15 Apr 2020 09:29:14 -0700 (PDT)
MIME-Version: 1.0
References: <20200414194641.GA29328@faui48f.informatik.uni-erlangen.de> <1F9CDC71-594A-48AD-959D-B70A72DEE9DD@gmail.com> <20200415001809.GA6205@faui48f.informatik.uni-erlangen.de> <0A7DF3CF-BBD9-4D45-BABF-5275EF311A54@gmx.de> <98D8D901-E0BC-4697-980C-FAE8D2DDF77A@gmail.com>
In-Reply-To: <98D8D901-E0BC-4697-980C-FAE8D2DDF77A@gmail.com>
From: Kyle Rose <krose@krose.org>
Date: Wed, 15 Apr 2020 12:29:03 -0400
Message-ID: <CAJU8_nUKrdm=OrjaYrTYQGuTNza+6qZLrCE2u-oGFuGX9FnEgQ@mail.gmail.com>
To: Jonathan Morton <chromatix99@gmail.com>
Cc: Sebastian Moeller <moeller0@gmx.de>, opsawg@ietf.org, Toerless Eckert <tte@cs.fau.de>, tsvwg IETF list <tsvwg@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000023250805a356d164"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/3TlfKLkr1btWxBI2V6VWlX9NCyk>
Subject: Re: [tsvwg] tsw/ospa: Internet phone-in-QoS ?
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: Wed, 15 Apr 2020 16:29:18 -0000

On Wed, Apr 15, 2020 at 11:08 AM Jonathan Morton <chromatix99@gmail.com>
wrote:

> I think the important point here is that reliably defining whose traffic
> is "more equal" than the rest - in the Animal Farm sense - is a Hard
> Problem, one that has been tackled many times over the years without any
> significant success.  It's also one that we don't even *need* to solve, as
> long as the "fair share" is sufficient to let the critical applications
> work.
>

Agreed. ISTM that this is the only reasonable way to address
underprovisioned links.

If a link is underprovisioned temporarily:
 * Small flows are not the problem, so we can give them low latency with no
penalty under any circumstance. FQ does this without overallocating
(unnecessarily reserving) capacity to these flows.
 * Large flows that are congestion-controlled and rapidly capacity-seeking
will always try to fill up the pipe, so the best you can do in the short
term is to divide some portion of the capacity equally among them in a
value-free manner. Low latency is not generally required for these (in
fact, Reno et al. preclude it), so FQ seems fine.
 * Large flows that are either completely unresponsive or that slowly
respond to congestion (e.g., clients dropping from 4K to HD on sustained
buffer underruns) are the flows that really want to be low latency but have
to suffer in the case of a heavily constrained pipe because not doing so
would be unfair to the other classes of flows at the bottleneck. Maybe the
priority should be to reduce rapidly capacity-seeking flows first, but not
enough to create the perverse incentive for all large flows to ignore
congestion signals.

If the link turns out to be perpetually underprovisioned:
 * The network needs to fix that by adding capacity, period. There's no
other solution. While doing this will result in capacity-seeking flows
sending more traffic, there is no link anywhere that would have unbounded
demand at any given time: there is always some other link that would become
new bottleneck. If you're the bottleneck and you aren't an access network,
you're probably doing it wrong.

Kyle