Subject: [rmcat] First meeting

From: Mirja Kühlewind <[email-masked]>
Date: Tue, 2 Oct 2012 18:09:19 +0200

Dear working group!

We are about to plan our first meeting in Atlanta. We will have a 2 hour time 
slot. Time and date are not announced yet but will be this week.

Our first milestones include the following items:

 * Draft of requirements

 * Draft of evaluation criteria

* Draft of RTCP extensions and interaction with applications/RTP flow (if 
needed)

Please let us know if you are working on a draft that will address one of 
these items and if you are planing to present this work at the next meeting.

Especially everyone who is working on a proposal for a congestion control 
algorithm, we would like to encourage to evaluate your own proposal (against 
other proposals) and contribute to the evaluation criteria draft. We would 
like to see sufficient discussion on each proposed algorithm on the mailing 
list before discussing the proposal at a meeting or even adopting a proposal 
as working group item. That also means that drafts describing a proposal in 
detail should be submitted early enough in advance of a meeting. 

See you in Atlanta!
Mirja

---

From: Michael Welzl <[email-masked]>
Date: Wed, 3 Oct 2012 13:14:41 +0200

Hi!

A comment / clarification below...

> * Draft of RTCP extensions and interaction with applications/RTP flow (if 

About the "interaction with applications" bit: there was, I think, general agreement pre-BOF / at the BOF that we need to some more information than now to be exchanged between applications (i.e. the codec, I think) and the transport (i.e. RTP/UDP). Some interesting thoughts on that are in the cc workshop's paper 19, for example: http://www.iab.org/activities/workshops/cc-workshop/papers/

One particular point that there seemed to be agreement on is that packets will have different value to an application, and these priorities should be specified to the transport to enable better mechanisms at that level.

So this is, essentially about the API between applications and transport. Unsurprisingly, the word "API" caused some trouble, which I resolved by rewording it into "interactions". Indeed we don't want to specify an API, but still, what type of information is exchanged at that, well, interface. I guess getting this right requires quite a bit of discussion...

I'm interested in this and volunteer to participate in document writing. I'm probably not enough of an RTP expert to be the main author, though.

> _______________________________________________
> rmcat mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rmcat

Cheers,
Michael

---

From: "Eggert, Lars" <[email-masked]>
Date: Fri, 5 Oct 2012 13:50:42 +0000

Hi,

> slot. Time and date are not announced yet but will be this week.

our TENTATIVE slot is THURSDAY, November 8, 2012, 1300-1500 Afternoon Session I. This may still change.

The ID cutoff for new -00 drafts (which most of ours will be) is Oct 15. Please make sure your draft-yourname-rmcat-* is submitted by then.

Begin discussing drafts on the list as soon as they become available. Mirja and me will gauge the need for facetime in Atlanta based on whether list discussion indicated interest in a draft or topic.

Lars

---

From: "Eggert, Lars" <[email-masked]>
Date: Tue, 9 Oct 2012 11:58:24 +0000

Hi,

> The ID cutoff for new -00 drafts (which most of ours will be) is Oct 15. Please make sure your draft-yourname-rmcat-* is submitted by then.

and even if your draft is not submitted yet, please already send Mirja and me requests for agenda time, so we can start the planning process.

Thanks,
Lars

---

From: "Eggert, Lars" <[email-masked]>
Date: Fri, 12 Oct 2012 08:29:21 +0000

Hi,

On Oct 11, 2012, at 18:45, Xiaoqing Zhu <[email-masked]> wrote:
> My colleague and I are working on a congestion control scheme for
> real-time conferencing applications at Cisco. A brief version of that
> algorithm was presented at the IAB Workshop in Vancouver (paper #12,
> "Network-Assisted Dynamic Adaptation (NADA): A Design Summary"). Due
> to time constraints, however, we did not get a chance to mention the
> delay-based variant of that scheme, which may be a better fit for
> rmcat.
> 
> We would like to request for a slot to present in Atlanta. We will
> also submit the ID draft before Oct 15, for further discussions on
> this mailing list.

I look forward to seeing the draft being discussed on the list!

Also, I'm noting your request for a slot. Because the actual CC mechanisms are not our most pressing milestones initially - the requirements and eval criteria are - we may decide to focus our meeting time on those other drafts, if demand for agenda time is high. 

Lars

---

From: "Xiaoqing Zhu (xiaoqzhu)" <[email-masked]>
Date: Fri, 12 Oct 2012 18:42:34 +0000

Hi Lars, 

Thanks a lot for your prompt response.  Fully agree with the chosen priorities for the topics 
to be discussed in the meeting.  I'll keep you posted once the draft is submitted. 

Best,
Xiaoqing

---

From: "Xiaoqing Zhu (xiaoqzhu)" <[email-masked]>
Date: Mon, 15 Oct 2012 21:43:59 +0000

And below is the notification of our submission:

Thanks,
Xiaoqing

--------------------------------------
A new version of I-D, draft-zhu-rmcat-nada-00.txt
has been successfully submitted by Xiaoqing Zhu and posted to the
IETF repository.

Filename:  draft-zhu-rmcat-nada
Revision:  00
Title:  NADA: A Unified Congestion Control Scheme for Real-Time Media
Creation date:  2012-10-14
WG ID:  Individual Submission
Number of pages: 10
URL:             http://www.ietf.org/internet-drafts/draft-zhu-rmcat-nada-00.txt
Status:          http://datatracker.ietf.org/doc/draft-zhu-rmcat-nada
Htmlized:        http://tools.ietf.org/html/draft-zhu-rmcat-nada-00

Abstract:
  This document describes a scheme named network-assisted dynamic
  adaptation (NADA), a novel congestion control approach for
  interactive real-time media applications, such as video conferencing.
  In the proposed scheme, the sender regulates its sending rate based
  on either implicit or explicit congestion signaling, in a unified
  approach. The scheme can reap the benefits of explicit congestion
  notification markings from network nodes. It also maintains
  consistent sender behavior in the absence of such markings, by
  reacting to queuing delays instead.

  We present here the overall system architecture, recommended
  behaviors at the sender and the receiver, as well as expected network
  nodes operations. Results from extensive simulation studies of the
  proposed scheme are available upon request.

The IETF Secretariat
--------------------------------------
On Oct 12, 2012, at 1:29 AM, Eggert, Lars wrote:

Hi,

On Oct 11, 2012, at 18:45, Xiaoqing Zhu <[email-masked]<mailto:[email-masked]>> wrote:

Lars

---

From: Michael Welzl <[email-masked]>
Date: Tue, 16 Oct 2012 10:11:32 +0200

Hi,

I took a quick look at this:

I like the general idea of using as much as possible of existing network support - but I'm critical about the actual control you propose.

In section 5.3.2, you suggest to replace eqn. 1 from section 5.3 with eqn. 2 when ECN feedback is available. This means to ignore a delay signal from now on, and interpret ECN marks in the exact same way as you interpreted delay before - this is too simplistic, I think. After all, ECN marks require a queue to grow, and this group intends to minimize delay... why would you stop using delay once you have ECN in addition?

In practice, using your scheme would probably mean that, as soon as I enable RED with ECN on the bottleneck between the two end systems, the users' observed delay grows. Not exactly an incentive?

Cheers,
Michael

---

From: Piers O'Hanlon <[email-masked]>
Date: Tue, 16 Oct 2012 09:54:39 +0100

Hi,

I too had a quick look at the proposal.

I was interested as to how kappa is calculated in equation (1) or whether it is a fixed value?

Also your slow start algorithm only seems to be time dependent - literally it appears to start slowly from t_0 to some preset time (T) - is there any mechanism to terminate slow start on loss/marked packets? Does slow start ever occur mid stream? (e.g. after a silence period?)

Out of interest it was mentioned that there were extensive simulation studies - would it be possible to post a simulation of multiple NADA flows competing. And also a competition of NADA with a TCP flow?

Thanks,

Piers.

---

From: "Xiaoqing Zhu (xiaoqzhu)" <[email-masked]>
Date: Wed, 17 Oct 2012 04:58:36 +0000

Hi Michael,

Thanks for your comments.  Please find my replies inline below.

Best,
Xiaoqing

On Oct 16, 2012, at 1:11 AM, Michael Welzl wrote:

Hi,

In our design, we considered the two cases, with or without ECN markings, separately.  Therefore, the dynamic scenario when ECN becomes available in the middle of a video conferencing session has not yet been fully studied.  Just wondering, are cases where ECN marking are turned on and off dynamically common in reality?

What you mentioned (uers observing higher delay in ECN-enabled systems) will not happen.

But rather, our simulation results have indicated that ECN with RED-based marking yields fairly similar results as the default delay-based scheme. They certainly do not incur higher delay, since the endpoint will automatically back off in face of higher ECN markings, which are indications of higher delay. The two systems (delay-based and ECN-based) can be tuned to stabilize that the same queuing delay at the bottleneck.

Cheers,
Michael

Thanks,
Xiaoqing

Abstract:

The IETF Secretariat

Hi,

Lars

---

From: "Xiaoqing Zhu (xiaoqzhu)" <[email-masked]>
Date: Wed, 17 Oct 2012 05:04:56 +0000

Hi,

On Oct 16, 2012, at 1:54 AM, Piers O'Hanlon wrote:

Hi,

The scaling values, kappa for (1) and eta for (2) are fixed values at the video conferencing endpoint during any session.  The system typically works with a range of values for kappa and eta, leading to the same steady-state behavior, but with different dynamics during transients.

Good point.  Right now slow start only works at the beginning of the stream. The rationale being that when a stream has not yet gathered enough congestion information (implicit or explicit) from the network, it rather stay on the cautious side.  Note that the sending rate is chosen to be the minimum of slow-start rate R_ss and congestion-based rate R_o, so if excessive congestion has been observed initially, the sender will still back off.

We haven't yet looked into the case whether slow start is needed mid-stream.  Open for comments/suggestions in this aspect.

Thanks for the suggestions.  I'll try to compile a set of representative results on multiple self-competing NADA streams to share over this mailing list.  Some modifications are need to make NADA compete fairly with loss-based TCP, we are still working on that.

Thanks,

Piers.

Thanks,
Xiaoqing

Abstract:

The IETF Secretariat

Hi,

Lars

---

From: Michael Welzl <[email-masked]>
Date: Wed, 17 Oct 2012 09:31:59 +0200

> In our design, we considered the two cases, with or without ECN markings, separately.  Therefore, the dynamic scenario when ECN becomes available in the middle of a video conferencing session has n…

First, anything can happen when you have a routing change.
Second, I'm really sorry, but this wasn't what I meant. I shouldn't have written "when" but "if". I wasn't referring to a case where we go from no-ECN-support to ECN-support. So this is about the ECN-always-supported case.

> But rather, our simulation results have indicated that ECN with RED-based marking yields fairly similar results as the default delay-based scheme. They certainly do not incur higher delay, since th…

Whether you see significant delay before you see a large enough amount of ECN markings depends on the queue length and RED parameters, none of which are under the end system's control. ECN is also a probabilistic signal, so sometimes you may get delay growth but just be lucky (or unlucky) enough to not get an ECN mark.

So, I'd have to see results that involve various RED settings and queue lengths before I believe that.

Cheers,
Michael

---

From: "Xiaoqing Zhu (xiaoqzhu)" <[email-masked]>
Date: Thu, 18 Oct 2012 03:49:38 +0000

Your points are well taken, Michael.  

Agree that ultimately, it would be nice to have the scheme consider a merge of delay and ECN signals, instead of switching naively between the two. We considered that as a stretch goal though, according to the priorities discussed in the last BOF. We are still in the process of improving the algorithm in that aspect. 

I will put in some results from ECN-based marking in the compiled file to share. But admitted, we have not yet explored the impact of all variations of ECN configurations.  I will need to run more tests for that. 

-Xiaoqing

---

From: Michael Welzl <[email-masked]>
Date: Wed, 24 Oct 2012 16:22:18 +0200

Actually...

It just occurred to me that the dynamic scenario (going from ECN-supported to non-ECN-supported) is also quite realistic.
Consider a situation where you traverse two routers: router 1, followed by router 2. Router 1 isn't usually your bottleneck, but it supports ECN. Router 2 doesn't support ECN, but is your bottleneck most of the time.

Now, if a sudden traffic burst causes the queue of router 1 to grow, you will start to believe that there is ECN support, and stop using delay. But then, this queue might never grow again, all the congestion could happen in router 2...

My point is, *relying* on ECN to be there no matter how much feedback you get is probably always the wrong thing to do. We can always only take it as a nice extra if its available, but I think we should never "switch to ECN mode".

Cheers,
Michael

---

From: Michael Welzl <[email-masked]>
Date: Thu, 25 Oct 2012 08:45:13 +0200

Hi,

On 25. okt. 2012, at 02:20, Xiaoqing Zhu wrote:

> Michael, 
> 
> In general, I agree with you that we need a more graceful scheme to accommodate both implicit and explicit congestion signals. Our current -00 draft obviously does not solve that yet.  I'll add this important point to the "open issue" section of the draft, and also strive to find a solution for that.  

Sure, I think we had already agreed, I just wanted to share this scenario that came to my mind.

> However, I am not sure the dynamic scenario you describe will happen. If a packet passes along both ECN-supported and non-ECN-supported routers, wouldn't the ECN field bits in its header be marked as '00' (not ECN-capable), as specified in RFC 3168?  In that case, even if congestion rises on the ECN-enabled route, the sender will still be reacting to the rise in observed delay. 

RFC 3168 is long and it's been a while since the last time I read it, but: I can't recall reading what you describe here.
My understanding of ECN (in a nutshell) is: ECN-capable end hosts sent 01 or 10; ECN-incapable routers might not react to ECN at all, so anyway you can't trust them to do something based on RFC 3168 if they don't implement RFC 3168  :-)    ; if an ECN-capable router sees a 01 or 10 packet, it may mark it to 11; if an ECN-capable router sees a 00 packet, it drops it instead of marking it.

So, no way to reliably determine if there are some routers that do *not* support ECN.

> Also, my understanding from the previous email threads on this mailing list seems to say that multi-hop congested links are hard scenarios to tackle anyway.  Do you think we should focus on that now, or defer it after we obtain some satisfactory results from the simpler case of single-congested link? 

As I tried to explain in my earlier email about that:
http://www.ietf.org/mail-archive/web/rmcat/current/msg00069.html
this was about multiple hops in the overlay - multiple RTP end systems attached to each other, to form a longer path, if you will. The underlay can always have more than just one hop.

Cheers,
Michael

> 
> Thanks,
> Xiaoqing
> 
> 
> On Wed, Oct 24, 2012 at 7:22 AM, Michael Welzl <[email-masked]> wrote:
> Actually...
>

---

From: Stefan Holmer <[email-masked]>
Date: Mon, 29 Oct 2012 15:05:52 +0100

Hi Xiaoqing,

Interesting draft, I have a few questions related to the queuing delay part
of it.

"The role of the receiver is fairly straightforward. It observes and
estimates end-to-end queuing delay d and ECN marking ratio p of the stream.
The former can be obtained from the RTP timestamp provided by the sender."

You don't provide much detail on how the end-to-end queuing delay is
estimated from the timestamps. Would it be possible to be more specific?
Are you employing a filter? Related to that, you seem to be running into a
divide by zero in equation 1 if your queuing delay turns out to be zero. It
also seems a bit bold to go directly from R_min to R_max if the queuing
delay is low enough.

/Stefan

On Mon, Oct 15, 2012 at 11:43 PM, Xiaoqing Zhu (xiaoqzhu) <
[email-masked]> wrote:

> URL:
> http://www.ietf.org/internet-drafts/draft-zhu-rmcat-nada-00.txt
> Also, I'm noting your request for a slot. Because the actual CC mechanisms
> are not our most pressing milestones initially - the requirements and eval
> criteria are - we may decide to focus our meeting time on those other
> drafts, if demand for agenda time is high.
>
> Lars
>
>
>

---

From: "Xiaoqing Zhu (xiaoqzhu)" <[email-masked]>
Date: Mon, 29 Oct 2012 14:53:19 +0000

Hi Stefan,

Thanks a lot for your comments. I'll add in more details on the description for the receiver actions.

You are right, we did employ some filtering of the observed per-packet queuing delay, to avoid erratic reactions in the sending rate. The queuing delay employed in the rate calculation in Eq. (1) is actually the time-smoothed averaging d_avg:

d_avg = (1-alpha)*d_avg + d_n, where d_n represents the measured queuing delay  (end-to-end delay minus minimum observed value) for the n-th packet. The parameter alpha adjusts the level of smoothness in our average process. In our experiments, we are using alpha = 10e-4.

Also, it's obvious that Eq.(1) wouldn't hold for for d=0, in which case the rate is chosen to be R_max.  As mentioned in the paragraph below Eq. (1), any calculated target rate R_o greater than R_max will also be clipped to the R_max.

Initially, I omitted these details in the draft proposal for brevity. Given your comments and concerns, looks like I'd better put them back in for clarity.

Best,
Xiaoqing

On Oct 29, 2012, at 9:05 AM, Stefan Holmer wrote:

Hi Xiaoqing,

Interesting draft, I have a few questions related to the queuing delay part of it.

"The role of the receiver is fairly straightforward. It observes and estimates end-to-end queuing delay d and ECN marking ratio p of the stream. The former can be obtained from the RTP timestamp provided by the sender."

You don't provide much detail on how the end-to-end queuing delay is estimated from the timestamps. Would it be possible to be more specific? Are you employing a filter? Related to that, you seem to be running into a divide by zero in equation 1 if your queuing delay turns out to be zero. It also seems a bit bold to go directly from R_min to R_max if the queuing delay is low enough.

/Stefan

On Mon, Oct 15, 2012 at 11:43 PM, Xiaoqing Zhu (xiaoqzhu) <[email-masked]<mailto:[email-masked]>> wrote:
And below is the notification of our submission:

Thanks,
Xiaoqing

Abstract:

The IETF Secretariat

Hi,

Lars

---

From: Stefan Holmer <[email-masked]>
Date: Mon, 29 Oct 2012 16:23:33 +0100

On Mon, Oct 29, 2012 at 3:53 PM, Xiaoqing Zhu (xiaoqzhu) <[email-masked]
> wrote:

>  You are right, we did employ some filtering of the observed per-packet
> queuing delay, to avoid erratic reactions in the sending rate. The queuing
> delay employed in the rate calculation in Eq. (1) is actually the
> time-smoothed averaging d_avg:
>
>  d_avg = (1-alpha)*d_avg + d_n, where d_n represents the measured queuing
> delay  (end-to-end delay minus minimum observed value) for the n-th packet.
> The parameter alpha adjusts the level of smoothness in our average process.
> In our experiments, we are using alpha = 10e-4.
>

Thanks. Just to be clear,

d_n = receiver_time_n - timestamp_n - min_observed

and min_observed is the smallest d_n seen in some window?

>
>  Also, it's obvious that Eq.(1) wouldn't hold for for d=0, in which case
> the rate is chosen to be R_max.  As mentioned in the paragraph below Eq.
> (1), any calculated target rate R_o greater than R_max will also be clipped
> to the R_max.
>
>  Initially, I omitted these details in the draft proposal for brevity.
> Given your comments and concerns, looks like I'd better put them back in
> for clarity.
>
>  Best,
> Xiaoqing
>
>
>> Also, I'm noting your request for a slot. Because the actual CC
>> mechanisms are not our most pressing milestones initially - the
>> requirements and eval criteria are - we may decide to focus our meeting
>> time on those other drafts, if demand for agenda time is high.
>>
>> Lars
>>
>>
>>
>
>

