Subject: [MMUSIC] New Version Notification for draft-singh-avtcore-mprtp-04.txt

From: Varun Singh <[email-masked]>
Date: Mon, 27 Feb 2012 12:55:37 +0200

Hi,

We have submitted an updated draft for Multipath RTP (MPRTP) and would
like the WG to review the draft and provide feedback.
The exact changes are:
https://tools.ietf.org/rfcdiff?url2=draft-singh-avtcore-mprtp-04.txt

The changes are:
1. MPRTP Interface advertisement can be  MPRTP interfaces can be
done in RTCP or in SDP. Both extensions are in the draft.
2. If an endpoint wants to do NAT traversal then it should use ICE
procedures but using ICE is optional. So session can be setup using
ICE and without ICE (Examples for session setup are in Section 11.6).
3. Using MPRTP with RTSP 2.0

For MMUSIC the interesting parts are:
Section 11 covers SDP:
a. Indicating support for MPRTP in SDP.
b. Advertise MPRTP interfaces in SDP.
c. If an endpoint wants to do NAT traversal then how to use ICE with MPRTP.
d. Using MPRTP in Offer/Answer and Declarative form.
e. Examples for ICE and non-ICE O/A

Section 12 describes procedures for using MPRTP in RTSP 2.0
i. without ICE
ii. with ICE
iii. Extensions required. (PLAY_NOTIFY, RTSP Transport Header Extension etc)

Initially, we have tried to keep all the information in one draft so
that it is easier to
compare and contrast the RTCP and SDP based interface advertisement.
We plan to split the document, the simplest thing would be to put the RTSP part
in another document. However, we are open to suggestions for
splitting/keeping the
draft as is.

Cheers,
Varun

Begin forwarded message:
> A new version of I-D, draft-singh-avtcore-mprtp-04.txt has been successfully submitted by Varun Singh and posted to the IETF repository.
>
> Filename:      draft-singh-avtcore-mprtp
> Revision:      04
> Title:                 Multipath RTP (MPRTP)
> Creation date:         2012-02-27
> WG ID:                 Individual Submission
> Number of pages: 49
>
> Abstract:
>   The Real-time Transport Protocol (RTP) is used to deliver real-time
>   content and, along with the RTP Control Protocol (RTCP), forms the
>   control channel between the sender and receiver.  However, RTP and
>   RTCP assume a single delivery path between the sender and receiver
>   and make decisions based on the measured characteristics of this
>   single path.  Increasingly, endpoints are becoming multi-homed, which
>   means that they are connected via multiple Internet paths.  Network
>   utilization can be improved when endpoints use multiple parallel
>   paths for communication.  The resulting increase in reliability and
>   throughput can also enhance the user experience.  This document
>   extends the Real-time Transport Protocol (RTP) so that a single
>   session can take advantage of the availability of multiple paths
>   between two endpoints.
>
>
>
>
> The IETF Secretariat

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 27 Feb 2012 12:42:45 +0100

Hi Varun,

I will have to look through my old comments, but a few ones that come to my mind when taking a first look at the new version of the draft.

Q1: The draft basically defines a mechanism to, without ICE, provide alternative IP addresses, e.g. one IPv4 and IPv6 address. But, eventhough the use-case is a little different, it doesn't mandate the usage of all addresses. We have had discussions about before, when people have suggested new attributes from provding alternative IP addresses, so I think the comments that have been given then needs to be evalauated also against this draft.

Q2: The draft says that ICE MAY be used to perform connectivity checks. But, if ICE is not used, what is then?

Q3: Section 7.1.1. says, that if an interface is reachable, connectivity checks are not needed. That sounds a little strange, but I assume you mean something else. Globally reachable?

Q4: Section 7.1.3. talks about in-band interface announcement. How does that affect the SDP state?

Q5: Section 7.4 says that flows must be kept alive, but there is no reference to any keep-alive mechanism for doing that.

Q6: Section 8.1.1 says that ICE may be used to gather additional candidates. But, aren't you only talking about additional interfaces, ie host candidates in ICE language. Why do you need ICE to gather such?

Q7a: In section 11.6.2.2 the first offer contains ICE information, but the updated offer doesn't. Is the intention to terminate ICE? 

Q7b: In section 11.6.2.2 the association between ICE candidates and interfaces are not described. I assume you are using a 1:1 mapping, or?

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Varun Singh
Sent: 27. helmikuuta 2012 12:56
To: mmusic
Subject: [MMUSIC] New Version Notification for draft-singh-avtcore-mprtp-04.txt

Hi,

