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

[Ted Hardie <[e-mail]>]

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.

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.

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?

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?

I am not currently subscribed to this list, so if there are comments in
response, please cc me.

thanks,

Ted