Re: [tcpm] [tsvwg] CONGestion RESponse and Signaling (CONGRESS) charter

Martin Duke <martin.h.duke@gmail.com> Thu, 10 November 2022 00:03 UTC

Return-Path: <martin.h.duke@gmail.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76B10C1524C8; Wed, 9 Nov 2022 16:03:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.104
X-Spam-Level:
X-Spam-Status: No, score=-7.104 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aCKyQr7vLkxN; Wed, 9 Nov 2022 16:03:30 -0800 (PST)
Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60C4DC14F73E; Wed, 9 Nov 2022 16:03:30 -0800 (PST)
Received: by mail-qt1-x836.google.com with SMTP id l2so142554qtq.11; Wed, 09 Nov 2022 16:03:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=+CBkqTOcP8LdMjKKn6nlBUS7U9+2cOLcChGvVvOaBEY=; b=gz1Hq7aPi5thjpNHGNb3ktScg/tLL4pTdRisJ3jYWB/9YbYZMhNCBMbg9WUa29cLZc Y2s+u7/vj8k60V98UJal1hx4QQGviKqgQYrF8yaESQgDCbu2VlZKN5pSddRdyILk0o2q B/IQ5cIoAC5yZS5g1ryp+DSiTeedVlhVc1SfHUdut9InxjjPzfNX/uQ4/FZ8ulfC3/tz 4KUZ+hYfKsdpXHDymq7pbSuB6kpxtYZ+8bLueeVcOsBRODRR66StIPZJ3EQfL/2xIwod GGZwc8Nywm01ddtuJE/orDA1aXD+fUr4lNN1xMZxb1iNbpyuwWZloMSP5OXBT7Pqt7QU Tw8g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=+CBkqTOcP8LdMjKKn6nlBUS7U9+2cOLcChGvVvOaBEY=; b=iLqRZBNn9Y6zp9RDni6hixGSe8GkklsZtxphv5CQ4TLvxBuAgTxrI3EILI4HCxu5Kt 4UpfBJp90PkKWLoa3Op06kyslTPkHTbcpuKzLNBfPL6B3hxj6dMFyA8W894Yt3Bqwnr6 JqSXKd+K2kBvLIMo1ZNReEXYW0Sd7p6YqN9WIeSHTkyWtxkYsenwlfv6ZQ+/HO62Sg7l NY3Qdxkgk++nq5WKZ+iBFMKX6biKFWQ+plm39mrfTUQCgow0ogpMsDdtLp30I/TJp3pS Q2pTwidtluSPamIhdKVnPUor6Izl6lOMsNZRBoVz4MARbrvXnJcdIM1z40jvPgzQxMFQ uchw==
X-Gm-Message-State: ANoB5pm7qy0pCJAAO5G9Z5eCxOALYo10rb+UYo0iLkt4mPrW+vVF3oib cXbN2O3/x0nK0+VWehtL/zyg8FOieoIuvEawGGu2zRg+m/nvIQ==
X-Google-Smtp-Source: AA0mqf7TnLyl9WUqcu7BCyx2K4Irj9uyasxpfHCqvOQdb21myIcJKrW1jIkJAJ85SmQOnHHPCCgTpJwl1Gl9u25+jwg=
X-Received: by 2002:a05:622a:5909:b0:3a5:89c1:a4bf with SMTP id ga9-20020a05622a590900b003a589c1a4bfmr624265qtb.387.1668038608873; Wed, 09 Nov 2022 16:03:28 -0800 (PST)
MIME-Version: 1.0
References: <CAM4esxQFn6V0OK6KddFEyuOLTKAxUS1+HjO_NvCNaCqD5SpSew@mail.gmail.com> <46aaf74d-b623-0408-5d57-818011c1b11e@bobbriscoe.net> <c387ed77-f917-7a25-c572-2bd3e71f904d@bobbriscoe.net> <203BE851-B78A-4196-8C2E-99D0E23D49DE@gmail.com> <36110731-130c-7c74-706a-19ca8d6a1bf8@bobbriscoe.net>
In-Reply-To: <36110731-130c-7c74-706a-19ca8d6a1bf8@bobbriscoe.net>
From: Martin Duke <martin.h.duke@gmail.com>
Date: Thu, 10 Nov 2022 00:03:18 +0000
Message-ID: <CAM4esxTY8NMhAu7cB-R=wqES5N7ecHRGX7-RfwRpvEpES1MUYA@mail.gmail.com>
Subject: Re: [tcpm] [tsvwg] CONGestion RESponse and Signaling (CONGRESS) charter
To: Bob Briscoe <ietf@bobbriscoe.net>
Cc: Jonathan Morton <chromatix99@gmail.com>, tsv-area@ietf.org, tsvwg <tsvwg@ietf.org>, IETF QUIC WG <quic@ietf.org>, "tcpm@ietf.org Extensions" <tcpm@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000c0ee1a05ed1280d9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/EJZS7Ad7AC7FmfB7g5ep0rMyRSo>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Nov 2022 00:03:34 -0000

There were a couple of reasons the name went this way:

- At IETF 114 there was a lovely bikeshed about whether "congestion
control" was the right name for this class of problems, so I picked
"response" which hopefully carries less baggage.
- I would like nontraditional indications of congestion to be in scope
(certainly beyond loss, probably beyond delay and ECN if we're creative
enough to do that). Speaking loosely, AQM fits in with this notion of
feedback. "Signals" don't have to be intentionally sent.
- An S-word fits the acronym :-)

I'll take two actions from this thread:
- make this scope a little clearer
- Open an issue to mirror Gorry's concerns about keeping AQM in scope.

On Wed, Nov 9, 2022 at 2:46 PM Bob Briscoe <ietf@bobbriscoe.net> wrote:

> Jonathan,
>
> On 09/11/2022 09:44, Jonathan Morton wrote:
> >> On 9 Nov, 2022, at 11:10 am, Bob Briscoe <ietf@bobbriscoe.net> wrote:
> >>
> >> 2/ Another question: Why 'and Signalling' in the title?
> >> Other than the title and response to congestion signals, the charter
> doesn't say anything about signalling itself.
> >> If, say, there were more work on tunnelling ECN or something, would
> tsvwg take that on, or congress?
> > "Congestion signalling" refers not only to the mechanisms that allow
> congestion to be detected by transports, but the algorithms (from drop-tail
> overflow upwards) which generate those congestion signals to control
> transports' demand on network resources.
> >
> > The former aspect, referring to the wire protocols, may well be properly
> handled by TSVWG and/or individual protocol WGs (eg. TCPM, QUIC, etc).  The
> latter aspect, however, is more general in terms of protocol and more
> specific to congestion control itself.  I think "… & Signalling" would
> refer very naturally to text mentioning AQM in the body of the charter.
>
> [BB] You're right. So this sort-of implies that 'congestion signalling'
> is a rather ambiguous phrase to have in the title. If both meanings will
> be handled by this group, then fine. But if only the generation of
> congestion signals is in scope, the title might need to be re-worked.
>
>
> Bob
>
> >
> >   - Jonathan Morton
>
> --
> ________________________________________________________________
> Bob Briscoe                               http://bobbriscoe.net/
>
>