Subject: [rmcat] Review of rmcat-cc-codec-interactions

From: "Michael Ramalho (mramalho)" <[email-masked]>
Date: Tue, 16 Feb 2016 21:59:07 +0000

All,

I have reviewed draft-zanaty-rmcat-cc-codec-interactions. My only comments concern Section 5.2.2 (Startup Ramp).

In what follows I have added two sentences and modified a sentence in this section.

****EXISTING TEXT****
5.2.2.  Startup Ramp

Startup Ramp (from Codec to CC, and from CC to Codec): Startup is an important moment in a conversation.  Rapid rate adaptation during startup is therefore important.  The codec should minimize its startup media rate as much as possible without adversely impacting the user experience, and support a strategy for rapid rate ramp.  The CC should allow the highest startup media rate as possible without adversely impacting network conditions, and also support rapid rate ramp until stabilizing on the available bandwidth.  Startup can be viewed as a negotiation between the codec and the CC.  The codec requests a startup rate and ramp, and the CC responds with the allowable parameters which may be lower/slower.  The RMCAT requirements also include the possibility of bandwidth history to further accelerate or even eliminate startup ramp time.  While this is highly desirable from an application viewpoint, it may be less acceptable to network operators, since it is in essence a gamble on current congestion state matching historical state, with the potential for significant congestion contribution if the gamble was wrong.  Note that startup can often commence before user interaction or conversation to reduce the chance of clipped media.
****EXISTING TEXT****

****PROPOSED TEXT****
5.2.2.  Startup Ramp

Startup Ramp (from Codec to CC, and from CC to Codec): Startup is an important moment in a conversation.  Rapid rate adaptation during startup is therefore important.  The codec should minimize its startup media rate as much as possible without adversely impacting the user experience, and support a strategy for rapid rate ramp.  The CC should allow the highest startup media rate as possible without adversely impacting network conditions, and also support rapid rate ramp until stabilizing on the available bandwidth.  Startup can be viewed as a negotiation between the codec and the CC.  The specification of the ramp may take a number of forms depending on the interface to the codec; for example, a percentage bit rate increase per RTT (or other time interval), or an increased transmit window (in number of packets and/or octets allowed outstanding) are all potential forms.  The codec requests a startup rate and ramp, and the CC responds with the allowable parameters which may be lower/slower.  The RMCAT requirements also include the possibility of bandwidth history to further accelerate or even eliminate startup ramp time. While this acceleration or elimination in ramp time is beneficial to the session user experience when bandwidth is sufficient, it can be detrimental if significant congestion results (the user experience of this session and all other sessions traversing the point of congestion may unnecessarily degrade).  Therefore, it is recommended that use of potentially stale congestion state for acceleration or elimination in ramp up be limited to topologies or deployments believed to have sufficient bandwidth margin or those in which the potential transient congestion risk is acceptable.  Note that startup can often commence before user interaction or conversation to reduce the chance of clipped media.
****PROPOSED TEXT****

The modification deletes the reference to "network operators", as I think the point may be made that many network administrators (be they service providers or other "network operators") or network designers/sizers would also have the same concern.

I have reviewed this change with the present authors and they generally approve of it. Other edits are welcome.

Regards,

Michael A. Ramalho, Ph.D.

---

From: Mirja Kühlewind <[email-masked]>
Date: Wed, 24 Feb 2016 12:31:20 +0100

Hi Mo, hi Michael,

two comments as individual:

Reading this text part now, I don't think we need to negotiate the startup 
ramp. Actually I'm not even sure what the term 'ramp' is supposed to mean 
here. I believe we need is to indicate the maximum initial sending rate from 
the cc to the codec. If the codec then delivers data with a lower rate that 
should not be a problem for the cc. And the initial (max) sending can solely 
be chosen by the cc, as it might either use a default value or some cached 
info from previous transmission to the same receiver (over the same access 
network).