We have submitted an updated draft for Multipath RTP (MPRTP) and would like the WG to review the draft and provide feedback.
The exact changes are:
https://tools.ietf.org/rfcdiff?url2=draft-singh-avtcore-mprtp-04.txt

The changes are:
1. MPRTP Interface advertisement can be  MPRTP interfaces can be done in RTCP or in SDP. Both extensions are in the draft.
2. If an endpoint wants to do NAT traversal then it should use ICE procedures but using ICE is optional. So session can be setup using ICE and without ICE (Examples for session setup are in Section 11.6).
3. Using MPRTP with RTSP 2.0

Section 12 describes procedures for using MPRTP in RTSP 2.0 i. without ICE ii. with ICE iii. Extensions required. (PLAY_NOTIFY, RTSP Transport Header Extension etc)

Initially, we have tried to keep all the information in one draft so that it is easier to compare and contrast the RTCP and SDP based interface advertisement.
We plan to split the document, the simplest thing would be to put the RTSP part in another document. However, we are open to suggestions for splitting/keeping the draft as is.

Cheers,
Varun

>   session can take advantage of the availability of multiple paths
_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Varun Singh <[email-masked]>
Date: Mon, 27 Feb 2012 15:15:18 +0200

Hi Christer,

Comments inline.

> Q1: The draft basically defines a mechanism to, without ICE, provide alternative IP addresses, e.g. one IPv4 and IPv6 address. But, eventhough the use-case is a little different, it doesn't mandate…

The context or use-case is slightly different, because the intention
of the endpoint is to use all the advertised interfaces (which may be
a subset of its available interfaces).

If an interface has both v4 and a v6 addresses then the potential
challenge using both the addresses is if the scheduling algorithm (or
congestion control) is able to take into account the available
bandwidth. Since the scheduling algorithm is not discussed in draft,
we haven't specified what may happen if an endpoint advertises both
the IPv4 and IPv6 address for a single interface.

So is the comment that we cannot advertise MPRTP interfaces in SDP?

> Q2: The draft says that ICE MAY be used to perform connectivity checks. But, if ICE is not used, what is then?

Nothing. NAT traversal is optional. If the endpoint is in a deployment
where the other endpoints are reachable (globally/locally) then they
shouldn't need to use ICE.

> Q3: Section 7.1.1. says, that if an interface is reachable, connectivity checks are not needed. That sounds a little strange, but I assume you mean something else. Globally reachable?

Yes, globally reachable or in some deployments/configurations where
the endpoints are reachable.

> Q4: Section 7.1.3. talks about in-band interface announcement. How does that affect the SDP state?

See response to this in Q7a.

> Q5: Section 7.4 says that flows must be kept alive, but there is no reference to any keep-alive mechanism for doing that.

In Section 7, we discuss about the available methods to choose from.
So it should refer to RFC 6263 (RTP keep-alive). However, MPRTP
proposes to multiplex RTP and RTCP on the same port (RFC 5761) in
Section 8.

> Q6: Section 8.1.1 says that ICE may be used to gather additional candidates. But, aren't you only talking about additional interfaces, ie host candidates in ICE language. Why do you need ICE to gat…

Right, for additional candidates host candidates should be enough.
However, for NAT traversal the endpoint would have to gather the
candidates for each of its host candidates.

> Q7a: In section 11.6.2.2 the first offer contains ICE information, but the updated offer doesn't. Is the intention to terminate ICE?

The intention is that at that point endpoint has sufficient interfaces
to proceed with MPRTP. However, if the endpoints implements only
aggressive ICE nomination, then we want the endpoints to continue with
their ICE checks. The updated offer is to advertise which interfaces
the endpoint is willing to use for MPRTP (stream media from or receive
media on). While it is in an offer/answer it is more of a notification
to the other endpoint.

For this reason, we also propose in-band advertisement. As soon as the
ICE checks succeed for a candidate, the endpoint can advertise its
updated set in-band (in RTCP). The other endpoint on receiving the
updated set of interfaces can start to stream data to them.

In Section 11, we also propose that if an endpoint receives MPRTP
interface advertisements in SDP and in RTCP (some kind of race
condition) then it should just respond in SDP.

See https://tools.ietf.org/html/draft-singh-avtcore-mprtp-04#section-11.4
Probably the endpoint's SDP state requires that the default address
(in the c= and m= lines) are still available.

> Q7b: In section 11.6.2.2 the association between ICE candidates and interfaces are not described. I assume you are using a 1:1 mapping, or?

Yes. 1:1 mapping but not all attributes in "a=candidate" (ICE) appear
in "a=mprtp interface" (MPRTP)

Regards,
Varun

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