Subject: [AVT] [Fwd: New Version Notification for draft-singh-avt-mprtp-00]

From: Joerg Ott <[email-masked]>
Date: Thu, 08 Jul 2010 09:19:18 +0300

Hi,

this is a heads-up for some work we have been doing on using
multiple paths with RTP, short multipath RTP.

Multipath RTP picks up ideas of SCTP and even more so MPTCP
to utilize multiple interfaces (that could have, e.g., been
learned from ICE or by other means) and exploit multiple paths
to provide in-band failover (for robustness), capacity aggregation
and/or broader resource pooling.

At this stage, the document is primarily a problem statement
identifying goals and issues, discussing necessary steps, and
including a tiny bit of a strawman spec to show feasibility of
and sketch a possible direction for extending RTP.

Joerg

-------- Original Message --------
Subject: New Version Notification for draft-singh-avt-mprtp-00
Date: Mon,  5 Jul 2010 00:24:12 -0700 (PDT)
From: IETF I-D Submission Tool <[email-masked]>
To: [email-masked]
CC: [email-masked],[email-masked],[email-masked]

A new version of I-D, draft-singh-avt-mprtp-00.txt has been successfully
submitted by Joerg Ott and posted to the IETF repository.

Filename:	 draft-singh-avt-mprtp
Revision:	 00
Title:		 Multipath RTP (MPRTP)
Creation_date:	 2010-07-05
WG ID:		 Independent Submission
Number_of_pages: 22

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: Roni Even <[email-masked]>
Date: Sat, 10 Jul 2010 01:10:35 +0300

Hi,
I can agree that this is an initial draft and need more work on defining the
solution and the extensions.
As for the proposed solution I have some questions.

1. It looks to me that the draft suggest using something similar to ICE over
RTP (in band). When looking at the advertisement it is not clear if the
proposed interfaces are alternatives for the same subflow or for a different
subflow.

2. I am not sure what is the RTP header of each subflow. What are the
timestamps and sequence numbers and how they relate to the SDP parameters
like clock rate.

3. Will each flow have a separate m-line? How will bandwidth of each subflow
be controlled using the b= parameter.

4. It looks to me that each subflow is using his own timestamp and sequence
number space so it will look like a valid RTP stream and the header
extension will provide information to handle the reassembly. I think that
the different links may support different bit rates so how do you propose to
synchronize the subflows or do you assume same rates on all links.

I think that the advantage for the solution depends on the complexity of the
disassembly and aggregation process. 

Thanks
Roni Even
As individual

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Joerg Ott
> Sent: Thursday, July 08, 2010 9:19 AM
> To: [email-masked]
> Cc: Roni Even; Varun Singh; Teemu Kärkkäinen; Keith Drage; Saba Ahsan
> Subject: [AVT] [Fwd: New Version Notification for draft-singh-avt-
> mprtp-00]
> 
> Hi,
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

---

From: Joerg Ott <[email-masked]>
Date: Mon, 12 Jul 2010 01:46:34 +0300

Hi,

> solution and the extensions.

indeed; but, we believe it is appropriate to discuss the problem
definition first, rather than jumping straight to a solution.

> As for the proposed solution I have some questions.

Please consider this as what it is said to be: a feasibility check.

> proposed interfaces are alternatives for the same subflow or for a different

Each subflow is by definition a pair of interfaces.

Once you change the interface you intentionally change (at most cases)
at least one hop of the path and, as a consequence, potentially the
path characteristics.

A subflow is thus always implies by your path choice; the basic
mechanism for the endpoint to control the path is to change the
interface (or use source routing or change the router or use some
other labeling mechanism, but we wanted to keep this intuitive
and simple for the time being).

> timestamps and sequence numbers and how they relate to the SDP parameters

This is a very good question.  Understanding what boxes are out there
and what they expect from RTP/RTCP flows they observe and how to make
all of this coherent is one of the challenging problems.  Since RTP
runs on top of UDP, I hope that we will clear many middleboxes, but
surely not all (including traffic monitors, SBCs, etc.)

> be controlled using the b= parameter.

No.  SDP negotiates sessions at the application layer.  All subflows
together make up such a session. The splitting is done at the transport
layer.

> synchronize the subflows or do you assume same rates on all links.

No, we don't.  One of the fundamental problems we face is rate
adaptation.  This is not very well defined for RTP as we know,
but we foresee that the overall RTP session rate (as a result
of "something like the sum of the subflows") will be eventually
adapted.  Before embarking on those kinds of mechanisms, we need
to understand how to organize subflows in the first place.

> disassembly and aggregation process. 

Right.  One of the things we want to actually keep open (similarly to
what is done in video or header compression) is how the sender precisely
works and splits streams.  but we want to define on how to organize an
RTP stream across multiple paths and give hints towards individual path
quality for the sender to react upon.

Joerg

---

From: Roni Even <[email-masked]>
Date: Mon, 12 Jul 2010 10:00:41 +0300

Hi Joerg,
Thanks for the response see inline.
Roni

> and simple for the time being).

I am not sure I understand the inband signaling, I thought it was similar to
ICE where you need to gather addresses for the same transport address.
> together make up such a session. The splitting is done at the transport

This was a question about the out of band signaling using SDP (no inband),
are you saying that it will have one m-line with multiple payload subtype
numbers. But each subflow needs a different c-line.

> quality for the sender to react upon.

I think that this is what I meant in the previous question. To have a good
solution there is a need to know the rate and delay of each path in order to
optimize the disassembly of the stream to multiple streams. I think that is
something that needs to be addressed before going to the actual splitting
solution.

---

From: Joerg Ott <[email-masked]>
Date: Mon, 26 Jul 2010 16:14:00 +0300

Hi Roni,

back from vacation and online again

> ICE where you need to gather addresses for the same transport address.

This is kind of correct.  Well, it is less about gathering the addresses
but rather about signaling what you know/got.

This is important if new interfaces come up or existing ones go down.

ICE so far has (seemingly) assumed a fairly static scenario in which
you don't have so much dynamics. (well, you run continuous connectivity
checks but I am not sure how much gets added and how often ICE is
re-invoked).  In any case, the whole procedure could be quite costly
(and too slow) for robustness/failover purposes.

But what we wanna do in the end, we still need to figure out.

> numbers. But each subflow needs a different c-line.

Yes.  If we will see any SDP signaling of subflows, I would assume that
those will use a= attributes, just like ICE does.  After all, you don't
have alternative or complementary media streams.  We think that
minimizing what we expose via SDP is a good idea.

> something that needs to be addressed before going to the actual splitting

We don't really have this for a single path right now :-)  But, yes,
this is what we need to find out in the end.  But, I think it may be
advisable to just give examples and not mandate anything at this point.
(At least we would not want to claim too much at this point).

Cheers,
Joerg