Re: [rmcat] Review of draft-ietf-rmcat-nada-01

["Xiaoqing Zhu (xiaoqzhu)" <[e-mail]>]

Stefan,

Much appreciate your detailed review.  Please find my answers/response below, labeled with [XZ].

Best,
Xiaoqing

From: Stefan Holmer <[e-mail]<mailto:[e-mail]>>
Date: Monday, November 2, 2015 at 11:38 AM
To: Xiaoqing Zhu <[e-mail]<mailto:[e-mail]>>, Karen Elisabeth Egede Nielsen <[e-mail]<mailto:[e-mail]>>, Mirja Kühlewind <[e-mail]<mailto:[e-mail]>>
Cc: "rmcat WG ([e-mail]<mailto:[e-mail]>)" <[e-mail]<mailto:[e-mail]>>
Subject: Re: Review of draft-ietf-rmcat-nada-01

A few more comments I forgot to add:

"This ensures that when multiple flows share the
   same bottleneck and observe a common value of x_n, their rates at
   equilibrium will be proportional to their respective priority levels
   (PRIO) and maximum rate (RMAX)."

Is this a desirable property? If I understand this correctly, targeting a higher rate gives you a higher share of the link capacity?

[XZ] This was one of our design goals for NADA in the beginning. The idea is that if an HD stream shares the bottleneck with an SD stream, it is more desirable for them to share the BW in a proportional fair manner, instead of equally. For example, if the HD stream has max rate of 4Mbps and the SD stream has max rate of 2Mbps, and the bottleneck BW is 3Mbps, then it is more desirable to have them operate at HD@2Mbps and SD@1Mbps than at 1.5Mbps each — the latter will result in very high quality of the SD stream but rather low quality for the HD stream.

