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

[Roni Even <[e-mail]>]

Hi Joerg,
Thanks for the response see inline.
Roni

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

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.
> 
> 
> > 3. Will each flow have a separate m-line? How will bandwidth of each
> subflow
> > 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.

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.

> 
> > 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.
> 
> 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.
> 
> > I think that the advantage for the solution depends on the complexity
> of the
> > 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.

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.

> 
> Joerg
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [e-mail]
> https://www.ietf.org/mailman/listinfo/avt