Further, I agree that it is good to add one sentence that this rate has to be 
chosen carefully (and a different value than a conservative default can only 
be used if further information about or from the network is available). But I 
don't really understand what exactly you want say with the two sentences that 
you have added below...?

Mirja

On 16.02.2016 22:59, Michael Ramalho (mramalho) wrote:
> Startup Ramp (from Codec to CC, and from CC to Codec): Startup is an
> important moment in a conversation.  Rapid rate adaptation during startup is
> therefore important.  The codec should minimize its startup media rate as
> much as possible without adversely impacting the user experience, and support
> a strategy for rapid rate ramp.  The CC should allow the highest startup
> media rate as possible without adversely impacting network conditions, and
> also support rapid rate ramp until stabilizing on the available bandwidth.
> Startup can be viewed as a negotiation between the codec and the CC.  The
> codec requests a startup rate and ramp, and the CC responds with the
> allowable parameters which may be lower/slower.  The RMCAT requirements also
> include the possibility of bandwidth history to further accelerate or even
> eliminate startup ramp time.  While this is highly desirable from an
> application viewpoint, it may be less acceptable to network operators, since
> it is in essence a gamble on current congestion state matching historical
> state, with the potential for significant congestion contribution if the
> gamble was wrong.  Note that startup can often commence before user
> interaction or conversation to reduce the chance of clipped media.
>
> ****EXISTING TEXT****
>
> ****PROPOSED TEXT****
>
> 5.2.2.  Startup Ramp
>
> Startup Ramp (from Codec to CC, and from CC to Codec): Startup is an
> important moment in a conversation.  Rapid rate adaptation during startup is
> therefore important.  The codec should minimize its startup media rate as
> much as possible without adversely impacting the user experience, and support
> a strategy for rapid rate ramp.  The CC should allow the highest startup
> media rate as possible without adversely impacting network conditions, and
> also support rapid rate ramp until stabilizing on the available bandwidth.
> Startup can be viewed as a negotiation between the codec and the CC.  The
> specification of the ramp may take a number of forms depending on the
> interface to the codec; for example, a percentage bit rate increase per RTT
> (or other time interval), or an increased transmit window (in number of
> packets and/or octets allowed outstanding) are all potential forms.  The
> codec requests a startup rate and ramp, and the CC responds with the
> allowable parameters which may be lower/slower.  The RMCAT requirements also
> include the possibility of bandwidth history to further accelerate or even
> eliminate startup ramp time. While this acceleration or elimination in ramp
> time is beneficial to the session user experience when bandwidth is
> sufficient, it can be detrimental if significant congestion results (the user
> experience of this session and all other sessions traversing the point of
> congestion may unnecessarily degrade).  Therefore, it is recommended that use
> of potentially stale congestion state for acceleration or elimination in ramp
> up be limited to topologies or deployments believed to have sufficient
> bandwidth margin or those in which the potential transient congestion risk is
> acceptable.  Note that startup can often commence before user interaction or
> conversation to reduce the chance of clipped media.
>
> ****PROPOSED TEXT****
>
> The modification deletes the reference to “network operators”, as I think the
> point may be made that many network administrators (be they service providers
> or other “network operators”) or network designers/sizers would also have the
> same concern.
>

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Wed, 24 Feb 2016 22:52:39 +0000

Hi Mirja,

Startup "Ramp" refers to rate (or window) increase over time at startup, not just the initial rate/window. The old app-interaction draft described this in section 5 (Interfaces and Interactions), but we were asked to remove this in the new cc-codec-interactions draft. Should we add this back?

https://tools.ietf.org/html/draft-ietf-rmcat-app-interaction-01#section-5

   o  Startup Ramp (CC-Codec): Initial rate (or number of packets in
      window-based CC proposals) and strategy for increasing the rate
      (or window) during media startup, similar to TCP intial congestion
      window and slow start.  See Section 5.4.3 for details.

While an initial window may be sufficient for TCP apps, it can be insufficient for codecs at startup. A codec can make many different (more intelligent) decisions at startup depending on the target ramp, versus usually making very poor decisions if only an initial rate is given.

