Re: [AVTCORE] draft-ietf-avtcore-mprtp-03

[Varun Singh <[e-mail]>]

Hi Ted,

Thanks for reviewing the document, I am just getting to the review
comments, see inline.

On Sat, Apr 8, 2017 at 12:49 AM, Ted Hardie <[e-mail]> wrote:

> Howdy,
>
> I was asked to review this draft in Chicago; sorry for not getting to it
> sooner.
>
> First, the security considerations seem to be TBD entirely, which seems
> surprising.  I was particularly interested to see how this draft would
> tackle linkability, since it is an ongoing discussion in other groups (e.g.
> QUIC).  I think that the security considerations, when written, need to
> tackle both linkability (the ability of an observer to cross-correlate
> traffic on two different paths as belonging to the same endpoint) and
> consent freshness.
>
>
This is indeed correct, I have not gotten around to this, especially since
RTP has several mechanisms including SRTP not mandatory. That being said,
webrtc-capable endpoints might prefer doing DTLS/SRTP. And here I
envisioned that the DTLS context would be reused for all the subflows.



> Second, I believe this requirement:
>
>    Multipath RTP (MPRTP) MUST be backwards compatible; an MPRTP Stream
>    needs to fall back to be compatible with legacy RTP stacks if MPRTP
>    support is not successfully negotiated.
>
> may need re-wording. I initially misread this team that MPRTP would appear
> to be non-multipath RTP if the MPRTP support were not available (following
> what was said about NAT bindings); it seems you mean instead that an MPRTP
> stack must fall back to non-multipath RTP.  Clarifying this would be useful.
>

The requirement section was written when we were designing the MPRTP
packets. The meaning that we were trying to get across was: consider a
MPRTP endpoint communicating with a RTP endpoint, the MPRTP endpoint should
be use multiple subflows and the RTP subflow should be able to receive
them. The fact that the subflows  are marked inside the RTP header
extensions and not in the RTP header, so that non-MPRTP capable endpoint
would still be able to parse the data even though it does not support MPRTP
and ignore the subflow header extensions. Ofcourse the non-MPRTP capable
endpoint may not do a great job because the path skew (latency across the
distinct paths) may be too high and it may end up arbitrarily start
dropping packets.

In the 2013 paper: MPRTP: Multipath Considerations for Real-time Media,
evaluated MPRTP in various network test scenarios.
http://www.netlab.tkk.fi/~varun/2013_MMSYS_Singh_MPRTP.pdf




>
> On the use cases,  the use case for fault tolerance has some very simple
> applications that I have seen proposed in the past.  In one case, ambulance
> telemetry was sent over multiple cellular networks--there, full duplication
> was appropriate and the receiver simply threw away any information already
> received from a different interface.  Load balancing applications are
> harder, and I believe the draft may want to explicitly consider how
> differential packet traversal times across different paths will impact the
> number of applications that can use this.  If I understand this correctly,
> a system with a playout buffer would be able to interleave RTP packets from
> different subflows successfully.  A system without such a buffer or with
> one too small for late arrivals will end up losing information.  There are
> ways to get around this, but the document does not go into them in detail.
> Will they be covered by later documents?
>


Your observation on the potential issues are correct. This comes down to
defining a couple of algorithms: scheduling algorithm on how to send
packets on particular paths, and how the playout buffer, handles the
varying packet skew of those paths to play packets out. Again pointing to
the above paper considered this for streaming video. We are currently
working on adding congestion control to the mix (i.e., webrtc applications
using MPRTP).


>
> Also, the document says:
>
> In contrast to RTCP, SDP offers a reliable
> communication channel so that no separate retransmissions logic is
> necessary.  In SDP, especially when combined with ICE, connectivity
> check mechanisms including sophisticated rules are readily available.
>
> While SDP is not inherently protected, suitable security may need to
> be applied anyway to the basic session setup.
>
> It's not clear what the draft means when it is saying "SDP offers a
> reliable
> communication channel"; does this man to say SIP?
>

The problem that we wanted to solve, is what does an endpoint do when it
discovers new interfaces (because it may be continuously gathering ICE
candidates). The solution we were discussing was should the availability of
new interfaces be announced to the remote endpoint: in-band (i.e., in RTP)
or out-of-band (i.e., in SDP or SIP).  The draft currently allows MPRTP
endpoints to announce the newly discovered interfaces in-band. With the
formation of the ICE working group and discussion around passive-aggressive
nomination or continuous nomination or similar techniques, we might be
leaning on the output of the ICE working group.


Thanks for the review again,
Varun


> I am not currently subscribed to this list, so if there are comments in
> response, please cc me.
>
> thanks,
>
> Ted
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [e-mail]
> https://www.ietf.org/mailman/listinfo/avt
>
>


-- 
http://www.callstats.io