Subject: [rmcat] please check draft minutes

From: "Eggert, Lars" <[email-masked]>
Date: Mon, 5 Aug 2013 08:50:26 +0000

Hi,

attached are our draft minutes from Berlin (THANK YOU BRIAN). Please check them carefully and send corrections to Mirja and me.

Lars

Chair Slides discussion:
-------------------------------------------------------------------------
RTCWEB + RMCAT:
Ted Hardie:
one thing I would add to slide 8 in chairs presentation: work in MMUSIC that RTCWEB asked for: what do do with large number of flows for NAT state. MMUSIC has adopted a solution: Unified Plan draft adopted earlier this week. Higher expectation that we can go forward with RTCWEB with large numbers of flows. May be conditions where a single flow has packets with different DSCP code points due to multiplexing.

Lars: For RMCAT, we operate with six tuples?
Mirja: It doesn't matter: map algorithm to protocols.

David Black: multiple DSCP per 5-tuple, have worked with Fluffy; the case is AF classes. This is done today. Plan: not to bundle beyond this. RMCAT should be able to deal with 5-tuples. Multiple DSCPs are only dro

Zahed: for RMCAT for should ... (overrun)
Fluffy: not the right place to discuss
Gorry: +1, has been discussed in TSV

Did RTCWEB desi.. no

Colin Perkins: ...circuit breakers will be discussed tomorrow
Mirja: we should be independent of decisions taken there
Lars: if you're not on both

Michael: what is a circuit breaker?
Fluffy: I'll explain it to you

Colin: Will we have separate CC for the data channel?
Lars: I don't think we have consensus
Mirja: If so we'll only look at the interactive.

Status of the Evaluation Criteria Design Team
Michael Ramalho
10 min (discussion after next presentation)
-------------------------------------------------------------------------
On test topology:
-----------------------

Lars: I'd assume that we have two-way media in rmcat

Michael: We're testing one direction now, will consider two-way.

Colin: The assumption is that there's loss due to bottleneck?

Michael: No, there can be additional loss at the impairment sources

Lars (as [email-masked]): we want to live with other delay flows except maybe if we're not in a Codel/etc environment (just for clarification)

Jana: is this the topology? the point is it has only one bottleneck.

Zahed: where we have other signals (e.g. ECN) we can use them. we don't necessarily only want to use delay.

On initial experiments:
-----------------------

Colin: infinite data seems strange given real time flows. 

Michael: we realize this... we want to run in a rate envelope that rmcat will specify, if we introduce too many things, we have too much uncertainty.

Colin: can't encode video for the future, limited by codec, that's not infinite.

Michael: We can load this up with e.g. holography

Mo: Infinite amount is not the right word, it's VBR versus CBR. We're still considering target rates, we're not going to vary the rate.

Lars: We're trying to start with a simplistic scenario. The most interesting feedback: Is there anything fundamentally wrong? We're not trying to model everything yet, that has shown to be intractable.

Toerless: Does it make you and Colin happy to say "there is a flow that would consistently like to see more data sent than congestion permits"

Colin: If that's the definition, this is fundamentally broken. Not appropriate for set of flows we have.

Lars: Let us note there is a point for discussion.

Michael: Please join the design team meetings.

Lars: When you say output data charateristic: is this what comes into RMCAT, or what RMCAT puts on to the wire. 1/100ms is a requirement of the solution, not a scenario parameter.

Mirja: You assume that CC is aware of this value, or is this an evaluation criterion?

Michael: Evaluaiton criterion. 

Zahed: These are the scenarios, we started with fairness as an issue, we wanted to be simplistic. Fairness requirement led to choose some of these figures.

On open issues:
---------------

Zahed: We haven't discussed this (DSCP) in the design team meeting.

Lars: The WG has not made a DSCP request

David Black: Submitted draft to TSVWG, will be discussed there

Rüdiger Gelb: please state requirements instead of solutions

Lars: we may have to take more time in Vancouver to discuss this

Evaluating Congestion Control for Interactive Real-time Media
Varun Singh
draft-singh-rmcat-cc-eval (milestone eval-criteria) 
30 min + 10 min discussion
-------------------------------------------------------------------------

On Unfairness:
--------------

Zahed: unfairness should be defined on a per scenario basis.

Varun: should we have generic metrics at all?

Zahed: You can devise all the metrics, then look at a per-scenario basis.

Colin: This is a plausible unfairness metric. It might be useful to define a numeric metric which would 

Lars: This is really a test, not a metric.

Colin: Metric would be useful.

Micheal Welzl: I like this, but it should contain a notion of time, in terms of RTT.

On Open Issues: Quality
-----------------------

Varun: Is quality off the table?

Mo: I thought we had consensus it's off the table.

Lars: We're struggling enough with packet characteristic metrics, but media quality would be nice. An appendix or conclusions section noting this as open...

Colin: One of the outputs has to be that rmcat is useful for interactive video.

Zahed: I agree with the chair, it's hard to define, but we should keep options open. A solution that doesn't give good video quality... It should be in the document.

Lars: say that metrics in document are packet flow characteristics, algorithms brought to WG must evaluate quality but leave exactly how up to them.

Xiaoquing Zhu: Video quality dependent on video content as well as network params... You need to keep the comparis

Ken Carlberg: Carriers still use MOS scores. Did this ever come up?

Varun: It came up for audio, 

Bob: What about MOS for video?

