Subject: [MMUSIC] Fwd: Re: AD Evaluation of draft-ietf-mmusic-sdp-simulcast-11

From: Magnus Westerlund <[email-masked]>
Date: Fri, 6 Apr 2018 11:48:01 +0200

WG,

We authors have received Ben's AD review comments. Here are our response 
to them. Note this email includes proposed changes to the draft.

/Magnus Westerlund

-------- Vidarebefordrat meddelande --------
Ämne: 	Re: AD Evaluation of draft-ietf-mmusic-sdp-simulcast-11
Datum: 	Fri, 6 Apr 2018 11:43:10 +0200
Från: 	Magnus Westerlund <[email-masked]>
Till: 	Ben Campbell <[email-masked]>, 
[email-masked]

Hi  Ben,

We have now reviewed your comments in detail and done edits to resolve 
them. We have a version ready to be submitted, but I am holding it until 
you have had a chance to see our proposed edits.

See inline for comments and suggestions.

Den 2018-03-30 kl. 05:44, skrev Ben Campbell:
> Hi,
>
> This is my AD Evaluation of draft-ietf-mmusic-sdp-simulcast-11.Thanks for all the work on this; overall it’s in good shape. I do, however, have some comments. I’d like to address my substantive comments and significatn editorial comments prior to IETF LC.
>
> Thanks!
>
> Ben.
>
> ---------------------------------
>
> Substantive:
>
> §5.2, paragraph 12:
>
> — " RTP duplication [RFC7104 ] procedures SHOULD be considered instead of simulcast”
>
> “considered” seems weak for a normative statement. Should this say “SHOULD use”?

Yes, I think that is what is intended. But, I suggest that we change 
this to:

...required, it is RECOMMENDED to use RTP duplication [RFC7104] procedures instead of simulcast"

> — " Note that this does not eliminate use of simulcast as an RTP duplication mechanism, since it is possible to define multiple different rid-id that are effectively equivalent.”
>
> Didn’t the first part of the paragraph say (or at least imply) that you SHOULD NOT do that?

Well, we recommend that one uses duplication if that is the user's only intention. However, the sentence in between forbids one to re-use the same RID ID twice to indicate duplication. It is in that context that we note that duplication could be achieved despite that restriction by defining multiple RID ID with the same semantic definition.

And if one actually likes to have duplication and some variant then I think it may actually be reasonable to use simulcast for both, rather than requiring an additional mechanism. So, I have a preference for leaving it there.

> §7: Is there anything to say about congestion? (I don’t know that there is; I just want to make sure people thought about it.)

Maybe the adaptation section is to assuming. We do assume that there 
will be congestion control or circuit breakers in place and that the 
sender will adapt the total bitrate of the stream to the available 
capacity. Maybe we should clarify that in the beginning of section 7.1. 
We also realized that maybe we should clarify that the combined 
bandwidth is bounded by the b= attribute applicable on the media stream 
level.

Maybe something like this:

    Use of multiple simulcast streams can require a significant amount of
    network resources.  The aggregate bandwidth for all simulcast streams
    for a media source (and thus SDP media description) is bounded by any
    SDP "b=" line applicable to that media source.  It is assumed that a
    suitable congestion control mechanism is used by the application to
    ensure that it doesn't cause persistent congestion.  If the amount of
    available network resources varies during an RTP session such that it
    does not match what is negotiated in SDP, the bitrate used by the
    different simulcast streams may have to be reduced dynamically.  When
    a simulcasting media source uses a single media transport for all of
    the simulcast streams, it is likely that a joint congestion control
    across all simulcast streams is used for that media source.

> §9: Is there any reason not to make the registration contact “The IESG  ([email-masked])” ?

No.

> Appendix A: Are the requirements met by this document? If so, is there value to the reader to keep the requirements in the document?

Yes, I think they are met. And Yes, I think there is a point of 
maintaining the requirements to show what space it solves.

I suggest to change the intro sentence to say:

The following requirements are met by the defined solution to support 
the use cases (Section 3):

> Significant Editorial:
>
> §2.2: Please use the boilerplate from RFC 8174—there are  at least several lower case “should”s in the document.

Agree.

> §3, 2nd bullet: “…  and does not require RTP Mixer (full) access to media content.”
>
> That’s a potentially strong advantage. Should there be a reciprocal “disadvantage” for the transcoding case?

Yes, but to actually deny the middlebox the access to the encoded 
content the system also needs to implement the PERC security solution. 
And it is mentioned at the end of the Transcoding case: The main 
disadvantages are ..., and requires RTP Mixer access to media content.

So I don't think there is need for a change here.

