Re: [AVTCORE] mufti path rtp

[Varun Singh <[e-mail]>]

Hi Lingli,

comments inline.

On Wed, Mar 20, 2013 at 6:06 AM, lingli deng <[e-mail]> wrote:
> Hi Varun,
>
> Thank you for your sharing~
>
> The paper is well-written and easy to follow, to which I have the following
> comments:
>
> 1) Firstly, although it may be out of scope for the current multi-rtp draft,
> but I kind of believe that the performance evaluation (between multipath and
> singlepath) on packet loss rate and PSNR is not sufficient for interactive
> real-time communication apps. Since the user perceived RTT delay ( or

We can compare the PSNR because we use the same media in all our
experiments. Moreover, packets that arrive late are discarded.
However, I agree we have not done a QoE evaluation, so cannot really
comment on user perceived annoyances.

> equivalently the MPRTP stack’s application’s perceived RTT delay) is not
> included as a metric. What concerns me is that, delay screwing may eat up
> all the potential benefit of multiple paths, if the increased RTT is above
> the tolerable threshold set by application. Therefore, I would suggest to

In our experiments, we let the application choose the tolerable skew between
path delays. For example, the skew tolerance for media streaming will be higher
than that for live streaming and much lower for interactive multimedia.

Also in our experiments, if the RTT of a path was above the acceptable delay
chosen by the application, it would try and ignore the path.

> add a suite of tests between the QoE gained from single-path transferring on
> the most promising candidate channel (e.g. the one with the biggest
> bandwidth and tolerable RTT) to multi-path transferring solution.
>

I agree and the endpoint only chooses paths which meets the RTT requirements.

> As matter of fact, the current scheduling algorithm is not delay centric and
> provides no hard protection for tolerable RTT requirements as it bases its
> decision for the most important I-frame streams according to the channel
> with the highest bandwidth/delay ratio. This could lead to suboptimal

maybe it is not explicitly mentioned in the algorithm section, but all
path delays
should be within the application's maximum delay budget. Another way to
look at it is the max allowed skew between the path RTTs, i.e., the scheduling
algorithm can ignore the paths that increase the skew from the optimum.


> scheduling results if some of channels looks better in ratio but actually is
> unacceptable in terms of RTT constraint.
>

As mentioned earlier, this max-RTT value is application dependent, and the
scheduling algorithm can ignore all paths that don't meet this requirement.

> 2) Secondly, even though the paper stresses the work is orthogonal to
> congestion control, I can’t help but thinking that the interaction between
> individual CC mechanism for sub-flows channels and the application (or
> codec) rate control mechanism seems to be at the heart of maximizing QoE
> boost gained from heterogeneous channels instead of doing simple traffic
> partition for CBR media flows.
>

In my opinion, for congestion control we would do something like
coupled congestion control. i.e., measure across all subflows and based
on the aggregate increase/decrease the media rate.

> It may be straightforward to borrow the current work in RTP CC algorithms in
> RMCAT WG here. But I still believe there may be case for two-level rate
> control in MPRTP stack, which means interfaces for cross-layer
> status-sharing and coordinated rate control needs to be considered.
>
> 3) Moreover, in this paper, to yield non-linear monitory overhead for
> sub-flow RTCP traffic, each sub-RTCP traffic is limited according to the
> sub-flow rate of media traffic. It is a clever choice, but one may wonder
> given the fact that the unfairness among the sampling and reporting activity
> may transfer to the unfairness in cross-channel traffic offloading and
> finally hold the ultimate application’s loss in QoE.

Receiving subflows can use early feedback (AVPF) if they observe losses.
Moreover, each subflow irrespective of its rate has a maximum RTCP interval
based on RFC3550 reporting interval. For example, passive subflows also
send subflow SRs and/or subflow RRs.

In our experimentation, we started by reporting on each subflow simultaneously
and slowly relaxed that requirement to the one in the paper. IMO, the MPRTP
protocol extension does not limit the timing requirements set in
RFC3550/RFC4585.

It should be noted that in our paper the scheduling decisions are not
made every time
an endpoint receives an subflow report but when sufficient subflow
reports have been received.
In some cases, the endpoint may have received multiple reports for a
single subflow
while only a single one for another subflow. It is up to the
scheduling algorithm
to synthesize the information in these reports to make scheduling decisions.


>
> If the source code is available, we would like to participate and do some
> more exploration.
>

We will try to get this out as soon as possible, however, we do not
have a delivery
date set for this.

>
> BR
> Lingli
>
>
> 2013/3/16 Varun Singh <[e-mail]>
>>
>> Hi Lingli,
>>
>> We are working towards releasing an open-source version of our
>> implementation. The details will emerge over the summer.
>>
>> The first thing we tested with our implementation was offloading. We have
>> some scenarios in the paper [1] that shows how load balancing can be
>> achieved, but these can be extended for offloading. Additionally, using
>> mobility-ice extensions may help with some of the engineering issues.
>>
>> There are several ways in which MPRTP can be used, therefore we don't
>> discuss the scheduling algorithm in the draft. I urge you to look at the
>> research paper for those details.
>>
>> [1] http://www.netlab.tkk.fi/~varun/2013_MMSYS_Singh_MPRTP.pdf
>>
>> Regards,
>> Varun
>>
>> ----
>> http://www.netlab.tkk.fi/~varun
>>
>>
>> On 15.3.2013, at 0.50, "[e-mail]" <[e-mail]>
>> wrote:
>>
>> Hi Varuna,
>>
>>
>> Impressive work.
>>
>> Do you have any implementation that provide support for real applications?
>>
>> Have you ever considered to apply this solution for Traffic offloading
>> from cellular to wifi networks or vise visa scenarios?
>>
>>
>> BR
>>
>>
>> Lingli
>>
>> China mobile
>>
>>
>> 发自我的 iPad
>>
>> _______________________________________________
>>
>> Audio/Video Transport Core Maintenance
>>
>> [e-mail]
>>
>> https://www.ietf.org/mailman/listinfo/avt
>
>
>
>
> --
> 邓灵莉/Lingli Deng
> 中国移动通信研究院/China Mobile Research Institute
> e-mail: [e-mail]
> tel: [phone]
> mobile: [phone]



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