[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: