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 <[email protected]
<mailto:[email protected]>> wrote:
On Fri, Feb 17, 2023 at 10:43 AM Matt Mathis
<[email protected]
<mailto:[email protected]>> 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 <[email protected]
<mailto:[email protected]>> 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
<[email protected] <mailto:[email protected]>> 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
>> [email protected] <mailto:[email protected]>
>> 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
[email protected]
https://www.ietf.org/mailman/listinfo/tcpm
