Re: [AVTCORE] Comments on draft-singh-avt-mprtp-01

[Ye-Kui Wang <[e-mail]>]

Hi Varun,

Thanks for your reply. See inline below. 

BR, YK

-----Original Message-----
From: varun singh [mailto:[e-mail]] 
Sent: Friday, February 11, 2011 9:16 AM
To: Wangyekui
Cc: [e-mail]; [e-mail]
Subject: Re: [AVTCORE] Comments on draft-singh-avt-mprtp-01

Hi Ye-kui,

comments inline

On Tue, Feb 8, 2011 at 02:15, Wangyekui <[e-mail]> wrote:
> -          First of all, I think this draft initiated a very useful work. For example, today, many mobile operators have deployed dual-plane IP bearer networks, wherein a multipath version of RTP can be used for real-time communications such as voice- and video-over-IP services. BTW, you may want to mention this in the introduction section.

Can you elaborate on what is a dual-plane IP bearer.

YK: This is basically an IP bearer network with two planes, between which there can be communications. When there is problem is one plane, services would be all switched to the other plane. Mobile operators deploy such networks for robust service provisioning. In the multi-path context, two planes provide at least two paths for data transfer.


> -          The draft specifies the negotiation of multiple paths is through upgrading from a single-path session and using in-band signaling (i.e. RTP header extension) for indication of additional paths. Would it be better to negotiate the use of one or more of the available paths out-of-band (i.e. using SDP)? One problem with in-band negotiation is that, if the initial path happens to be broken, then even the session setup would fail. Another problem is that in-band information may get lost (and when it happens the negotiation would fail).

If the initial path is broken then it would also fail for the case of
single path RTP. 

YK: Right, that's the point. If initially multiple possible paths are offered, then the other side may check and choose the best one or at least a working one.

In the spec we allow for ICE and SDP. SDP is too slow
to always negotiate.

YK: What do you mean by "allow for SDP"? Allow for offering multiple paths using SDP?

> -          In some cases, it may be useful to use multiple paths concurrently, for improved throughput. In some other cases, it may be more desirable to use only a subset of available paths at any time instance. For example, in mobile networks using dual-plane IP bearer, typically the better-performing path is used, while the other path is kept there for fast fallback when the path being used has problem. Therefore, it would be desirable if signaling of such a capability/preference is possible.
>

This is a good point and the draft aims to have basic mechanisms
first. Profiles to be added later, may be to the same document or as a
different draft. We'll add this inside as an editor's note.

YK: Good.

> -          Finally, it would be useful if it is possible to indicate more path specific information when advertising paths (or "interfaces" as used in the draft), e.g., which of the two planes in a network using dual-plane IP bearer. It might be sufficient if there is a hook specified to enable backwards compatible extensions when the potential multipath RTP standard is used in the future by application system standards.

We need to stay independent of network architecture or infrastructure.

YK: Agreed.

However, can you elaborate on the extension that can signal a path's
characteristic?

YK: Actually I found that the "mprtp-optional-parameter" in the current draft is already sufficient for this. We just need to keep in mind that in the final spec there should be such an openly specified parameter.