Minutes for RMCAT at IETF-87
minutes-87-rmcat-3

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. ??: not to bundle beyond this. RMCAT should be
able to deal with 5-tuples.

Zahed: for RMCAT we should design a solition for BE class and make sure the
solution performs better (or does not break) when other classes are used.
Cullen: not the right place to discuss Gorry: +1, has been discussed in TSV

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?
Cullen: 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 traffic

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 jesup at jabber.org): 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 Geib: 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
parameters... You need to keep the comparison

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 Randell): 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.

Randell (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 be in different draft

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.

Randy: when competing against TCP with droptail, do you know 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)