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

[varun singh <[e-mail]>]

Hi Ye-kui,

Thanks for the response, responses inline.

On Thu, Feb 24, 2011 at 19:52, Ye-Kui Wang <[e-mail]> wrote:
> Hi Varun,
> From: varun singh [mailto:[e-mail]]
> Sent: Friday, February 11, 2011 9:16 AM

snip!

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


VS: Like mentioned elsewhere, that this specification is supposed to
be generic and agnostic to specific architectures. To reiterate, the
draft aims to use multiple interface at one or both end-points to
achieve its goals. If the mobile operator is one of the end-point then
it could advertise its multiple paths and use MPRTP as currently
defined.

However, if the mobile operator is an intermediate component (hop)
then this is a bit more complex use-case and is currently out of scope
for the current document. It also opens up new issues like route
labeling, route advertisement etc. So that endpoints can schedule
packets to take a specific route.

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

VS: The in-band negotiation is a mechanism to quickly start a basic
RTP session and then upgrade it without running combinatorial number
of connectivity checks before the first frame of audio/video is sent.

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

VS: This is an open questions: do we want to use ICE for MPRTP? or is
it possible to use subset of its features and adapt them for MPRTP. To
that end, we have kept the draft open ended and think that this is
something we need to clarify within at the meeting in Prague.

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

VS: Yes, the intention is to keep it open ended.