[{"author": "Gorry Fairhurst", "text": "

On meetecho, I couldn't really hear - but there seems to be a bit of background noise?

", "time": "2022-07-25T17:30:06Z"}, {"author": "Colin Perkins", "text": "

We can hear you

", "time": "2022-07-25T17:30:44Z"}, {"author": "Gorry Fairhurst", "text": "

Aha - thanks, heard remotely here! :-)

", "time": "2022-07-25T17:30:53Z"}, {"author": "Thomas Fossati", "text": "

ah, I could hear well

", "time": "2022-07-25T17:30:57Z"}, {"author": "Hang Shi", "text": "

MASQUE is rechartering?

", "time": "2022-07-25T17:35:29Z"}, {"author": "Jana Iyengar", "text": "

I read that as \"Run from Area Director\"

", "time": "2022-07-25T17:36:49Z"}, {"author": "Al Morton", "text": "

:-D

", "time": "2022-07-25T17:37:42Z"}, {"author": "Lucas Pardue", "text": "

nominate Jana due to his bad joke

", "time": "2022-07-25T17:37:55Z"}, {"author": "Jana Iyengar", "text": "

@Lucas -- if you start nominating me for bad jokes, you'll be nominating me all the time

", "time": "2022-07-25T17:40:07Z"}, {"author": "Brian Trammell", "text": "

/me raises a hand

", "time": "2022-07-25T17:40:28Z"}, {"author": "Lucas Pardue", "text": "

guilty

", "time": "2022-07-25T17:40:32Z"}, {"author": "Jana Iyengar", "text": "

BTW, this is an english language problem -- I meant to say \"read\" in the past tense

", "time": "2022-07-25T17:40:39Z"}, {"author": "Jonathan Morton", "text": "

that's how I understood it

", "time": "2022-07-25T17:40:54Z"}, {"author": "Jonathan Morton", "text": "

preface something with \"Mic:\" or similar if you want me to put it in the audio

", "time": "2022-07-25T17:43:49Z"}, {"author": "Jana Iyengar", "text": "

@Jonathan: yes, it has interactions, but it doesn't mean that deployment requires collaboration.

", "time": "2022-07-25T17:49:12Z"}, {"author": "Rodney Grimes", "text": "

Please remind speakers coming to mic to identify themselves.

", "time": "2022-07-25T17:51:33Z"}, {"author": "Gorry Fairhurst", "text": "

I'm sorry; Gorry Fairhurst forgot to say his name also!

", "time": "2022-07-25T17:55:07Z"}, {"author": "Spencer Dawkins", "text": "

There was discussion on the mailing list about rate control. Is that part of the domain we're talking about?

", "time": "2022-07-25T17:55:17Z"}, {"author": "Jonathan Morton", "text": "

if it's specifically for congestion control as an alternative/supplement to congestion windows, then yes - but if it's for selecting which quality of a video stream gets sent, then no

", "time": "2022-07-25T17:57:02Z"}, {"author": "Jonathan Morton", "text": "

that's how I understand what's in the proposal, anyway

", "time": "2022-07-25T17:57:15Z"}, {"author": "Gorry Fairhurst", "text": "

+1 to David on teasing out whether datacenter CC is in scope... I'd expect the DC world is not the same as deployable Internet methods, nor the same incentive to standardise common DC solutions.

", "time": "2022-07-25T17:57:17Z"}, {"author": "Colin Perkins", "text": "

Traditional congestion control doesn't need that interoperability. If you need network support (e.g. L4S) the IETF may have more of a role.

", "time": "2022-07-25T17:59:30Z"}, {"author": "Hang Shi", "text": "

Or congestion control status reporting to upper layer to help application layer optimization

", "time": "2022-07-25T18:00:19Z"}, {"author": "Jana Iyengar", "text": "

Not my question, David. My point is that this work falls quite neatly within tsvwg

", "time": "2022-07-25T18:01:25Z"}, {"author": "David Black", "text": "

@Jana - a lot of other things fall into that scope. TSVWG is a catch-all WG for TSV work that doesn't have its own WG. There is plenty of work beyond congestion control to keep TSVWG busy.

", "time": "2022-07-25T18:02:56Z"}, {"author": "Lucas Pardue", "text": "

the QUIC charter says

\n

\"Defining new congestion control schemes is explicitly out of scope for the WG. However, new QUIC extensions that support development and experimentation with new congestion control schemes may fall under [extensions to QUIC]\"

\n

and we're seeing some cases where extensions are being published as I-Ds but its unclear where to tell people to go to do the other bits

", "time": "2022-07-25T18:03:12Z"}, {"author": "Jana Iyengar", "text": "

Spencer: We've tried that for years. We still don't have a good way to say anything meaningful about what is a safe congestion controller to deploy. This is a research problem, and it can belong in ICCRG, but shouldn't be the basis for a new IETF wg.

", "time": "2022-07-25T18:03:17Z"}, {"author": "Gorry Fairhurst", "text": "

+1 to Jana, I do think it could be done in TSVWG, however, we will need to generate momemtum to ACTUALLY MAKE a new document /guidance ...

", "time": "2022-07-25T18:04:30Z"}, {"author": "Jonathan Morton", "text": "

NewReno is a standard because it's the minimum acceptable functionality

", "time": "2022-07-25T18:04:45Z"}, {"author": "Spencer Dawkins", "text": "

Jana - I understand. I am wondering if the seriousness of the problem has grown.

", "time": "2022-07-25T18:04:55Z"}, {"author": "Jana Iyengar", "text": "

I'll distill one point -- the reason that existing congestion controllers have not been documented yet is not because we don't have a forum for it. Creating a forum does not mean that people will start showing up with CC documents that they want to standardize.

", "time": "2022-07-25T18:07:30Z"}, {"author": "Matt Joras", "text": "

+1 Jana. We really have to ask ourselves: \"What is the incentive for someone seeking standardization of a congestion control algorithm?\"

\n

The incentives for standardizing protocol mechanics are much clearer than those for standardizing congestion control algorithms. Making a new \"better\" framework for such standardization does not change the fundamental incentive problem which actually drives behavior.

", "time": "2022-07-25T18:10:52Z"}, {"author": "Jana Iyengar", "text": "

Apologies for being curmudgeonly today -- but I again worry about opening up \"safety rules for congestion control experiments\" for discussion. It has all the makings of a \"written by committee\" piece of work, with a risk of becoming irrelevant. Folks who deploy new CC deploy based on metrics that matter to them. Safety is important, but performance often trumps that in decisions.

", "time": "2022-07-25T18:12:52Z"}, {"author": "Brian Trammell", "text": "

I think that's the key question. CC was deployed in a coordinated fashion in order to avoid congestion collapse. Is Internet-scale congestion collapse due to uncoordinated congestion control deployment a realistic enough possibility that we need to coordinate away from it in the IETF?

", "time": "2022-07-25T18:17:44Z"}, {"author": "Brian Trammell", "text": "

(sorry, just in the chat at the moment, remotely attending two meetings at once)

", "time": "2022-07-25T18:18:07Z"}, {"author": "Jonathan Morton", "text": "

we're not likely to see \"congestion collapse\" as long as a reasonable response to congestion is retained in all cases

", "time": "2022-07-25T18:19:05Z"}, {"author": "Lucas Pardue", "text": "

\"Proposals that depend on the capabilities of a single transport protocol should generally remain in the working group of that protocol\"

\n

It's not clear how much groundwork a proposal would need to do ahead of time to ensure that it would fit this remit. For instance, if all in-scope transport could be extended to support something, is that ok? What if those extensions die on the vine

", "time": "2022-07-25T18:19:52Z"}, {"author": "Jonathan Morton", "text": "

but there is a concern that transports using \"conventional\" congestion control would get squeezed out by transports inappropriately deploying something markedly more aggressive in search of higher performance

", "time": "2022-07-25T18:20:06Z"}, {"author": "Jonathan Morton", "text": "

eg. if someone tried to deploy DCTCP over the Internet rather than carefully restricting it to a DC

", "time": "2022-07-25T18:21:00Z"}, {"author": "Brian Trammell", "text": "

jonathan: right... but this is a self-correcting environment (and AFAIU has driven \"default\" CC deployment from Reno toward CUBIC)

", "time": "2022-07-25T18:21:40Z"}, {"author": "Jonathan Morton", "text": "

CUBIC is higher performance, but is specifically designed to work alongside NewReno

", "time": "2022-07-25T18:23:11Z"}, {"author": "Jonathan Morton", "text": "

DCTCP - I'm not sure a deployment of that would be \"self correcting\"

", "time": "2022-07-25T18:23:27Z"}, {"author": "Hang Shi", "text": "

+1 to AQM

", "time": "2022-07-25T18:23:31Z"}, {"author": "Brian Trammell", "text": "

so one of the potentially valuable outputs of a group like this would be to educate people who would otherwise accidentally drive the deployment of non-cooperative CC algorithms...?

", "time": "2022-07-25T18:26:34Z"}, {"author": "Gorry Fairhurst", "text": "

+1 Brian, and the IETF also will learn in that process...

", "time": "2022-07-25T18:27:12Z"}, {"author": "Jonathan Morton", "text": "

+1 Brian

", "time": "2022-07-25T18:27:48Z"}, {"author": "Jonathan Morton", "text": "

also +1 AQM

", "time": "2022-07-25T18:27:56Z"}, {"author": "Spencer Dawkins", "text": "

+1 Brian

", "time": "2022-07-25T18:27:59Z"}, {"author": "Gorry Fairhurst", "text": "

The reason L4S was moved to TSVWG to ensure that a broad spectrum of people were engaged - that happend, but it proved a big job, for sure.

", "time": "2022-07-25T18:29:27Z"}, {"author": "Spencer Dawkins", "text": "

Yeah, step one will be having people who aren't ADs take the pen on the proposed charter.

", "time": "2022-07-25T18:29:39Z"}, {"author": "Colin Perkins", "text": "

Is \"this\" community willing to contribute might not be the right question. Can we get new people to contribute?

", "time": "2022-07-25T18:29:56Z"}, {"author": "Brian Trammell", "text": "

+1 colin

", "time": "2022-07-25T18:30:04Z"}, {"author": "Zaheduzzaman Sarker", "text": "

+1 to spencer

", "time": "2022-07-25T18:30:07Z"}, {"author": "Hang Shi", "text": "

maybe we can define the interface around the CC, AQM is kind of the interface between CC and network node. Another interface would be what information from CC can provide to upper layer protocol

", "time": "2022-07-25T18:30:35Z"}, {"author": "Zaheduzzaman Sarker", "text": "

I think this expectation on the \"this\" community is that \"this \" community is not a fixed number of persons..

", "time": "2022-07-25T18:30:58Z"}, {"author": "Spencer Dawkins", "text": "

+1 Colin, and I'm thinking of the AVTCORE people who may not be in the room now.

", "time": "2022-07-25T18:31:05Z"}, {"author": "Zaheduzzaman Sarker", "text": "

so yes, new contributors are the part of the ask

", "time": "2022-07-25T18:31:27Z"}, {"author": "Jonathan Lennox", "text": "

I'm in the room, but yeah, whether to cover the AVTCORE/RMCAT use cases (and the extent to which they overlap) is interesting

", "time": "2022-07-25T18:31:52Z"}, {"author": "Lucas Pardue", "text": "

talk to me jana

", "time": "2022-07-25T18:32:25Z"}]