Subject: [payload] #6: Section 4.4: SST vs. MST

From: "payload issue tracker" <[email-masked]>
Date: Tue, 10 Dec 2013 03:27:38 -0000

#6: Section 4.4:  SST vs. MST

 This memo enables transmission of an HEVC bitstream over a single
    RTP session or multiple RTP sessions.  The concept and working
    principle is inherited from [RFC6190] and follows a similar design.
    If only one RTP session is used for transmission of the HEVC
    bitstream, the transmission mode is referred to as single-session
    transmission (SST); otherwise (more than one RTP session is used for
    transmission  of  the  HEVC  bitstream),  the  transmission  mode  is
    referred to as multi-session transmission (MST).

 [BA] This definition strikes me as inexact, because with BUNDLE, it is
 possible for RFC 5583 to be used to negotiate "MST" usage within a single
 RTP session.  However, such an implementation sending multiple SSRCs on
 the same RTP session would not really be "SST", would it?

 In reality, the Multi-Session vs. Single-the distinction is not the
 salient one -- it is Single SSRC Transport vs. Multiple SSRC Transport.

    SST SHOULD be used for point-to-point unicast scenarios, while MST
    SHOULD be used for point-to-multipoint multicast scenarios where
    different receivers require different operation points of the same
    HEVC bitstream, to improve bandwidth utilizing efficiency.

 [BA] While "Multi-Session Transport" is indeed more appropriate for
 multicast scenarios, "Multi-SSRC Transport" is also used for unicast
 scenarios.  So this aspect could also be better explained.

 In addition to the unicast vs. multicast distinction, I'd like to see the
 text go into the advantages/disadvantages of SST vs. MST in unicast
 scenarios.  Advantages of MST include:

 a. Not requiring sequence number rewriting on layer drops
 b. Ability to utilize stream pause/resume RTCP messages
 c. Potential improvements in ability to utilize RTCP reports to diagnose
 SVC performance
 d. Ability to negotiate FEC on some layers but not all
 e. Explicit negotiation of layering in SDP

 There are also some disadvantages, such as:

 g. Need to utilize DON and/or timestamp for order recovery.

    The transmission mode is indicated by the tx-mode media parameter
    (see section 7.1).  If tx-mode is equal to "SST", SST MUST be used.
    Otherwise (tx-mode is equal to "MST"), MST MUST be used.

 [BA] Overall, I'd like to see this document have a goal to make progress
 beyond RFC 6190 by eliminating interoperability failures between SST and
 MST transport implementations.

 IMHO, with WebRTC on the horizon (where there may be no SDP exchange), we
 are increasingly moving to codecs that "just work", rather than those that
 rely on O/A to negotiate "modes" (and sometimes failing to find common
 ground). Can we instead strive for interoperability by design?

 With the commendable reduction in packet formats (e.g. STAP-A/B & FU-A/B
 -> AP & FU) would it be possible to mandate support for both MST and SST
 or at least mandate support for one of them in unicast & multicast
 scenarios?

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |      Owner:  draft-ietf-payload-
  [email-masked]          |  [email-masked]
     Type:  defect                   |     Status:  new
 Priority:  blocker                  |  Milestone:  milestone1
Component:  rtp-h265                 |    Version:  1.0
 Severity:  Candidate WG Document    |   Keywords:
-------------------------------------+-------------------------------------

Ticket URL: <http://tools.ietf.org/wg/payload/trac/ticket/6>
payload <http://tools.ietf.org/payload/>

---

From: Stephan Wenger <[email-masked]>
Date: Wed, 18 Dec 2013 23:31:47 +0000

Hi Bernard, all,

Bernard, thanks for writing up these detailed notes.  They are quite
helpful.

As for the general philosophy on how to deal with multiplexing schemes and
BUNDLE, please see my reply to Ticket #7.

More details inline.

> the same RTP session would not really be "SST", would it?

In the pre-BUNDLE and SSRC mux age, the distinction made was solid and
consistent.  Are we sure that we are already in the post-BUNDLE age, when
it comes to the use of H.265?  Could we kick that can down the road?

