Re: [payload] Problem with draft-ietf-payload-rtp-h265

[Stephan Wenger <[e-mail]>]

Hi Bernard,
Sorry for the late reply.
In London, we agreed that the signaling aspects of (what was then called) MST within one RTP session are out of scope for this payload format.  See here: http://www.ietf.org/proceedings/89/slides/slides-89-payload-6.pdf (presentation in London) and here http://www.ietf.org/proceedings/89/minutes/minutes-89-payload (minutes, including quote “The conclusion was to take MST support out of the document in order to finish the payload.”).  This was confirmed on the mailing list (by lack of objection to notes and my email requesting for objections) sometime in late April/early May of 2014.
Unless we change this agreement, the support for bundle-like mechanisms is out of scope for this draft.
In this light, I propose to modify our draft as shown inline and marked [StW].  These changes mostly soften previously overly tight language and clarify the scope.
For the I-D authors,
Stephan

From: Bernard Aboba <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, October 28, 2014 at 14:46
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: [payload] Problem with draft-ietf-payload-rtp-h265

Just noticed a bunch of problems introduced into the draft by the use of the "Single Stream Mode" and "Multiple Stream Mode" terminology.


   Dependency of one RTP stream on another RTP stream is typically
   indicated as specified in [RFC5583<https://tools.ietf.org/html/rfc5583>].  When an RTP stream A
   depends on another RTP stream B, the RTP stream B is referred to
   as a dependee RTP stream of the RTP stream A.




[BA] The statement above is wrong. RFC 5583 dependency groups based on the

use of a=group:DDP and a=mid: lines and therefore can only deal with

dependencies between m-lines (multiple RTP sessions).  If the RTP streams

are sent within the same RTP session, the dependency cannot be indicated as specified in RFC 5583.

[StW] Bernard’s statement is correct.  However, we had an agreement in London that this I-D does not deal with the complexities resulting from streams being sent in the same session (SSRC mutilplexing).  We concluded at the time that the generic problem of signaling things like dependencies will need to be addressed by a generic signaling mechanism, applicable to all payload formats.
Therefore, we propose to to clarify as follows:


   In some systems, the dDependency of one RTP stream on another RTP stream is typicallycan be

   indicated as specified in [RFC5583<https://tools.ietf.org/html/rfc5583>].  In the future, signaling mechanisms may become available that

   offer similar functionality also when multiple RTP stream are carried in the same RTP session,

   where the [RFC5583] mechanism does not apply.  Regardless of the signaling details, wWhen an RTP stream A

   depends on another RTP stream B, the RTP stream B is referred to

   as a dependee RTP stream of the RTP stream A.

[/StW]


      Informative note: An MSM may involve one or more RTP sessions.
      Each RTP stream in an MSM may be in its own RTP session or a
      set of multiple RTP streams in an MSM may belong to the same
      RTP session, e.g. as indicated by the mechanism specified in
      the Internet-Draft [I-D.ietf-avtcore-rtp-multi-stream<https://tools.ietf.org/html/draft-ietf-payload-rtp-h265-06#ref-I-D.ietf-avtcore-rtp-multi-stream>] or in
      [I-D.ietf-mmusic-sdp-bundle-negotiation<https://tools.ietf.org/html/draft-ietf-payload-rtp-h265-06#ref-I-D.ietf-mmusic-sdp-bundle-negotiation>].  This document is not

      addressing MSM scenarios in which multiple RTP streams are conveyed
      in the same RTP session (SSRC multiplexing).


   SSM SHOULD be used for point-to-point unicast scenarios, while
   MSM 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] This is also wrong. While it was accurate that Multi-Session-Transport

should be used for point-to-multipoint multicast scenarios, Single-Session-Transport

of multiple streams can be used in point-to-point unicast scenarios.

[StW] I think Bernard is right, again.  From a bandwidth viewpoint, the use of SSM and MSM do not necessarily make a difference.  It’s the same number of packets with the same packet overhead that are being sent.  When RoHC is in the picture, things may be different (SSRC cannot be compressed away), but do we really care about that scenario?  I start wondering why we wrote about the bandwidth thing (probably was me who wrote this, carelessly…)
I propose to remove the paragraph.  The note can stay, with the amendment shown.
[/StW]



   The transmission mode is indicated by the tx-mode media parameter
   (see section 7.1<https://tools.ietf.org/html/draft-ietf-payload-rtp-h265-06#section-7.1>).  If tx-mode is equal to "SSM", SSM MUST be
   used.  Otherwise (tx-mode is equal to "MSM"), MSM MUST be used.


[BA] This also does not make sense, because it will not allow for distinguishing

between multi-stream within a single session, and multi-session-transport.

Within SDP this is critical because RFC 5583 is not designed to deal with

single session-multi stream transport, and therefore we will get negotiation

failures.

[StW] As we are NOT addressing SSRC-based mutilplexing in this draft (except by forward looking statements in informative notes, as per London agreement), I think the sentence as written is correct.  However, I would agree that it is a bit misleading.  How about adding a note:


      Informative note: This document is not addressing MSM scenarios in which

      multiple RTP streams are conveyed in the same RTP session (SSRC multiplexing).




[/StW]


   Receivers MUST support both SSM and MSM.



[BA] This is a nice statement, but by the above confusion created by bad terminology will make it

meaningless.  Overall, this document creates additional confusion above and beyond that which we

already had in RFC 6190.

[StW] with above changes, I hope there is no confusion anymore.  Yes?