> §4, 4th paragraph: “ Each simulcast RTP stream identifier (rid-id) is separated by a semicolon (";").  When rid-ids are separated by a comma (","), they describe alternative representations for that particular simulcast RTP stream.”
>
> That text is confusing, it says instances of rid-id are separated by semicolons, then says “when separated by commas”. I think you mean that a semicolon separates rids for different streams, and a comma separates multiple rids for the same stream?

Agreed, propose to change this to:

Each simulcast stream is described by one or more RTP stream identifiers 
(rid-id), each group of rid-ids for a simulcast stream is separated by a 
semicolon (";"). When a simulcast stream has multiple rid-ids that are 
separated by a comma (","), they describe alternative representations 
for that particular simulcast RTP stream.

> §4, last paragraph: This paragraph seems like it belongs earlier in the section.

It is actually a summary of the section. To make this clearer, I suggest 
that we change the start of the paragraph to:

To summarize, the "a=simulcast" line ...

> §5.2:
> — First paragraph: "The meaning of the attribute on SDP session level is undefined, MUST NOT be used by implementations of this specification and MUST be ignored if received on session level.”
>
> Convoluted sentence. I suggest something to the effect of:
>
>     “The use of this attribute at the session level is undefined. Implementations of this specification MUST NOT use it at the session level and MUST ignore it if received at the session level.”

Thanks, good suggestion.
> — same paragraph: “ Extensions to this specification MAY define such session level usage.”
>
> That “MAY" seems more a statement of fact than permission. I suggest stating it without the normative keyword.

Agreed, implementing.

> — 6th paragraph: "In this case, it is not possible to align what alternative rid-id that are used across different simulcast streams, like requiring all simulcast streams to use rid-id alternatives referring to the same codec format.”
>
> I don’t understand the sentence.

The intention of the sentence is to make clear that there exists no
protocol mechanism to force the peer to choose the same alternative
in both simulcast streams in case there are multiple alternatives,
e.g. when both simulcast stream A and simulcast stream B have the
choice between HEVC and VP9, i.e. ensure that only HEVC or only VP9
is used for both simulcast streams. I propose to address this by
removing the sentence you didn't understand, and instead add a new
sentence last in the paragraph. Thus the whole paragraph reads:

Use of more than a single, alternative simulcast format for a
simulcast stream MAY be specified as part of the attribute parameters
by expressing the simulcast stream as a comma-separated list of
alternative rid-id. The order of the rid-id alternatives within a
simulcast stream is significant; the rid-id alternatives are listed
from (left) most preferred to (right) least preferred. For the use of
simulcast, this overrides the normal codec preference as expressed by
format type ordering on the "m=" line, using regular SDP rules. This
is to enable a separation of general codec preferences and simulcast
stream configuration preferences. However, the choice of which
alternative to use per simulcast stream is independent, and there is
currently no mechanism to align the choice of alternative rid-ids
between different simulcast streams.

Better?
> — 10th paragraph: The first sentence is hard to parse.

I agree that this sentence is hard:

Including an initially paused simulcast stream in "recv" direction for 
the part sending the SDP, sent towards an RTP sender, SHOULD cause the 
remote RTP sender to put the stream as unsolicited locally paused, 
unless there are other RTP stream receivers that do not mark the 
simulcast stream as initially paused.

Is this reworded sentence better?

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. 
This unless there are there are other RTP stream receivers that do not 
mark the simulcast stream as initially paused.

> §5.3.2, paragraph 3: “The answerer MUST be prepared to receive any of the receive direction rid-id alternatives, and MAY send any of the send direction alternatives that are kept in the answer.”
>
> I think from reading further that you intend “that are kept in the answer” to restrict both the alternatives one must be ready to receive and may choose to send. But the comma before “and MAY” makes it seem like it only restricts the alternatives the answerer can choose to send.
>
An what the answer can sends is what is important. And the answer can 
actually add alternatives to what it can receive. Thus, "kept" is 
actually wrong. I suggest that we modify the sentence to read:

The answerer MUST be prepared to receive any of the receive direction 
rid-id alternatives and MAY send any of the send direction alternatives 
that are part of the answer.

Does that resolve the unclarity?

> Editorial and Nits:
>
> §1, last paragraph: Unclear antecedent for “it”.  (The document is motivated?)

This document describes a few scenarios that motivates the use of 
simulcast, and also defines the needed RTP/RTCP and SDP signaling for it.

> §3.1, Codec: “… (such as SDP MIME type) …”: Should that be SDP payload MIME type? (We aren’t talking about application/sdp, are we)

(such as RTP payload format MIME type)
> - Bitrate: s/amount/number

Ok

> §3.3: I want to say s/ “ preferences to “ / “ preferences for”, but that seems wrong with “apply preferences”. So now I think there’s something awkward about the phrase “apply preference to the characteristics”. Does this mean the same as “state preferences for the characteristics”?

