RMCAT Agenda at IETF-85 THURSDAY, November 8, 2012 1300-1500 Afternoon Session I SCHEDULED DISCUSSIONS Administrativa & WG Overview [pdf] Chairs http://trac.tools.ietf.org/wg/rmcat/trac/wiki/RearrangedCharter 10 min + 10 min discussion Magnus: Should discuss how the media flows interact with other transports. What other cases should be discussed so parallel local flows behave better, as opposed to non-local flows. Lars: One reason we're here is that we had the impression that for data channel we'd be using SCTP congestion control, but there were adaptations proposed, and if that's required, then we need to rethink where it happens. There shouldn't be two teams. Magnus: Some of the proposals floated might include drop LEDBAT into SCTP. Randall: You're missing timestamps in SCTP Mirja: LEDBAT is just a framework, so the framing protocol adaptation should to to its working group Gonzalo: We need to talk about this. Bringing this into transport makes lots of sense Matthew: Some of this comes out of the w3c meeting where there is a desire to have differentiated flow treatment, whether or not they're actually diffserv tagged. Gorry: The diffserv bit is fine to define recommendations... but is there really experience to do that in that group, it belongs in transport Mirja: Just making this group aware what is going on Lars: It's OK for RTCWEB to say we use these DSCPs, but network treatment is for transport Colin: Concerned about scope creep. The real-time cc problem is difficult enough for one WG. Yes there are RTCWEB issues for prioritisation, and they need to go somewhere, but that might not be here as this group is very aggressively chartered Lars: Therefore it belongs somewhere else, perhaps new Matt Mathis: +1 There are two relatively easy problems, and a third tough problem. We want to solve the easy ones first. x: +1 Clearly differentiation would be useful, but there's an issue with the network trusting this as well. So I strongly encourage not taking on this scope creep. Gorry: This refers to something as a work item, adopted, in RTCWEB (beyond their charter) Michael Welzl: There was a point in favour of postponing data cc. The right answer seems to be coupled CC, which is later on in our charter, so it's not all going to resolve until we get there. Lars: It's hard to start stuff, it's even harder to stop. If there's energy for this now, we might end up with a bigger conflict later than if we attack it now. This is not a rechartering discussion, it seems like the work split between RAI and TSV might not be right yet, not a surprise because it's quite complicated. Diffserv belongs in tsvwg, I think. ADs are here, they can sort it. Architectural Overview [pdf] Michael Welzl 15 min + 10 min discussion Bob: On the feedback question. Could we assume that we have data in both directions, so we are unlikely to have pure ACK loss as per TCP. Michael: I don't think we should assume that Lars: Will there be a similar level of asymmetry to TCP? Randall: Typically there will be roughly symmetric traffic, but at any point, there may be little or no reverse traffic. Colin: I don't think we can assume reverse traffic in all cases Zahed: Is pluggable congestion control a good thing? Michael: Yes Lars: Yes, it decouples the evolution. I don't know if it was a design decision, but it has proven useful. Ping?: If you can have more frequent feedback right now because there's lots of media, the overhead fraction is reduced, this is when you want more feedback too Brian: Are you talking about making all flows ECN capable? Bob: I believe the problems only occur when there's routers that actually mark, and I think this is a corner case where we shouldn't complicate the protocol Lars: Unlike TCP, where ECN was an addon, here we would want to build it so we always try to use ECN, it merely needs to work OK when ECN is not available. Does that make sense? Gorry: Makes sense to me. One complication is, we're talking multiple diffserv code points, we've not yet considered coupled cc over multiple diffserv codepoints... that's very complicated, let's not go there. Lars: Because in TCP you observe the ACK stream to extract congestion info, and the mechanisms are abstracted from info collection. There are limits to this, of course. We should identify what kind of information we can make available for the cc level, we should have a coherent view of what sort of information is available Randall: It's not so much generic as a term, as opposed to well-defined. A well defined state machine as to what comes back Lars: TCP recievers are generic as well. e.g. TCP window advertising, which is used for unintended purposes Jana: You mentioned this on two slides, the problem is understanding what is generic enough. If you have selective acks, you don't get inter-packet delay coming back, so is that enough. Michael: I think we should make an effort to define this Mirja: The point is well-defined Yuchung: Is this receiver ok for even current receivers? Radio aggregation bunches up packets, for example, which adds noise to this signal Bill: Let's not worry about the state machines, lets define the information flow between them, that way we can tweak the machines later x: Let's not define mechanisms yet, lets provide the information for it first Matt: I have a sense that trying to pick a compromise behaviour for either end is likely to be an unbounded behaviour. Minimal TCP receiver behaviour has been slowly creeping up... for example, DSACK, which is an experimental addition to an experimental RFC that is deeply entrenched. Picking the right thing for the first launch here is going to be challenging. We need to build in a way to extend things. x: Receivers might need to be able to inform they can recover from certain amounts of loss using FEC or whatever Matthew Kaufman: One answer to making it so one end can do whatever it wants is to make the other end simple, or you can make the other end very programmable Harald: From a software engineering perspective, I'm worried. If you plan for extensibility before you understand the problem, your extensibility mechanism will probably be harmful. Lars: I agree with Harald, but for a different reason. I think it's early, without adequate experience. Certainly we need to decide sometime. Bob: I disagree. There is a huge amount of expertise in here, the lesson Michael is describing is summarising that Michael: I'll argue against publishing multiple fundamentally different RFCs on this Colin: Having fewer mechanisms is better than having many. There's been a lot of discussion of how TCP does things, which is great because of the experience. If we have to fit these things into RTP, we might need to make radical changes to RTP. I think we should make an explicit decision if we're going to do that or not. We should think about fitting within what RTP can do, or not, and decide explicitly. Lars: We're not really chartered to change RTP. Something that works with RTP now is where we should start. Colin: I think we are going to change RTP, it's a question of how much. Randall: +1 to delying deciding now Magnuss: How can you determine one sender is best? I would wait until we have some results of different proposals Matthew Kaufman: Flash player includes a deployed example of multi-host coupled congestion control, and this was presented to tsvarea at IETF 77. Lars: There may be a more readable document about that sometime, discussion is ongoing Lars: I'd like to assign some homework before Orlando. We need to know what information is available from RTP and RTCP, please let the list know what kind of feedback will be available from minimally or optimally extended RTP, which will drive some of these answers. It would also be good to have a record of those questions and decisions. Receiver- or sender- based approaches will both benefit from knowing what information is available. Bob: Why are we sticking with RTP, this has no interoperability problem? We were asked to do something about RTP, have to ask RTCweb. We should do that Christian: I'd like to ask how much of RTP are we allowed to change? Michael?: Be careful, RTP has lots of stuff we want. We could change feedback, and stream aggregation. Mirja: To be clear, we're not changing RTP, we're setting requirements for other groups to change RTP x: Can we get specific people to do that analysis, rather than just the room? Colin: There's a lot that can be done in RTP as currently specified. I will try to get that documented before Orlando Congestion Control Requirements For RMCAT [pdf] Randell Jesup draft-jesup-rmcat-reqs 15 min + 10 min discussion Lars: One of my takeaways from the workshop is that the low latency requirement needs to be more nuanced, because TCP will mess with you in some situations. We can't change that. Randall: There is more nuance in the draft than there is here. For example, if we can't keep the latency low, then degrade to no worse than loss-based. If we're fighting TCP, a pure delay-based algorithm may need to switch to loss based and wear the extra latency Michael: I'd like to undestand, is this a requirement for coupled CC as a whole or is it applied to individual mechanisms? Lars: I thought we would have the requirements that a solution would have to fulfil. Randall: This is the requirements for solution Zahed: ECN: I don't see using ECN if it is there in the draft Christian: if you're talking about flows, what kind of flows? 5-tuple or something more? Randall: If you can find a way to do something better, but I have been thinking about 5-tuples. It's hard to separate. Matt: Cases where there is competition with TCP, in general you can't make it work except in the network. The charter is worded to say it's required to work when protected from TCP, but merely desirable to work in presence of TCP. Randall: When faced with sufficient TCP, you're going to be forced to do something. You can't fix TCP, but avoid having that be an undefined result, and we need to know what will happen. Lars: You can try to put pressure against TCP, and the app gets to decide whether it is doing OK x: Latency seems to be the major requirement, not CBR Randall: My interest is to find out how much bw I can use without inducing delay, rather than finding a constant bit rate x: jitter buffers are used to help deal with delay Randall: let's say "as low as possible and useful" delay, which is situational x: What reverse streams? Randall: When you have RTP and RTCP running in both directions, so you can attach feedback to reverse traffic on the same 5-tuple x: not always Randall: Sure, you have to have ways to do this when there is no reverse traffic, this may or may not make sense Piers: The competition with TCP isn't necessarily out of luck, depending on RTT. If you're loss based, the delay budget may still be OK Harald: CBR doesn't exist any more, all modern codecs are VBR. Trying to be CBR too hard creates artifacts, so bitrate will vary, just a question of how x: Delay being low as feasible. There's a tradeoff, they're hard to put into words in prose Randall: I agree. You want to undershoot what you believe the bw to be most of the time, that way you don't have creeping queue increase x: +2 Lars: You might not want to merge feedback across dscps, you're running a 6-tuple really. Colin: I agree startup behaviour is a very important requirement. I would be interested to see a discussion of how quickly 'straight away' really is. It would be interesting to see some usability investigations before we start engineering Randall: I don't have hard requirements or research. Having the picture appear early and at least be reasonable is a big usability thing. x: Part of this can be guidelines as to how you start your video, to optimise UX vs bit rate. Randall: You can also have memory as to what the previous experience on this was, can we make use of that Christian: Solution space is quite large, you can keep the first pictures blank, or connection setup during ringing Lars: What should we require, not designing mechanisms x: How slow is too slow? For small RTT it's probably OK... during ringing get an inital pic, for example. y: wrt the good experience immediately, look at the waste of effort over iptv channel changes. There are compromises to be had. Zahed: startup discussions can go on and on... Should the cc dictate the startup time or should service? Lars: It is bad to send at high rate without current cc info. We will need to do something like this. What exactly, I don't know, we need to figure that out. Slow start, and restart over idle. Wonder if we need to nail this down initially... maybe assume slow start, then tweak Zahed: requirements on startup should be tech agnostic ?: classic slow start may be too fast a: draft is very vague at present, these need to be more specific Bob: Detect we're saying 'like slow start', also watch the overshoot Evaluating Congestion Control for Interactive Real-time Media [pdf] Varun Singh draft-singh-rmcat-cc-eval 15 min + 10 min discussion Christian: trade-off is very application dependant, what kind of conversational pattern etc Colin: I don't know what this metric should be, but it seems strange we should be designing this without one. Xiao Ping: We might want to standardise on one metric... there is huge debate though Zahed: metric is fine, should be very careful not to use it to judge codecs etc Michael: Whether we want it or not, this is going to be tied to the codec Lars: Hopefully there will be some mandatory to implement codecs, so we can restrict to those Christian: There's a lot known about this at the ITU, they have some standard models Lars: There's a well analysed model here Varun: I'll look in to it Harald: Just pick one, because any not-hopeless metric is better than an ID full of hand-waving. In video codec comparison, 'PSNR is the least horrible metric we have' is a common phrase. I'd like to see some very specific scenarios for tests we want to run. I want the draft examples expanded with bitrates etc. Any number is better than no number. Lars: Ideally I'd like it to be very specific. I'd also like to see cross-validation of the algorithms. So please try to replicate everybody's results. Piers: Making code available is a good thing. Closer ties between these two drafts seem like a good idea Lars: If we do the evaluation, we should know Gorry: All these results are not entirely reproducable, and so we should pick some use cases and point solutions, but not expect that we can extrapolate between them Jana: It seems like the interaction between codec adapation and metrics should be documented Lars: That's a lot of work... Mirja: do you have some cycles? Jana: No... but I can email what exactly I think the problem is Xiao: Jain's index is a metric of fairness Varun: I'm not sure that works for short flows Bob: Jain's index is for comparing metrics, but it doesn't work if you don't know what metric to use Lars: take that to the list Xiao: Metric that is missing is the time variation of the video rate Randall: This is asking for a jitter variation Michael: When you're talking about impact on cross traffic, congestion measure is on your flow and unknown aggregate traffic. What's your assumed fraction of the bottleneck traffic is a criterion... evaluate when minority or majority of the bottlenec Matt: The same problem isn't solved for TCP either, so take TCP out of the equation IF TIME PERMITS Note: we will prioritize the scheduled discussions above over everything listed below, based on chairs' discretion, even if they run over their assigned time slots. Congestion control algorithm for lower latency and lower loss media transport [pdf] Piers O'Hanlon draft-ohanlon-rmcat-dflow A Google Congestion Control Algorithm for Real-Time Communication on the World Wide Web [pdf] Harald Alvestrand draft-alvestrand-rtcweb-congestion NADA: A Unified Congestion Control Scheme for Real-Time Media [ppt] Xiaoqing Zhu draft-zhu-rmcat-nada