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

On 09/11/2022 09:44, Jonathan Morton wrote:
>> On 9 Nov, 2022, at 11:10 am, Bob Briscoe <[email protected]> wrote:
>>
>> 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?
> "Congestion signalling" refers not only to the mechanisms that allow congestion to be detected by transports, but the algorithms (from drop-tail overflow upwards) which generate those congestion signals to control transports' demand on network resources.
>
> The former aspect, referring to the wire protocols, may well be properly handled by TSVWG and/or individual protocol WGs (eg. TCPM, QUIC, etc).  The latter aspect, however, is more general in terms of protocol and more specific to congestion control itself.  I think "… & Signalling" would refer very naturally to text mentioning AQM in the body of the charter.
>
>   - Jonathan Morton

Clearly, if an AQM is designed only for a constrained environment, and 
never intended for the general Internet, placing this with transport CC 
might work - of course, *IF* the IETF decides that protocols for 
constrained environment is something where standards are important.

After thinking further on this though, I do think that new AQM deisgns 
ought to take into consideration other forwarding at the IPv4/IPv6 
packet level, this is something that needs careful coordination with 
other aspects of forwarding (as in RFC 7567). Therefore, I do not 
something where we can simply encourage an experiment with a range of  
behaviours, and I do not think it should be put in a separate group.

Gorry



Gorry

_______________________________________________
tcpm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpm