Minutes IETF112: rmcat
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 -