Re: [rmcat] My notes from today's RMCAT session

["Eggert, Lars" <[e-mail]>]

Hi,

THANK YOU!

Note that I've also gotten two more sets of notes. While this is awesome, merging them is a pain. In the future, could I ask that any additional minute takers sync up with the main stuckee to e.g. collaboratively minute in etherpad, so we end up with one set of complete notes instead of three sets of rough ones?

Lars

On Mar 12, 2013, at 5:18, Spencer Dawkins <[e-mail]> wrote:

> 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