RMCAT Working Group, IETF 99 ============================ Reported based on notes taken by Alan Ford and Colin Perkins. ## Working Group Status The chairs reviewed the agenda and status of the working group documents. The requirements (draft-ietf-rmcat-cc-requirements-09) remain in the RFC Editor queue, blocked on a missing normative reference. The group has three candidate congestion control algorithms and two related drafts: - draft-ietf-rmcat-coupled-cc-06 has been submitted to the IESG - draft-ietf-rmcat-sbd-08 has been updated to address review comments, and is now ready for submission to the IESG - draft-ietf-rmcat-scream-cc-09 is ready for submission to the IESG - draft-ietf-rmcat-nada-04 is waiting for an update from the authors to address working group last call comments, and is expected to be ready for submission to the IESG soon - draft-ietf-rmcat-gcc-02 is waiting for an update from the authors The group also has several drafts relating to evaluation of candidate algorithms, test criteria, and the like: - draft-ietf-rmcat-eval-test-05 is ready for working group last call - draft-ietf-rmcat-eval-criteria-06 is waiting resolution of an open issue around the choice of TCP model; the intent is to send it for working group last call along with draft-ietf-rmcat-eval-test-05 once this has been done - draft-ietf-rmcat-wireless-tests-04 has no known open issues, but reviews and implementation experience are needed. - draft-ietf-rmcat-video-traffic-model-03 has been updated, and needs review. The authors believe this is ready for working group last call. The codec interactions (draft-ietf-rmcat-cc-codec-interactions-02) and framework (draft-zhu-rmcat-framework-00) drafts have expired. The next steps for these were discussed later in the meeting. The feedback format (draft-dt-rmcat-feedback-message-03) was updated, but the feedback timing draft (draft-ietf-rmcat-rtp-cc-feedback-03) has expired. These were discussed in the design team status update. ## RMCAT feedback design team status update Zahed Sarker gave a brief review of the design team activities since the last meeting, and passed over to Colin Perkins who presented an analysis of the overheads of different congestion feedback mechanisms. Colin compared the performance of the congestion feedback mechanism from draft-holmer-rmcat-transport-wide-cc-extensions-01 with the design team proposal (draft-dt-rmcat-feedback-message-02), for VoIP and two-party video conferencing scenarios. Details are in the slides, but in summary the mechanism in transport-wide-cc-extensions has lower overhead than the design team proposal for the VoIP scenario, but doesn't provide ECN feedback. For the video conferencing scenario, the design team proposal generally, but not always, has slightly lower overhead -- and it also provides ECN feedback (the results for the video conferencing scenario depend heavily on the loss patterns and the number of RTP packets sent per report). Zahed summarised the conclusion of the design team: it's not believed the benefits of further optimising draft-dt-rmcat-feedback-message-02 are worth the complexity. There were a number of questions for clarification on the analysis. Varun Singh and Jonathan Lennox asked about the differences between the two mechanisms, and where the variation in overheads came from: it's slightly different information being reported, XR vs regular RTCP, per-SSRC reporting overheads in RTCP vs RTP header extension overheads, and so on. Varun Singh asked if the group could give guidance on how to reduce reporting overheads. Colin Perkins suggested the congestion feedback draft (draft-ietf-rmcat-rtp-cc-feedback) would be a good place to do this, since it has related analysis already. Jonathan Lennox asked if signalling was needed for the RTCP extensions we propose. Colin Perkins believes it is needed, but that we have the mechanisms required already if the design team proposal is used. The chairs asked if there was agreement to move the design team draft on to AVTCORE for further development. In a hum, the consensus of the room was strongly to do so. ## Next steps for the RMCAT WG The chairs led a discussion of the next steps for the working group, now the initial candidate congestion control algorithms are complete. The group first considered interactions between applications and RTP flows (draft-ietf-rmcat-app-interaction-01) and between applications and codecs (draft-ietf-rmcat-cc-codec-interactions-02), and also the overall congestion control framework (draft-zhu-rmcat-framework-00). Varun Singh noted that the cc-codec-interactions draft is relatively mature, but the app-interaction draft has been overtaken by events and may no longer be useful to complete. Zahed Sarker suggested that the framework tried to lay the groundwork, and implicitly says what the app-interaction draft was going to say. Mirja Kuehlewind slightly disagreed, stating that the framework is for people who want to work on congestion control, codec-interactions is for codec people, and app-interaction is for applications authors - they have different audiences and should address different things. Varun Singh reminded that the goal was that the framework should be adopted by the candidates but this never happened. Mirja Kuehlewind agreed, but noted that this was because the group didn't want to delay the candidates waiting for the framework to be complete. Anna Brunstrom suggested that there's value in aligning with the framework if we move several candidates to proposed standard but perhaps not at the stage of experimental RFCs. The chairs asked if the group could see benefit in completing these drafts. Varun Singh and Zahed Sarker agreed that there was, for the cc-codec-interactions and the framework, but perhaps not for the app-interactions. Zahed noted that there's probably not a huge amount of work to align the framework and cc-codec-interactions. Overall, there seemed general agreement that we should keep these two drafts, mostly for when we take things to proposed standard, but there was less interest in app-interactions. Varun Singh and Zahed Sarker will review cc-codec-interactions and the framework and come back to the mailing list with a proposal on how to proceed with these documents. The group then discussed how to evaluate the candidate and progress the candidate algorithms to standards track. Varun Singh and Sergio Mena discussed the benefits and trade-offs of simulations, noting that they're useful to compare algorithms and to go from ideas to experimental drafts, but perhaps insufficient to go the Proposed Standard. Colin Perkins asked if we need formalised experiments to perform to judge if work is ready for Proposed, or if deployment results are needed. Mirja Kuehlewind noted that we're looking to collect real world experiences with the candidates. Randell Jesup agreed that we should be trying the candidates in the wild, and stated that Mozilla was willing to help integrate candidates for testing. Varun Singh also noted that callstats.io was willing to help with evaluation. Anna Brunstrom noted that we still need comparison of the proposals since much of the evaluation is individual. She also reminded the group that don't have evaluations showing behaviour with the common feedback format, and that these will be needed before candidates can progress to Proposed standard. Mirja Kuehlewind noted that the bar for publishing as Experimental is not high but for Proposed Standard it's much higher: "we're sure this works well and are recommending it". The chairs concluded by suggesting that next steps should be to collect deployment results and experiences with the candidate algorithms and common feedback format, to allow us to make an informed decision on how to proceed. Proponents of the various candidates are encouraged to bring their evaluation results, however preliminary, to the group for discussion in future meetings. ## Other Business Varun Singh reminded the group that he presented work on a FEC-based congestion control algorithm to the group some years ago. They intend to re-submit this work soon, for consideration as an experimental RFC. -+-