Subject: Re: [MMUSIC] Simulcast draft review needed

From: Adam Roach <[email-masked]>
Date: Wed, 19 Oct 2016 18:12:28 -0500

On 9/22/16 18:44, Flemming Andreasen wrote:
> Please note that we also have the simulcast draft
>
> https://www.ietf.org/id/draft-ietf-mmusic-sdp-simulcast-05.txt
>
> to go along with this, and we really need some reviews of that one 
> too. If you have some time to review it, please do so and send your 
> comments to the list (incl. "looks good"). 

I'm one of the dedicated volunteers who agreed to review this document. 
I apologize for the delay in providing feedback.

In general, this document looks to be in really good shape. I have a 
handful of comments, some editorial, and some minor technical. I don't 
see any major technical issues. The largest issue I have is that one of 
the examples contravenes the recommendations in avtext-rid, and is 
consequently likely to cause interop failures.

Technical:

Section 4, REQ-1.2 -- it's not clear to me how this requirement is met. 
The current mechanism does not allow implementations to determine which 
streams are part of a single simulcast media source by looking at the 
RTP/RTCP in isolation. The SDP must be used in concert with the RTP/RTCP 
information. This requirement needs to be either removed or clarified.

Section 6.3.2, paragraph 3, states: "The answerer MUST NOT add any 
alternative SCID that were not present in the offer." This seems like an 
odd restriction on SCID in the send direction. It is not reasonable for 
the offerer to know how many Simulcast Formats a single Simulcast Stream 
that the other end can send might be expressed in. Functionally, this is 
the same as saying that the offerer gets to choose how many PTs the 
answer is allowed to contain, which is a new (and presumably 
unnecessary) restriction. The minimal change to fix this issue would be 
to add "in the receive direction" to the sentence I quote.

I'm sure the conversation happened after -05 was published, but to make 
sure it doesn't get lost: we're not supporting declarative use, so 
section 6.4 should be removed.

The most complicated SDP example (Figure 6, on page 20) uses 
nonoverlapping RIDs for the two different video media sections. This 
implies that the RID space is globally unique in some way. In practice, 
RIDs are scoped to be unique only within a single media section. 
Implementors are likely to incorrectly infer from this example that RIDs 
need to be unique even between media sections, which can lead to interop 
failures. Please adjust the example so that the RIDs in the second media 
section start over at 1 rather than resuming where the first video 
section left off.

Editorial:

In the terminology section, the second sentence of the definition of 
Simulcast Streams (starting "Decoding a dependent stream...") is 
difficult to parse and difficult to understand. Assuming I did 
eventually understand what it's saying, I don't think it necessary or 
helpful, and can probably be removed rather than fixed.

The first comma in the definition of Simulcast Format should be a colon.

Section 3 should also mention the use case in which the media switch 
does not have access to the media contents, as in the type of 
conferences that PERC is being designed for.

Section 3.2 should contain commas around the phrase "for example" in the 
second sentence of the first paragraph.

The prose in section 6.1 seems to suffer from the lack of a formal term 
for the construct that the ABNF calls "sc-alt-list." For example, the 
third paragraph says "each SCID is separated by a semicolon." That's 
inaccurate and confusing: the syntax clearly indicates that SCIDs are 
indicated by commas, and the "sc-alt-list" construct is separated by 
semicolons. I think the smallest change we can make to fix this is to 
say "each _stream_ is separated by as semicolon", but that's a bit 
unsatisfying. I think it would be better to define an English term for 
this "sc-alt-list" thing and use it where appropriate.

This missing terminology shows up again in the fourth paragraph of 
section 6.2: the construct "The number of (non-alternative, see above) 
SCID..." is awkward and hard to follow. If we define a term that means 
this "sc-alt-list" thing, it should be used here. If we don't, then I 
again suggest using the term "stream" rather than "(non-alternative, see 
above) SCID".

