[rmcat] RMCAT - RAW NOTES
Gorry Fairhurst <gorry@erg.abdn.ac.uk> Mon, 20 July 2015 11:32 UTC
Return-Path: <gorry@erg.abdn.ac.uk>
X-Original-To: rmcat@ietfa.amsl.com
Delivered-To: rmcat@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92A111A1ADB for <rmcat@ietfa.amsl.com>; Mon, 20 Jul 2015 04:32:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.705
X-Spam-Level:
X-Spam-Status: No, score=-2.705 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GwdIwD636gSQ for <rmcat@ietfa.amsl.com>; Mon, 20 Jul 2015 04:32:03 -0700 (PDT)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 65F031A1A90 for <rmcat@ietf.org>; Mon, 20 Jul 2015 04:32:03 -0700 (PDT)
Received: from dhcp-9873.meeting.ietf.org (dhcp-9873.meeting.ietf.org [31.133.152.115]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 19AD71B00118 for <rmcat@ietf.org>; Mon, 20 Jul 2015 12:31:57 +0100 (BST)
Message-ID: <55ACDC2F.9030600@erg.abdn.ac.uk>
Date: Mon, 20 Jul 2015 13:31:59 +0200
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Organization: University of Aberdeen
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: rmcat@ietf.org
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/rmcat/rGIw43sFRtnNc1hKkZ405utBV-o>
Subject: [rmcat] RMCAT - RAW NOTES
X-BeenThere: rmcat@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: gorry@erg.abdn.ac.uk
List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." <rmcat.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rmcat>, <mailto:rmcat-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rmcat/>
List-Post: <mailto:rmcat@ietf.org>
List-Help: <mailto:rmcat-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rmcat>, <mailto:rmcat-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Jul 2015 11:32:06 -0000
Here are raw notes from the meeting today (as best I can) - Chairs please can you tidy and merge any other notes, Gorry --- 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 (authors) - Feedback appreciated - Requirements will be removed from this document. Mirja: There is also a TCP model from Mozilla for traffic with document size. 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 evaluation criteria. The question is whether this should be a separate draft because of the size? -: What do we do with video sequences? -: We could define a few video sources, and refer to the other draft for traces. Maybe pick slow and high motion cases? -: 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. Francesco: We can build a list of frame sizes output, and agree a codec. Chairs: Please discuss in the video source model presentation. Evaluation Tests 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. Volunteers to review the next version: ? 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. -: Agree Chairs: We need some evaluation of this. Can you do this anytime some? 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 other interactions, and some we have not explored. Ahed: What is the plan in RMCAT? How do I test? 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 seem 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 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. 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: 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: We do not seem to have 2 competing ideas. If someone uses SCREAM they may already have this. Is there a question about whether we use one solution or another? Mirja: I think this is not super useful. Karen: The specification between streams seems to change the way. Mirja: I think this is just two different ways. Karen: I think you get a different behaviour when you use the two approaches. Priorities can be different, Mirja: This could go into the interface draft. Karen: I think we have just one method, if we come up with a different approach then we will see the interface. Gorry: I do not know what the chairs are adopting. Has the WG agreed there is one approach and that we will put scheduling out of scope for this document, and then make other adoption calls for other drafts with other approaches? Mirja: This is what we discussed with the authors. The WG chairs made a decision after the last meeting to ask to adopt this. Xiaoqin Zhu: How easy is it to extend the approach? Zahed: Are we saying this is a proposal to just specify this for NADA? Michael: This is for NADA - it says this in the abstract. Mirja: We think we should adopt this just for NADA. Zahed: What about other approaches? Karen: I think SCREAM needs to also be described and allow the document to either be updated or to a separate draft. There may also be two different mechanisms that can be described in two separate drafts. Michael Ramahlo: I see it is in scope for the milestone. If we need to make a call today for acceptance, so we do not end up with a separate document for each of the candidates (N-squared documents]. Is the call just to adopt a solution for NADA? Mirja: I think we start with NADA. Karen: I think we can try to make new additions to the document for other schemes and see if this works. Chairs: I would like to see the adoption call for this draft as a basis for a WG version with the scheduling moved to the appendix. We suggest we adopt this. [Hums for some; Hums against few]. Chairs: Did we hear hums against? [No Hum] 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. Xiaoqing Zhu: Can we ask if this can become a working group item, that can be merged with the cellular case? Zahed: It would be nice try some alternatives, and find out a little more. I’d be interested in what the WG thinks. Mirja: I think this text belongs in the WG document. Zahed: I would like to know if this is ready to merge. Varun: I can see why it may be merged. I think the ones we saw yesterday were good. Michael Ramahlo: I see differences in the way these operate. I would like to know what the WG thinks. Mirja: Do you want to merge all of this into the document? Varun: The ones that are tested make sense. Zahed: We can merge, but I have not tried these things, so I do not know what you want me to do. Chairs: Please go ahead and merge this. 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. ---- Note:
- [rmcat] RMCAT - RAW NOTES Gorry Fairhurst