Subject: Re: [rmcat] NADA questions

From: Randell Jesup <[email-masked]>
Date: Sun, 03 Nov 2013 21:35:27 -0800

On 10/24/2013 9:42 AM, Piers O'Hanlon wrote:
> H
>
> 1) Whilst not explicitly laid out in the draft, from your presentation in RMCAT@IETF86, d_n = t_{r,n} - t_{s,n} - which I understood to mean that it was calculating the absolute one-way delay for each packet - which would imply that one would need synchronised clocks on the sender and receiver? Is that correct or was there an additional difference factor that I missed?
>
>> Your understanding is correct.  For now, we are using one-way delay as the baseline for congestion signal. We are aware of all the drawbacks and limitations associated with one-way delay measurements, and are planning to address those issues once we start playing around with a testbed setup. One tentative plan is to subtract out a minimum OWD and work with relative OWD instead, another option is to move the per-packet statistical handling to the sender instead, and use RTT in lieu of OWD.  Yet another measure could be to employ a separate mechanism for clock synchronization between sender and receiver. We are, of course, also open to suggestions on that matter.
>>
> Ok. Yes it would be nice to have a scheme that doesn't rely on absolute OWD, though there are some environments where one could expect synchronised clocks.

I think it's more than nice to not rely on synchronized clocks; I think 
we absolutely have to work with non-synchronized clocks as the default, 
or include within this scheme a way to (sufficiently) synchronize the 
clocks - or prove that non-synchronized clocks don't cause a problem, 
even if they're sub-optimal.

>>> 2) On a related issue in Section "6.3 Reference rate calculator" in equation (2) it seems that the selection of x_ref is dependent upon knowledge of the absolute one-way delay?
>> The rationale of choose x_ref to be the value of absolute one-way delay (basically, propagation delay along the path) is that ideally, we would want the video stream to reach the highest possible rate when the queue stays is empty, e.g., when bottleneck link rate exceeds r_max of video. In practice, the stream can simply set x_ref as the minimum OWD it has observed so far.
>>
> ok - though it might also be useful to have some sort of mechanism to accommodate path changes in the setting of x_ref.