Does this formulation resolve the issue?

The application logic that controls the communication session may
    allow receiving participants to state their preferences on the
    characteristics of the RTP stream they like to receive, for example
    in terms of the aspects listed in Section 3.1.

> §4, 5th paragraph (starting with “The RID mechanism, as defined…”: It would make things easier to understand if you moved this paragraph before most of the discussion that talks about rids.

Agreed, move it up to be the second paragraph.

> — 8th paragraph: "interpreted on a high level” s/on/at
Ok

> §5.2:
> — paragraph 9: Missing “the” before send. “part” seems like the wrong word choice, but I’m not sure what was intended, maybe “peer”? (Same for paragraph 10).

endpoint I think works.

> — Paragraph 10: Please expand “ TMMBR/TMMBN”

Done.
> §6.1, 2nd paragraph: s/“may not”/“might not"

Done.

-- 

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: Magnus Westerlund <[email-masked]>
Date: Tue, 10 Apr 2018 15:11:11 +0200

Hi,

Removing down to the items requiring response. I will now submit a 
version as I don't see any additional outstanding changes. I hope my 
explantation of the design choice to forbid multiple simulcast streams 
using the same rid-id for a particular media source.

Den 2018-04-09 kl. 22:32, skrev Ben Campbell:
> Thanks for the response. My followup comments are also inline. I removed sections that do not seem to need further discussion.
>
> Ben.
>
>> On Apr 6, 2018, at 4:43 AM, Magnus Westerlund <[email-masked]> wrote:
>>
>>
> Why do literally identical  rid-ids cause complications for this, but semantically identical ones do not?

There are several reasons here, addressing various different cases. So 
there are some cases where it would not be an issue, but it is in 
others. Thus, we agreed when doing the design that it would be simplest 
to disallow identical rid-ids to be reused.

The first one has to with identification of a particular simulcast 
stream for a media source. If they would re-use the rid-id, on the RTP 
level we would have two RTP streams with different SSRCs, but otherwise 
be identical in MID, rid-id. Thus, there are no real identification 
between the simulcast layer and the RTP stream level for which 
duplicated stream one changes. Thus, with pause or renegotiation there 
could be confusion about with of the RTP streams will be affected.

Secondly, when dealing with legacy receivers using PT mapping this type 
can't be done, as each simulcast stream needs an unique pt and thus 
individual rid-id also.

So thus we took the decision that not allowing multiple simulcast 
streams with identical rid-ids was simpler, and would eliminate some 
complexities from the implementations.
>> Including an initially paused simulcast stream in "recv" direction for the part sending the SDP, sent towards an RTP sender, SHOULD cause the remote RTP sender to put the stream as unsolicited locally paused, unless there are other RTP stream receivers that do not mark the simulcast stream as initially paused.
>>
>> 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. This unless there are there are other RTP stream receivers that do not mark the simulcast stream as initially paused.
> Would it make sense to replace the last sentence with “However, this does not apply if there are other RTP stream receivers that do not mark the simulcast stream as initially paused.” ?

Yes, I think this is clear that there is an exception to this.

I will incorporate this change.

Cheers

Magnus Westerlund

SE-164 80 Stockholm, Sweden | mailto: [email-masked]

---

From: Ben Campbell <[email-masked]>
Date: Tue, 10 Apr 2018 10:18:49 -0500

This looks good. I’ve requested IETF last call.

Thanks!

Ben.

> On Apr 10, 2018, at 8:11 AM, Magnus Westerlund <[email-masked]> wrote:
> 
> Hi,
> 
> Removing down to the items requiring response. I will now submit a version as I don't see any additional outstanding changes. I hope my explantation of the design choice to forbid multiple simulcast streams using the same rid-id for a particular media source.
> 
> 
> There are several reasons here, addressing various different cases. So there are some cases where it would not be an issue, but it is in others. Thus, we agreed when doing the design that it would be simplest to disallow identical rid-ids to be reused.
> 
> The first one has to with identification of a particular simulcast stream for a media source. If they would re-use the rid-id, on the RTP level we would have two RTP streams with different SSRCs, but otherwise be identical in MID, rid-id. Thus, there are no real identification between the simulcast layer and the RTP stream level for which duplicated stream one changes. Thus, with pause or renegotiation there could be confusion about with of the RTP streams will be affected.
> 
> Secondly, when dealing with legacy receivers using PT mapping this type can't be done, as each simulcast stream needs an unique pt and thus individual rid-id also.
> 
> So thus we took the decision that not allowing multiple simulcast streams with identical rid-ids was simpler, and would eliminate some complexities from the implementations.
>>> Better?