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

Christian Huitema <huitema@huitema.net> Sun, 19 February 2023 17:59 UTC

Return-Path: <huitema@huitema.net>
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 80A90C151553 for <tsv-area@ietfa.amsl.com>; Sun, 19 Feb 2023 09:59:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-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_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
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 NxMXD1z647bP for <tsv-area@ietfa.amsl.com>; Sun, 19 Feb 2023 09:59:18 -0800 (PST)
Received: from mx36-out21.antispamcloud.com (mx36-out21.antispamcloud.com [209.126.121.69]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 AE20FC151556 for <tsv-area@ietf.org>; Sun, 19 Feb 2023 09:59:18 -0800 (PST)
Received: from xse426.mail2web.com ([66.113.197.172] helo=xse.mail2web.com) by mx202.antispamcloud.com with esmtp (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1pTnxu-0005Qq-MM for tsv-area@ietf.org; Sun, 19 Feb 2023 18:59:17 +0100
Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 4PKYG353SYz9lL for <tsv-area@ietf.org>; Sun, 19 Feb 2023 09:59:07 -0800 (PST)
Received: from [10.5.2.15] (helo=xmail05.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1pTnxr-0007Z4-J4 for tsv-area@ietf.org; Sun, 19 Feb 2023 09:59:07 -0800
Received: (qmail 31284 invoked from network); 19 Feb 2023 17:59:06 -0000
Received: from unknown (HELO [192.168.1.104]) (Authenticated-user:_huitema@huitema.net@[172.58.43.120]) (envelope-sender <huitema@huitema.net>) by xmail05.myhosting.com (qmail-ldap-1.03) with ESMTPA for <mattmathis@measurementlab.net>; 19 Feb 2023 17:59:06 -0000
Message-ID: <4ad263b0-55bd-3bb6-b504-e3a4bd37363d@huitema.net>
Date: Sun, 19 Feb 2023 09:59:05 -0800
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.7.2
Content-Language: en-US
To: Matt Mathis <mattmathis@measurementlab.net>, Dave Taht <dave.taht@gmail.com>
Cc: Zaheduzzaman Sarker <zaheduzzaman.sarker@ericsson.com>, "tsvwg@ietf.org" <tsvwg@ietf.org>, quic@ietf.org, congress@ietf.org, "tcpm@ietf.org" <tcpm@ietf.org>, tsv-area@ietf.org, Reese Enghardt <ietf@tenghardt.net>, rscheff@freebsd.org
References: <80ccaea8-1813-06ff-6b0f-9f66e2a8a00f@gmx.at> <CAA93jw63z6En6a_EteQxc70jJkfSb3QgXNCeJwRyamFB1Ae7eA@mail.gmail.com> <CAEsRLK8FYE8Rru0+OHK4H4Cfnz-fW_Lg+ho-y9_uJK2oQpdNtA@mail.gmail.com> <CAA93jw4HAaLqVqqndYdq+-to5PabMVUmGVMqd0hNVa5ZOSmYLA@mail.gmail.com> <CAEsRLK9M_keDQp2736kRA1jU8bNwP8+D=U-88yquZnWM13AwbQ@mail.gmail.com>
From: Christian Huitema <huitema@huitema.net>
Subject: Re: [tcpm] [Congress] [tsvwg] New Version Notification for draft-scheffenegger-congress-rfc5033bis-00.txt
In-Reply-To: <CAEsRLK9M_keDQp2736kRA1jU8bNwP8+D=U-88yquZnWM13AwbQ@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Originating-IP: 66.113.197.172
X-Spampanel-Domain: xsmtpout.mail2web.com
X-Spampanel-Username: 66.113.197.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.197.0/24@xsmtpout.mail2web.com
X-Spampanel-Outgoing-Class: unsure
X-Spampanel-Outgoing-Evidence: Combined (0.29)
X-Recommended-Action: accept
X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT/uy+2+vpcRT/fplIJCH+m+PUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5zjF072oHsJIQObyfseEKcosUZJtCCyJ/40+Yul5FWs42pB 2EKQMTlpLLXMRwiBiagEybI1sOftHmSKUCHCvcq0J8xIgi6BNPj7dx4YC4myx3BXvrLBlKCVRjjd PbjQ4Hm0eMlrqJpeGu2cNuSWKgfvqJIzT787QaLDjrkUT60iKu3om1NOCXE1kCr91rpFr6QKC0ra ugw27URpR3In5wkBvPANsM1bM1O771Fzdn4sPy0n+6u17EFNvY1xrVxHOMjdaWolaEIooNu/YQK5 hGs0BSl7YrgCdzbaCwJPCCSougyg4uMaxHP8xQTpohmgJxQ1dHhpUbi1UdTVmV3LL7N9ueszlpij Q8vuNSxljixs9l2PHznFCr1UPjZRtNG50GjfX8TdqEXkwxwMjsp2mNApSeHdAXZjQylE/yU10UCZ JpnckpWaLvahyBjmQxBKOzuhP7r/qeCcLfNPkwm2lNnsvr3LBR8rUYXJ4jh62pfHaKqsknzQ1WVE SSlbgJ6e928BIkUL/j1Y48GvmeURQjjEwAD7U/ahcFChVzHooqVT2V7lLXQUcNAszDsnoUOr0Bgv MMAqbgMKDIKtXgzM1DRwOI+gTB/pfSlbi1HgG7umZ25gpnihbI3Vv1c2tRvdVD2GbN7BITAZon7Z Iz1ONK9yUo4/+EUytKrR9Md9I2Rs15rdBm0Un2juhgb9Wc/c3vNPCC/cRgvQKtcrMMueERx3EUzF 7oh08e4ZZ5a42FeJc31f8bkHaWJdVengTsSpTleIaIzNoZzswxuMaWjBAlpwW14FA1sB0DGxktNC 4IFWKvUf9oDBqtClgM5jH/om1Q5UomG0v+rwIiID/kwKc8V5Tj9+FRkaOS/DNjANmb8tO61SbYdY AwdpaVzHW7wHO7YhEWyJzIkwSFAW0Pw8uiKeubcolFl/rX+2ReQklqJDASQX2Id+W5hjJNcdGs0+ iHjXODmj5PX/tZQU3bYnWKpb
X-Report-Abuse-To: spam@quarantine14.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-area/PdOIxnJsr0eAeDGg1lfHCJS-HR0>
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: Sun, 19 Feb 2023 17:59:22 -0000

Maybe we should split the WiFi CC question in two. One is about 
solutions to the problem, i.e., how exactly do we implement congestion 
control and data scheduling algorithms that achieve desired results when 
various applications compete for Wi-Fi access. The second is, what 
should RFC5053bis say about that.

I have ideas about the Wi-Fi problem that may or may not be useful. But 
when it comes to RFC5033bis, the problem is obvious. The impetus of 
RFC5033 was, "don't break the Internet by fielding CC algorithms that 
send too much data." It is almost entirely about bandwidth and capacity, 
and very little about latency, or the impact that a connection's traffic 
will have on latency experienced by other connections. That's something 
that I believe should change with RFC 5033bis.

My first idea was to tie this to bufferbloat (see: 
https://github.com/rscheff/rfc5033bis/issues/8), because "filling 
buffers and queues to capacity" is one of the worse ways a CC algorithm 
can increase latency for competing apps. But there are other ways, as 
Matt points out for Wi-Fi.

-- Christian Huitema

On 2/19/2023 6:10 AM, Matt Mathis wrote:
> Dave, I was referring to the underlying technical problems for WiFi CC 
> and competition between video conferencing, gaming and bulk data.  Are 
> you convinced that there exist deployable solutions that would be viewed 
> as correct by all parties?  I am not.
> 
> To the extent that solutions exist we can shape the process/WG scope to 
> encompass it.  I am not at all worried about that part of the problem, 
> even after the fact.
> 
> I think I have a pretty good understanding of WiFi vs CC, and the 
> fundamental tradeoff between transport causing backlog to facilitate 
> batching MACs vs fully paced flows that never inflict unnecessary jitter 
> on other flows.
> 
> The other problem has been technically solved many times over, except 
> none of the solutions have been deployed widely enough.  New solutions 
> in this space actually make the deployment problem worse.
> 
> 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 12:16 PM Dave Taht <dave.taht@gmail.com 
> <mailto:dave.taht@gmail.com>> wrote:
> 
>     On Fri, Feb 17, 2023 at 10:43 AM Matt Mathis
>     <mattmathis@measurementlab.net
>     <mailto: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
>     <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
>     <mailto: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 <mailto: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://rscheff.github.io/rfc5033bis>
>      >> >
>      >> > https://github.com/rscheff/rfc5033bis/issues
>     <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 <https://www.ietf.org/archive/id/draft-scheffenegger-congress-rfc5033bis-00.txt>
>      >> > Status:
>      >> >
>     https://datatracker.ietf.org/doc/draft-scheffenegger-congress-rfc5033bis/ <https://datatracker.ietf.org/doc/draft-scheffenegger-congress-rfc5033bis/>
>      >> > Html:
>      >> >
>     https://www.ietf.org/archive/id/draft-scheffenegger-congress-rfc5033bis-00.html <https://www.ietf.org/archive/id/draft-scheffenegger-congress-rfc5033bis-00.html>
>      >> > Htmlized:
>      >> >
>     https://datatracker.ietf.org/doc/html/draft-scheffenegger-congress-rfc5033bis <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 <https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-6981366665607352320-FXtz>
>      >> Dave Täht CEO, TekLibre, LLC
>      >>
>      >> --
>      >> Congress mailing list
>      >> Congress@ietf.org <mailto:Congress@ietf.org>
>      >> https://www.ietf.org/mailman/listinfo/congress
>     <https://www.ietf.org/mailman/listinfo/congress>
> 
> 
> 
>     -- 
>     Surveillance Capitalism? Or DIY? Choose:
>     https://blog.cerowrt.org/post/an_upgrade_in_place/
>     <https://blog.cerowrt.org/post/an_upgrade_in_place/>
>     Dave Täht CEO, TekLibre, LLC
> 
> 
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm