Subject: [MMUSIC] Adam Roach's Discuss on draft-ietf-mmusic-sdp-simulcast-12: (with DISCUSS and COMMENT)

From: Adam Roach <[email-masked]>
Date: Tue, 19 Jun 2018 19:43:15 -0700

Adam Roach has entered the following ballot position for
draft-ietf-mmusic-sdp-simulcast-12: Discuss

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/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thanks to everyone who put in the hard work to make this document happen. I have
found a blocking issue that I believe should be easy to address; but (due to the
potential impact on interoperability) document publication does need to be
blocked pending resolution of this issue. The problem is that the SDP examples
in this document are not consistent with the syntax and semantics defined in
draft-ietf-mmusic and draft-ietf-avtext-rid, as described below.

---------------------------------------------------------------------------

§4, Figure 1:

>  a=rid:1 send pt=97 max-width=1280;max-height=720
>  a=rid:2 send pt=98 max-width=320;max-height=180
>  a=rid:3 send pt=99 max-width=320;max-height=180
>  a=rid:4 recv pt=97

The final syntax for RID ended up with PT being treated the same as other
parameters, and therefore requiring a semicolon delimiter between it and
stream restrictions. So this example should read:

   a=rid:1 send pt=97;max-width=1280;max-height=720
   a=rid:2 send pt=98;max-width=320;max-height=180
   a=rid:3 send pt=99;max-width=320;max-height=180
   a=rid:4 recv pt=97

---------------------------------------------------------------------------

§4, Figure 1:

>  a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:RtpStreamId

Although the SDES item is called "RtpStreamId," the URN registered for its
identification is urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id -- see section
4.3 of draft-ietf-avtext-rid. This example should read:

   a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id

---------------------------------------------------------------------------

The preceding two comments regarding SDP syntax also apply to Figure 2,
Figure 5, Figure 6, Figure 7, and Figure 8.

---------------------------------------------------------------------------

Figure 8 (which is missing a figure label):

>  a=rid:5 send pt=99,102;max-br=64000
>  a=rid:6 send pt=100,97,101,102

The selection of "5" and "6" for these RIDs goes against the advice in section
3.3 of draft-ietf-avtext-rid; and, even worse, may give the incorrect impression
that RID space is shared between media sections. Please adjust them to be 1 and
2 instead of 5 and 6.

Also, if LPC is intended to be used with the first RID (as is suggested by the
text above the example), then your "pt" value needs to be "pt=99,102,98" --
otherwise, the RID will prevent the use of PT 98. Remember: RID defines
*restrictions*. If you say "pt" and then don't list a PT in it, then that
missing PT is strictly forbidden from appearing with that RID.

There is a similar problem with the video section, which needs to read as
follows to match the explanatory text:

   a=rid:1 send pt=103,105,107;max-width=1280;max-height=720;max-fps=30
   a=rid:2 send pt=104,106,107;max-width=1280;max-height=720;max-fps=30
   a=rid:3 send pt=103,105,107;max-width=640;max-height=360;max-br=300000
   a=rid:4 send pt=104,106,107;max-width=640;max-height=360;max-br=300000

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

I will be recusing myself from a ballot position once the preceding issues
have been resolved, as I am a contributor to this document. I found some minor
issues and a number of editorial nits that warrant correction prior to
publication.

---------------------------------------------------------------------------

§1:

>  Usage of multicast or broadcast transport is out of scope and left
>  for future extension.

"...future extensions."

---------------------------------------------------------------------------
§1:

>  This document describes a few scenarios that motivates the use of

"...that motivate the use..."

---------------------------------------------------------------------------

§3:

>  There are two principle approaches for an RTP Mixer to provide this

"...two principal approaches..."

---------------------------------------------------------------------------

§5.1:

>   sc-send      = "send" SP sc-str-list
>   sc-recv      = "recv" SP sc-str-list

While it's a bit muddled in the base SDP spec, it appears that the general
convention here is to make SDP strings case-sensitive. I believe this document
wants to cite RFC 7405, and adjust these two lines to read:

    sc-send      = %s"send" SP sc-str-list
    sc-recv      = %s"recv" SP sc-str-list

---------------------------------------------------------------------------

§5.2:

>  there is currently no mechanism for align the choice between
>  alternative rid-ids between different simulcast streams.

"...mechanism to align..."

---------------------------------------------------------------------------

Figure 7:

>  m=video 49602 RTP/AVPF 96 104
>  a=mid:zen
>  a=rtpmap:96 VP8/90000
>  a=fmtp:96 max-fs=3600; max-fr=30
>  a=rtpmap:104 rtx/90000
>  a=fmtp:104 apt=96;rtx-time=200
>  a=rid:1 send pt=96;max-fs=921600;max-fps=30
>  a=rid:2 send pt=96;max-fs=614400;max-fps=15
>  a=rid:3 send pt=96;max-fs=230400;max-fps=30
>  a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
>  a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:RtpStreamId
>  a=rtcp-fb:* ccm pause nowait
>  a=simulcast:send 1;~2;~3