---

From: "Xiaoqing Zhu (xiaoqzhu)" <[email-masked]>
Date: Mon, 29 Oct 2012 15:28:20 +0000

On Oct 29, 2012, at 10:23 AM, Stefan Holmer wrote:

On Mon, Oct 29, 2012 at 3:53 PM, Xiaoqing Zhu (xiaoqzhu) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Stefan,

That's right.  BTW, while the time-averaged filtering works well for us, for now, we are also considering building in more robustness against individual bad samples. The Kalman filtering approach presented in your proposal seems to be a good candidate for that. Maybe there is a way to incorporate that approach here for the delay estimation as well.  What do you think?

Best,
Xiaoqing

Hi Xiaoqing,

/Stefan

Thanks,
Xiaoqing

Abstract:

The IETF Secretariat

Hi,

Lars

---

From: "Xiaoqing Zhu (xiaoqzhu)" <[email-masked]>
Date: Mon, 29 Oct 2012 18:26:02 +0000

Ah, okay.  Thanks a lot for the clarification for the multi-hop scenario.

In that case I will only worry about the scenario where ECN-capable and ECN-incapable routers co-exist on the same path.

-Xiaoqing

On Oct 25, 2012, at 1:45 AM, Michael Welzl wrote:

Hi,

Michael,

Cheers,
Michael

Thanks,
Xiaoqing

On Wed, Oct 24, 2012 at 7:22 AM, Michael Welzl <[email-masked]<mailto:[email-masked]>> wrote:
Actually...

Cheers,
Michael

---

From: Piers O'Hanlon <[email-masked]>
Date: Tue, 30 Oct 2012 10:08:39 +0000

Hi,

Presumably by time-smooth average you mean EWMA - so you're missing an alpha?

> d_avg = (1-alpha)*d_avg + d_n

Should be:  d_avg = (1-alpha)*d_avg + alpha*d_n

Piers.

On 29 Oct 2012, at 15:28, Xiaoqing Zhu (xiaoqzhu) wrote:

>> On Mon, Oct 29, 2012 at 3:53 PM, Xiaoqing Zhu (xiaoqzhu) <[email-masked]> wrote:
>> Hi Stefan, 
>> 
>>> On Mon, Oct 15, 2012 at 11:43 PM, Xiaoqing Zhu (xiaoqzhu) <[email-masked]> wrote:

---

From: Stefan Holmer <[email-masked]>
Date: Tue, 30 Oct 2012 12:22:00 +0100

On Mon, Oct 29, 2012 at 4:28 PM, Xiaoqing Zhu (xiaoqzhu) <[email-masked]

>>  d_avg = (1-alpha)*d_avg + d_n, where d_n represents the measured
>> queuing delay  (end-to-end delay minus minimum observed value) for the n-th
>> packet. The parameter alpha adjusts the level of smoothness in our average
>> process. In our experiments, we are using alpha = 10e-4.
>>
>
>  That's right.  BTW, while the time-averaged filtering works well for us,
> for now, we are also considering building in more robustness against
> individual bad samples. The Kalman filtering approach presented in your
> proposal seems to be a good candidate for that. Maybe there is a way to
> incorporate that approach here for the delay estimation as well.  What do
> you think?
>
>
That would be an option. Note that RRTCC isn't based on one-way delay
estimates but on inter-arrival time, which is changes in one-way delay.

---

From: "Xiaoqing Zhu (xiaoqzhu)" <[email-masked]>
Date: Tue, 30 Oct 2012 14:36:10 +0000

Oops. Sorry about the typo.  Yes, there is the alpha for the second term.

Best,
Xiaoqing

On Oct 30, 2012, at 5:08 AM, Piers O'Hanlon wrote:

Hi,

Piers.

Best,
Xiaoqing

Hi Xiaoqing,

/Stefan

Thanks,
Xiaoqing

Abstract:

The IETF Secretariat

Hi,

Lars