In the seventh paragraph of section 6.2 (starting "A simulcast 
stream..."), the sentence "...such 'related' formats MUST NOT be defined 
as SCID and listed..." needs to have something like "having their own" 
inserted, to read: "...such 'related' formats MUST NOT be defined as 
having their own SCID and listed..."

The following paragraph contains a sentence fragment that can be turned 
into a sentence by changing "...each of which can be individually 
prefixed..." to "...each can be individually prefixed..."

The final paragraph of section 6.3.2 contains a comma preceded by a 
space. This comma should be removed.

Section 8 should clearly indicate that the technique described in the 
third paragraph is out of scope for this document, and that additional 
specification would be necessary to implement simulcast in a multicast 
context.

/a

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 21 Oct 2016 11:52:55 +0200

Thanks Adam,

We will work on a update to meet the deadline where we will make our 
best to incorporate your feedback. My read through indicates that they 
are reasonable comments. And first after having thought through them and 
attempted implementing them will I know if there some issues with them. 
So a follow up after implementing the changes.

Cheers

Magnus

Den 2016-10-20 kl. 01:12, skrev Adam Roach:
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

-- 

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Bo Burman <[email-masked]>
Date: Mon, 31 Oct 2016 16:31:58 +0000

Hi Adam,

Thank you for the review and for good comments! I'm in the process of making edits to the upcoming version of the draft (to be submitted before deadline). Please see my responses inline below.

Cheers,
/Bo (as individual)

> -----Original Message-----
> From: mmusic [mailto:[email-masked]] On Behalf Of Magnus Westerlund
> Sent: den 21 oktober 2016 11:53
> To: Adam Roach <[email-masked]>; Flemming Andreasen <[email-masked]>; mmusic <[email-masked]>
> Subject: Re: [MMUSIC] Simulcast draft review needed
> 
> Thanks Adam,
> 
> We will work on a update to meet the deadline where we will make our best to incorporate your feedback. My read
> through indicates that they are reasonable comments. And first after having thought through them and attempted
> implementing them will I know if there some issues with them.
> > see any major technical issues. The largest issue I have is that one
> > of the examples contravenes the recommendations in avtext-rid, and is
> > The current mechanism does not allow implementations to determine
> > which streams are part of a single simulcast media source by looking
> > at the RTP/RTCP in isolation. The SDP must be used in concert with the
> > RTP/RTCP information. This requirement needs to be either removed or clarified.
[BoB] That is actually true. Good catch. I believe this requirement to be a remnant from the time we had ideas of including a "structured" ID in the RTP packets. I don't know to what extent this requirement is still desirable, but I'm personally open to remove it. The now used RtpStreamId actually has no specific value restrictions apart from the security considerations expecting them to be opaque, which I interpret as it could be possible to re-introduce RtpStreamId structuring that would satisfy REQ-1.2.

> > alternative SCID that were not present in the offer." This seems like
> > an odd restriction on SCID in the send direction. It is not reasonable
> > for the offerer to know how many Simulcast Formats a single Simulcast
> > Stream that the other end can send might be expressed in.
> > Functionally, this is the same as saying that the offerer gets to
> > choose how many PTs the answer is allowed to contain, which is a new
> > (and presumably
> > unnecessary) restriction. The minimal change to fix this issue would
> > be to add "in the receive direction" to the sentence I quote.
[BoB] OK. Would this be acceptable: "The answerer MUST NOT add any alternative SCID in send direction in the answer that were not present in the offer receive direction"?

> >
> > I'm sure the conversation happened after -05 was published, but to
> > make sure it doesn't get lost: we're not supporting declarative use,
> > so section 6.4 should be removed.
[BoB] OK, good. I did not remove it, but changed content of 6.4 to basically say the same as mmusic-rid section 7; not defined for declarative SDP, but can be addressed by additional specification in the future.

> > implies that the RID space is globally unique in some way. In
> > practice, RIDs are scoped to be unique only within a single media section.
> > Implementors are likely to incorrectly infer from this example that
> > RIDs need to be unique even between media sections, which can lead to
> > interop failures. Please adjust the example so that the RIDs in the
> > second media section start over at 1 rather than resuming where the
> > first video section left off.
[BoB] No problem. Done.

> > helpful, and can probably be removed rather than fixed.
[BoB] Agree. Removed.

> > The first comma in the definition of Simulcast Format should be a colon.
[BoB] Thanks.

> > conferences that PERC is being designed for.
[BoB] OK. Added.

> >
> > Section 3.2 should contain commas around the phrase "for example" in
> > the second sentence of the first paragraph.
[BoB] OK

> >
> > The prose in section 6.1 seems to suffer from the lack of a formal
> > term for the construct that the ABNF calls "sc-alt-list." For example,
> > the third paragraph says "each SCID is separated by a semicolon."
> > That's inaccurate and confusing: the syntax clearly indicates that
> > SCIDs are indicated by commas, and the "sc-alt-list" construct is
> > separated by semicolons. I think the smallest change we can make to
> > fix this is to say "each _stream_ is separated by as semicolon", but
> > that's a bit unsatisfying. I think it would be better to define an
> > English term for this "sc-alt-list" thing and use it where appropriate.
[BoB] I discussed this with Magnus, went through the entire text and tried to consistently reflect that a simulcast stream (separated by semicolon and thus effectively an "sc-alt-list") can be expressed as having one or more simulcast formats (separated by comma), and that each simulcast format is identified/represented by the SCID.

> > again suggest using the term "stream" rather than "(non-alternative,
[BoB] Changed according to the above.

> > stream..."), the sentence "...such 'related' formats MUST NOT be
> > defined as SCID and listed..." needs to have something like "having their own"
[BoB] OK

> >
> > The following paragraph contains a sentence fragment that can be
> > turned into a sentence by changing "...each of which can be
> > individually prefixed..." to "...each can be individually prefixed..."
[BoB] OK

> > space. This comma should be removed.
[BoB] OK

> > specification would be necessary to implement simulcast in a multicast
[BoB] OK. Done.