Subject: [rmcat] RMCAT draft agenda for IETF-96

From: Martin Stiemerling <[email-masked]>
Date: Wed, 6 Jul 2016 06:33:56 +0200

Dear all,

Please find here the draft agenda for the IETF-96 RMCAT meeting.

Unfortunately, we did not get too many requests, but we will discuss all 
WG items at least briefly.

The always up to date agenda is here:
https://www.ietf.org/proceedings/96/agenda/agenda-96-rmcat

And here is a copy:

Tuesday, July 19, 2016 (CEST)
10:00-12:30 	Tuesday Morning session I
Room: Potsdam II

Chairs:
Anna Brunstrom ([email-masked])
Martin Stiemerling ([email-masked])

0) Administrativa (5 minutes) -- chairs
    minute taker
    jabber scribe
    blue sheets
    note well

1) Update about working documents and way forward to complete them (30 
minutes)
	draft-ietf-rmcat-cc-codec-interactions-02
	draft-ietf-rmcat-coupled-cc-02
	draft-ietf-rmcat-sbd-04
	draft-ietf-rmcat-wireless-tests-02
	draft-ietf-rmcat-eval-test-03

2) Framework document (10 minutes) -- chairs
3) Update on NADA performance evaluation (20 minutes) -- Sergio Mena de 
la Cruz
         draft-ietf-rmcat-nada
4) Update on RMCAT Video Traffic Models (15 minutes) -- Sergio Mena de 
la Cruz
        draft-ietf-rmcat-video-traffic-model
5) SCreAM present update, what is new? (10 minutes) -- Ingemar Johansson
        draft-ietf-rmcat-scream-cc
6) Present test results for testcases outlined in section 5 in 
draft-ietf-rmcat-eval-test-03 (20 minutes) -- Ingemar Johansson
7) Status of the feedback design team (20 Minutes) -- chairs
8) FEC + congestion control (20 minutes) -- Varun Singh

Kind regards,

   Martin

---

From: Martin Stiemerling <[email-masked]>
Date: Mon, 18 Jul 2016 15:52:59 +0200

Dear all,

Here is the updated agenda:

Chairs:

         draft-ietf-rmcat-eval-criteria-05
         draft-ietf-rmcat-gcc-02

2) Status of the feedback design team (25 Minutes) -- chairs
         includes update on draft-ietf-rmcat-rtp-cc-feedback -- Colin 
Perkins
3) Framework document (10 minutes) -- Zaheduzzaman Sarker
         draft-zhu-rmcat-framework-00
4) Update on RMCAT Video Traffic Models (15 minutes) -- Sergio Mena de 
la Cruz
        draft-ietf-rmcat-video-traffic-model
5) Update on NADA performance evaluation (20 minutes) -- Sergio Mena de 
la Cruz
         draft-ietf-rmcat-nada
6) SCreAM present update, what is new? (10 minutes) -- Ingemar Johansson
        draft-ietf-rmcat-scream-cc
7) Present test results for testcases outlined in section 5 in 
draft-ietf-rmcat-eval-test-03 (20 minutes) -- Ingemar Johansson
8) Status of the feedback design team (25 Minutes) -- chairs
         includes update on draft-ietf-rmcat-rtp-cc-feedback -- Colin 
Perkins
9) FEC + congestion control (20 minutes) -- Varun Singh

Regards,

   Martin

---

From: Martin Stiemerling <[email-masked]>
Date: Mon, 18 Jul 2016 16:32:34 +0200

Please use the error free web version for your reference:
https://www.ietf.org/proceedings/96/agenda/agenda-96-rmcat

---

From: Randell Jesup <[email-masked]>
Date: Tue, 19 Jul 2016 08:51:13 -0400

Colin - thanks for the analysis!

Agree with Mo that this implies we're way over the default 5% (which can 
be bumped, of course, but knowing how far we need to bump it is important).

As for expected rates... I would expect a common range of rates 
(especially at the start of a stream) would be 200-500kbps @ 30fps, 
extending up to 1-3Mbps @ 30fps.  I would expect to see bandwidths scale 
down to  40-50Kbps @ 30fps (I've deployed videophones operating well 
down to that (QCIF H264)).  At the high end, I expect to scale up to 
5+Mbps @ 30 or even 60fps.  And there may be use for 60fps down in the 
500Kbps-2Mbps range for some usecases.

This speaks to:
* improve compression of the feedback data (RLE the loss data (or 
huffman encode, etc), and delta-encode the arrival times).  I was pretty 
sure we'd need to do this, and this confirms it.
** There's more to win with compressing the arrival times aggressively
* negotiate the needed resolution and reporting intervals with the 
sender-side control in some manner.  If need be, do it in-band in RTCP.
** while more painful in implementation, even the resolution/range of 
the timestamps could be negotiated
* we should consider if there's a way to compress or omit the repeated 
information that's in every report that Colin enumerated
** list of streams etc rarely changes

The bandwidth implications of this was part of why (for adaptation in 
the 30-250Kbps @ 30fps) I used sparse receiver-side congestion control 
in the Ojo, reporting only significant changes in derived bandwidth via 
RTCP.  The challenge here will be to find a way to fit feedback needed 
for sender-side congestion control into the available bandwidth.  I'm 
not concerned with having to increase the 5% default per se, but I am 
concerned with how much "goodput" we get in two-way traffic.  I don't 
want 200Kbps @ 30 spending 50Kbps on feedback....

-- 
Randell Jesup -- rjesup a t mozilla d o t com
Please please please don't email [email-masked]!  Way too much spam

---

From: Randell Jesup <[email-masked]>
Date: Tue, 19 Jul 2016 10:59:07 -0400

Adding avtext:

On 7/19/2016 8:51 AM, Randell Jesup wrote:
> Agree with Mo that this implies we're way over the default 5% (which 
> can be bumped, of course, but knowing how far we need to bump it is 
> important).
>
> extending up to 1-3Mbps @ 30fps.  I would expect to see bandwidths 
> scale down to  40-50Kbps @ 30fps (I've deployed videophones operating 
> well down to that (QCIF H264)).  At the high end, I expect to scale up 
> to 5+Mbps @ 30 or even 60fps.  And there may be use for 60fps down in 
> the 500Kbps-2Mbps range for some usecases.
>
> This speaks to:
> huffman encode, etc), and delta-encode the arrival times).  I was 
> pretty sure we'd need to do this, and this confirms it.

I'll add:
* at lower bandwidths relax the reporting interval to reduce effects of 
overhead and improve compression of the data, at the cost of 
less-reactive results in the congestion control
** Implies the need to test the algorithms for sensitivity to 
less-than-ideal feedback intervals
* look at (with some annoying complexity implied) piggybacking this data 
on RTP packets in header extensions
** shares overhead with reverse-direction RTP (good), may add to delay 
in receiving them (bad), but given that packets may be queued in both 
directions, piggybacking may work well in practice at higher 
framerates.  If we need to send feedback and the next anticipated packet 
going out isn't for a "while", we'd send an RTCP.  If we're pacing 
packets out or likely to send one "soon" relative to the reporting 
frequency, piggyback it.
** size of the extension might be an issue (packet size limits)
** this definitely adds complexity, but can save a considerable amount 
of overhead

> in the Ojo, reporting only significant changes in derived bandwidth 
> via RTCP.  The challenge here will be to find a way to fit feedback 
> needed for sender-side congestion control into the available 
> bandwidth.  I'm not concerned with having to increase the 5% default 
> per se, but I am concerned with how much "goodput" we get in two-way 
> traffic.  I don't want 200Kbps @ 30 spending 50Kbps on feedback....