* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Rmcat Status Pages

RTP Media Congestion Avoidance Techniques (Active WG)
Tsv Area: Zaheduzzaman Sarker, Martin Duke | 2012-Sep-25 —  

IETF-112 rmcat minutes


minutes-112-rmcat-00 minutes

          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
          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 -

Generated from PyHt script /wg/rmcat/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -