Subject: [AVT] draft-ietf-avt-rapid-acquisition-for-rtp-07: Applicability and congestion control

From: Magnus Westerlund <[email-masked]>
Date: Mon, 01 Mar 2010 21:06:52 +0100

Hi,

There is going to need to be an applicability section in this draft.
RAMS is not suitable to deploy outside of a managed network where you
have at least knowledge about upper bandwidth limits and preferably
traffic class prioritizations. This needs to be extremely clear and we
do use "Applicability Statements" for describing such limitations on
where this is appropriate to be used.

When it comes to the congestion control the document does not even
mandate some basic mechanisms to ensure that this cause persistent
congestions events. As I see it mandating RTCP receiver reports in the
unicast session with sufficient bandwidth to have rapid reports during
the burst is required. Otherwise the server can't stop the burst if high
level of packet loss is occurring.

Secondly, there is no specification of that the RTP_RX shall react and
terminate the burst when it sees significant congestion control and if
RAMS-R update isn't allowed. IF it is allowed, then the client really
should send an updated RAMS-R and adjust the bandwidth.

It isn't okay to ignore these type of issues. And basic mechanisms do
need to be mandated to be supported so that persistent congestion is
avoided.

Cheers

Magnus Westerlund

IETF Transport Area Director
----------------------------------------------------------------------
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: "VAN CAENEGEM Tom" <[email-masked]>
Date: Tue, 2 Mar 2010 10:36:14 +0100

Hi Magnus,

I thought we did address your 1st point 

("As I see it mandating RTCP receiver reports in the unicast session with sufficient bandwidth to have rapid reports during the burst is required. Otherwise the server can't stop the burst if high level of packet loss is occurring.")

by using "must" terminology in the text, as copied below:

"In both cases, during the burst transmission RS MUST continuously
   monitor for packet losses as a result of congestion by means of one
   or more of the mechanisms described in (b,c,d,e,f).  When RS relies
   on RTCP receiver reports, sufficient bandwidth must be provided to
   RTP Rx for RTCP transmission.  To achieve a reasonable fast
   adaptation against congestion, it is recommended that RTP_Rx sends a
   receiver report at least once every two RTTs between RS and RTP_Rx."

On your second point: 

"Secondly, there is no specification of that the RTP_RX shall react and terminate the burst when it sees significant congestion control and if RAMS-R update isn't allowed. IF it is allowed, then the client really should send an updated RAMS-R and adjust the bandwidth."

The text puts the responsability at the server-side: based on reporting from the RTP Rx (RTCP RR or RAMS-update), the server determines whether and how fast to increase/decrease bursting rate and/or to stop the burst.:

"Although the specific heuristics and algorithms that deduce a
   congestion state and how subsequently RS should act are outside the
   scope of this specification, the following two practices are
   recommended:

   o  Upon detection of a significant packet loss, which RS attributes
      to congestion, RS should decrease the burst bitrate.  The rate by
      which RS increases and decreases the bitrate for the burst may be
      determined by a TCP-friendly bitrate 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].

   o  If the congestion is persistent and RS has to reduce the burst
      bitrate to a point where the RTP Rx buffer may underrun or the
      burst will consume too much RS resources, RS should terminate the
      burst and transmit a RAMS-I message to RTP Rx with the appropriate
      response code.  It is then up to RTP Rx to decide when to join the
      multicast session. "

Is your concern then addressed by having "must" rather than "should" in the 1st bullet? IMO, that makes RAMS also applicable to non-managed networks, hence applicability statement can be omitted.

Tom

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Magnus Westerlund
Sent: maandag 1 maart 2010 21:07
To: IETF AVT WG
Subject: [AVT] draft-ietf-avt-rapid-acquisition-for-rtp-07: Applicability and congestion control

Hi,

There is going to need to be an applicability section in this draft.
RAMS is not suitable to deploy outside of a managed network where you have at least knowledge about upper bandwidth limits and preferably traffic class prioritizations. This needs to be extremely clear and we do use "Applicability Statements" for describing such limitations on where this is appropriate to be used.

When it comes to the congestion control the document does not even mandate some basic mechanisms to ensure that this cause persistent congestions events. As I see it mandating RTCP receiver reports in the unicast session with sufficient bandwidth to have rapid reports during the burst is required. Otherwise the server can't stop the burst if high level of packet loss is occurring.

Secondly, there is no specification of that the RTP_RX shall react and terminate the burst when it sees significant congestion control and if RAMS-R update isn't allowed. IF it is allowed, then the client really should send an updated RAMS-R and adjust the bandwidth.

It isn't okay to ignore these type of issues. And basic mechanisms do need to be mandated to be supported so that persistent congestion is avoided.

Cheers

Magnus Westerlund

IETF Transport Area Director
----------------------------------------------------------------------
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]
----------------------------------------------------------------------
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www.ietf.org/mailman/listinfo/avt

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 22 Mar 2010 10:14:47 -0700

>    receiver report at least once every two RTTs between RS and RTP_Rx."

Ok, this is likely okay.

> Is your concern then addressed by having "must" rather than "should" in the 1st bullet? IMO, that makes RAMS also applicable to non-managed networks, hence applicability statement can be omitted.

Yes this are fine sender side recommendations. Even if I might think
that TCP-friendly part might be problematic.

However, I think you should consider that also the receiver should react
if it sees really sever congestion. As the burst anyway will not provide
any big benefit for the client if there are a lot of packet losses. Thus
either terminating the burst or update the over subscription rate seems
possible from a client perspective.

The only issue is interactions. But at least if you are terminating the
burst from the client side then it is what the client feels most
efficient when a substantial part of the burst has been lost.

Cheers

Magnus Westerlund