Re: [Congress] [tsvwg] New Version Notification for draft-scheffenegger-congress-rfc5033bis-00.txt

Dave Taht <dave.taht@gmail.com> Fri, 17 February 2023 20:16 UTC

Return-Path: <dave.taht@gmail.com>
X-Original-To: tsv-area@ietfa.amsl.com
Delivered-To: tsv-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6905C15171B; Fri, 17 Feb 2023 12:16:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 k5yoOCoLX65d; Fri, 17 Feb 2023 12:16:47 -0800 (PST)
Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (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 C226FC14F740; Fri, 17 Feb 2023 12:16:47 -0800 (PST)
Received: by mail-wr1-x42a.google.com with SMTP id i15so1861586wry.8; Fri, 17 Feb 2023 12:16:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=hNrCDCMrI3Bfj7zvNDf3GlTJQ7DuuN9rBQw2dgkAXDs=; b=Fc5+fl2vHTBf0MXy8a8o5wHjo785+8BKPgcoDWvGUN2rpi6Jv1KjwQpUqvuO73aeGH RPn1jHPzaTFTmt/FhHkArRxkUXWmtS93A+vM9LOJaOBKKUbIZVi0wwLKKxjSauDqm6SJ lKadEP78Yfl39iP4DIKgf/Q8+QUMhm56ncbAtZwyT2prtq95BCmHu4BAZVVFQiVVLpvd QGFf13dMzk7a1BYyvJpiWOSNWMdQ++gBmNZUY2X9A7Qfb3DqWiXQH7qk9lL3Rvd/si6t FA7Q1aAwR9TcqYE3dhEmsSS+tPgbLoLeeOd3IkeF4deh0kEnvL6v7dlW/7vg9zmr3nLV 8DGQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding: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=hNrCDCMrI3Bfj7zvNDf3GlTJQ7DuuN9rBQw2dgkAXDs=; b=lxNstvKZ7Utmw+VBay1lu2bXqEOyUKFP/1yPV+xs/hQaqzF6lquHuvU3rnyB6yB7CS LI65OUPD44+puHcap6SpZujSbc7BlqA8vyszJromoGqpYeQR9/Vnma+cXmvd4oV5pqQj l+Q4VOZlgZntG4iJTxfQSOfi8qAsUGX4FwqFro7zN5b40jJ/yNUeJLLvMYMxggV2vePc GD+CbH8OVBJm9cfDYp6p+/Gdkggsn763ymgB9SAv7ZWTRwq4n9iAFlQuBwsmkjGZ/7Xy Xa21zewGg2d1Rnjs2zrc8wcObCxV74FANCisY9J7R+GNPK0qw9KmxIKA+q71AkkwFw0w GsIw==
X-Gm-Message-State: AO0yUKXeHYdZjQuAqb25pajNSBthXWGILzl+TdVbTOXnRofjVext7hWG iZKUiO94nBac+oeGpTwSKD7Mxlx/oz8CfngsDn4=
X-Google-Smtp-Source: AK7set9OEyq27HaH/Ah2AIJlk/euWXm/6yLQTM2gqgpRqr1/JcdneZdq4+hG7gERiYAk4auxS+bQmMFWuR8kGO9ov64=
X-Received: by 2002:a5d:570c:0:b0:2c5:6459:4ebd with SMTP id a12-20020a5d570c000000b002c564594ebdmr234942wrv.46.1676665006107; Fri, 17 Feb 2023 12:16:46 -0800 (PST)
MIME-Version: 1.0
References: <80ccaea8-1813-06ff-6b0f-9f66e2a8a00f@gmx.at> <CAA93jw63z6En6a_EteQxc70jJkfSb3QgXNCeJwRyamFB1Ae7eA@mail.gmail.com> <CAEsRLK8FYE8Rru0+OHK4H4Cfnz-fW_Lg+ho-y9_uJK2oQpdNtA@mail.gmail.com>
In-Reply-To: <CAEsRLK8FYE8Rru0+OHK4H4Cfnz-fW_Lg+ho-y9_uJK2oQpdNtA@mail.gmail.com>
From: Dave Taht <dave.taht@gmail.com>
Date: Fri, 17 Feb 2023 12:16:34 -0800
Message-ID: <CAA93jw4HAaLqVqqndYdq+-to5PabMVUmGVMqd0hNVa5ZOSmYLA@mail.gmail.com>
Subject: Re: [Congress] [tsvwg] New Version Notification for draft-scheffenegger-congress-rfc5033bis-00.txt
To: Matt Mathis <mattmathis@measurementlab.net>
Cc: rscheff@freebsd.org, congress@ietf.org, Martin Duke <martin.h.duke@gmail.com>, Zaheduzzaman Sarker <zaheduzzaman.sarker@ericsson.com>, Reese Enghardt <ietf@tenghardt.net>, Eric Kinnear <ekinnear@apple.com>, "tsvwg@ietf.org" <tsvwg@ietf.org>, tsv-area@ietf.org, "tcpm@ietf.org" <tcpm@ietf.org>, quic@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-area/g4lDtb12bUhayIXPcx0bL1DW05s>
X-BeenThere: tsv-area@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF Transport and Services Area Mailing List <tsv-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-area>, <mailto:tsv-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsv-area/>
List-Post: <mailto:tsv-area@ietf.org>
List-Help: <mailto:tsv-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-area>, <mailto:tsv-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Feb 2023 20:16:51 -0000

On Fri, Feb 17, 2023 at 10:43 AM Matt Mathis
<mattmathis@measurementlab.net> wrote:
>
> Dave, I'd be curious to know what you think is the proper shape for either of the problems that you pose.  Both have deep ambiguities/conflicts in the definition of correct, in the sense that solutions that would be considered optimal by some audiences call for behaviors that would be considered anti-optimal by others.

I am sorry, Matt, are you looking for me to wordsmith things relative
to updating RFC5033, or issues of the draft "congress" charter? If the
former...

:before:

The IETF's standard congestion control schemes have been widely shown
    to be inadequate for various environments (e.g., high-speed
    networks).

:after:

The IETF's standard congestion control schemes have been widely shown
to be inadequate for various environments (e.g., high-speed networks,
wireless technologies such as 3GPP and WiFi, long distance satellite
links)  and also in conflict with the needed, more isochronous,
behaviors of VOIP, gaming, and videoconferencing traffic.

...

Would be a start, I suppose. I am perhaps well known for my fierce
desire to make human interactive traffic as near zero latency and
jitter as possible, all the time. I am not sure how this could be
considered sub-optimal except by AIs. My ideal internet would have no
more than 2ms jitter in it,
and the parameters of all the probing techniques fit within that.

...

What I observe today in high speed networks is most TCP flows never
getting out of slow start, with folk building request/response
protocols that complete in a single round trip, with IW256 (or
higher), FQ'd at the switch, and paced by the host. Is this what
others are seeing?

To skip to the end of RFC5033, it seemingly depends on work in
progress from 2008, the last draft of that, is here:

https://datatracker.ietf.org/doc/html/draft-irtf-tmrg-tools

It is a very good read. Was there a successor?

As for the middle...

>
> Thanks,
> --MM--
> Evil is defined by mortals who think they know "The Truth" and use force to apply it to others.
>
>
> On Fri, Feb 17, 2023 at 9:16 AM Dave Taht <dave.taht@gmail.com> wrote:
>>
>> wow! what a blast from the past, and what sadness I felt when
>> stumbling across Sally Floyd's name in the credits.
>>
>> My primary comment is that I wish somehow, in the IETF, we attempted
>> to address the congestion control problems our wireless transports
>> have, as that seems to be the principal means of users' access to the
>> internet.
>>
>> Secondary comment is what I always harp on, in aiming for an internet
>> that can safely and reliably transport videoconferencing and gaming
>> traffic while duking it it out with more aggressive capacity seeking
>> traffic.
>>
>>
>> On Fri, Feb 17, 2023 at 7:41 AM Scheffenegger, Richard <rs.ietf@gmx.at> wrote:
>> >
>> > Hello,
>> >
>> > In order to facilitate the github based editorial process of a revised
>> > RFC5033 document that outlines the current best practises when it comes
>> > to designing new congestion control mechanisms, I want to invite
>> > everyone who has commented across various lists and in meetings, to
>> > raise issues and contribute text here:
>> >
>> >
>> > https://rscheff.github.io/rfc5033bis
>> >
>> > https://github.com/rscheff/rfc5033bis/issues
>> >
>> >
>> > As the home for this work has not yet fully formed yet, I created this
>> > as an individual draft. There are no text changes in rfc50333bis-00
>> > compared to rfc5033, only minor editorial changes due to the use of
>> > markdown for the body of the document.
>> >
>> > A number of individuals have already expressed their interest in
>> > contributing improvements to this document. I am looking forward to
>> > those contributions - either as issues and discussion points, or as
>> > concrete text snippets - in order to reflect the current best
>> > understanding of the congestion control environment.
>> >
>> >
>> > A new version of I-D, draft-scheffenegger-congress-rfc5033bis-00.txt
>> > has been successfully submitted by Richard Scheffenegger and posted to
>> > the IETF repository.
>> >
>> > Name:           draft-scheffenegger-congress-rfc5033bis
>> > Revision:       00
>> > Title:          Specifying New Congestion Control Algorithms
>> > Document date:  2023-02-17
>> > Group:          Individual Submission
>> > Pages:          11
>> > URL:
>> > https://www.ietf.org/archive/id/draft-scheffenegger-congress-rfc5033bis-00.txt
>> > Status:
>> > https://datatracker.ietf.org/doc/draft-scheffenegger-congress-rfc5033bis/
>> > Html:
>> > https://www.ietf.org/archive/id/draft-scheffenegger-congress-rfc5033bis-00.html
>> > Htmlized:
>> > https://datatracker.ietf.org/doc/html/draft-scheffenegger-congress-rfc5033bis
>> >
>> >
>> > Abstract:
>> >     The IETF's standard congestion control schemes have been widely shown
>> >     to be inadequate for various environments (e.g., high-speed
>> >     networks).  Recent research has yielded many alternate congestion
>> >     control schemes that significantly differ from the IETF's congestion
>> >     control principles.  Using these new congestion control schemes in
>> >     the global Internet has possible ramifications to both the traffic
>> >     using the new congestion control and to traffic using the currently
>> >     standardized congestion control.  Therefore, the IETF must proceed
>> >     with caution when dealing with alternate congestion control
>> >     proposals.  The goal of this document is to provide guidance for
>> >     considering alternate congestion control algorithms within the IETF.
>> >
>> >
>> >
>> >
>> > The IETF Secretariat
>> >
>>
>>
>> --
>> This song goes out to all the folk that thought Stadia would work:
>> https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-6981366665607352320-FXtz
>> Dave Täht CEO, TekLibre, LLC
>>
>> --
>> Congress mailing list
>> Congress@ietf.org
>> https://www.ietf.org/mailman/listinfo/congress



-- 
Surveillance Capitalism? Or DIY? Choose:
https://blog.cerowrt.org/post/an_upgrade_in_place/
Dave Täht CEO, TekLibre, LLC