Mirja: We also don't have test scenarios. We probably don't want to do that.

Varun: MOS for video: send to list. Sequences available. But we didn't do that.

Lars: We want to see an indication of video quality from candidates, maybe a metric will fall out of that.

Xiaoquing: Why are we considering only drop-tail queues? AQM WG is forming.

Varun: Eval probably shouldn't look into other ones until they're mature enough.

Lars: Charter says effective use of ECN in scope, that requires AQM

Lars (as Randal): TCP cross-traffic will need to include long term flows, and also short-term/bursty queues.  The requirements document says we need to work well with AQM queues - algorithms for delay-based could easily fail badly in an AQM situation

Lars: Not sure if evaluating multiple delay-based flows makes sense.

Randal (via jabber room): disagree with lars: we do need to consider delay-based flows other than the selected one, since people use algorithms on the net which aren't appoved/specced by the IETF (frightening, I know ;-)

Lars: We shouldn't prioritize it... I don't want to rathole on this.

Ken Carlberg: What about roaming?

Varun: Comes down to how we want to model it. 

Lars: Metrics will be common across different scenarios, may make sense in a different draft. Topologies could also 

Mirja: I would like to move this somehow forward. Comments on the mic add more and more. If splitting this up makes sense to speed it up, then let's consider that. 

Lars: Pleased with progress since Orlando, but we are so not done yet. Is there anything else we can do to have work occur in the next twelve weeks.

Mirja: Who has read the document? Six. No basis to adopt at this time as a WG doc.

Xiaoquing: More consensus on evaluation scenario side, less around how to evaluate. Makes sense split into scenario and criteria. 

Lars: these will be tightly linked. Let's discuss.

Coupled congestion control for RTP media
Safiqul Islam
draft-welzl-rmcat-coupled-cc (milestone group-cc) 
20 min + 10 min discussion
-------------------------------------------------------------------------

Lars: This seems to be at least an order of magnitude more complex than RFC2140. Why?

Michael Welzl: This uses unused bandwidth, fairness across RTTs, etc; main goal not to change main CC, update rate based on feedback.  

Mirja: No interface to application, only between congestion controllers?

Michael Welzl: Yes.

Zahed: We should discuss the fundamentals, if these are not right...

Lars: Input to fairness decision is number of bytes over fixed time, with respect to throughput.

Michael Welzl: yes

Mirja: Assume that for one flow you give the rate, and there will be no CC. 

Safiqul: When a flow has a new calculated rate, it sends it to FSE, and FSE adjusts the rate.

Lars: There's a control loop linking the control loop of each flow.

Michael: In that sense it's like 2140, but it's asynchronous.

Mirja: I'm not sure if we should keep these control elements so separately, I'd like to understand what different possibilities we have.

Mo: Distributed congestion control without flow state exchange.

Zahed: We could do the aggregation anywhere.

Michael: THe point is to not do weighted CC, it will compete and fluctuate.

Mirja: Hard to understand how this affects the control of the CC it's connected to.

Safiqul: we'll evaluate that next.

Lars: need realistic traffic and realistic cc.

Mirja: Do you want to give input to evaluation criteria?

Michael Welzl: hope to discuss in the hallway.

Mo: What is the actual state that is currently exchanged. What happens when you rely on more things? What happens when you replace TFRC?

Lars: Chair's prerogative: cut the discussion. Hesitant here: We're struggling with building a single control loop CC, and this proposal links two loops, and adds complication at a time that that's not what we need. I hope we can come back to this. I don't think we have the cycles in the next few months. We hope group CC will help. When we have no idea about the mechanism, it's hard to evaluate. We can talk further offline.

NADA: Implementation Status and Interaction with AQM Schemes
Xiaoqing Zhu
draft-zhu-rmcat-nada 
15 min + 10 min
-------------------------------------------------------------------------

Lars: Would be interesting to see delay measurements for competing NADA streams

Xiaoqing: We can evaluate that.

Jim Gettys: fq-codel is radically more interesting than codel. simulators in ns3 only. codel implementation in linux is for testing, we don't expect it's deployable. Poorly documented codel pitfalls, make sure you read the webpage over it, talk to Dave Taht and myself

Rong Pan: Should we forget about ns2 evaluation of Codel? 

Jim Gettys: Fine to see how they'll interact, but default won't be codel by itself.

Randal: when competing against TCP with droptail, do you kinow why the first NADA flow doesn't change when a second was added?  Was there some floor that stopped it from driving into the ground? (asked after end of meeting)

---

From: Luca De Cicco <[email-masked]>
Date: Mon, 5 Aug 2013 13:13:53 +0200

Dear all,

the m3u link http://ietf87streaming.dnsalias.net/ietf/ietf873.m3u I've
found on http://tools.ietf.org/wg/rmcat/agenda
seems to be a dead link. Is the audio of the RMCAT session available
somewhere else?

Thanks,
Luca

---

From: "Eggert, Lars" <[email-masked]>
Date: Mon, 5 Aug 2013 11:29:25 +0000

Hi,

On Aug 5, 2013, at 13:13, Luca De Cicco <[email-masked]> wrote:
> seems to be a dead link.

it's not a dead link, it's a link to the live stream. Which is by definition only active during the session.

> Is the audio of the RMCAT session available
> somewhere else?

The recordings are (or will be) at https://www.ietf.org/audio/ietf87/

Lars