[rmcat] My notes from today's RMCAT session

[Spencer Dawkins <[e-mail]>]

Lars asked me to take notes at today's session; I'm sending my notes to 
the list so when I've horribly misunderstood or misquoted you, you can 
clue me in ...

Thanks,

Spencer

2013-03 IETF 86 - RMCAT
Lars is chairing this meeting solo ...
Note Well - thank you, Ericsson for disclosing IPR on a Google draft

== Chair Intro
We're running late on Requirements, we have one draft to choose from
We're running late on Evaluation Criteria and group-cc
We aren't sure we need to do rtcp-requirements and application 
interactions milestones
We're going to talk with AD about milestones - proposing 1 year slip for 
submission to IESG milestones
Nothing happened on the mailing list over winter holidays, picking up a 
little speed now

No agenda bashing

== Requirements - Randall Jesup
Draft was discussed in Atlanta, revised as -01
Reviewing issues we're discussing and haven't closed on
Definition of "fair"
- we don't have one, and there's not a single definition
- doesn't have to be 1x TCP
- matters more against longer flows
- matters most against other low-delay flows
- can't collapse, can't take too long for a new flow to become usable
- needs to be bounded if we can't define it
- needs to cover both local fairness and aggregate fairness at nodes 
deeper in the net

Other issues
- "minimum bandwidth" can be application-defined.
- need to think about oscillation and possible "mode-switching" between 
"fair" and "aggressive"

Q and A
- anything we can do to bound the problem will help
- we know what UNfairness is. Can we define tests for unfairness?
- can we describe principles for identifying unfairness?
- Lars: this is the biggest issue facing the group, need to make 
progress this week
- can we agree on a list of priorities?
- how self-friendly is existing non-real time traffic?
- how self-friendly can we be with no other traffic, dedicated nets?
- need to think about what else we're competing against -RTCWeb data 
channels
- Matt: one definition is impossible, think about what matters
- Lars: we need to form a design team this week
- is friendliness part of fairness?
- can we come up with a test plan to check for fairness?
- Lars: remember that bad congestion control makes it bad for everyone
- Colin: decide whether competing with TCP is a short-term goal
- Randall: especially competing against short-term TCP flows
- Pat: need to notice the effect of fairness constraints on other 
characteristics
Lars: this may be one of the hard problems in computer science, but 
we're going to solve it before Berlin :-)

== Evaluating Congestion Control - Varuna Singh
Now at -02
- Open issue: two metrics under discussion, other metrics seem ok
- ideally, we do a distribution and then think about what "discard rate" is
- needs to be more than one number
- we can do things during evaluation we can't do in deployments

We've identified 8 evaluation guidelines
- do we need a minimum set?
- are the identified guidelines sufficient? Have proposed 3 more
- Lars: if you are proposing a solution you need to look at proposal
- have included a proposal for various evaluation scenario parameters
- also want to limit combinatorial explosion of test scenarios
- do we use media packet generators or real video streams?
- video ends up trying to keep quality consistent, not bit rate
- Randall: have to know where the edges are - not one parameter set
- Harald: need to be able to show we aren't ruining video experience
- Gorry: what happens if your delay exceeds 300ms? Need to separate out 
the transport aspects and focus on them
- we need to start someplace - pick scenarios, parameters
- need to use simple and consistent traffic stream
- would like to see continuity from requirements draft to this draft
- need to characterize requirements for various media types
- need to look at multiple network types - wired, WiFi, cellular ...
- Magnus: video is so changeable - that's why it's important to look at 
various media sources

Evaluation Scenarios
- fixed link capacity, variable link capacity, self-awareness
- do all scenarios use the same parameters?
- Matt: assuming single queue or multiple? Need to make that explicit
- Lars: want some scenarios that do it each way

== Working Group Hums
Adopt requirements draft? 20 hands yes, no nos
Adopt evaluation draft? 10 hands yes, 4 nos
What do people want to see in the document to be "yes"? No comments from 
the mikes

== Coupled Congestion Control - Michael Wetzl
Controlling groups of flows has been tried in the past
- why didn't these see deployment?
- hard to identify flows, hard to implement

Flow State Exchange (FSE)
- Flows register with FSE when they start, stop, change rates
- could use various algorithms, but competing flows all use the same one
- not priorities, but proportional share
- Magnus: need to think about RTCWeb control channels, HTTP, etc
- need to figure out shared bottleneck detection, still working on this
- browser could use flow table to self-regulate
- Dale: if everyone builds the same state table, we can understand more
- this would have security implications
- current algorithm has two problems: flow told to use rate that's not 
what congestion manager determined, highly asynchronous flows
- can this be sender-side only? Can do better management if receiver is 
involved

(Missed question here)

== On the use of RTCP feedback for congestion control - Colin Perkins
Thinking about how existing feedback channel works (with AVPF)
- Per-packet feedback would be great, but RTCP feedback is much less 
frequent, and no mechanism to piggyback information
- per-video frame? 30 fps gives you 0.033 second RTCP control interval
- assuming compound RTCP, but not cross-reporting
- per-RTT? Longer than inter-frame interval
- Hannes: can't adjust sending rates arbitrarily with most codecs, and 
frequent quality changes cause problems with user experience anyway
- conclusion - RTCP suitable for per-frame, per-RTT, not per-packet
- Colin's presentation assumes no RTCP extensions
- remember you can lose feedback packets, too. Just need stable control 
system
- don't adjust what we do in RMCAT based on existing codec limitations
- may need to accommodate massive sending rate changes
- can we ignore the fact that this is audio/video? Video streams are 
likely to drive congestion, audio is small and you can end up sending 
more feedback than audio
- packet rate in wireless networks more significant than bandwidth, need 
piggybacking to reduce that
- what about sampling? Could give you enough feedback
- two issues - how often do you sample, latency for feedback to sender
- do we have any minimum requirements that cover feedback?
- this isn't easy stuff (and wasn't easy with TCP, either)

Colin wrote the draft to generate discussion, not planning to progress

== NADA - a unified congestion control scheme for real-time media - Rong Pan
Design goals: limit self-inflicted delay, leverage a suite of network 
feedback mechanisms (loss-based, delay-based, ECN, PCN)
Sender does linear prediction to accommodate feedback latency
Simulation of NADA with ECN shows improvement in avoiding queue build
PCN allows zero standing queue

Q and A
- PCN? Standards are out but haven't been deployed yet
- Rate-shaping buffer on frame basis? Different frame types - I-frames 
can span packets, and buffering them can degrade predictive calculations 
for receiving codec
- Do you see problems with self-interference after congestion happens? 
Depends on traffic and where you stabilize
- 3-5 percent loss rates in your simulations are very bad for video traffic
- If we have a high loss rate, we need FEC or other recovery mechanisms 
that come with overhead
- Have you looked at CoDeL? Not yet ...
- How does this compete with TCP? We're looking at that
- We don't know if ECN has benefits when you're already doing 
delay-based mechanisms
- Should evaluation criteria look at both loss and delay? Probably not, 
we're evaluating the results of the algorithms - but we need to look at 
latency and loss as part of the results
- If you cause other people 5 percent loss, that's worse than causing 
yourself 5 percent loss that you can recover from