Subject: [AVTCORE] draft-ietf-avt-app-rtp-keepalive and RTCP

From: Xavier Marjou <[email-masked]>
Date: Mon, 21 Feb 2011 16:32:40 +0100

Hi,

This mail deals with the rtp-keepalive draft:
http://tools.ietf.org/id/draft-ietf-avt-app-rtp-keepalive-09.txt

This 09 version still has one issue with regards to the IESG feedback,
which is that "RTCP can not be left out of this draft".
An explicit section about RTCP is thus needed. Magnus proposed some
text for that. The resulting section would be the proposal below.
Please give feedback if you think some details must be changed.

Here is a link of what could be the complete draft when RTCP is added (ie: RTCP
appears in tittle, abstract, introduction...)
http://tinyurl.com/5ss2zyz
You can use the menu "File"->"Download as"->"TXT" to use it with he
http://tools.ietf.org/rfcdiff tool if you want.

If I haven't heard anything to the contrary by March 3rd, I will
submit -10 containing this text.

Cheers,
Xavier

8.  RTCP Flow Keepalive

  RTCP packets are sent periodically and can thus normally maintain the
  NAT mappings open as long as they are sent frequently enough.  There
  are two conditions for that.  First RTCP needs to be used bi-
  directionally and in a symmetric fashion, as described in [RFC4961].
  Secondly, RTCP needs to be sent frequently enough.  However, there
  are certain configurations that can break this latter assumption.

  There are two factors that need to be considered to ensure that RTCP
  is sent frequently enough.  First the RTCP bandwidth needs to be
  sufficiently large so that transmission will occur more frequently
  than the longest acceptable packet transmission interval (Tr).  The
  worst case RTCP interval (Twc) can be calculated using this formula
  by inserting the max value of the following parameters:
  o  Maximum RTCP packet size (avg_rtcp_size_max)
  o  Maximum number of participants (members_max)
  o  RTCP receiver bandwidth (rtcp_bw)

  The RTCP bandwidth value to use here is for a worst case, which will
  be the receiver proportion when all members are not senders except
  one.  This can be approximated to be all members.  Thus for sessions
  where RR and RS values are used, then rtcp_bw shall be set to RR.
  For sessions where the [RFC3550] defines proportions of 1/4 for
  sender and 3/4 for receivers are used, then rtcp_bw will be 5% of 3/4
  of the AS value in bits per second.

  Twc = 1.5 / 1.21828 * members_max * rtcp_bw / avg_rtcp_size_max * 8

  The second factor is the minimum RTCP interval Tmin defined in
  [RFC3550].  Its base value is 5 seconds, but it might also be scaled
  to 360 divided by the session bandwidth in kbps.  The Extended RTP
  Profile for Real-time Transport Control Protocol (RTCP)-Based
  Feedback (RTP/AVPF) [RFC4585] also allows for the setting of a trr-
  int parameter which is a minimal RTCP interval for regular RTCP
  packets.  It is also used as the Tmin value in the regular Td
  calculation.  An analysis of the algorithm gives that the longest
  possible regular RTCP interval possible are:

  RTCP_int_max = trr-int * 1.5 + Td * 1.5 / 1.21828

  And as long as the there is sufficient bandwidth according to
  criteria 1, then this can be simplified by setting Td = trr-int
  giving

  RTCP_int_max = trr-int * (1.5 + 1.5 / 1.21828) = 2.73123 * trr-int

  Thus the requirements on the RTCP parameters are the following for
  functioning keepalive:
  1.  Ensure that sufficient RTCP bandwidth is provided by calculating
      Twc and ensure that this is less than or equal to Tr.
  2.  If AVP or SAVP is used the Tmin value can't be greater that Tr
      divided by 1.5 / (e-3/2).
  3.  If AVPF or SAVPF is to be used trr-min must not be set to a
      greater value than Tr / 3.