Subject: [AVTCORE] Comments to draft-singh-avtcore-mprtp-02: A bunch of comments

From: "Miguel A. Garcia" <[email-masked]>
Date: Fri, 19 Aug 2011 12:06:29 +0200

Here is a bunch of comments to the MPRTP draft.

- In several sections (take for example the second paragraph in the 
Introduction), the text talks of packets that are "transmitted over 
different paths". I think we need to differentiate the use case that you 
are considering from the use case when two packets with the same origin 
and end travel through different paths in the network, due to, e.g., 
congestion of intermediate routers. So, I guess you need to clarify that 
you are not addressing that use case, but instead, one where at least one 
of the endpoints has multiple interfaces at its disposal. Furthermore, 
these multiple interfaces at an endpoint should also have different IP 
addresses among them.

- In the third paragraph of the introduction you mention that SCTP, MPTCP 
and SHIM6 are not suitable for realtime communications. I wouldn't dare 
to write such statement, perhaps you don't want to hurt someone else's 
sensitivity.

- Section 1.2 reads:

Endpoint: host either initiating or terminating an RTP connection.

I don't know what is an RTP "connection". Perhaps "flow", or "session".

- Section 1.3 reads:

    o  Load balancing: Transmitting one RTP stream over multiple paths
       can reduce the bandwidth usage, compared to transmitting the same
       stream along a single path.  This reduces the impact on other
       traffic.

Question: why is it so that transmitting the same flow over several paths 
reduces the bandwidth usage? I guess that the aggregated bandwidth 
wouldn't change when you use several paths.

- Section 7.1. When you mention "RTP/RTCP header extension" you should 
add a reference to where such extension is defined, I guess Sections 9.1 
and 9.2 in your same draft. The same applies to the second paragraph in 
Section 7 .2

- Confusing text in Section 8:

    To enable a quick start of a multimedia session, a multipath session
    MUST be upgraded from a single path session.

The text gives me the impression that something will break if one does 
not upgrade to a multipath from a single path session. The problem is how 
the "MUST" is interpreted. I guess what you want to say is:

    If an endpoint wants to enable a quick start of a multimedia session, 
it will first start a single path session and will then upgrade it to a 
multipath session.

- Section 8.1.3, first paragraph, reads:

    The sender MAY open any number of subflows from the set of candidate
    subflows after performing connectivity checks.

What is "open"? Do we open flows? In particular, I don't know if you are 
referring to "publish the SDP", "is ready to receive RTP", or "starts 
sending RTP". Please clarify it.

- Section 9.1, third paragraph reads:

    To signal the use of the above RTP header extensions in SDP, the
    following URI MUST be used: urn:ietf:params:rtp-hdrext:mprtp.

I believe the above text is written in the wrong section. Section 9.1 is 
about the RTP header extension for MPRTP, not about SDP. Additionally, 
you have the same sentences correctly included in the SDP section, 
therefore, you can safely delete the above misplaced paragraph in 9.1.

- Section 9.3.1 reads:

       Address: 4 octets (IPv4), 16 octets (IPv6), or n octets (DNS name)

          The address to which receivers send feedback reports.  For IPv4
          and IPv6, fixed-length address fields are used.  A DNS name is
          an arbitrary-length string.  The string MAY contain
          Internationalizing Domain Names in Applications (IDNA) domain
          names and MUST be UTF-8 [8] encoded.

I don't know how IPv4 and IPv6 addresses are encoded. One could use its 
binary representation per octet, or its UTF-8 encoding of the string 
(e.g., including the dots, colons, etc.). Please clearly specify how this 
is done.

- Section 11.2 has normative text to use ("MUST use") a URN. But without 
normatively specifying how to use, e.g., in which line, attribute, to 
include it, the normative strength is useless.

- Section 11.3.1 says:

  <unicast-address>: is taken from RFC5245 [3].

This is not true. RFC 5245 does not define unicast-address. RFC 5245 
reuses <connection-address> from RFC 4566, which also includes 
multicast-address. I guess you need to point to RFC 4566, which is the 
canonical source of unicast-address for this purpose.

/Miguel

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain