RMCAT Working Group, IETF 97
15:20-17:50, Thursday, November 17, 2016 (KST) 
==============================================

## Administrivia and Working Group Status

The chairs reviewed the agenda and status of the working group documents. 

It was noted that draft-ietf-rmcat-cc-requirements-09 has been in the RFC
Editor queue for many months. This draft is blocked waiting on completion
of several RTCWEB drafts (-overview, -jsep, -security, -security-arch) of
which most are transitive dependencies arising from a normative reference 
to draft-ietf-rtcweb-overview.

The chairs noted that draft-ietf-rmcat-coupled-cc-04 has completed working
group last call, but has normative references to draft-ietf-rmcat-nada and
draft-ietf-rmcat-gcc which will delay its publication. The chairs suggested
that it might make sense to try to invert these dependencies, by moving the
text describing how NADA and GCC can use coupled congestion control into
the drafts describing those algorithms, to avoid delaying publication of 
this draft. Zahed Sarker expressed concern that this proposal is not just
an editorial change, and wondered if it would impact the SCReAM algorithm. 
Xiaoqing Zhu also suggested that concrete examples should be part of the
coupled congestion control specification, and suggested leaving the NADA
text in place and moving the GCC reference to informational. Both Harald
Alvestrand and Zahed Sarker agreed with this suggestion. Accordingly, the
chairs asked Michael Welzl to make a proposal along these lines, to review
on the list.

The chairs noted that the milestones have been missed, and suggested a
revised timeline. There were no objections to this, and the chairs will
propose concrete milestones via the list.


## Updates to video traffic modelling: our experience with the Mozilla web browser 

Xiaoqing Zhu and Sergio Mena presented new work measuring the behaviour of
video traffic generated using the codec shipped in the Mozilla browser, to
update draft-ietf-rmcat-video-traffic-model. The draft will be updated to
incorporate this work after the meeting.


## Update on NADA 

Xiaoqing Zhu summarised the recent changes to the NADA algorithm. There are
some minor updates to be made to the draft, to add the lambda parameter and
to revise the test cases. Once these are done, the authors expect it to be
ready for working group last call for Experimental.


## RMCAT DT status update

Zahed Sarker gave a brief update on the work of the congestion control
feedback design team since the last meeting.


## Feedback for congestion control 

Colin Perkins presented the changes in draft-dt-rmcat-feedback-message-01.
These are to remove an unnecessary field from the XR block format, and to
add an RTP/AVPF transport layer feedback packet containing the same data.
He highlighted the overhead in the reports, especially in RTCP XR reports
that have to be sent in a compound RTCP packet. 

Randell Jesup noted that the slides exclude SRTP headers, which make the
overhead worse.


## New packet format for feedback 

Michael Ramalho presented some possible updates to the congestion control
feedback format that can slightly reduce the overheads, but that make the
format slightly more complex. The proposal reorganises the information in
the packets, and allows the ECN feedback to be omitted in some cases. It
also should allow the run-length encoding to compress the data, although
the details of this have not been finalised. 

Mo Zanaty suggested to also consider how the flexible FEC payload format
works, and if similar techniques can be applied to this packet format. It
does marking for a range, so a similar thing (beginning seq num and mask)
could be applied here.

Varun Singh noted that burst losses can occur, and wondered if over-range
arrival time offsets could occur as a result? He also noted that I-frames
can be large, so there might be enough packets that using an RLE format
could give useful compression. 

Gorry Fairhurst wanted to check if this method could hide the presence of
an ECE-CE mark? We don't want to receive an ECN-CE mark and not report it.
Michael will check, but doesn't think this is an issue. 

Jonathan Lennox asked if there is an "I don't know when this was received"
arrival time offset, and if not, if there should be?

Colin Perkins and Mo Zanaty noted that the loss patterns matter, so any
discussion of compression will have to consider the burstiness of loss, not
just the loss rate, to get meaningful results. Colin Perkins also noted
that RTCP reports are sent periodically, so we can specify an upper bound
on the arrival time offset, since a report will be sent whether or not data
was received. 

This is all useful feedback, that should be considered by the design team.


## RTCP feedback for congestion control 

Colin Perkins presented draft-ietf-rmcat-rtp-cc-feedback-02. This outlines
the timing and overhead of feedback sent using the RTCP congestion control
feedback format described in draft-dt-rmcat-feedback-message-01.

Jonathan Lennox and Ingemar Johansson noted that, when using RTP/AVPF, the
T_rr_interval parameter can be used to delay scheduled compound feedback,
to allow more non-compound RTCP reports to be sent between each scheduled
report, which will reduce the overheads. 

Jonathan Lennox suggested that the RGRS packet shouldn't be needed when
using aggregated reduced size RTCP feedback (slide 17). This is likely
true, but it is believed the reporting group specification requires it.  We
should consider if this can be relaxed, since the reporting groups draft is
not yet published (it's in the RFC Editor queue).

Jonathan Lennox asked for confirmation that when you say reducing amount of
feedback, this is just reducing the number of reports, still report on all
packets? Colin - Yes.

Randell Jesup again noted that the SRTP authentication tag adds 10 bytes
per packet. Randell also noted that there's no reason to send compound RTCP
packets frequently. Colin - agreed, but compound RTCP packets must be sent
every few seconds, as least, 

Randell Jseup pointed out that an audio only session must be very bad proportion, 
that is a high RTCP overhead.  Colin - yes it could be 33% if sent for every other
packet, but it doesn't make sense to send them that regularly.

Joerg Ott noted that in terms of guidance for implementers, most interesting detail
is at what interval do you reconfigure rate control. Since there's a strong
risk of overshooting or undershooting.  Colin - please send suggestions!

Zahed Sarker asked if we should do just RTP/AVPF given overhead of compound packets?
Colin - You still need to send compound packets occasionally, else the
rest of RTCP breaks, so we still need the XR block definition. The format
of the XR blocks and transport layer feedback packets should be aligned,
aside from the headers, though.

Bernard pointed out that the Opus payload has burst loss, so this information is critical
for adaptation.  Colin - yes, depends on feedback format.


## Status update on ns-3 module reflecting the RMCAT framework document 

The session concluded with a brief updated from Xiaoqing Zhu on the status
of an ns-3 implementation of the framework document. Colin Perkins and
Zahed Sarker thanked her for the work, noting that this is useful, and
a lot of effort to create. 


-- End --