If the only cc-codec interaction at startup is an initial rate, then Allowed Rate can already capture that interaction without anything special needed for startup. However, startup is indeed special because the initial rate is very transient and rapid increase is expected. Codecs can make better decisions if they are aware of the CC startup dynamics.

For example, if the codec is only told 300 kbps, it may adapt to a very low resolution like CIF with poor quantization in order to maintain a stable, moderate frame rate at 300 kbps. If instead it is told 300 kbps ramping up geometrically to 2.5 Mbps in 0.5 seconds, it may target HD 1080p with better quantization and pace the initial frame over a longer time until the startup rate stabilizes before attempting full frame rate.

Cheers,
Mo

On 2/24/16, 6:31 AM, Mirja Kühlewind <[email-masked]<mailto:[email-masked]>> wrote:

Hi Mo, hi Michael,

Mirja

I have reviewed draft-zanaty-rmcat-cc-codec-interactions. My only comments
concern Section 5.2.2 (Startup Ramp).

In what follows I have added two sentences and modified a sentence in this
section.

****EXISTING TEXT****

5.2.2.  Startup Ramp

****EXISTING TEXT****

****PROPOSED TEXT****

5.2.2.  Startup Ramp

****PROPOSED TEXT****

The modification deletes the reference to "network operators", as I think the
point may be made that many network administrators (be they service providers
or other "network operators") or network designers/sizers would also have the
same concern.

I have reviewed this change with the present authors and they generally
approve of it. Other edits are welcome.

Regards,

---

From: Mirja Kühlewind <[email-masked]>
Date: Thu, 25 Feb 2016 16:57:58 +0100

Hi Mo,

again individual comments:

You are actually right that for the initial rate, allowed rate is enough as 
an interface.

I can see that the start up behavior would be interesting, but I don't 
understand how you define this in an interface. Would you say something like 
'I use slow start' or 'I will increase by x [some unit] within x ms'. 
However, even if you say something like this, it's still no promise that the 
codec can rely on because there simply might be congestion. So not sure how 
useful this is. However, if we keep this ramp, we need to be much more clear 
about what this means.

My other point actually was/is that I don't think we really need a 
negotiation here (as currently described in the text); it's enough to have an 
interface that signals the intended behavior from the cc to the codec. Or 
have you been thinking about something like 'I support slow start and this 
alternative algo' and the the codec say 'please take the alternative'...? 
This sound very complicated to me.

Mirja

On 24.02.2016 23:52, Mo Zanaty (mzanaty) wrote:
> Hi Mirja,
>
> Startup "Ramp" refers to rate (or window) increase over time at startup, not
> just the initial rate/window. The old app-interaction draft described this in
> section 5 (Interfaces and Interactions), but we were asked to remove this in
> the new cc-codec-interactions draft. Should we add this back?
>
> While an initial window may be sufficient for TCP apps, it can be
> insufficient for codecs at startup. A codec can make many different (more
> intelligent) decisions at startup depending on the target ramp, versus
> usually making very poor decisions if only an initial rate is given.
>
> If the only cc-codec interaction at startup is an initial rate, then Allowed
> Rate can already capture that interaction without anything special needed for
> startup. However, startup is indeed special because the initial rate is very
> transient and rapid increase is expected. Codecs can make better decisions if
> they are aware of the CC startup dynamics.
>
> For example, if the codec is only told 300 kbps, it may adapt to a very low
> resolution like CIF with poor quantization in order to maintain a stable,
> moderate frame rate at 300 kbps. If instead it is told 300 kbps ramping up
> geometrically to 2.5 Mbps in 0.5 seconds, it may target HD 1080p with better
> quantization and pace the initial frame over a longer time until the startup
> rate stabilizes before attempting full frame rate.
>
> Cheers,
> Mo
>
>
> On 2/24/16, 6:31 AM, Mirja Kühlewind <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> Hi Mo, hi Michael,
>