Subject: [rmcat] Design Team Meeting Minutes & Recording June 3

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Mon, 10 Jun 2013 13:45:38 +0000

RMCAT Eval Design Team Meeting
Monday, June 3, 2013, 11:00AM New York Time (EDT UTC-4)
58 minutes, 29.43MB
Streaming recording link:
https://cisco.webex.com/ciscosales/ldr.php?AT=pb&SP=MC&rID=68706657&rKey=9b2b690901a2b3d7
Download recording link:
https://cisco.webex.com/ciscosales/lsr.php?AT=dw&SP=MC&rID=68706657&rKey=4a23354c5554cc60

Next meeting is Monday June 17, which conflicts with the MMUSIC/RTCWEB interim on signaling multiple RTP streams. Please reply if we should reschedule to June 24 or July 1 or keep June 17.

Meeting Minutes: (from Varun/Mo, others please add anything missed)

Quantitative statement for fairness:
  - define it based on a case-by-case or anchor it to a scenario?
  - If we cannot agree on an optimal balance, define gross inequality. because
    it may be easier to define unfairness.
  - minimum rate would be a non-starter because of bottleneck link, better to
    make it share of capacity.

Metrics:
  - Log every RTP packet arrival, every RTCP sent. Metrics are derived from these.
  - At what times scales do we consider rate to oscillate?
  - What if the CC undershoots the target rate? Similar to TCP data limited
    interval. Can someone summarize the TCP/TFRC issues related to this based
    on prior research in TCP/TFRC?
  - We know all apps want to minimize delay and maximize throughput and
    stability but how can we quantify different combinations of the above for
    comparison in various scenarios?
  - Compare throughput as a step function of delay, i.e., compare goodput within delay
    thresholds.

Application:
  - Should we consider different preferences for different apps/media? Like audio,
    video, screen share?
  - Are APIs needed between the app and transport?
  (For transport feedback to app/sender, and app setting transport parameters.)
  - Or will RMCAT be baked into RTP stacks which have their own API to apps
    using the stack?
  - What about non-RTP flows, like SCTP data channels? Will RMCAT be an
    optional CC for SCTP?
Testing scenarios:
  - how to measure startup behaviour? Should we have separate tests for
    startup behavior? Or a startup performance/impairment metric applicable
    to all tests?
  - Should we have separate tests for impairments present before RMCAT flow
    startup vs. introduced mid-stream? (To separate performance of startup
    convergence to static capacity vs. mid-stream adaptation to dynamic capacity.)

Drafts:
  - Do we need a new rev of the requirements draft? Yes.
  - What needs to be added to it to guide and limit the evaluation draft?
  - What are we doing with the evaluation draft?
    Varun has updates pending based on feedback and Michael’s doc review,
    which should be incorporated in a few weeks.

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Fri, 14 Jun 2013 19:20:06 +0000

Unless folks object, we will skip June 17 and meet again on July 1. Please raise any objections before Monday.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mo Zanaty (mzanaty)
Sent: Monday, June 10, 2013 9:46 AM
To: [email-masked]
Subject: [rmcat] Design Team Meeting Minutes & Recording June 3

Metrics:

Application:

Testing scenarios:

Drafts:

---

From: "Michael Ramalho (mramalho)" <[email-masked]>
Date: Tue, 25 Jun 2013 15:35:03 +0000

WARNING: contains banned part

Subject: RE: Design Team Meeting Minutes & Recording June 3
From: "Michael Ramalho (mramalho)" <[email-masked]>
To: "Mo Zanaty (mzanaty)" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 25 Jun 2013 15:35:03 +0000

RMCAT Design Team,

At the RMCAT design team meeting on May 13, I agreed to revise the Proposed RMCAT Testing Methodology Document with the comments made at the meeting and post to the list. It is attached here.

There has been other discussion on the list since May 13 that has NOT been incorporated (e.g., Wes’ comment on RTT-fairness).

As per Mo’s announcement previously, the next RMCAT design team meeting is scheduled for July 1 (next Monday). The meeting details for this meeting is in the thread below.

Note that the cutoff for initial IDs (i.e., “00”) is July 8 and updates to non-initial IDs is July 15. Thus, we need to make some decisions regarding how we incorporate our work into IETF drafts (e.g., via update to the rmcat-cc-eval draft or another draft).

Regards,

Michael Ramalho

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mo Zanaty (mzanaty)
Sent: Friday, June 14, 2013 3:20 PM
To: [email-masked]
Subject: Re: [rmcat] Design Team Meeting Minutes & Recording June 3

Metrics:

Application:

Testing scenarios:

Drafts:

---

From: Michael Welzl <[email-masked]>
Date: Wed, 26 Jun 2013 10:25:54 +0200

Hi,

In her recent email to the list, Mirja said:

***
Also in the minutes of the last call, there were mainly a large number of open 
questions. Do we also already have a couple of answers?
***

I'll try to answer a few of them, in line:

>     on prior research in TCP/TFRC?

The issue is that you have no clue about the actual bandwidth in the network because you stopped measuring it, yet you want to make a reasonable decision. One lesson learned from history is that we perhaps shouldn't be too conservative - e.g. for TCP, "Congestion Window Validation" (RFC 2861) was too conservative to convince people to implement it (or turn it on). This is currently being updated:
http://tools.ietf.org/html/draft-ietf-tcpm-newcwv-01

For TFRC, I think the state-of-the-art is well captured in this paper:
TCP Friendly Rate Control (TFRC) for Bursty Media Flows
A. Sathiaseelan and G. Fairhurst, Elsevier Computer Communications, Vol 34, Issue 15, pp. 1836-1847, September 2011.

(again, too conservative at first, and fixed afterwards)

For RMCAT, the issue is also addressed by coupled congestion control:
http://tools.ietf.org/html/draft-welzl-rmcat-coupled-cc
which allows greedy flows to "take" the bandwidth that non-greedy flows are not using. I think that's the best solution whenever it applies, but, of course, it requires more than one flow to be active (and identifiable) across a bottleneck.

>   - Should we consider different preferences for different apps/media? Like audio,

Definitely, it's requirement F34 in
http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-10

>   (For transport feedback to app/sender, and app setting transport parameters.)

This is December 2013 milestone... an important question to ask. My personal view is yes, it's clear that things can work better when such APIs are there. Is it an absolute necessity? Of course not. FWIW one could also send data of TCP...  :-)

>   - What about non-RTP flows, like SCTP data channels? Will RMCAT be an

I'd love to see that happen but either way this is outside of the RMCAT charter, I think.

>     which should be incorporated in a few weeks.

Cheers,
Michael