RMCAT at IETF-93 (Prague) Chairs: Mirja Kuehlewind & Karen Nielson Monday, July 20, Morning Session I 0900-1130 Room Name: Congress Hall II Agenda and Note Well was presented. WG Status (Chairs) Evaluation Criteria (Varun) - Feedback appreciated - Requirements will be removed from this document. --- Mirja: There is also a TCP model from Mozilla for traffic with file sizes. Mirja: There is also a video model draft that could be referenced. Zahed Sarker: The test draft describes the video sequence, you need to separate hard and soft content that are to be used for evaluation. Where does this fit? Karen: This is in evaluation criteria. The question is whether this should be a separate draft because of the length of the document? Zahed: What do we do with video sequences? Varun: We could define a few video sources, and refer to the other draft for traces. Maybe pick slow and high motion cases? Xiaoqing: I support choosing a few sequences. We could also use a synthetic codec. Karen: Suggest text on these topics, and we can discuss on the list. Zahed: I think we can also explore screen casting. Screen casting of video is hard. Sergio: We can build a list of frame sizes output, and agree on a codec. Chairs: Please discuss in the video source model presentation later. Evaluation Tests (Zahed) --- Karen: Document should be stable (please comment now), but will be kept open until we can finalise, and we can also explore whether the wireless test cases will be added or separate. Zahed: One thing is when you change the bandwidth, you can use UDP background traffic to synthesise capacity changes. ... traffic bursts induce congestion. Mirja (at Mic): Changing the capacity of the link is different, because the UDP traffic can be dropped in congestion. Chairs: Authors will update the draft. Scream (Zahed) - Code is now available. The draft is expected to be finished in August. --- Chairs: Volunteers to review the next version: Xiaoqing Stefan Holmer Mo Zanty Varun Singh FEC (Varun Singh) --- Mo Zanty: I think the FEC work should be generic, most codecs are already doing this. Varun: Agree Chairs: We need some evaluation of this. Can you do this anytime soon? Varun: We’ll work on this. Xiaoqin Zhu: I am not following this draft in detail, but plan to look at this. Stefan: We do use FEC. No current plans for this approach, but that can change. Mirja: There is a use of probing for higher capacity using FEC. Chairs: Please send inputs via the list. Interactions with RTP and Codecs (Mo Zanty) - There will be series of 3 drafts that will exist. --- Colin Perkins: I think it is important this draft talks about these things, I think the draft is useful as it stands. Karen: There are about 7 different interactions that are possible. Some are used in RMCAT. We should try to understand why not all are supported by RMCAT; can we understand which have been considered? Colin Perkins: I think there are things here that may be useful if other approaches are being considered. At the moment everyone appears to be taking the same approach. I think it depends on the types of CC being used. Karen: If the things are beyond the scope of the current WG, then we could perhaps put these in an appendix. Colin: We should not take this out, we could highlight this. Mo: We can make this document says more clearly which ones are mandatory for RMCAT. Varun Singh: We seem to have started evaluation, this had implications in VP8. The impact on H.264 may be different, it could be too early to know which are needed. There could be feedback to netvc. Xiaoqin Zhu: There is the allowed rate, and there are other interactions, and some we have not explored. Zahed: What is the plan in RMCAT? How do I test these interactions if currently not supported by codec? Mirja: The test cases do not use a real encoder, there could be a synthetic codec used to work with encoder people. Stefan: We can’t assume that a codec has knobs, apart from requesting a keyframe; or setting a new bit rate target. Chairs: There seems to be a way forward. The scope was not to cut-out options, but to label these. We propose to adopt the draft as a basis for a WG draft. Should the WG adopt this document? [Hum for adoption; No Hum against] Chairs: The chairs will confirm this adoption on the list. Chairs: We would like to see common terminology between candidates (this could be a separate document). We would like to see all candidates individually specify all the things needed to implement. Gorry Fairhurst: It may be useful to write a terminology ID, even if this is not published, just to agree common text. Mo: I think the framework will be needed to compare. Harald A: If we want common terminology that we have to agree this. Mo & Zahed: I could edit. Xiaoqin Zhu: ??? Michael Ramahlo: We need to pin down the framework and terminology. Gorry: I suggest the WG tries to start with a short I-D that may not even be adopted (or published), but then could allow the text to be copied into the draft. Chairs: Please propose some common terminology. Wireless Test Case (Zahed) --- No comments/questions Coupled congestion control with RTP (Safiqul Islam) draft-welzl-rmcat-coupled-cc-05 (milestone group-cc) --- Zahed: I like the use of the test case. Did all the streams have the same priority? Safiqul: They did have the same priority. We can provide priority results at the next IETF. Zahed: It would be nice to look at mismatches in the encoding rate and give insight on what happens when the codec does not behave (exceeds what is asked for). Michael Welzl: Encoder not using the rate is the start/stop test case. If we need another test case, then please ask. Zahed: I am suggesting not to use the CBR traffic for evaluation. Chairs: Please discuss the test cases on the list. Chairs: Is this ready for adoption? Zahed: I am unsure about prioritisation status. Karen (at Mic): If we adopt this draft then we adopt this solution, but not the scheduling approach. Michael: The scheduling part is something that could be described, we can describe the pros and cons in the next document. Karen (at mic): Are you saying your solution would have the same behaviour if you do scheduling. Zahed: Why is there one flow stated? Michael: This is not quite the same. Chairs: Is there an option to move the scheduling to an appendix? Zahed: My concern is that we have not studies these results. How does it work, move it to the appendix and then bring it back to the body? We do not seem to have 2 competing ideas. If someone uses SCREAM they may already have scheduling. Is there a question about whether we use one solution or another? Mirja: I agree with Micheal that is not super interesting to evaluate this approach (scheduling) because it's straight-forward. Karen (at mic): When you do coupled congestion control by means of implementing priorities between the stream, the behavior that you get depend very much on how you specify the priority to be chosen. The specification between streams seems to change the way. Mirja: The alternative approach of just specifying different priorities and then use a common congestion control is juts an idea in the draft. Karen: I think you get a different behaviour when you use the two approaches: either priorities between different congestion controller, or you get a different behavior if you put different priorities into one common congestion controller. Two approaches give slightly different behavior. And I you have an interface to set priorities this may be different for the two approaches. Mirja: That's an interface question now? This could go into the interface draft. Karen (at mic): In the interface draft is does just say right now that there is a way to do elasticity, it doesn't doesn't specify priority. Right now the interface draft is more generic. And we have to see if the interaction draft stay's more general or if we explicitly describe how the interface looks like; and if we only have one coupled congestion as currently described in this draft, that it may just say that you have to set priorities. If we come up with a different coupled cc as described in scream we might come up with what the exact interface is. Mirja: I'm hearing you und that should be discussed but I don't think this must be discussed for the adoption of this document. Karen (at mic): Agree but stoll would like to understand what we adopt. Are we adopting a document that is describing only the mechanism that are described here or are we adopting a document that may eventually extended to describe multiple mechanisms for coupled congestion control? Or we might say that we adopt the current doc that described this one mechanism in detail and then we may later on decide to extend the doc. Mirja: Would like to propose that we adopt this as one candidate for coupled cc and that we would be able to adopt a different proposal if someone brings in another proposal. If that's the approach we should move the alternative scheduling approach to the appendix. Michael is nodding and agreeing with this. Gorry: Clarification what we are calling here: if there is consensus that this is the solution the wg wants to adopt for this approach. And then you say that there is an open agreement that there may be more approaches that may be added later that are different. Is that what you are saying? Because I'm not clear what the adoption call is Zahed: Same question: Not clear if it is general mechanism for coupled cc as we know it or coupled cc with NADA? Mirja: It's the concrete mechanism coupled cc with NADA. Zahed: You are saying that we possibly will have a different doc describing coupled cc with GCC if that's adopted and separate doc for coupled cc with Scream...? That's not what I recall from the last meeting. At the last meeting we said this document will have section for different approaches. Mirja: This is what we discussed with the authors after the last meeting. And the reason why we propose this approach (adoption call for the concrete proposal to use coupled cc with NADA) is because we had trouble to agree early because there have been not enough evaluation results and you can only provide evaluation results if you pick one congestion control. Varun: One more clarification question: would the process be if this expends to e.g. GCC, to expend the scope or there be a different doc? Mirja: As soon as this is under control of wg, the wg should decide. But if there are commonalities and coupled cc part is the same, it probably should be in the same doc, but should discuss this when we want to do it Varun: FEC should do the same process Xiaoqin Zhu: To authors: If we see more results on NADA and GCC, how easy is it to extend the doc, as there is already section? Safiqul: no more work, simple considerations Mirja: It not hard to write the section for another cc but you need to do the evaluation as well to show that it still works. That's why we try to treat this separately Zahed: Are we saying that you want to (ask for) adoption for this proposal to specify this for NADA? But I don't get the feeling from the draft Michael: This is for NADA - it says this in the abstract. Mirja: The adoption call is for a mechanism for coupled congestion control with NADA. If ou think the doc doesn't reflect this, we can still adopt this and you should review and say what need to be changed. Zahed: What about the other scheduling approaches in scream? We leave it in scream or we propose as an alternative? Karen: I think scream's approach needs to be further described and allow the document to either be updated or to a separate draft. Both is possible, we have to see later and discuss when it has been proven to work. Karen: Ask Michael to put scheduling in appendix because we need description and more discussion before we know what to do with it. Michael Ramahlo: Agree with what Karen just said. I see it is clearly in scope for the charter. But if you say this is specific for NADA, we also need one for scream and one for GCC, so you have the the N-squared problem. This call should be on this doc as a basi and not just on NADA. Mirja: We don't need an own doc for each candidate. Need to decided as a wg. Karen: I think we can adopt this a one mechanism that is proven to work with NADA and hopefully can extend this but we have to see. Chairs: With this clarification we will make a call adoption to adopt this document with the comment that the scheduling will be moved to the appendix. Michael: Only three sentences... Chairs: Please hum if you support adoption: [Some hums for adoption; no clear if any hums against]. Chairs: Please hum if you are against this approach: [No Hums] Update on GCC (Stefan Holmer) draft-alvestrand-rmcat-congestion-03 (milestone cc-cand) --- Chairs: We saw promising results yesterday that suggest this is ready. -: I was not there. What was discussed yesterday? Mirja: They compared GCC with NADA. I think this is a reasonable way to move forward. Chairs: The chairs would like to know if this should be adopted. [Hums for few; Hums against none]. Update on NADA (Xiaoqing Zhu) draft-ietf-rmcat-nada-00 (milestone cc-cand) --- Xiaoqing Zhu: We’d be interested in implementation feedback from people reading the draft. Chairs: Please send comments to the list and update the draft. Chairs: Who is willing to review? Stefan Holmer Zahed Sarker Anurag Bhargava WiFi test cases (Xiaoqing Zhu) draft-fu-rmcat-wifi-test-case-01 (milestone eval-criteria) --- Chairs: Please send comments to the mailing list. Mirja: I believe the plan is to merge this into the wireless test case doc? Xiaoqing Zhu: Can we ask if this can become a working group item, with the potential to merged it with the cellular case? Mirja: Why can't you just merge it right now? xiaoqing: We are fine with that. Zahed: It would be nice try it our more, that only a first version. It's up to the wg to decided Mirja: It's a starting point; we still can change it in the wg. If you think this is a good starting point and we should try it out, then I think this text belongs in the WG document. Zahed: If you think it's ready to incorporate, let me know. I have not tried it. Varun: We saw results that were very promising. I would suggest integrating it. It gooc to converenge. Michael Ramahlo: I don't have objections in merging it, but there are somehow orthogonal. Numbering, terminology, taxonomy is all different. So I could also see a cellular doc and a wifi doc. It's whatever the group want to do. Mirja: Wireless test case doc already have a section for wifi. Zahed: Wireless test case was adopted as a single doc for radio and wifi. Mirja: We made this decision already last time. Zahed: Yes, exactly. Varun: I think it's good to move forward and if there are problem with the terminology, the author can resolve this. Mirja: Should everything be merge or just those that are tested? Is there something that should not be merged? Varun: The ones we saw results for are very promising, and I don't see any point to hold back merging them. Maybe also some easy ones could be moved forward. Xiaoqing: Which should we merge now? Just copy and paste? Zahed: We can merge, but I have not tried these things, so I do not know what should be changed or is not working. But we can also make those changes as part of the wg doc. See no point of holding them back. Chairs: Please sit together and decided what you want to merge. Then copy and paste the text. Varun: Clarification: Does 802.11g needs to be there, or just say these scenarios have wireless and 802.11g as implemented in ns-3 seems to work. Xiaoqing: Yes, draft explain this and 802.11g is an example. Modeling Video Traffic Sources for RMCAT Evaluations (Sergio Mena de la Cruz) draft-zhu-rmcat-video-traffic-source-02 (milestone eval-criteria) --- Mirja: No time for comments. Chairs: How many people have read the draft? [4 people had read the draft] Chairs: Please read the document and discuss on the mailing list. Shared Bottleneck Detection for Coupled Congestion Control for RTP Media (David Hayes) draft-ietf-rmcat-sbd-00 (milestone group-cc) --- Matt Mathis: There is work in IPPM that talked about this? Brian Tramell (as IPPM Chair): We should send a note to the list saying this isn’t useful for this use case. It would be interesting to know if the IPPM metrics match those from this draft. Matt: Yes I see this as a lightweight approach and you may like to quantify the differences. Chairs: What are the next steps? David: We are going to revise.