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

[Mirja Kühlewind <[e-mail]>]

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:
> 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.
>