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

Martin,

1/ I turned the AQM text below into a PR, but feel free to reject and do 
it another way.
https://github.com/martinduke/congestion-control-charter/pull/13

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?

I would have thought that tsvwg is still the best place for changes to 
congestion signals on the wire, 'cos they can interact with 
non-transport areas like measurement, tunnels. People outside the 
transport area expect to be able to come to tsvwg to catch all that sort 
of stuff. But I'm sure there are arguments both ways.


_________
3/ BTW, while searching for this charter, I discovered the IETF already 
has one for a 'Performance and Congestion Control' WG: 
https://datatracker.ietf.org/wg/pcc/about/
It closed in 1987 - the last chartered item being to investigate slow 
start for TCP ;)


Bob

On 08/11/2022 17:10, Bob Briscoe wrote:
> Martin,
>
> Thx for setting up the remote access, and thanks for including AQM.
>
> I'm sure you know that the body of the text is still really all about 
> CCAs and AQM looks like an afterthought at the moment.
> Would it be useful to be given some suggested text about why AQM is 
> included, and what might be done on AQM. Or would you rather write 
> that yourself?
>
> In my mind, it would be quite simple. Sthg like:
>
>     Over the last few years, several developments have raised
>     questions about the
>     value of this model:
>
>     * The community working on congestion control *and AQM*, both
>     industry and academia, now has a much better understanding ...
>     ...
>      * As the only Standards-Track general-purpose congestion control
>     is Reno, other standards reference it, although it is a minority
>     of Internet traffic today.
>
>     ** Some AQM algorithms that were originally published on the
>     experimental track are becoming widely deployed. However, the
>     original specifications do not always include more recent
>     improvements and operational aspects.*
>
>     ...
>
>     A separate working group can review some of the impediments to
>     early congestion control work occurring in the IETF, and
>     generalize transport in this area from TCP to all the relevant
>     transport protocols. *The congestion control expertise in the
>     working group would also make it a natural venue to take on any
>     work on AQM algorithms. *Accordingly, CONGRESS is chartered
>     to do the following work:
>     ...
>
> I can put the above in a PR if you want.
>
>
> Bob
>
> On 07/11/2022 18:54, Martin Duke wrote:
>> As I've mentioned in a few venues, the congestion control working 
>> group (renamed CONGRESS) has had some fine-tuning to the charter:
>>
>> https://github.com/martinduke/congestion-control-charter
>>
>> I am currently the proponent and Zahed is the responsible AD. We are 
>> holding a side meeting at 1700 on Thursday in Richmond 6. Depending 
>> on the attendees, possible subjects include:
>>
>> - comments on the charter
>> - discussions about next steps
>> - solicitation of draft authors for key deliverables.
>>
>> See you there!
>> Martin
>>
>
> -- 
> ________________________________________________________________
> Bob Briscoehttp://bobbriscoe.net/

-- 
________________________________________________________________
Bob Briscoehttp://bobbriscoe.net/