Subject: [AVT] Congestion Considerations for RAMS

From: Magnus Westerlund <[email-masked]>
Date: Thu, 28 Jan 2010 18:55:01 +0100

Hi,

As I raised before I are of the opinion there need to be some text on
Congestion Consideration and also relate to the applicability statement.
Below is a proposal for the WG to consider and improve on.

   Congestion control for RAMS is a fundamentally difficult problem that
   lacks an easy and simple solution.  The goal of RAMS is to reduce the
   acquisition delay when joining a multicast session carrying RTP
   media.  However, as discussed in Section 5, this goal is difficult to
   achieve by using a mechanism similar to slow start to gradually build
   up the transmission rate to the desired level (although that would
   likely be a network-friendlier and safer option to take).

   Instead of being generally safe and deployable in any network
   environment, RAMS targets a limited applicability where certain
   assumptions can be made.  It is targeted at a semi-managed network
   where the media service is deployed with the access network
   operator's cooperation.  The managed network is engineered to meet
   the QoS needs of the media service using RAMS. QoS reservation
   capabilities is one method of ensuring that sufficient resources are
   available.

   When using RAMS in environments where it is known that the above
   assumption holds, the Retransmission Server MAY transmit the burst
   packets at the requested bitrate as long as it is within the
   engineered or reserved bandwidth limit.  If the assumption is not
   known to hold, a transport protocol providing some sort of congestion
   control, such as DCCP [I-D.ietf-dccp-rtp], or a TCP-friendly rate
   adaptation algorithm for RTP over UDP MUST be used.

   To ensure that the assumptions hold and to handle the errors during
   the transmission of RTP packets, RTCP MUST be used to monitor the
   packet loss.  In case of substantial packet loss, the bitrate must be
   halved each RTCP reporting interval until the packet loss disappears.
   To achieve reasonable reporting intervals, the bandwidth for RTCP
   SHOULD be configured such 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.

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: Fri, 29 Jan 2010 12:03:13 +0100

Hi Magnus,

I have some comments on your text.

Because RAMS is used in conjunction with SSM, in practice this already assumes a "semi-managed" context. And in this context, the delta bandwidth consumed by the RAMS bursts as compared to the SSM bandwidth consumption is the only thing to be concerned with. This also means that the bitrate starting point for "slow start" is actually the SSM bitrate. So a "slow start" alike mechanism is feasible in this context, without impacting the response time (but resulting in longer bursts)

In a completely unmanaged context and assuming that an RTP receiver can get access to a SSM (and RAMS), it appears strange to me to state "must" requirements related to RAMS congestion control, without stating anything related to  congestion control for the associated SSM. I do not think we should have any "must" statement in this text.

Your last paragraph is not 100% clear to me:

"To ensure that the assumptions hold and to handle the errors during
   the transmission of RTP packets, RTCP MUST be used to monitor the
   packet loss.  In case of substantial packet loss, the bitrate must be
   halved each RTCP reporting interval until the packet loss disappears.
   To achieve reasonable reporting intervals, the bandwidth for RTCP
   SHOULD be configured such 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."

Q1: is this paragraph applicable to the (semi-) managed case?
Q2: "RTCP retransmission" : do you mean "RTP retransmission"  or "RTCP retransmission requests"

Regards
Tom

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Magnus Westerlund
Sent: donderdag 28 januari 2010 18:55
To: IETF AVT WG
Subject: [AVT] Congestion Considerations for RAMS

Hi,

As I raised before I are of the opinion there need to be some text on Congestion Consideration and also relate to the applicability statement.
Below is a proposal for the WG to consider and improve on.

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: Fri, 29 Jan 2010 15:44:40 +0100

> Because RAMS is used in conjunction with SSM, in practice this already assumes a "semi-managed" context. And in this context, the delta bandwidth consumed by the RAMS bursts as compared to the SSM…

Tom, at system startup you don't even know if the SSM transmissions are
going to fit in the available bit-rate. A correctly engineered network
should be able to handle that, but there are no hard guarantees. If you
are switching from one SSM group to another then you clearly have a
pre-establish rate that you can go against. However, RAMS burst are
expected to be sent at a higher than SSM group bit-rate to speed up the
catch up.

