Subject: [AVTCORE] Short WGLC on Port Mapping Between Unicast and Multicast RTP Sessions -reminder

From: Roni Even <[email-masked]>
Date: Fri, 04 Feb 2011 11:22:19 +0200

Hi,

I would like to start a one week working group last call on
http://tools.ietf.org/html/draft-ietf-avtcore-ports-for-ucast-mcast-rtp-00 .

This draft finished a WGLC in the AVT WG before the restructure and the new
00 revision reflects that changes that were done based on email discussion.

Please review the draft and send any comment to the AVTCore mailing list
([email-masked]) till the end of Monday February 7th 2011.

Thanks

Roni Even

AVTCore co chair

---

From: Wangyekui <[email-masked]>
Date: Tue, 08 Feb 2011 00:15:54 +0000

Hi Varun, all,

I have some comments on draft-singh-avt-mprtp-01, for discussion.

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

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

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

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

BR, YK

---

From: varun singh <[email-masked]>
Date: Fri, 11 Feb 2011 16:16:14 +0200

Hi Ye-kui,

comments inline

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

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

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

If the initial path is broken then it would also fail for the case of
single path RTP. In the spec we allow for ICE and SDP. SDP is too slow
to always negotiate.

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

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.

> -          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.
However, can you elaborate on the extension that can signal a path's
characteristic?

Regards,
Varun

---

From: Ye-Kui Wang <[email-masked]>
Date: Thu, 24 Feb 2011 17:52:28 +0000

Hi Varun,

Thanks for your reply. See inline below. 

BR, YK

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

Hi Ye-kui,

comments inline

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.

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?

YK: Good.

YK: Agreed.

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.