Subject: [AVTCORE] ECN for RTP: Multiple SSRC init optimization

From: Magnus Westerlund <[email-masked]>
Date: Wed, 20 Apr 2011 14:16:37 +0200

Hi,

We had some discussion in Prague in the meeting session regarding what
optimization one should do for using multiple SSRCs in one RTP session
on one end-point, i.e. someone that sends multiple SSRCs from the same
transport protocol, port and address when using unicast.

It was clear that it was desirable to optimize this case. However, we
appear to have issues finding an optimization that is generally
applicable to the different potential deployments that can contain unicast.

As WG editors we don't see much choice than to continue without an
optimization. If someone has a good idea for how it could work please
contribute it.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 28 Apr 2011 11:29:14 +0200

Hi,

I actually have thought a bit more about this and changed my mind about
it. It appears that same CNAME is actually reasonable and the failure
mode is when you have a decomposited design of a node. That is not
common and it appears reasonable to lay the burden on them. Also the
failure mode isn't that bad as the verification will detect if there is
an issue.

So I have written up text for this for Section 7.2.1:

   Determination of ECN Support:  RTP is a group communication protocol,
      where members can join and leave the group at any time.  This
      complicates the ECN initiation phase, since the sender must wait
      until it believes the group membership has stabilised before it
      can determine if the paths to all receivers support ECN (group
      membership changes after the ECN initiation phase has completed
      are discussed in Section 7.3).

      An RTP sender shall consider the group membership to be stable
      after it has been in the session and sending ECT-marked probe
      packets for at least three RTCP reporting intervals (i.e., after
      sending its third regularly scheduled RTCP packet), and when a
      complete RTCP reporting interval has passed without changes to the
      group membership.  ECN initiation is considered successful when
      the group membership is stable, and all known participants have
      sent one or more RTCP ECN feedback packets indicating correct
      receipt of the ECT-marked RTP packets generated by the sender.

      As an optimisation, if an RTP sender is initiating ECN usage
      towards a unicast address, then it MAY treat the ECN initiation as
      provisionally successful if it receives RTCP ECN feedback report
      indicating successful receipt of the ECT-marked packets, with no
      negative indications, from a single RTP receiver.  Where a single
      RTP receiver is considered as all SSRCs used by a single CNAME.
      After declaring provisional success, the sender MAY generate ECT-
      marked packets as described in Section 7.3, provided it continues
      to monitor the RTCP reports for a period of three RTCP reporting
      intervals from the time the ECN initiation started, to check if
      there is any other participants in the session.  Thus as long as
      any additional SSRC that report on the ECN usage are using the
      same CNAME as the previous reports and they are all indicating
      functional ECN the sender may continue.  If other participants are
      detected, i.e other CNAMEs, the sender MUST fallback to only ECT-
      marking a small fraction of its RTP packets, while it determines
      if ECN can be supported following the full procedure described
      above.  Different CNAMEs received over an unicast transport may
      occur when using translators in a multi-party RTP session.

         Note: The above optimization support peer to peer unicast
         transport with several SSRCs multiplexed onto the same flow
         (e.g.  SSRC multiplexed RTP retransmission [RFC4588]).  It is
         desirable to be able to rapidly negotiate ECN support for such
         a session, but the optimisation above can fail if there are
         implementations that use the same CNAME for different parts of
         a distributed implementation that has different transport
         characteristics.

      ECN initiation is considered to have failed at the instant when
      any RTP session participant sends an RTCP packet that doesn't
      contain an RTCP ECN feedback report or ECN summary report, but has
      an RTCP RR with an extended RTP sequence number field that
      indicates that it should have received multiple (>3) ECT marked
      RTP packets.  This can be due to failure to support the ECN
      feedback format by the receiver or some middlebox, or the loss of
      all ECT marked packets.  Both indicate a lack of ECN support.

   If the ECN negotiation succeeds, this indicates that the path can
   pass some ECN-marked traffic, and that the receivers support ECN
   feedback.  This does not necessarily imply that the path can robustly
   convey ECN feedback; Section 7.3 describes the ongoing monitoring
   that must be performed to ensure the path continues to robustly
   support ECN.

   When a sender or receiver detects ECN failures on paths they should
   log these to enable follow up and statistics gathering regarding
   broken paths.  The logging mechanism used is implementation
   dependent.

Comments are welcome.

Cheers

Magnus Westerlund