Thus in both cases you definitely have uncertainties and there are
factors that the ISP has some difficulties to control that can affect
the available bit-rate.

> In a completely unmanaged context and assuming that an RTP receiver can get access to a SSM (and RAMS), it appears strange to me to state "must" requirements related to RAMS congestion control, wit…

For a totally unmanaged network, there is clearly need for having
congestion control for the SSM channel also. This is specified on a high
level in RFC 3550. For SSM it is basically, drop the channel if there
are significant level of packet loss.

I would argue that RAMS is all about how one comes to the point when one
has sent the IGMP/MLD join to the SSM group. Not, specifying for that
SSM group. Thus RAMS needs to concern itself also with congestion
control for this actions.

I am trying to contribute text so that this document at least have a
reasonable consideration around congestion control. If you don't have
any you will never get past the transport ADs. The difficulty here is to
specify something that ensures that the network is protected and still
provide a reasonable performance. Adaptation for real-time media is well
known to be difficult.

> Q1: is this paragraph applicable to the (semi-) managed case?

Yes, all cases. The reason is that one should always monitor that the
assumptions about available bit-rate is correct.

> Q2: "RTCP retransmission" : do you mean "RTP retransmission"  or "RTCP retransmission requests"

It says RTCP transmission, not retranmission.

Cheers

Magnus Westerlund
(As individual)

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Fri, 29 Jan 2010 06:55:41 -0800

> >    halved each RTCP reporting interval until the packet loss
disappears.

This is not the best course of action in the RAMS context. If we start
lowering the burst rate, it may probably never catch up with the
multicast. Even if it does, if it will catch up in e.g., 5x time frame
instead of 1x, then the RAMS should be terminated at that moment anyway.
Why waste the server resources or network resources? This is explained
in Section 5, i.e., RAMS should not perform worse than the simple-join.

-acbegen

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Fri, 29 Jan 2010 07:09:52 -0800

> > Because RAMS is used in conjunction with SSM, in practice this
already
> assumes a "semi-managed" context. And in this context, the delta
bandwidth
> consumed by the RAMS bursts as compared to the SSM bandwidth
consumption is
> the only thing to be concerned with. This also means that the bitrate
> starting point for "slow start" is actually the SSM bitrate. So a
"slow
> start" alike mechanism is feasible in this context, without impacting
the
> response time (but resulting in longer bursts)
> 

This is not a problem we need to discuss in the RAMS draft IMO.

> factors that the ISP has some difficulties to control that can affect

As I recall we previously agreed that the methods measuring the
available bitrate were outside the scope of the rams draft. There might
be SP-managed limitations in a managed network or there could be
client-driven algorithms (or server-driven algorithms) to derive an
estimate for the available bitrate. This is a different discussion.
 
> >
> > In a completely unmanaged context and assuming that an RTP receiver
can
> get access to a SSM (and RAMS), it appears strange to me to state
"must"
> requirements related to RAMS congestion control, without stating
anything
> related to  congestion control for the associated SSM. I do not think
we
> should have any "must" statement in this text.
> >
> 

I'd like to understand this better. Who is supposed to drop the ssm
channel if there is significant packet loss? The receiver? If so, this
may not help to ease this problem as the packet loss might somewhere in
the upstream. And how do we know when the loss is significant? Is it 1%,
5%?

> provide a reasonable performance. Adaptation for real-time media is
well

Agree, so at the beginning the ret server has the responsibility to
determine whether bursting will help this particular client or not. If
the server knows that under the given conditions, the rams-based
acquisition will not be faster than the client doing a simple join, it
should reject the request in the first place.

-acbegen

---

From: Eric Friedrich <[email-masked]>
Date: Fri, 29 Jan 2010 10:15:07 -0500

Magnus-
    For some applications of RAMS I can see the halving of bitrate as  
being acceptable, but I don't think it would work well for all media  
types. Take video as our typical example. Assuming that the RAMS burst  
starts at some rate faster than the nominal rate of the SSM session,  
the RS could somewhat respond to congestion by lowering the RAMS  
bitrate until it reaches the bitrate that the data is being consumed  
at. If the bitrate is lowered beyond this point, the RTP_Rx transport  
buffer will underrun resulting in artifacts visible/audible to the end  
user.

An additional possible response to congestion in cases that would  
result in artifacts would be to abort the RAMS entirely and fallback  
to a simple multicast join. This approach would result in a glitch of  
the same type I am trying to avoid above, but it would only occur once  
and for a short period of time.  Lowering the bitrate too much as  
above would result in a sustained period of poor quality.

One additional effect to be wary of is creating a feedback loop by  
requesting retransmissions for packets affected by congestion. The  
response to congestion based packet loss should not be to request  
retransmission of those packets. To do that would only increase the  
amount of congestion on the network.

Thanks,
Eric Friedrich

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 29 Jan 2010 16:21:14 +0100

> in Section 5, i.e., RAMS should not perform worse than the simple-join.

I understand the problem. But continuing causing congestion because one
has overstated the available bit-rate isn't a choice either. There is
need to act here. Terminating the burst may be a better alternative then
and directly try to join.

Cheers

Magnus Westerlund
(as Individual)

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 29 Jan 2010 16:33:30 +0100

> This is not a problem we need to discuss in the RAMS draft IMO.

Ali, exactly what are you referring to here? The SSM groups congestion
control or the burst startup problem for RAMS?

> estimate for the available bitrate. This is a different discussion.

Who are we?

And I am not talking about including estimation systems here as a
required component. In the engineered and with configured RAMS RS and
clients it should be possible to start up at the assumed to work rates.
However, it needs to be monitored to ensure that this was not a wrong
assumption.

However for RAMS usage over the top, there need to be more intelligent
mechanisms that are not simply bursting.

> the upstream. And how do we know when the loss is significant? Is it 1%,

To the first part, if all receivers that see the packet loss drops the
SSM group the congestion will go away. If not all do it then it remains.

Numbers are difficult here. I think dropping a group is the case when
you see persistent loss, i.e. during multiple RTTs of loss rates
somewhere from 1-5% or more.

I understand the desire to not drop the session unnecessary. That will
result in unhappy customers. However, its is possibly a case of pushing
other flows out of the way.

I would also note that even if you have a network dedicated to IPTV it
could end up being wrongly dimensioned, due to more STBs or more channel
diveristy than what one has expected. In this case, what is the better,
that it works for some or that it fails for everyone?

That is why I think it is important to have a mechanism that prevents
persistent high levels of congestion.

> should reject the request in the first place.

Is this sufficiently clear in the new text?

Cheers

Magnus Westerlund
(as individual)

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Fri, 29 Jan 2010 07:34:53 -0800

The current protocol allows the client to change the burst rate or terminate it right away. Likewise, server is also allowed to change the burst rate or terminate the burst.

If the client sees a problem, it may try a lower bitrate (hoping the congestion will go away and bursting is still a good idea). But, then the server needs to make a decision. It can compute whether keeping the burst or telling the client to join the ssm right away is a good idea. The server is expected to do this analysis.

Or, if the client immediately attempts to send a termination request upon seeing a problem, the server simply terminates the burst.

So, in summary, what I am saying is that using a "MUST" or "must" language around these issues is not easy since there are multiple possible different implementation flavors.

-acbegen

> From: Magnus Westerlund [mailto:[email-masked]]
> Sent: Friday, January 29, 2010 10:21 AM
> To: Ali C. Begen (abegen)
> Cc: VAN CAENEGEM Tom; IETF AVT WG
> Subject: Re: [AVT] Congestion Considerations for RAMS
>

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 29 Jan 2010 16:35:52 +0100

Eric Friedrich skrev 2010-01-29 16:15:
> starts at some rate faster than the nominal rate of the SSM session, the
> RS could somewhat respond to congestion by lowering the RAMS bitrate
> until it reaches the bitrate that the data is being consumed at. If the
> bitrate is lowered beyond this point, the RTP_Rx transport buffer will
> underrun resulting in artifacts visible/audible to the end user.
> 
> An additional possible response to congestion in cases that would result
> in artifacts would be to abort the RAMS entirely and fallback to a
> simple multicast join. This approach would result in a glitch of the
> same type I am trying to avoid above, but it would only occur once and
> for a short period of time.  Lowering the bitrate too much as above
> would result in a sustained period of poor quality.

As I wrote in respons to Ali, terminating the burst is also a viable
option that can be better for bursts that can't handle halving or at
least some kind of down adjustments. I think that alternative should be
documented.