> salient one -- it is Single SSRC Transport vs. Multiple SSRC Transport.

We could introduce the notion of SSRC multiplexing into the draft.  Doing
so has certain risks, the main one being that the amount of documented
implementation experience in this field is limited--certainly for the case
of layered or simulcast codecs and absolutely for H.265 in a layered mode.
 In the interest of full disclosure: we in Vidyo have been doing something
like this ion the transport plane for ages, and we know it works in our
application.  However, until just recently we were quite lonely in this
camp.  Beyond that, to me, the tricky part is the signaling support.
Implementation experience with BUNDLE in the layered codec case is
limited.    

> scenarios.  So this aspect could also be better explained.

It is, no doubt.  Is the payload format the right place to document that?
Was it at the time of RFC6190?  As I said before in my response to Ticket
#7: having now the benefit of hindsight, I¹m quite certain that we made a
serious mistake when we added the SST/MST differentiation into the SVC
payload spec.  I¹m very reluctant to pile onto that mistake for the
transport mode that is currently in fashion.  OTOH, I¹m also very
reluctant to try to ³clean up² the signaling by ripping out all we have
and start from fresh.  I rather go conservative with a spec that works in
all documented cases, and leave the design work towards new operation
modes for other documents.

> g. Need to utilize DON and/or timestamp for order recovery.

We could add those points.  Thanks for writing them up.  But again, this
is stuff that is not really H.265 related (or related to any other
specific scalable/simulcast payload), right?  More and more reason to
write up a general layered/simulcast (dare I add multiple description)
transport architecture doc.

> or at least mandate support for one of them in unicast & multicast

Enthusiastically agreed in spirit, and not only because of rtcweb.  I
personally have no objection to require all receivers to implement both
MST and SST.  But note though, that there are still a number of use cases
where full capability exchange is available, and where users are (or
pretend to be) worried about implementation complexity.  I¹m personally
willing to push; let¹s see what the group thinks.

Regards,
Stephan

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 20 Dec 2013 09:39:10 -0800

> it comes to the use of H.265?  Could we kick that can down the road?
[BA] It is possible (and maybe even advisable) for the H.265 draft to avoid a dependency on the BUNDLE and the appID drafts.   That would imply using the same SDP facilities as were utilized in the examples of RFC 6184 and 6190. But that seems ok. 
> camp.  Beyond that, to me, the tricky part is the signaling support.
[BA] In terms of RTP transport (e.g. use of DONL field), the distinction is really whether you have a single sequence number space (single SSRC) or not (multiple SSRC, whether on a single RTP session or not).  That much seems worth clarifying. 
> I personally have no objection to require all receivers to implement both

[BA] It seems like a useful goal to ensure that temporal scalability "just works", regardless of whether SST or MST transport is in use.  For example, I noted with approval that the "mst-mode" parameter from RFC 6190 was not included in this draft.  
> More and more reason to write up a general layered/simulcast (dare I add multiple description)
[BA] Not a bad idea.

---

From: "Wang, Ye-Kui" <[email-masked]>
Date: Mon, 23 Dec 2013 19:50:51 +0000

I am trying to cover the discussions on issue #7 in another thread as well (these two #6 and #7 are closed related anyway).

One thing I am not clear is why there is an IOP issue with SST and MST for H.265. In RFC 6190 (the SVC payload format), there could be such an issue as different sets of payload structures are used for SST and MST therein. However, in the H.265 payload draft, SST and MST use the same set of payload structures. From a full implementation point of view, SST is a subset of MST as MST implementation requires more code than SST for handling the difference sources of the RTP streams. However, if purely from de-packetization point of view, they are identical, as can be seen from the unique de-packetization process in Section 6 of the draft. Thus, I think there won't be an IOP issue even if not both SST and MST are required. On the other hand, I think it actually makes sense to require the support of both SST and MST in this payload format due to that they use the same set of payload structures and the same de-packetization process, also as Bernard correctly said, in a similar spirit, in the other thread, "Assuming that implementations correctly handle DON, we should be most of the way there anyway." Thus, I'd suggest that we go ahead to do this, and I will include it into the next version, unless there are other opinions expressed such that this cannot be considered as a consensus.

