Subject: [MMUSIC] Benjamin Kaduk's No Objection on draft-ietf-mmusic-sdp-simulcast-12: (with COMMENT)

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 19 Jun 2018 08:36:50 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-mmusic-sdp-simulcast-12: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-simulcast/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I have some questions, probably just due to confusion on my part, as well as some nit-leve comments.

Section 3

   There are two principle approaches for an RTP Mixer to provide this
   adapted view of the communication session to each receiving
   participant:

I think this is more a case for "principal" than "principle", as
it's talking about the primary or main options.

Section 3.1

Expand QoE at first usage only (the fourth usage also has an
expansion).

Section 5.1

   [...] Since pause capability specified via
   the "a=rtcp-fb" attribute and rid-id specified by "a=rid" can refer
   to common payload types, it is unfeasible to pause streams with rid-
   id where any of the related RTP payload type(s) do not have pause
   capability.

My brain is having trouble reading this last sentence; maybe it's
trying to say there's a singular/plural disagreement between
"capability" and "payload types", but I think the second clause may
also be giving my brain trouble.  Am I parsing things properly as
this noting that some ("common"/"widely used") payload types do not
support pausing, and that trying to use SDP syntax to pause streams
using that payload type is not going to work well?

Section 5.2

   All RTP payload types related to such initially paused simulcast
   stream MUST be listed in the SDP as pause/resume capable as specified
   by [RFC7728], e.g. by using the "*" wildcard format for "a=rtcp-fb".

nit: I think "streams" plural is needed to be consistent with
"payload types" plural.

   If the endpoint sending the SDP includes an "recv" direction
   simulcast stream that is initially paused, then the remote RTP sender
   receiving the SDP SHOULD put its RTP stream in a unsolicited locally
   paused state.  However, this does not apply if there are other RTP
   stream receivers that do not mark the simulcast stream as initially
   paused.

I'm not sure if I'm parsing this properly (probably due to ignorance
on my part).  Are the "other RTP stream receivers" other SDP
participants that are for some reason (multicast?) using the same
descriptions, or is this covering the case of things like dependent
streams where something else in the whole negotiated session
requires that stream?

I'm not entirely sure what concrete
information/recommendation/action I'm supposed to take from Section
6.2.2.  Maybe I just haven't had enough tea yet today.

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 20 Jun 2018 15:14:13 +0200

Hi Benjamin,

Please see my comments inline.

> https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-simulcast/

Yes, that should be changed.

> Expand QoE at first usage only (the fourth usage also has an

Will do.

> using that payload type is not going to work well?

So each payload type can have the capability or not of being possible to 
pause, then the resulting pause capability for a RID that include a set 
of payload types is inconsistent and not generally usable. Common in 
this case refers to that payload types are being defined for a 
particular RTP session and the same payload type can be included in 
multiple RIDs.

> nit: I think "streams" plural is needed to be consistent with

No, a given simulcast stream can use multiple RTP payload types, so this 
is the right form.

> streams where something else in the whole negotiated session

So in case of either multicast or more likely a centralized topology 
where a middlebox forwards the senders media to multiple receivers. The 
signalling is done only between the sender and the signalling system 
controlling system.

The last sentence quoted above actually contains an issue. The media 
sender in a multi-party conference is actually not in the position to 
determine if an receiver refuses the pause. That would require a 
renegotiation from the conference signalling server towards the sender, 
or from some other knowledge. Will consider how to address this.

> 6.2.2.  Maybe I just haven't had enough tea yet today.
So this section likely requires that one understand the Selective 
Forwarding Middlebox (SFM) topology as defined in RFC 7667. It provides 
a recommendation that for such a middlebox:

- Sender to SFM: Multiple simulcast streams per media source
- SFM to Receiver: One stream per media source
- No need to use CSRC values.
- SFM to receiver: use only MID identifier values agreed in SFM to 
receiver signalling
- SFM may use RFC 7728 PAUSED indication when turning of a particular 
RTP stream to avoid end of stream uncertainties.

I believe this is fairly clear for someone that actively work with these 
topics.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 21 Jun 2018 19:33:13 -0500

Hi Magnus,

Thanks for the explanations; I just have one (nit) followup, inline.

> No, a given simulcast stream can use multiple RTP payload types, so this 

Ah, then it should probably be "to such an initially paused simulcast
stream" (add "an").

-Benjamin