Subject: [rmcat] wanted: minute taker and jabber scribe

From: "Eggert, Lars" <[email-masked]>
Date: Tue, 5 Nov 2013 19:15:37 +0000

Hi,

I'd like to ask for volunteers to act as minute takers and jabber scribes for the meeting this week. Please volunteer!

For the minutes, I'd suggest we use the Etherpad at http://tools.ietf.org/wg/rmcat/minutes for collaborative editing. This has the advantage that people can contribute to it during the session and after, in a way that leaves us with one consolidated set of minutes in the end. I'd still like one identified minute taker, however, others are free in helping out by adding to and correcting the Etherpad.

Lars

---

From: "Eggert, Lars" <[email-masked]>
Date: Thu, 7 Nov 2013 02:16:51 +0000

Hi,

thank you Gorry! for taking minutes today.

Everyone: please go to the Etherpad at http://tools.ietf.org/wg/rmcat/minutes and check and correct the minutes. Especially if you presented or spoke at a microphone.

Thanks,
Lars

---

From: Varun Singh <[email-masked]>
Date: Fri, 8 Nov 2013 18:59:59 -0800

Hi all,

Meeting notes from the traffic model session are attached within.
Thank you Colin for the taking the notes.
if something is not documented or incorrect, please send me the corrections.

Cheers,
Varun

-- 
http://www.netlab.tkk.fi/~varun/

---

From: "Eggert, Lars" <[email-masked]>
Date: Thu, 14 Nov 2013 15:08:22 +0000

Some of you have made edits - thanks!

There are still quite a few unattributed comments in the minutes. So if you spoke at the microphone, please check that your name appears where it should, and check that your question/answer was correctly captured.

---

From: Dave Taht <[email-masked]>
Date: Thu, 14 Nov 2013 09:02:55 -0800

> There are still quite a few unattributed comments in the minutes. So if you spoke at the microphone, please check that your name appears where it should, and check that your question/answer was cor…

I am not really sure if the various points regarding the differences
in congestion response between audio, video, and data flows made at
the mic are completely represented, starting here:

"D Taht: I think audio and video have different properties."

I know that what I was going through in my head at the ensuing coupled
congestion discussion is different than what is up here (but I'm
pretty sure I was merely mentally talking to myself) but since this
thread is about the minutes and not the concepts, I'll stop, and hope
the other participants elucidate what they said.

I would like however to talk about those flow types at length at some
future point,
but not in comments on the minutes!

-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

---

From: Michael Welzl <[email-masked]>
Date: Fri, 15 Nov 2013 14:34:07 +0100

Hi,

Below:

> the other participants elucidate what they said.

I think the minutes are correct in capturing what was said (else feel free to fix them), but I'm happy to have the conversation here, based on what your thoughts really were.

So, what I got from you (and from James who went to the mic after you) is a concern that different types of traffic have different characteristics, and hence controlling them together may not be the right thing to do.
Please correct me if I'm wrong! This was my impression of the concern and my interpretation of what was said.

Assuming that this is indeed the concern, here is my answer is: this is meant to work over a single combined bottleneck, i.e. a single queue. The required behavior for rmcat traffic is low delay, while of course trying to saturate the bottleneck as good as possible at the same time (and working reasonably well with TCP if possible). Low delay is an overarching requirement for everything, really - e.g., if you 1 interactive audio flow and 1 data stream that doesn't care much about delay, you're better off trying to avoid delay or the audio flow will suffer.

The next issue is then the fairness between the flows: how much of the bandwidth do they get? Again, different flows and different traffic types may have different priorities. Getting ideal fairness is the very point of this exercise - coupled congestion control gives us 100% control over the fairness, much better than what you get when you let them "fight it out" on the bottleneck link. Plus, we're trying to get even lower latency and loss as a result of combining the flows (but this is work in progress).

So my argument is that if done right, coupled congestion control will only be a good thing, wherever it can be applied, whatever the mix of traffic is (well, *in particular* when you have delay-sensitive traffic in the game).

Was that helpful?

Cheers,
Michael