Another point of Bernard I have thought in a similar way is the following:
[BA] In terms of RTP transport (e.g. use of DONL field), the distinction is really whether you have a single sequence number space (single SSRC) or not (multiple SSRC, whether on a single RTP session or not).  That much seems worth clarifying.

I was thinking if we specify SST and MST as "Single-Stream Transmission" and "Multi-Stream Transmission" instead of "Single-Session Transmission" and "Multi-Session Transmission", then it would simply applies to whatever multiplexing scheme, multiple sessions or within one session, or even mixed. From de-packetization point of view, there is no difference among all these, as they all just need to follow the simple, less-than-one-page de-packetzation process specified in Section 6 of the draft. Is "RTP Stream" a correct term to be used here? I'd admit I am not good at the terms of RTP session, RTP stream, and so on. If we specify this way, using the correct term (whatever that is), then the design can work with both pre-BUNDLE-and-SSRC-mux age and post-BUNDLE-and-SSRC-mux age. And we don't have to let this payload draft have a normative referencing dependency on the BUNDLE draft (and other similar signalling drafts), rather they can be just mentioned as example mux mechanisms used and included in informative references. Opinions?

BR, YK

From: payload [mailto:[email-masked]] On Behalf Of Bernard Aboba
Sent: Friday, December 20, 2013 9:39 AM
To: Stephan Wenger; [email-masked]
Cc: [email-masked]
Subject: Re: [payload] #6: Section 4.4: SST vs. MST

[BA] Not a bad idea.

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 23 Dec 2013 15:54:26 -0500

I think use of the terms "single stream" and "multiple stream" would be an improvement. Also agree with your other recommendations.

> On Dec 23, 2013, at 2:50 PM, "Wang, Ye-Kui" <[email-masked]> wrote:
> 
> One thing I am not clear is why there is an IOP issue with SST and MST for H.265. In RFC 6190 (the SVC payload format), there could be such an issue as different sets of payload structures are used for SST and MST therein. However, in the H.265 payload draft, SST and MST use the same set of payload structures. From a full implementation point of view, SST is a subset of MST as MST implementation requires more code than SST for handling the difference sources of the RTP streams. However, if purely from de-packetization point of view, they are identical, as can be seen from the unique de-packetization process in Section 6 of the draft. Thus, I think there won’t be an IOP issue even if not both SST and MST are required. On the other hand, I think it actually makes sense to require the support of both SST and MST in this payload format due to that they use the same set of payload structures and the same de-packetization process, also as Bernard correctly said, in a similar spirit, in the other thread, “Assuming that implementations correctly handle DON, we should be most of the way there anyway.” Thus, I’d suggest that we go ahead to do this, and I will include it into the next version, unless there are other opinions expressed such that this cannot be considered as a consensus.
>  
> I was thinking if we specify SST and MST as “Single-Stream Transmission” and “Multi-Stream Transmission” instead of “Single-Session Transmission” and “Multi-Session Transmission”, then it would simply applies to whatever multiplexing scheme, multiple sessions or within one session, or even mixed. From de-packetization point of view, there is no difference among all these, as they all just need to follow the simple, less-than-one-page de-packetzation process specified in Section 6 of the draft. Is “RTP Stream” a correct term to be used here? I’d admit I am not good at the terms of RTP session, RTP stream, and so on. If we specify this way, using the correct term (whatever that is), then the design can work with both pre-BUNDLE-and-SSRC-mux age and post-BUNDLE-and-SSRC-mux age. And we don’t have to let this payload draft have a normative referencing dependency on the BUNDLE draft (and other similar signalling drafts), rather they can be just mentioned as example mux mechanisms used and included in informative references. Opinions?
>  
> BR, YK
>