> amount of congestion on the network.

Fully agreed.

I think there are some considerations around that in RFC 4588.

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 29 Jan 2010 16:41:28 +0100

> So, in summary, what I am saying is that using a "MUST" or "must" language around these issues is not easy since there are multiple possible different implementation flavors.

Ali,

>From my perspective it needs to be mandated that you must monitor and
respond to congestion. If you have better ideas on how to respond that
is great. However, token responses aren't acceptable either. It needs to
have impact. Yes, that will affect the application adversely, but if the
resources are insufficient they are.

So specifying alternative responses are ok from my perspective. However,
it needs to be clear who's action it is to do something. If you leave it
open I think that will lead to finger pointing: "It was he who should do
something".

Cheers

Magnus Westerlund

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Fri, 29 Jan 2010 08:16:55 -0800

> Sent: Friday, January 29, 2010 10:34 AM

The former.
 
> > estimate for the available bitrate. This is a different discussion.

This was discussed in the AVT session in Stockholm, if I am not mistaken. And the related text already exists in Section 6.
 
> However, it needs to be monitored to ensure that this was not a wrong

I agree with this. My concerns are around the imposed actions we will mention in the draft.
 
> mechanisms that are not simply bursting.

You mean over-the-top video? If they will use SSM distribution and RAMS, it will be a pretty advanced OTT service :)
 
> SSM group the congestion will go away. If not all do it then it remains.

True but we also have local repair servers to handle packet loss, or we can have FEC, etc. By definition, multicast is not a reliable service.

> that it works for some or that it fails for everyone?

If it is a paid service, it must work for everyone, or money back ;)
 
> persistent high levels of congestion.

Agree.
 
> Is this sufficiently clear in the new text?

We will try to make this more explicit in the revision.

-acbegen

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Fri, 29 Jan 2010 08:18:52 -0800

> Sent: Friday, January 29, 2010 10:41 AM
> > The current protocol allows the client to change the burst rate or
> terminate it right away. Likewise, server is also allowed to change the
> burst rate or terminate the burst.
> >
> > If the client sees a problem, it may try a lower bitrate (hoping the
> congestion will go away and bursting is still a good idea). But, then the
> server needs to make a decision. It can compute whether keeping the burst
> or telling the client to join the ssm right away is a good idea. The server
> is expected to do this analysis.
> >
> > Or, if the client immediately attempts to send a termination request upon
> seeing a problem, the server simply terminates the burst.
> >
> > So, in summary, what I am saying is that using a "MUST" or "must"
> language around these issues is not easy since there are multiple possible
> different implementation flavors.
> >
> 
> Ali,
> 

I don't wanna leave loose ends in the spec, either.

But, I am not sure at this stage how we can formulate a decision process acceptable to everyone. As usual, we are open to suggestions.

Thanks, acbegen.

---

From: "Bill Ver Steeg (versteb)" <[email-masked]>
Date: Fri, 29 Jan 2010 12:56:22 -0600

As we discuss this matter, it is important to understand how the system recognizes congestion. Note that the typical deployment models for deploying such schemes include paths with noise-driven packet loss (think DSL lines to a home). Packets with explicit congestion markings on them would clearly signal congestion, but not all packet loss events would be congestion driven.

In the presence of unambiguous congestion, the most prudent course of action would be to terminate the burst and allow the main stream to have all of the available bandwidth.

For the general case of experiencing packet loss -IMHO, we should be sure to design a mechanism that is well-behaved in cases due to noise-driven loss and to congestion driven loss. In the interest of simplicity, a requirement to abort the acceleration in the presence of significant packet loss comes to mind. This would be the correct action for both congestion and significant noise-driven packet loss. The acceleration would fail, and the available bandwidth would be used to carry the normal flow. 

This plan pushes the baseline congestive/noncongestive loss problem back into the normal RTP/RTCP domain, where it belongs.

Bvs

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Magnus Westerlund
Sent: Friday, January 29, 2010 10:41 AM
To: Ali C. Begen (abegen)
Cc: VAN CAENEGEM Tom; IETF AVT WG
Subject: Re: [AVT] Congestion Considerations for RAMS

Ali,

Cheers

Magnus Westerlund