Subject: [rmcat] NADA questions

From: Piers O'Hanlon <[email-masked]>
Date: Wed, 23 Oct 2013 15:19:53 +0100

Hi Xiaoqing and Rong,

I was reading over your draft and wanted to check a couple of things about the draft:

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?

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?

3) Also in section 6.3 - the parameter tau_o says it is the 'reference RTT' - does this mean it is like the baseRTT which accumulated over some sort of minima of the RTTs, or another configurable parameter?

Thanks,

Piers O'Hanlon

---

From: "Xiaoqing Zhu (xiaoqzhu)" <[email-masked]>
Date: Wed, 23 Oct 2013 23:07:05 +0000

Hi Piers, 

Thanks for going through our draft in detail. Please see answers below. 

Best,
Xiaoqing

> 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 e…

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. 

> 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.  

> 3) Also in section 6.3 - the parameter tau_o says it is the 'reference RTT' - does this mean it is like the baseRTT which accumulated over some sort of minima of the RTTs, or another configurable p…

The parameter tau_o is a fixed value but configurable. The purpose of the prediction is to compensate for the effect of the time delay in the feedback control loop. That's why its value should be comparable to the RTT of the flow, but does not need to match exactly. Throughout all our simulations, we used a fixed value of tau_o = 200ms.

---

From: Piers O'Hanlon <[email-masked]>
Date: Thu, 24 Oct 2013 17:42:44 +0100

Hi Xiaoqing,

Thanks for your clarifications - it would be useful to add these to the next version of the draft.

Some comments inline.

> 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 measuremen…
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.

> 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 r…
ok - though it might also be useful to have some sort of mechanism to accommodate path changes in the setting of x_ref.

> The parameter tau_o is a fixed value but configurable. The purpose of the prediction is to compensate for the effect of the time delay in the feedback control loop. That's why its value should be c…
I see - so I guess you could use tau_o = 2*x_ref

Cheers,

Piers.