While this isn't technically invalid (modulo the extmap lines), it's saying
something a bit odd. Namely, it's offering to use RTX if the answerer doesn't
understand RID, but forbidding the use of RTX if they do. You probably meant
something more like:

   a=rid:1 send pt=96,104;max-fs=921600;max-fps=30
   a=rid:2 send pt=96,104;max-fs=614400;max-fps=15
   a=rid:3 send pt=96,104;max-fs=230400;max-fps=30

Or, really, since that's all the PTs that are defined for this media section,
just leave it out altogether:

   a=rid:1 send max-fs=921600;max-fps=30
   a=rid:2 send max-fs=614400;max-fps=15
   a=rid:3 send max-fs=230400;max-fps=30

Either way is valid and sensible -- the second might be a better example,
since it demonstrates the use of simulcast without payload-restricted RID
lines. You don't want to give the erroneous impression that "pt" is required
on the RID line for simulcast to work.

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 21 Jun 2018 16:43:25 +0200

Hi Adam,

I think we have one real issue  beyond the inconsistencies that clearly 
was not updated to the latest syntax and some other mistakes. Thanks for 
catching these.

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

Snipped a number of editorial things that I fully agree needs to be 
changed.

> missing PT is strictly forbidden from appearing with that RID.

Yes, but 98 will never occur in an RTP payload header in this 
configuration, it will only be encapsulated in the RED payload format 
(100). See the mmusic-RID drafts section 8.3 that contains this example 
focused on this particular issue.

>     a=rid:4 send pt=104,106,107;max-width=640;max-height=360;max-br=300000

Here we get into the real issue as I see it. My interpretation of RID 
and what Simulcast says is that the RTX and flexfec streams related to 
any Simulcast streams are not indicated in the PT list for the RID. 
This, due to that they are separate RTP streams. And for example a 
Flex-Fec stream could be related to multiple simulcast streams' packets.

draft-ietf-mmusic-rid-15 Section 4 says:

    Implementations that use the "a=rid" parameter in SDP and that make
    use of redundancy RTP streams [RFC7656], e.g.  RTP RTX [RFC4588] or
    FEC [RFC5109], for any of the source RTP streams that have "a=rid"
    lines remaining after applying the rules in Section 6 and its
    subsections, MUST support the RepairedRtpStreamId SDES item described
    in [I-D.ietf-avtext-rid] for those redundancy RTP streams.
    RepairedRtpStreamId MUST be used for redundancy RTP streams to which
    it can be applied.

    The redundancy RTP
    stream MAY (but need not) have an "a=rid" line of its own, in which
    case the RtpStreamId SDES item value will be different from the
    corresponding source RTP stream.

    Section 8.3 which contains the rest of discussion of redundancy 
which is focused only on RED type
   formats.

    draft-ietf-mmusic-simulcast-12 does not contain any discussion 
beyond the example in 5.6.3 of redundancy.

So this only requires the use of RepairedRtpStreamId which the example 
does not include as an RTP header extension, I will fix this.

So maybe it should be a requirement to indicate in the RID which 
redundancy mechanisms that will be applied to the different simulcast 
streams, however currently this definition are in my view done only on 
media description (m=) level and thus in Figure 8 flexfec can be applied 
to any simulcast stream, while RTX is defined for retransmitting packets 
with payload type 103 and 104. And likely if this is to be address this 
is a change to mmusic-RID.

The editorials I have removed and will make.

> on the RID line for simulcast to work.

Agree that we should go with the later as example here. The first part 
of the comment I would refer back to the main open issue.

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: Adam Roach <[email-masked]>
Date: Thu, 21 Jun 2018 10:57:41 -0500

On 6/21/18 09:43, Magnus Westerlund wrote:
> Hi Adam,
>
> I think we have one real issue  beyond the inconsistencies that 
> clearly was not updated to the latest syntax and some other mistakes. 
> Thanks for catching these.
>

Thanks. Replies inline.

> (100). See the mmusic-RID drafts section 8.3 that contains this 
> example focused on this particular issue.

Ah, okay. Yep, I see that now.

>>     a=rid:3 send 
>> pt=103,105,107;max-width=640;max-height=360;max-br=300000
>>     a=rid:4 send 
>> pt=104,106,107;max-width=640;max-height=360;max-br=300000
>

Right. I think I was thrown off because there wasn't any repair-stream 
marking. I agree that the only fix needed here is to add another extmap 
line. (BTW, the typo for the corresponding URN in avtext-rid has already 
been fixed in an RFC editor note.)

> media description (m=) level and thus in Figure 8 flexfec can be 
> applied to any simulcast stream, while RTX is defined for 
> retransmitting packets with payload type 103 and 104. And likely if 
> this is to be address this is a change to mmusic-RID.

No, I don't think a change in mechanism is needed here. Nailing things 
down to the degree you describe doesn't seem to serve a useful purpose. 
If a legitimate use case arises in the future, it can be added as an 
extension to mmusic-rid.

...
> of the comment I would refer back to the main open issue. 

Right. Resolve figure 7 the same way as figure 8.

Thanks!

/a