[XZ] To clarify, this notion of proportional fairness is *not* our invention, and has been first proposed by Frank Kelly in a 1998 paper (http://www.statslab.cam.ac.uk/~frank/rate.html)  We are borrowing this idea with video quality as utility functions of allocated rate.


Have you considered the case of sending multiple streams? For instance if sending several resolutions of the same video stream, or if we have both audio and video?

[XZ]  You mean sending multiple streams within a single flow or as separate flows?   As separate flows it would be equivalent to multiple senders operating independently (one flow per one congestion module). If multiple streams share the same congestion control module, then there will be another layer to allocate the total rate recommended by congestion control across individual streams.  So far we have not tested much the second case, and I am still trying to understand what complications it introduces for congestion control.

[XZ]  For now, we consider audio as separate CBR stream.


/Stefan

On Mon, Nov 2, 2015 at 10:36 AM Stefan Holmer <[e-mail]<mailto:[e-mail]>> wrote:
Hi,

My comments on draft-ietf-rmcat-nada-01:

Section 1:
"The signaling mechanism consists of standard RTP
   timestamp [RFC3550] and standard RTCP feedback reports."

I would suggest mentioning that the RTCP feedback reports are using a non-standard message.

[XZ]  Good catch. Thanks.


Section 3:
"In addition, the encoder can only change
      its bit rate at rather coarse time intervals, e.g., once every 0.5
      seconds."

Maybe this could be replaced with a reference to the video traffic draft instead?


[XZ]  Good suggestion.


"responsible for measuring and estimating end-to-end
      delay based on sender RTP timestamp, packet loss and ECN marking
      ratios..."

I suggest reformulating slightly:

"responsible for estimating end-to-end delay (based on RTP timestamps), packet loss (based on RTP sequence numbers) and ECN marking ratios..."

[XZ]  Currently our implementation use RTP sequence number for packet loss estimation, but not RTP timestamp for delay estimation.  We use timestamps at finer granularity, which records the precise sending time of a packet (instead of media sample time for RTP timestamp).   Is there any compelling reason why one should use RTP timestamp instead?


"Note that network node operation is out of scope for
      the design of NADA."

Should this say "out of control" rather than "out of scope"?

[XZ]  Yes, “out of control”.


Section 4:

4.1:
Does "n" in r_n, d_n and x_n indicate an index? In that case, should x_prev be named x_n-1? Or should r_n, d_n, x_n simply be named r, d and x?

[XZ]  The subscript “n” does not indicate an index.  I can now see that this can be confusing.  Will rename to avoid that issue.


Can TAU maybe be named RTT_MAX instead?

[XZ]  I’m a bit reluctant about that choice, as TAU is a design parameter by choice. Renaming it to RTT_MAX may give the wrong notion of maximum RTT measured over the network.


4.2:
I can't see that it's mentioned anywhere what the implications of using RTP timestamp to measure the queuing delay are. RTP timestamps are the same for all packets of a video frame, and are taken at the time of frame capture. This means that the measurements will include encoding delay, time spent in the rate shaping buffer, etc. Two things I think should be described are:
- Effects of measurements including rate shaping buffer delay and encoder processing time.
- Effects of getting one measurement per frame, since all packets of a frame have the same RTP timestamp.


[XZ] As mentioned earlier, RTP timestamp is currently not used for queuing delay measurement. I will add some clarifications in the draft.


"  When packet losses are observed, the estimated queuing delay follows
   a non-linear warping inspired by the delay-adaptive congestion window
   backoff policy in [Budzisz-TON11]"

Does this mean that non-linear warping only is done if p_loss > 0?

[XZ] Yes.



"...but does assume that ECN markings, when available,
   occur before losses"

Is this perhaps obvious? I was a bit confused by it when I read it, thinking that the equations made some implicit assumption.

[XZ] The assumption is that an ECN-enabled AQM will mark a packet first before dropping it.  Will this be a better way of stating the assumption?


"Furthermore, the values of DLOSS and DMARK need
   to be set consistently across all NADA flows for them to compete
   fairly."

Is there some range that these parameters should be within to compete with TCP in a reasonable way?

[XZ] Yes.  Work in progress:  to come up with recommended range of values and their impact on how NADA aggressively competes against TCP.


Section 4.3:

In equation (3) QBOUND is divided by rtt+DELTA. Shouldn't rtt+DELTA also include the estimated queue filter delay? Currently constant, so maybe it doesn't matter? But since DELTA is included, which is also a constant, I'm not sure?

[XZ]  Good point. I overlooked that factors.


"The value of X_REF is chosen that the maximum rate..." ->
"... chosen so that ..."

" At equilibrium, the aggregated congestion signal stablizes at" ->
"...signal stabilizes at..."

5.1.1:

"Current
   implementation employs a 15-tab minimum filter over per-packet
   queuing delay estimates."

Should it say "15-tap minimum filter"? 15 taps sounds like a lot to me, if we have 30 fps that means 0.5 seconds to detect increasing queuing delay. And what if we have 15 fps or even 7.5 fps, which is pretty common?

[XZ] Yes, should be “15-tap”. The filtering is operated on per-packet, not per frame.  For 1Mbps and MTU size of 1000B, that would add 15*1000B/1Mbps = 120ms of filtering delay.


5.1.3:

" It is fairly straighforward to estimate the receiving rate r_recv" ->
"...fairly straightforward to..."


6.3:

"  Furthermore, both simulation studies and frequency-domain analysis
   have established that a feedback interval below 250ms will not break
   up the feedback control loop of NADA congestion control."

Is 250 ms independent of other parameters, such as RTT?

[XZ] Good question. Previous studies were all for base RTT at 100ms.  I just tried out with simulations. ACK interval at 250ms runs okay in terms of stability in feedback loop control for base RTT up to 300ms. Will catch up on the numerical analysis side and report back on this mailing list.


6.4:
" In the current design, the aggregated congestion signal x_n is
   calculated at the receiver"

I don't think the current design aggregates the congestion signal at the receiver?

[XZ] Currently in our implementation the receiver calculates the aggregated congestion signal (x_n), so the feedback message only contains x_n and receive rate (r_recv). That’s a change/simplification since last draft.  As mentioned in Sec. 6.4,  we believe calculations of x_n can be moved to the sender too (like what we did before, with slightly higher overhead).


/Stefan

On Thu, Oct 15, 2015 at 10:07 PM Mirja Kühlewind <[e-mail]<mailto:[e-mail]>> wrote:
Hi Stefan, hi Zahed, hi Anurag,

you’ve agree at the last meeting to review the next version of draft-ietf-rmcat-nada. As there is a new version out now, it would be great if you could review it before the next meeting.

I’m cc’ing the group mailing list: Of course, if others are interested in this work, please also review now and send comments on the list or be prepared to provide feedback at the next session directly to the authors!

Thanks in advance!
Karen & Mirja