Subject: Re: [AVTCORE] mufti path rtp

From: [email-masked]
Date: Fri, 15 Mar 2013 00:49:42 -0400

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

---

From: Varun Singh <[email-masked]>
Date: Fri, 15 Mar 2013 12:17:34 -0400

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, "[email-masked]" <[email-masked]> wrote:

Hi Varuna,

Impressive work.

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

[email-masked]

https://www.ietf.org/mailman/listinfo/avt

---

From: lingli deng <[email-masked]>
Date: Wed, 20 Mar 2013 12:06:51 +0800

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 <[email-masked]>

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

-- 
邓灵莉/Lingli Deng
中国移动通信研究院/China Mobile Research Institute
e-mail: [email-masked]
tel: 15801696688-3367
mobile: 13810597148

---

From: Varun Singh <[email-masked]>
Date: Wed, 20 Mar 2013 15:55:16 +0200

Hi Lingli,

comments inline.

On Wed, Mar 20, 2013 at 6:06 AM, lingli deng <[email-masked]> wrote:
> Hi Varun,
>
> Thank you for your sharing~
>
> 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
> 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
> status-sharing and coordinated rate control needs to be considered.
>
> 3) Moreover, in this paper, to yield non-linear monitory overhead for
> 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

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

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