Minutes for RMCAT at IETF-93
minutes-93-rmcat-2

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.