[MMUSIC] Review of draft-nandakumar-mmusic-sdp-mux-attributes-02

[Magnus Westerlund <[e-mail]>]

Hi,

Here is my review of the introduction and those sections related to RFCs
that I have been part of writing as requested (5.3, 5.9, 6.2, 6.3, 8.3).

I would have to note that although it is good to solicit reviews it
would have been desirable to not CC the WG mailing list for each
solicitation.

1) Section 1)

   However, in the RTCWeb WG, a requirement has
   arisen to multiplex several RTP Sessions over a single transport
   layer flow.

I wished this was the part there was strong consensus because, the only
solution on the table that tries to solve this issue is:
https://datatracker.ietf.org/doc/draft-westerlund-avtcore-transport-multiplexing/

What so far been most discussed is having multiple media types in one
RTP session. That also implies multiple SDP Media Descriptions (m=
blocks) describing one RTP session.

There are a very important distinction here. Something I will return to.

2) Section 3:

   The specific problem is that there are attribute combinations which
   make sense when specified on independent m-lines -- as with classical
   SDP -- that do not make sense when those m-lines are then multiplexed
   over the same transport.

I think this must be clarified to discuss one particular case:

do not make sense when those m-lines are then jointly describing an RTP
session over one specific transport.

If you want to describe the issues of having multiple RTP sessions over
the same transport, then you gets a different problem, as having
multiple RTP sessions over the same transport requires some method for
explicitly indicating which RTP session a particular RTP/RTCP packet
belongs to as well as its signaling attribute. In fact almost the whole
problem that arises in SDP signaling can go away as long as one enforces
one m-line equals one RTP session.

The "only" issue that remains under a paradigm of one m-line equeals one
RTP session, and then using SHIM multiplexing are the SDP parameters
that describe the common transport, i.e. ports, protocols, ICE, flow
level QoS and aggregate bandwidths.

3) Section 4:

   o  Attributes related to media content such as media type, encoding
      schemes, payload types.
   o  Attributes specifying media transport characteristics like RTP/
      RTCP port numbers, network addresses, QOS.
   o  Metadata description attributes capturing session timing and
      origin information.
   o  Attributes establishing relationships between media streams such
      as grouping framework

This is clearly one way of classifying them. However, for the task in
hand I think it would make more sense to maybe classify them in relation to:

* Transport level: Specifying the underlying transport and protocol,
such as ICE.
* RTP Session level: RTP/RTCP extensions, payload types

* Media Stream level: Identities, bandwidth, purpose, timing

* Releationships: Grouping information

I think using a two part classification might help: One for describing
what scope a parameter has, and some might have more than one scope, and
in that scope discuss the perceived impact on the attribute according to
the proposed handling, i.e. normal, not recommended, identical, sum,
special. The transport class should possibly be changed to "select one".

4) I also think your classes are assuming a bit of the solution as it
appears to include make a difference for things that you think needs to
be different to work with legacy, but if multiple media lines form one
RTP session in the end must have a particular result. For example the
difference between Transport and Identical is actually encoding that
difference. If you have no legacy you could set all transport parameters
identical over all the m-lines that are part of a common RTP session.
Only if might encounter legacy do you need to have a different behavior.

Thus a potential would be to separate the required behavior for legacy
resulting in fallback into separate RTP sessions compared to forming a
common one.

For example a=candidate
LEGACY: Unique
BUNDLE: Identical

I have not analyzed if this would expose new information, or if the
transport category is sufficient to capture this difference?

5) Section 5.3:

Appears correct. This is clearly a transport and RTP session affecting
parameter.

6) Section 5.9:

Identical works, but as being an RTP session level parameter one can see
two interpretations here:

A) RTP session level only, i.e. is reduced size RTCP enable for the RTP
session. Then it should truly be identical.

B) That is both an enabling and an indication of intent/allowance to use
it related to the RTP media streams specified under this m-line. Thus
the RTP session would be enabled for reduced size RTCP as soon as any
m-line includes it and the peer acks it, while the individual m= lines
indicates if it should be used.

I don't know if that level of indication is necessary. Just pointing out
that this is not a clear cut classification.

7) Section 6.1:

For b=AS isn't normal and SUM a conflict?

b=AS has two impacts, it will specify the RTCP bandwidth unless b=RR
and/or b=RS is used. Thus it is a RTP session parameter. It is also one
of these paramters that I gotten the feeling that people applies for an
individual media stream, rather than a session aggregate. We also have
the directionality issue here. In which directions does it applies? Note
these issues arise from the unclear specification of b=AS rather than
anything else.

8) Section 6.2:

SUM is a reasonable classification. However, for a multi-stream
environment it is not clear that an application actually need the sum of
all RR and RS, as there is significant efficiency benefits in sharing
RTCP bandwidth for multiple flows compared to needing to reach
statistical feedback timeliness goals individually. Thus, you might want
to have different values for a BUNDLE compared to a legacy case.

9) Section 6.3:
First of all TIAS has no defined Offer/Answer usage. I know it is used
in O/A context but that is not well defined. In fact it can't be
providing accurate information of expected bit-rate for RTP level, only
on media level prior to packetization.

I would also note that a=maxprate is missing. It is an integral part of
the solution that can't be ignored.

The intention of TIAS is that you take the media level bit-rate and then
multiply the known per-packet overhead for the selected transport with
the maxprate value to determine the worst case bit-rate from the
transport to more accurately capture the required usage.

Thus, these values can't be SUMMED independently and then multiplied.
That would inflate the value significantly. Multiply first then sum must
be applied to even get close.

This still ignores the fact that this is a send side declaration, and
not intended for receiver negotiation.

9) Section 8.3:

The capabilitiy to use ECN is a combination of transport and RTP
session. I would note that it does requires certain additional SDP
paremters such as the a=ecn-capable-rtp: attribute. I think these should
be more explicitly be listed together. Especially as they don't appear
to be mentioned otherwise in the document.

As this is something you enable on RTP session level, I think it is need
to arrive in identical parameters in a bundle case. And they can
actually be identical in a legacy case also. I don't really see an
reason for trying to use ECN with RTP for some RTP media streams and not
all.

cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------