Re: [AVTCORE] mufti path rtp

[lingli deng <[e-mail]>]

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

** **

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 scheduling results if some of channels looks better in ratio but
actually is unacceptable in terms of RTT constraint.****

** **

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

** **

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.

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


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]