Subject: [AVT] Proposal for text addressing congestion control for RAMS draft

From: "VAN CAENEGEM Tom" <[email-masked]>
Date: Mon, 15 Feb 2010 16:49:25 +0100

Dear all,
 
please find below proposed text to address the congestion control
concerns related to RAMS. Magnus provided initial text on the congestion
control (thanks Magnus) on the AVT list, after which some discussion
took place. The RAMS draft authors' proposal is to include congestion
control considerations into the existing section 6.4 ("shaping the
unicast burst") and hence rename it to  "RS Burst Shaping and Congestion
Control for RAMS"
 
Please provide your comments, and if no comments received in the next
three days, the plan is to release an update of the RAMS draft which
includes this update for section 6.4, as well as the definition of a new
response code for the RAMS-I message (see the text).

Regards
Tom

6.4.  RS Burst Shaping and Congestion Control for RAMS

This section provides informative guidelines about how RS can shape the
transmission of the unicast burst and how congestion can be dealt with
in the RAMS process.

A higher bitrate for the unicast burst naturally conveys the Reference
Information and media content to RTP_Rx faster.  This way, RTP_Rx can
start consuming the data sooner, which results in a faster acquisition.

A higher rate also represents a better utilization of RS resources. As
the burst may continue until it catches up with the primary multicast
stream, the higher the bursting rate, the less data RS needs to
transmit.  

However, a higher rate for the burst also increases the chances for
congestion-caused packet loss.  Thus, as discussed in Section 5, there
must be an upper bound on the extra bandwidth used by the burst.

When RS transmits the burst, it should take into account all available
information to prevent any packet loss that may take place during the
bursting as a result of buffer overflow on the path between RS and
RTP_Rx and at RTP_Rx itself, i.e. congestion.  The bursting rate may be
determined by taking into account the following data, when available:

   a. Information obtained via the RAMS-R message, such as Max RAMS
Buffer Fill Requirement and/or Max Receive Bitrate (See Section 7.2).

   b. Information obtained via RTCP receiver reports provided by RTP_Rx
in the retransmission session, allowing in-session rate adaptations for
the 	burst. When these receiver reports indicate packet loss, this
may indicate a certain congestion state in the path from RS to RTP_Rx.  

   c. Information obtained via RTCP NACKs provided by RTP_Rx in the
primary multicast RTP session, allowing in-session rate adaptations for
the burst.  	Such RTCP NACKs are transmitted byRTP_Rx in response to
packet loss detection by RTP_Rx in the burst.  NACKs may indicate a
certain congestion 	state on the path from RS to RTP_Rx.  

   d. There may be other feedback received from RTP_Rx, e.g., in the
form of ECN-CE RTCP feedback messages [I-D.westerlund-avt-ecn-for-rtp]
that may 	influence in-session  rate adaptations.

   e.  Information obtained via updated RAMS-R messages, allowing
in-session rate adaptations, if supported by RS.

   f. Transport protocol-specific information: e.g. when DCCP is used to
transport the RTP bursts, the ACKs from the DCCP client can be leveraged
by the  	RS / DCCP server for burst shaping and congestion
control (note that the DCCP congestion control mechanisms may defeat the
purpose of the RAMS 	protocol, see further).

   g. Pre-configured settings for each RTP_Rx or a set of RTP_Rxs that
indicate the upper-bound bursting rates for which no packet loss will
occur as a 	result of congestion along the path of RS to RTP_Rx.
Note that these bursting rates are by definition higher than the
associated SSM bit rates. For 	example, in managed IPTV networks, where
the bottleneck bandwidth along the end-to-end path is known and where
the network between RS and this link 	is provisioned and dimensioned
to carry the burst streams, the bursting rate does not exceed the
provisioned value.  These settings may also be 	dynamically adapted
using application-aware knowledge.

The RS chooses the initial bursting rate as follows: 

1)When using RAMS in environments as described in (g), the
Retransmission Server MUST transmit the burst packets at an initial
bitrate higher than the SSM bitrate, but within the engineered or
reserved bandwidth limit. 

2)When the RS cannot determine a reliable value for the unicast burst
(through a or g), RS should choose an appropriate initial rate not above
the SSM bitrate and increase it gradually if no congestion is detected
(see further).  

In both cases,  during the burst transmission the RS MUST continuously
monitor for packet losses as a result of congestion by means of one (or
a multiple) of the mechanisms described in (b,c,d,e,f). When the RS
relies on RTCP RR monitoring, sufficient bandwidth must be provided to
the RTP Rx for RTCP transmission. To achieve reasonable reporting
interval, it is recommended that RTCP transmissions are enabled to
happen on average at least as frequent as two times the round-trip time
between the Retransmission Server and the RTP receivers.

Note that heuristics or algorithms that deduce a congestion state and
how subsequently the RS should act, are in general outside the scope of
this document, but the following two practices are strongly recommended:

1)Upon detection of significant packet loss, which the RS attributes to
congestion, the RS should decrease the burst bit rate. 

The rate by which RS increases and decreases the bit rate for the burst
may be determined by a TCP-friendly rate adaptation algorithm for RTP
over UDP , or in the case of (f) by the congestion control algorithms
defined in DCCP [I-D.ietf-dccp-rtp].

2)If the congestion is persistent and RS has to reduce the burst bitrate
to a point where the RTP Rx buffer may underrun and/or the bursting
process consumes too much RS resources, the RS should terminate the RAMS
bursting process and transmit a RAMS-I message to the RTP Rx with
appropriate response code. 

(editor note: suggest to add a new RAMS RESPONSE code : "RAMS burst
terminated due to network congestion"). 

It is then up to the RTP Rx, to decide to join or not to join the
primary multicast stream. 

In case of no congestion during the bursting process, a specific
situation occurs near the end of the unicast burst, when RS has almost
no more additional data to sustain the relatively higher bursting rate,
thus, the upper-bound bursting rate automatically gets limited by the
nominal rate of the primary multicast stream.  During this time frame,
RTP_Rx eventually needs to join the multicast session.  This means that
both the burst packets and the multicast packets may be simultaneously
received by RTP_Rx for a period of time, enhancing the risk on
congestion again.

Since RS signals RTP_Rx when it should send the SFGMP Join message, RS
may have a rough estimate of when RTP_Rx will start receiving multicast
packets in the SSM session.  RS may keep on sending burst packets but
should reduce the rate accordingly at the appropriate instant by taking
the rate of the SSM session into account.  If RS ceases transmitting the
burst packets before the burst catches up, any gap resulting from this
imperfect switch-over by RTP_Rx can be later repaired by requesting
retransmissions of the missing packets from RS.  The retransmissions may
be shaped by RS to make sure that they do not cause collateral loss in
the primary multicast RTP session and the RTP retransmission session.