Re: [rmcat] application interface

[Michael Welzl <[e-mail]>]

Hi,

I don't understand why you call it a control loop, it's just an API, and I don't understand why you say it's not in the charter? The charter says:

"Identify interactions between applications and RTP flows to enable conveying
helpful cross-layer information such as per-packet priorities, flow elasticity, etc.
This information might be used to populate an API, but the WG will not define a
specific API itself."

The intention behind this really was an API, conceptually - as far as I can tell the (later added) "anti-API" wording is just there to ensure that there won't be an API defined in the sense of defining datatypes and such machine-specific things, but something more abstract. But it's about defining how applications communicate with the transport layer.

FWIW, the result on slide 16:
http://www.ietf.org/proceedings/87/slides/slides-87-rmcat-2.pdf
is only possible because we assume that coupled congestion control gets not only the rate that the congestion controller has calculated, but also the "desired rate" from the application (which may be smaller than the congestion controller's rate).

Now this is the other direction than what you mean - the transport getting the rate from the application - but it does require at least some rudimentary communication between applications and the transport. About the rest of your musings, I agree, and I also agree with the concerns that were raised about defining too much, we'd have to be careful here. In your answer to Piers, you wrote:

"I would be careful to make the interface too large and too complicated. The 
question is which information is really needed for the application to decide 
to switch the coding and also (maybe even more important) which information 
can be understood by every application designer. I currently believe that the 
information, what the estimated largest possible rate is, might be enough."

and I agree, probably you won't need more than this, *upward*, and what we called the application's "desired rate", *downward*.

As another comment to address Kevin's concern: this would be only about things that are of definite concern to the application and can't be dealt with below without involving the application. ECN is in fact a nice example of a case that doesn't need the application, it could be dealt with below - even for TCP, as Mirja et al's related draft shows:
http://tools.ietf.org/html/draft-kuehlewind-tcpm-ecn-fallback

Cheers,
Michael


On 11. okt. 2013, at 13:55, Mirja Kuehlewind wrote:

> Hi Kevin,
> 
> sure the congestion control could also be implemented in the application. I 
> was assuming that the congestion control is part if the transport layer. But 
> even if you implement it in the application, you potentially would like to 
> define some kind of interface such that the same congestion control could 
> more easily be implemented (or even code could be re-used) by different 
> applications and the application could then implement an addition control 
> loop on top to change the coding. This additional higher layer control loop 
> is not part of the rmcat charter thus having a well defined interface would 
> be useful form my point of view.
> 
> Mirja
> 
> 
> 
> On Thursday 10 October 2013 17:05:19 Kevin Gross wrote:
>> I thought the scope of the work for this group was to develop techniques
>> applications can use to avoid congestion. Since this is all being done
>> internal to the application, there's no need for an API to an application.
>> We may need to have interfaces to the network for ECN or whatnot.
>> 
>> Kevin Gross
>> [phone]
>> Media Network Consultant
>> AVA Networks - www.AVAnw.com <http://www.avanw.com/>
>> 
>> On Thu, Oct 10, 2013 at 8:28 AM, Piers O'Hanlon <[e-mail]> wrote:
>>> Hi Mirja,
>>> 
>>> You bring up two points:
>>> 
>>> - I'd agree we do need to have some sort of communication between the
>>> congestion control and media/codec delivery - probably some API is needed
>>> to communicate current parameters such as operating rate, latency, and
>>> possibly some time limited projections (or confidence) of such
>>> parameters.
>>> 
>>> - The issue in your second point as I see is the issue of how deal with
>>> application limited and/or silence periods - which are a tricky area. I
>>> guess the corresponding concept for TCP is Congestion Window Validation,
>>> and the changes in TFRC from RFC3448 to  RFC5348 were largely down to
>>> such data-limited behaviours. For general info Gorry Fairhurst has a
>>> couple of recent papers on the subject:
>>> "TCP-Friendly Rate Control (TFRC) for bursty media flows", ComCom, 2011
>>> And for TCP:
>>> "Enhancing TCP to Support Rate-Limited Traffic", CSWS, 2012
>>> 
>>> But you are suggesting a further addition to this - maybe when CWV limits
>>> are exceed - by adding a probe phase. Although I think it's possible to
>>> monitor the 'available' bandwidth on the link - the problem maybe that
>>> other other flows will rapidly take up their 'fair share' of the that
>>> available capacity. So probably the only way to maintain one's capacity
>>> is send some sort of dummy traffic - or if we're WebRTC mode - send some
>>> HTML/JS/CSS etc in between the lulls of media.
>>> 
>>> I guess this mix could be handled via some coupled congestion service or
>>> suitable multi-substream low latency transport with optional reliability
>>> per substream...
>>> 
>>> Cheers,
>>> 
>>> Piers
>>> 
>>> On 10 Oct 2013, at 14:23, Mirja Kühlewind wrote:
>>>> Hi group,
>>>> 
>>>> I have a question as an individual contributor. Looking at the current
>>>> proposals which are all rate-based (right?), I was wondering if we
>>>> maybe
>>> 
>>> need
>>> 
>>>> a higher layer interface to announce the current rate to the
>>>> application?
>>>> 
>>>> Moreover, if the sending rate is application limited, don't we need a
>>> 
>>> way to
>>> 
>>>> tell the application that there is more space on the link and e.g. the
>>>> quality could be increased? Therefore we would need to know how much
>>>> more capacity would be available. Normally congestion control does this
>>>> by probing/slowly increasing the sending rate, but if the traffic is
>>> 
>>> application
>>> 
>>>> limited that's not possible. Thus we maybe need some kind of
>>>> measurement/testing method, that maintains an average rate as provided
>>> 
>>> by the
>>> 
>>>> application, but can send for very short intervals with a higher and
>>>> respective lower rate, like chirping (see PathChirp or TCP Rapid).
>>>> 
>>>> Any opinions on this?
>>>> 
>>>> Mirja
> 
> 
> 
> -- 
> -------------------------------------------------------------------
> Dipl.-Ing. Mirja Kühlewind
> Institute of Communication Networks and Computer Engineering (IKR)
> University of Stuttgart, Germany
> Pfaffenwaldring 47, D-70569 Stuttgart
> 
> tel: [phone]
> email: [e-mail]
> web: www.ikr.uni-stuttgart.de
> -------------------------------------------------------------------