Hrmcat Session @ IETF91 Wednesday, November 12, Morning Session I 0900-1130 Room Name: Coral 4 Note taker: Pasi Sarolahti WG Status [slides] Chairs Zahed Sarker: cc-requirements version is wrong on slides. Chairs: ack. Ver 08 is going for IESG Telechat. Varun Singh : (on interim meeting) Hoping than there was one CC algorithm proposal that would desire to work with FEC. As not we will just choose one CC scheme to work on.  Mirja Kühlewind: Any opinions on adoption of NADA Zahed: evaluation is my main concern. All the simulation results have not been tested with wireless. Authors have promised to give some results, would like to see results before making decisions.  Lars Eggert: I agree with you that evaluation of nada, etc. needs to be done. It's not yet for publication, but just asking if this is something wg wants to work on. I'm fine with adoption Zahed: I agree with you. NADA has been there for long time. It is improving. Give both NADA and Scream one more cycle. Good technical base. Lars: Certain similarities in proposals looks like that there is a framework coming up here. Mirja: not sure if we need framework or just some interfaces to other documents Xiaoqing Zhu: From designers point of you the NADA algorithm have solid foundation. My view is that these are implementation issues. We would feel motivated if this was adopted. There are certain portions of algorithm that are more about cc, other parts are to make it better with video traffic. Could try to extract these parts separately. Mirja: Another update, then adoption. Xiaoqing: need to do it anyway, will send updated draft on how to decouple the interaction techniques, then can decide on adoption. Lars: if we adopt, it doesn't say we must publish it, just asking if people are interested. Michael Ramalho: Different proposals accomplish same ends through variety of means. There are certain control loops that can be implemented in either way. There are no winners or losers. There can be two candidates going forward as wg items. Other standard groups don't work like that. Lars: can adopt multiple experimental documents. They might not fulfill all requirements, but ensure that they do not cause harm. Zahed: I agree with Xiaoqing, both algorithms can focus on core. It is very hard to declare winners or losers. Can work on commonalities. Best to have next iteration. Lars: My motivation to adopt soon is to easier ensure we have enough resources to work on these. Paul Coverdale: To clarify the process, you are going to have several experimental documents? Market is going to decide? How's it going to work Lars: We chartered to publish one or more candidate experimental algorithms. In second phase we publish subset of them as PS. Yes, community will decide. Criteria is that we believe they are safe for internet, might not work in all cases, but except them to be safe. Spencer Dawkins: think chairs are doing the right thing. We've had congestion control algorithms before TCP, but we have stopped working on them. Applications change and network changes, problems might be different in 10 years, need to work on more schemes then. Varun: are we talking only about Scream and Nada, and not the google cc, that's the one being deployed. What's chairs comment? Lars: haven't seen much activity about the google draft. No means exclude it, but need to see activity in wg. Harald Alvestrand: When I started this, I expected to have resources, was wrong. People were moved to higher priority things. Hope that we will come back. Main priority is that we have something that works. I hope to be able to give more feedback in future, Mirja: Nada and Scream to go through one more update. If we can have the updates soon, we can try to adopt. This can happen as soon as the updates are there. Can happen on the list in-between meetings. Lars: want to hear opinions if you want to arrange Sunday meeting again. Think it was useful. ------- Evaluating Congestion Control for Interactive Real-time Media [slides] Varun Singh draft-ietf-rmcat-eval-criteria-02 (milestone eval-criteria) adopted as WG document  15 min + 5 min discussion  Mirja: my idea is that you discuss a range of parameters to be evaluates. Define ranges and exact values we are interested in. Varun: appendix has range of parameters. Zahed: agree with Mirja.  Mirja: for me it was hard to find the connection to requirements Varun: I agree, will try to address in -03 ----- W3C Constraints API for WebRTC [slides] Varun Singh  (related to milestone app-interactions)  5 min + 5 min discussion  Justin Uberti: This is what the api is designed to operate for. The constrains that it is designed for is to say that if I want to get HD, then give me this. What you are talking about is not about what actual captured media is doing, but it is about encoding.   Bernard Aboba: to second Justin, app wouldn't want to do congestion control, but let the browser do it. Mo Zanaty: Agree. The original API is about raw streams, not encoded streams. works in chrome, does not work in Firefox Some oddity in there. We need some way off the application to control the bitrate. Will have bitrate knobs as objects Justin: you need priority, second temporal space tradeoff.  Bernard: you can enable something like scalable video encoding. Goal of max bitrate is to give browser guidelines about what app wants. Michael Welzl: on priorities, we assume in requirements doc that we can control priority based on requirements doc Peter ?: W3C has consensus to have some knobs, but not about what the knobs should be. Feel free to propose them. Michael Welzl: It is more a question if these knobs are being developed for other usecases than ours. Justin: need something more than max bitrate and temporal space tradeoff. If you need something other than that, then we need to have this on the list.  ------ RMCAT Application Interaction [slides] Mo Zanaty draft-ietf-rmcat-app-interaction-00 (milestone app-interactions) adopted as WG document  10 min + 5 min discussion  Xiaoqing: I don't think we need to look inside cc. still keep modular about what’s calculated and what's the output of the controller. Mirja: tries to describe all possible interfaces, would like to focus on interfaces relevant to congestion control Zahed: you will get more input from us, will help Xiaoqing: many congestion control algorithms have their own ramp up behaviors, wondering whether it is easier to specify rate than ramp-up behavior. [about should we move RTP circuit breakers to requirements doc] Zahed: yes, we have already moved [RTP Circuit Breakers] to requirements Someone at the mike: Are you also looking for guidance for api implementers? For example a web application. Mo: like apis to set rates? Zahed: Didn't get the control of congestion control part?  Mo: API is config to codec interface, we don't expect apps to dynamically influence behavior. You are also measuring feedback about media quality, not sure where it is modeled. if you think it is useful and needed in draft, let’s talk Michael R: talking about interface from cc to codecs.... need input from codec community about what input they want, to improve api/document ----- Modeling Video Traffic Sources for RMCAT Evaluations [slides] Xiaoqing Zhu draft-zhu-rmcat-video-traffic-source-00 (related to milestone eval-criteria)  10 min + 5 min discussion  Geert van der Auwera: are you talking about windowed rate behavior or frame level? Temporal layers? Xiaoqing: potentially yes. That should be one possible outcome of the model Varun: what is the rate range? Is this configuration that goes to cc module? set only once or is it going to change? Xiaoqing: more like app limited max and min. can go only once, but can be dynamic Mo: support having realistic synthetic generation tool. a little hesitant about reverse engineering approach. useful starting point is to look their design points. typically leaky bucket. might give more common approach for better deriving simple statistics. Answer: We want to mimic a particular codec, then we collect traces from that codec Someone at the mike: For video conferencing you could use open gops, will be quite different from streaming applications. Of course you will have different kinds of contents, affects on models Xiaoqing: model limits what range of contents we can investigate  Harald: do you have data about trying to generate parm sets of codecs, how close have you got to them?  answer: we have data of high definition video source. haven't done statistical match-ups yet. Harald: I am worried about you don't have the right parameters to generate right things. you might be evaluation wrong content set. Zahed: should validate model, decide what is the content. validation part is important Stephen Botzko: I agree that most video codecs use some sort of leaky bucket model. Really important to understand how codec responds to loss. Geert: video content activity. There could be lot of activity in content, difficult to evaluate Xiaoqing: we acknowledge limitation Geert: important that cc candidates are tested with real codecs. Need to work with many configurations  ans: that's one of the potential benefits of this Varun: we are releasing open source ns-2 traffic generator. We looked at 2000 you tube videos. We would be providing trace-driven model. Xiaoqing: please post to mailing list Zahed: do you have iframe generated when there is a packet loss? Stephen: our codecs will send iframes, whenever receiver does not receive frame. we tend to use traffic shaping. we slow down frame rate, don't scale video rate linearly. This is applicable to all polycom codecs. Bernard: depends on different factors. If you can retransmit packet, you do not need iframe, or you may have error correction. Lot of things involved. Michael R: answer is: it depends. All a matter of design, don't expect given answer. Harald: yes, it depends. I like the approach of statistically modeling the codec. Models do get quite complex, what happens after packet loss, depends on lot of aspects. It gets complicated. Zahed: Please help us defining synthetic model. To identify what aspects makes difference in models Xiaoqing: question about the status of draft Karen: my reaction is that there is interest, there is possibility that we will adopt, but not deciding now. looks useful to wg. Lars: send further emails to list ------ Shared Bottleneck Detection for Coupled Congestion Control for RTP Media [slides] David Hayes draft-hayes-rmcat-sbd-00 (milestone group-cc)  30 min + 15 min discussion  Michael R: Very interesting work. I'm wondering if this really does embrace the aqms worked on in ietf, maybe the flow you are using has different characteristics than majority of the other flows. Would this model break down if there is aqm such as fq-codel David: if you have aqm, you have another signal that you can use as statistic. hard to tell if this breaks down. Michael W: not sure if breaking down is concern here. don't think it is Randell Jesup (from jabber):  you'd have correlate packet losses for AQM (working under the assumption that AQM *won't* include ECN/etc) and determining that a link s AQM or not may be tricky David: this case we do use packet loss, when it is measurable. When AQMs get standardized, we'll be able to use that. When AQM is deployed, we can add that signal. This is meant to be extensible. Varun: applicablity? do you want this to work only with coupled congestion control, or do you want to abstract it to the level that other cc's can use is as well. David: draft is written such that part of it is quite generic, but there are specific parts. Karen: in summer people said they are not able to evaluate coupled cc. wondering if people have read this, and do they think it fills the hole we had in summer. Zahed: we can use the concept of sbd with other algorithms Chairs: who has read the document? [about 6] Karen: we think this should move ahead in its own right. Lars: we are struggling in seeing how all this will fit together. we should work on it a bit more.  Mirja: would like to see the candidates first Michael R: I like the work. Q: where does this belong? i think there is more here than just real-time media cc. This could be used in aqm group or iccrg. not sure if its main applicability is in this wg Lars: same feeling. we could move it to tsvwg, but this is the only place where similar work is chartered. At the moment I think this is closest Varun: agree. I want to span the scope, but not so much it does not belong here anymore Xiaoqing: this work has potential work adding value to this wg. We should focus on something else first. Lars: for potential candidate authors: think if any of this will improve your algorithms. we are not blocking any candidates because of this. Randell Jesup (from jabber): I think work to look at AQM here, especially *without* and assumption of ECN is important to move forward with this. AQM is getting deployed in edge nodes/routers/etc Michael W: I think AQM concern is not a big deal. Karen: I understood Randall's concern is that we have AQMs that do not use ECN wherefore this work is important. ------- Coupled congestion control for RTP media [slides] Micchael Welzl, Safiqul Islam (presenting), Stein Gjessing draft-welzl-rmcat-coupled-cc-04 (milestone group-cc)  10 min + 5 min discussion  Varun: without results from rmcat, it is hard to say if it is useful. Answer (Safiqul): now the time has come that we can start working on it more closer. We will figure out how to incorporate a couple of ccs Zahed: would be good to collaborate to see how this will work Karen: you do grouping based on 5/6-tuples. Are you using dscp codepoints to differentiate? Answer (Safiqul): We do differentiate on the DSCP. Mo: question about both last two presentations: has struggle to see if this will benefit any of the clients, but lot of potential on server side. In sbd, did you look how that would operate in data-center environment? how would coupled cc work on rmcat connections over large number applications David: Haven't tested directly on datacenter, we believe this will work, but not with the grouping algorithm currently in draft. Randell (jabber): if the server is tied to the clients (and it will be normally), it can use application signaling to the clients to tell them to back down bandwidth as needed. Ted Hardie: not the case. I agree with Randell in theory but not in practice Varun: if you have mesh of 4-5 people in group call, you would need coupling. If you look at how google cc works, it gets information across multiple flows. Mirja: if you could write down a different proposal, we could discuss. If we standardize coupled cc, we don't need to use it everywhere Varun: individual schemes can do this in very simple way. sbd is the main part that everyone needs. Michael W: I'm getting totally lost, are people talking about multiple or one sender. This document is about one sender. This document tries to be simplest possible way how to control this. Mirja: this discussion is not reflected in the draft Michael W: will be happy to discuss more in the draft. Zahed: We have schedulers, we have different flows. When having multiple apps, we need coupled congestion control. I think coupling makes more sense when we have multiple apps sharing bottleneck. Mirja: should we first adopt shared bottleneck detection Varun: sbd should be decoupled from coupled cc. --- Ending: Lars: Who would show up for Sunday interim in Dallas? [about 10 hands] Zahed: whenever we have data, we will send it to mailing list Mirja: need to know early, so that we can organize the meeting Xia: expecting to share some new data. could leverage webex meeting. Lars: think additional time is useful Michael w: there was no clear indication to me that sbd should be adopted first? Lars: we want to prioritize work on the candidates. I saw more confusion on coupled congestion control than sbd. Therefore sbd is closer to adoption