Minutes IETF112: rmcat
minutes-112-rmcat-00
Meeting Minutes | RTP Media Congestion Avoidance Techniques (rmcat) WG | |
---|---|---|
Date and time | 2021-11-12 14:30 | |
Title | Minutes IETF112: rmcat | |
State | Active | |
Other versions | plain text | |
Last updated | 2021-11-20 |
minutes-112-rmcat-00
RMCAT meeting at IETF 112 Friday, 12 November 2021, Session II, 1430-1530 UTC RMCAT Chairs: Anna Brunstrom (anna.brunstrom@kau.se) Colin Perkins (csp@csperkins.org) Notetaker: Gorry Fairhurst (1) Administrativa and Introduction Status of drafts reviewed - most outputs now published as RFCs. RFC 8888 has been published, and the remaining WG ID on RTCP feedback can now progress. (2) Update on Status of RMCAT Algorithms (2a) Introduction -- chairs (2b) SCReAM (RFC 8298): experiments and future -- Ingemar Johansson SCReAM hasn't been used with webrtc; but experience with cloud rendering gaming at high rates (30 Mbps); remote driving of a 1:10 remote control car; and benchmarking test tool that emulates a video codec. Winodw-based CC was good for cellular access - but responsiveness of the video codec is important. Feedback was provided for about 1/60 RTP packets (1/50th of media rate). L4S is in the running code, possible some improved support in the future. We didn't look at other ECN options. Mo Zanaty: Is the design for wireless or would it work for DC-to-DC traffic. Do we need to consider different controls for different environments. Ingemar: This was mainly focussed on the last mile. Mo: Does it matter whether you optimise for sending or receiving? Ingemar: The method is similar to TCP with no retransmissions and sensitive to delay increase. The SCReAM algorithm is not optimized specifically for uplink or downlink transmission. We use the same settings for the cloud gaming (DL) and remote control (UL) experiments. (2c) Update on SBD (RFC 8382) -- David Hayes Shared Bottleneck Detection has been added to MPTCP and in a MPQUIC version. Measurments to detect bottleneck; effect of path delay; and multiple parallel bottlenecks. No known number of groups made clustering algorithms hard, and various methods were compared. RFC8382 performed well, but the sending pattern can cause grouping for the wrong reasons (rather than because they share a bottleneck). Gorry: Did you also look or think about any complex bottlenecks - where capacity was a fucntion of something external (such as rain-fade or movement)? David: We didn't look at this in the study, but all SBD detection algorithms essentially look at correlations in the behavior of flow and it's rather like the effect of different patterns for sources, and this can have the same sort of effects. (3) RTCP feedback for congestion control -- Colin Perkins Described the packet formats and overhead calculations from RFC3550 etc, that makes assumptions about how video is formatted; and the resultant number of reports for RTP video and audio for various frame rates. Rev -07 is consistent with RFC8888, and thought by Colin to be ready to publish. Jonathon Lennox: Is this useful for implementors in its current state? Colin: Yes, I think it is useful. Jonathon: Can you follow this to find an answer to more complex cases? Colin: This is a starting point, it depends on how familiar readers would be with RTP operation. Anna: Please comment on the latest revision. This is targeting Informational. I suggest we look for WG feedback in WGLC. Please comment on the list. (4) Wrap up of activities -- Chairs The Charter permits moving some methods to PS based on experience. However, from the Chair's perspective we haven't seen enough experience to progress at this time. Chairs: Are there any comments on future work? Lars Eggert (as an individual): The last remaining document could be AD-sponsored. I suggest closing the group. Colin: I think the document just needs typos addressed and it is ready. Martin Duke: We talked about SCREAM.bis. This might be ICCRG Gorry: Who might be willing to read/review the ID that is left? (answers via Jabber) Joerg Ott - volunteered to read the ID (had read an earlier version) Ingemar: Also volunteed Anna said XZ who worked on NADA might also be asked. Mirja Kühlewind: I would support WGLC. Jonathan Lennox: +1 WGLC and then close. Zahed: I would expect this document can be taken to WGLC. I don't see additional work, so this group has done really good documents, but I think it is now ready to close the WG. The IETF could keep the mailing list open for any future discussion. Colin & Anna: Agree to this plan and will aim to start the WGLC shortly. - meeting closed -