[RAI] Using media stream signaling in media plane or in signaling plane (re-send)

[Bo Burman <[e-mail]>]

As part of the comments during IETF 83 on the following drafts

* Media Stream Selection (https://datatracker.ietf.org/doc/draft-westerlund-dispatch-stream-selection/)
* PAUSE / RESUME (https://datatracker.ietf.org/doc/draft-westerlund-avtext-rtp-stream-pause/)
* Codec Operation Point (https://datatracker.ietf.org/doc/draft-westerlund-avtext-codec-operation-point/)

there was a discussion on the reasons to use one technology or the other for signaling related to specific media streams. The community was lacking knowledge of the performance implications coming from transporting information using a specific technology, and wanted a discussion on this mailing list.

I want to provide input to this discussion and have performed a comparison between using RTCP and using SIP as signaling technology for a particular purpose. I chose, more or less arbitrarily, this purpose to be sending a "PAUSE" command from a media receiver to a media sender for a specific RTP media stream (identified by SSRC).

Very briefly, these are the results (extracts from Section 5.1 of PAUSE / RESUME draft above, where more detailed descriptions of pre-conditions and assumptions can be found):

   The targeted topology is outlined in the following figure.

                  Provider A's network  .  Provider B's network
                                        .
   +-----+ SIP +------+ SIP +-------+  SIP  +-------+ SIP +-----+
   |Proxy|<--->| AS A |<--->| SGW A |<--.-->| SGW B |<--->|Proxy|
   +-----+     +------+     +-------+   .   +-------+     +-----+
       ^          ^                     .                    ^
       |          | SIP/H.248           .                    |
       |          v                     .                    |
   SIP |       +-----+ RTCP +-------+ RTCP  +-------+    SIP |
       |       | MCU |<---->| BGW A |<--.-->| BGW B |        |
       |       +-----+      +-------+   .   +-------+        |
       v         ^                      .       ^            v
   +------+     / RTCP                  .        \  RTCP  +------+
   | UA A |<---+                        .         +------>| UA B |
   +------+                             .                 +------+

   In the figure above, UA is a SIP User Agent, Proxy is a SIP Proxy, AS
   is an Application Server, MCU is a Multipoint Conference Unit, SGW a
   Signaling GateWay, and BGW a media Border GateWay.
   ...

   As a partial result, the message sizes can be compared, based on the
   messages defined in this specification (Section 8) and a SIP UPDATE
   with contents (Section 10) as discussed above.  Favorable and
   unfavorable message sizes are presented as stacked bars in the figure
   below.  Message sizes include IPv4 headers but no lower layer data,
   are rounded to the nearest 25 bytes, and the bars are to scale.

            250       500       750      1000      1250      1500 [byte]
   +---------+---------+---------+---------+---------+---------+--> Size
   |
   +-+--+
   | |50| 125 RTCP
   +-+--+---------------+--------------------------------------------+
   | SIP                | 525                                   1650 |
   +--------------------+--------------------------------------------+
   |
   ...
Favorable RTCP size comes from using non-compound RTCP packets.
Favorable SIP size comes from using dynamic SIP SigComp.
   ...

   The signaling delay results of the study are summarized in the
   following two figures.  Favorable and unfavorable values are
   presented as stacked bars.  Since there are many factors that impact
   the calculations, including some random processes, there are
   uncertainty in the calculations and delay values are thus rounded to
   nearest 5 ms.  The bars are to scale.

             50       100       150       200       250       300   [ms]
   +---------+---------+---------+---------+---------+---------+---> t
   |
   | Wireless UA to Wireless UA
   +---------------------+--------------------------------------+
   | SIP                 | 110                                  | 305
   +-----+---------------+-----------------------------+--------+
   |RTCP | 30                                          | 260
   +-----+---------------------------------------------+
   |
   | Wireless UA to MCU
   +-------------+--+
   | SIP         |70| 85
   +----+--------+--+--------------------------+
   |RTCP| 25                                   | 225
   +----+--------------------------------------+
   |
   | MCU to Wireless UA
   +--------------+-----------------------------------+
   | SIP          | 75                                | 255
   +---+----------+------------------------------+----+
   |   | 20 RTCP                                 | 230
   +---+-----------------------------------------+
   |
   ...

It should be noted that RTCP scheduling above is based on a 200 kbps media stream, leaving only 10 kbps (5%) for RTCP traffic, even for the favorable case. Should the media stream instead be 1000 kbps (50 kbps RTCP), the unfavorable RTCP delays will be reduced from 260 ms to 115 ms for Wireless-Wireless, from 225 ms to 80 ms for Wireless-MCU, and from 230 ms to 80 ms for MCU-Wireless.

   ...
   Below are the same cases for fixed access depicted.  Although delays
   are generally shorter, scales are kept the same for easy comparison
   with the previous figure.

             50       100       150       200       250       300   [ms]
   +---------+---------+---------+---------+---------+---------+---> t
   |
   | Fixed UA to Fixed UA
   +------------+
   | SIP        | 65
   +----+-------+---------------------------+
   |RTCP| 25                                | 205
   +----+-----------------------------------+
   |
   | Fixed UA to MCU
   +---------+
   | SIP     | 50
   +---+-----+-----------------------+
   |   | 15 RTCP                     | 200
   +---+-----------------------------+
   |
   | MCU to Fixed UA
   +---------+
   | SIP     | 50
   +---+-----+-----------------------+
   |   | 15 RTCP                     | 200
   +---+-----------------------------+
   |

As can be seen, there is no obvious winner in all cases. RTCP is definitely more compact, even when using SIP SigComp. Regarding response time, RTCP is more beneficial unless it is subject to unfavorable scheduling rules, too low bandwidth, or both, in which case SIP can perform better.

This rises further questions to be able to make an informed choice:
* Are there other, general, reasons or recommendations that should
  be taken into account when choosing signaling technology?
* What should the signaling strategy be when there are multiple nodes
  that need the signaled information, possibly not being in the direct
  route between the signaling peers?

My own conclusion is that I would prefer using RTCP for this type of media stream-related signaling, since:
* The media stream-related signaling does not have any major impact on
  the session itself, only what can be considered normal in-session
  variations, and thus there should be no need to notify all session-
  handling functions via SIP
* All media-handling nodes are already in the media path and will
  automatically have access to this new signaling, but may of course
  have to implement support for it if they need to act on it
* The difference in signaling bandwidth is definitely in RTCP's favor
* The RTCP signaling delay has a clear potential to be lower than SIP
  and it should already be possible to configure RTCP such that this
  low delay can be achieved in a large majority of cases

Comments on the above are greatly appreciated!

Cheers,

Bo Burman

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Färögatan 6                 | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------