Right - the problem is that accommodating path changes means in some 
manner aging-out the minimum OWD observed, and that can lead to 
delay-pumping (we start seeing delay we're inducing as part of OWD).  I 
believe this was shown in simulation at least for LEDBAT.

-- 
Randell Jesup
[email-masked]

---

From: Michael Welzl <[email-masked]>
Date: Mon, 4 Nov 2013 05:42:44 -0800

On 3. nov. 2013, at 21:35, Randell Jesup <[email-masked]> wrote:

> I think it's more than nice to not rely on synchronized clocks; I think we absolutely have to work with non-synchronized clocks as the default, or include within this scheme a way to (sufficiently) synchronize the clocks - or prove that non-synchronized clocks don't cause a problem, even if they're sub-optimal.

I don't get that. Any congestion control scheme will only use OWD as a congestion indicator, which means that the absolute OWD value isn't really what counts - it's about changes in the OWD. This, again, means that non-synchronized clocks produce a wrong absolute value, but noone cares. This is how LEDBAT works with OWD; clock drift is another issue, but perhaps not such a big deal; IIRC it's also addressed in LEDBAT in some way.

> Right - the problem is that accommodating path changes means in some manner aging-out the minimum OWD observed, and that can lead to delay-pumping (we start seeing delay we're inducing as part of OWD).  I believe this was shown in simulation at least for LEDBAT.

Both in simulation and with real-life tests. Here:
http://ieeexplore.ieee.org/xpl/articleDetails.jsp?tp=&arnumber=6496997&queryText=assessing+ledbat's+delay+impact

But this would be easy to fix: just don't send a lot while you update your base delay. LEDBAT keeps sending, and so it keeps measuring itself.

Summarizing, I don't see a problem with using OWD.
Cheers,
Michael

---

From: Piers O'Hanlon <[email-masked]>
Date: Mon, 4 Nov 2013 14:25:01 +0000

> I don't get that. Any congestion control scheme will only use OWD as a congestion indicator, which means that the absolute OWD value isn't really what counts - it's about changes in the OWD. This,…
The issue with NADA is that it does not use the OWD difference - it uses the absolute OWD.

I think LEDBAT essentially references the NTP RFC which says that clock drift isn't a big issue in the time scales that LEDBAT would be operating. Though that does depend on speed at which LEDBAT is running - Not sure how well it'll work at 10Gb/s?

> Summarizing, I don't see a problem with using OWD.

Agree - If it used as the basis for calculating the OWD difference.

Piers

---

From: Michael Welzl <[email-masked]>
Date: Mon, 4 Nov 2013 06:28:35 -0800

> The issue with NADA is that it does not use the OWD difference - it uses the absolute OWD.

...but that obviously makes no sense and should just be fixed. And it shouldn't be too hard to fix.

Cheers,
Michael

---

From: Piers O'Hanlon <[email-masked]>
Date: Mon, 4 Nov 2013 14:34:22 +0000

> ...but that obviously makes no sense and should just be fixed. And it shouldn't be too hard to fix.
Sure - though the current algorithm would need to be largely rewritten for it operate using OWD difference. This is why the question first occurred to me when I looked over the draft in more detail.

I presume they have use cases for NADA in some controlled environments...

Cheers,

Piers.

---

From: "Xiaoqing Zhu (xiaoqzhu)" <[email-masked]>
Date: Mon, 4 Nov 2013 16:04:08 +0000

Folks:

We hear you about the potential issues regarding using absolute
OWD as a congestion metric. Agree.  Special thanks to Piers who
first pointed this out.

I also tend to think along with Michael Welzl that it should be
relatively easy to fix by using a relative OWD instead.  Just that
we are deferring this change until we can try it out in a real test-bed.
This is one aspect of a CC solution where simulation-based studies
won’t help much.

So, yes, please stay tuned for an update ...

Best,
Xiaoqing

On Nov 4, 2013, at 8:34 AM, Piers O'Hanlon <[email-masked]<mailto:[email-masked]>> wrote:

On 4. nov. 2013, at 06:25, Piers O'Hanlon <[email-masked]<mailto:[email-masked]>> wrote:

On 3. nov. 2013, at 21:35, Randell Jesup <[email-masked]<mailto:[email-masked]>> wrote:

Cheers,

Piers.

Cheers,
Michael

---

From: Michael Welzl <[email-masked]>
Date: Tue, 5 Nov 2013 10:44:35 -0800

As a follow-up to this,

I'd just like to say that I think RFC6297 (*) should be required reading for folks dealing with delay-based congestion control. The focus is on Lower-than-Best-Effort schemes, but naturally, many of them are delay-based, and many of these typical problems have been resolved in such schemes long ago.  Similarly, there's a ton of work on delay-based TCP, e.g. CxTCP, CDG-TCP, but also much older yet elaborate ones like e.g. FAST, but also Compound TCP, TCP-Illinois, TCP-Yeah used delay. Does anyone have a good survey of delay-based TCP's? Surely there is one somewhere. Else I suppose the related work section of e.g. the paper on CxTCP should have useful pointers.

The goals of both these things are not the same as RMCAT's, but the problems experienced with delay-based congestion control are close enough. Why repeat history?

Cheers,
Michael

(*) or the paper we later made out of it:
http://ieeexplore.ieee.org/xpl/articleDetails.jsp?tp=&arnumber=6226797&contentType=Early+Access+Articles&searchField=Search_All&queryText=Less-than-Best-Effort+Service%3A+A+Survey+of+End-to-End+Approaches

On 4. nov. 2013, at 08:04, Xiaoqing Zhu (xiaoqzhu) <[email-masked]> wrote:

> On Nov 4, 2013, at 8:34 AM, Piers O'Hanlon <[email-masked]> wrote:
> 
>>