Subject: Re: [rmcat] WGLC for draft-ietf-rmcat-cc-requirements-02

From: Magnus Westerlund <[email-masked]>
Date: Mon, 3 Mar 2014 19:28:25 +0000

On 2014-02-17 14:53, Eggert, Lars wrote:
> Hi,
> 
> we'd like to start the working group last call for 
> draft-ietf-rmcat-cc-requirements-02. Please send your feedback to
> the list.
> 

I have reviewed the draft and here are my feedback on the draft.

1. Abstract:

   This document is derived from draft-jesup-rtp-congestion-reqs
   [I-D.jesup-rtp-congestion-reqs].

I think this can be removed from the abstract. It doesn't appear
relevant at this stage to be in the abstract.

2. Section 1

   ... and since it's consumed in real
   time, data delivered late is useless.

I agree that is commonly useless, but not always. I don't know if we
want to be more precise here and write this as:

and since it's consumed in real
   time, data delivered late is commonly useless.

3. Section 1

   Given that this use case is the focus of this document, use cases
   involving noninteractive media such as YouTube-like video streaming,
   and use cases using multicast/broadcast-type technologies, are out of
   scope.

I wonder if it is appropriate to use the trademark "YouTube" in this
text. I would suggest to remove it.

4. Section 2, Req 1.D:

   Similarly periodic bursty flows such as DASH or proprietary

I would suggest adding a reference to DASH and possibly expand it.

5. Section 2, Req 1.D
            or
            may cause a shift in the location of the bottleneck fir the
            duration of the burst.

Spelling fir/for

5. Section 2, Req 3.A

        A.  If possible, it should also share information and adaptation
            with other non-RTP flows between the same endpoints, such as
            a WebRTC data channel

I would recommend a reference after "WebRTC data channel"

6. Section 2, Req 5.A
        A.  In order to react sufficiently quickly when using RTCP for a
            backchannel, an RTP profile such as AVPF/SAVPF that allows
            sufficiently frequent feedback [RFC4585] MUST be used.

The references and the RTP Profiles don't align well, I would suggest
that this is modified to:

        A.  In order to react sufficiently quickly when using RTCP for a
            backchannel, an RTP profile such as RTP/AVPF [RFC4585] or
            RTP/SAVPF [RFC5124] that allows
            sufficiently frequent feedback MUST be used.

7. Section 2, Req 5

A back channel requirement I don't know if it has been discussed is
the need for back channel congestion control.

8. Section 2, Req 6

        Flows managed by this algorithm and flows competed against at a
        bottleneck may have different DSCP markings depending on the
        type of traffic.  A particular bottleneck or section of the
        network path may or may not honor these markings.

A. This talks about DSCP only. What about flow based QoS? Is the not
included here as differnet network behaviors would require differnet
5-tuples. The RTP streams could still be under common application
control so I wonder if this is relevant?

B. I would ad a reference here to DSCP, and maybe you need to include
the word Diffserv here.

9. Section 2, Req 6.A

        A.  In WebRTC, a division of packets into 4 classes is
            envisioned in order of priority: faster-than-audio, audio,
            video, best-effort, and bulk-transfer.  Typically the flows
            managed by this algorithm would be audio or video in that
            heirarchy, and feedback flows would be faster-than-audio.

This doesn't match what is currently in
draft-dhesikan-tsvwg-rtcweb-qos-05. I wonder if this needs to be
either generalized or reference this document?

10. Section 2.

Another requirement that might be missing and is related to 6.A, but
not the same. It is the possibility to indicate the relative priority
between multiple streams in the same session context. This doesn't
require any QoS, just that the sending application indicates relative
priority and that affects how bit-rate gets distributed. Or has the
discussion been that it will be the higher layers that do this
re-distribution between streams for which one have indication if they
can increase or reduce the stream.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Randell Jesup <[email-masked]>
Date: Tue, 04 Mar 2014 10:38:54 -0500

> I have reviewed the draft and here are my feedback on the draft.

Thanks!  Sorry I can't be there in person (I'd planned to until a couple 
of weeks ago).

Consider my response to be "ok, will do" to everything I don't mention 
below.

> the need for back channel congestion control.

This has been discussed, and the draft mentions that RTCP backchannel 
messages may be delayed due to RTCP bandwidth rules, and that bandwidth 
should be limited.  It also mentions that this is a flexible area for 
design and different approaches to backchannels are expected to be 
considered.  I think that's enough to cover it.

> control so I wonder if this is relevant?

If you want to propose something specific, please do.  "Is the not 
included here" is confusing...  Mostly this is just a warning that we 
can't rely on markings to be honored, even if they're honored on one 
part of the path.

Also s/competed/competing/

> either generalized or reference this document?

We can reference the document and make it align.

> can increase or reduce the stream.

See section 3.

Perhaps something there along the lines of "When there are multiple 
streams across the same 5-tuple coordinating their bandwidth use and 
congestion control, it should be possible for the application to control 
the relative split of available bandwidth."

-- 
Randell Jesup -- rjesup a t mozilla d o t com

---

From: Randell Jesup <[email-masked]>
Date: Tue, 04 Mar 2014 10:45:21 -0500

On 2/19/2014 5:25 PM, Michael Welzl wrote:
> Hi,
>
> Sorry if I missed this in Randell's responses to the reviews - but this text is still there and should be fixed IMO:
>
> ***
>     2.   The algorithm must be fair to other flows, both realtime flows
>          (such as other instances of itself), and TCP flows, both long-
>          lived and bursts such as the traffic generated by a typical web
>          browsing session.  Note that 'fair' is a rather hard-to-define
>          term.
>
>          A.  Existing flows at a bottleneck must also be fair to new
>              flows to that bottleneck, and must allow new flows to ramp
>              up to a useful share of the bottleneck bandwidth quickly.
> ***
>
> Being fair to other instances of itself is one issue, being "fair" to TCP is another one. The latter is covered by the text about trying to avoid starvation of TCP, so I suggest that this item here should not bring TCP into the mix and only talk about other instances of itself.
>
> Regarding fairness, I don't think that saying "must be fair" and "Note that 'fair' is hard to define" isn't really useful - we need to be clear about what we mean. (Sub-item A doesn't make the paragraph above it clearer, it just adds a restriction. I have no problem with sub-item A although I think it's unnecessary.)
>
> I once proposed: "Send at roughly the same rate under similar conditions."
> (with more details in a previous email with subject "Fairness", see the list archives).

This is why it's hard.  Fairness is actually larger than what your 
statement covers - it implies how it reacts when one side has (say) a 
10ms RTT and 10Mbps access links and another flow at the bottleneck has 
150ms RTT and 1Mbps.  (Exactly *what* happens in that case is tough to 
define in detail, but it falls under "fairness" and isn't covered by 
your statement.)

And while we have most control over self-fairness, a workable solution 
to the problem here must coexist "fairly" with other traffic which 
includes TCP (and DNS, etc).

> It has sldo been said that we should mandate RTT-independence too. I'm for it.

Mandate as a requirement?  Not sure; I wouldn't throw out an otherwise 
excellent solution that fell down some there in favor of a so-so 
RTT-independent solution.  Goal or a positive point in evaluation?  yes.

---

From: Michael Welzl <[email-masked]>
Date: Tue, 4 Mar 2014 15:53:07 +0000

On 4. mars 2014, at 15:45, Randell Jesup <[email-masked]> wrote:

> This is why it's hard.  Fairness is actually larger than what your statement covers - it implies how it reacts when one side has (say) a 10ms RTT and 10Mbps access links and another flow at the bottleneck has 150ms RTT and 1Mbps.  (Exactly *what* happens in that case is tough to define in detail, but it falls under "fairness" and isn't covered by your statement.)

I'm aware of that  :-)   My point is that a mechanism must *at least* do what I request here. If it can't achieve a roughly equal rate under completely similar conditions, we deal with a beast that exhibits a behavior that we can't do much with.

> And while we have most control over self-fairness, a workable solution to the problem here must coexist "fairly" with other traffic which includes TCP (and DNS, etc).

Yes, for some definition of that... I think trying to nail the fairness with TCP down into a very specific definition is bound to fail. The current text with "avoid starving and avoid being starved" seems ok to me

> Mandate as a requirement?  Not sure; I wouldn't throw out an otherwise excellent solution that fell down some there in favor of a so-so RTT-independent solution.  Goal or a positive point in evaluation?  yes.

I think the group should have a discussion about this later today.

Cheers,
Michael

---

From: Randell Jesup <[email-masked]>
Date: Tue, 04 Mar 2014 11:03:07 -0500

> I'm aware of that  :-)   My point is that a mechanism must *at least* do what I request here. If it can't achieve a roughly equal rate under completely similar conditions, we deal with a beast that…

Ok, as a subset of fairness, I can state something along that way (it's 
implied by other statements, but this adds a bit more teeth to it).

> Yes, for some definition of that... I think trying to nail the fairness with TCP down into a very specific definition is bound to fail. The current text with "avoid starving and avoid being starved…

ok

> I think the group should have a discussion about this later today.

Ok.  I still don't see it as a hard MUST requirement here, but a 
goal/part of evaluation.  Let's see where the discussion goes.

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 4 Mar 2014 08:26:10 -0800

Here are my comments on the document.
   1.   The congestion control algorithm must attempt to provide as-low-
        as-possible-delay transit for real-time traffic while still
        providing a useful amount of bandwidth, even when faced with
        intermediate bottlenecks and competing flows.
[BA] I am not sure that this requirement is meaningful because of the potential influence of the competing flows.  For example, when TCP is competing withrealtime traffic, it will tend to fill the queue to the point of inducingloss, and there is not much that the RMCAT algorithm can do about this - the "attempts" will be in vain.  So I would separate the requirement into multiple parts, one stating goals in the absence of competing traffic, and another part talking about goals in the presence of competing flows. 
        There may be
        lower limits on the amount of bandwidth that is useful, but this
        is largely application-specific and the application may be able
        to modify or remove flows in order allow some useful flows to
        get enough bandwidth. 
[BA] There are situations such as scalable video coding where the "lowerlimit" is not application-specific, because it relates to the characteristics of the base layer.  So in these situations, once you have stopped sendingextension layers, you only have the base layer, whose characteristics maynot be flexible because of the relationship between the base and extensionlayers. 
        A.  It should also handle routing changes and interface changes
            (WiFi to 3G data, etc) which may radically change the
            bandwidth available, and react quickly, especially if there
            is a reduction in available bandwidth.
[BA] We need to separate routing and interface changes, because routingchanges are typically invisible to the application, whereas interfacechanges will not be.  I would argue that reacting "quickly" to routingtransients is a non-goal because this is a regular feature of the Internet,and the major requirement is to be resilient against them.   This is oneof the reasons that Circuit Breakers is likely to be ineffective in practice- shutting down communications and requiring manual intervention inresponse to a routing transient is going to be annoying at best. 
Interface changes are a distinct issue, because information could beprovided (either through use of bw estimates or information relatingto the interface itself) that could help reset the parameters of thevideo encoder shortly after the interface change.  
        C.  The algorithm must not overreact to short-term bursts (such
            as web-browsing) which can quickly saturate a local-
            bottleneck router or link, but also clear quickly, and
            should recover quickly when the burst ends.  This is
            inherently at odds with the need to react quickly-enough to
            avoid queue buildup.
[BA] It is also at odds with the ability to react quickly to rate adaptation on wireless networks. 
        D.  Similarly periodic bursty flows such as DASH or proprietary
            media streaming algorithms may compete in bursts with the
            algorithm, and may not be adaptive within a burst.  They are
            often are layered on top of TCP.  The algorithm must avoid
            too much delay buildup during those bursts, and quickly
            recover.  Note that this traffic may on an access link, or
            may cause a shift in the location of the bottleneck fir the
            duration of the burst.
[BA] I would argue that it is not within the power of the algorithm to avoiddelay buildup due to competing flows.  They are what they are.  The onlything RMCAT can do is to decide how it wishes to behave in response.
        A.  If possible, it should also share information and adaptation
            with other non-RTP flows between the same endpoints, such as
                              a WebRTC data channel 
[BA] Cooperative adaptation between RTP and SCTP is a tall order, particularly since the RMCAT WG is not chartered to work on SCTP congestion control. 
   11.  It should be evaluated in how it works both with backbone-router
        bottlenecks, (asymmetric) local-loop bottlenecks, and local-lan
        (WiFi/etc) bottlenecks, and in competition with varying numbers
        and types of streams (TCP, TCP variants in use, LEDBAT
        [I-D.ietf-ledbat-congestion], inflexible VoIP UDP flows).
[BA] WiFi, with its (often broken) rate adaptation is going to be a specialchallenge for evaluation, because the loss could be due to interference or poor rate adaptation, rather than dueto congestion.  I would probably delete this.

---

From: Michael Welzl <[email-masked]>
Date: Tue, 4 Mar 2014 17:04:15 +0000

> Ok.  I still don't see it as a hard MUST requirement here, but a goal/part of evaluation.  Let's see where the discussion goes.

So I'm not so concerned about the "throw out an otherwise excellent solution" thing because you can have an excellent solution and *force* it to be RTT-independent... it's about changing the controller, e.g. via using the RTT itself to take it out of the equation - a pretty simple way to do this was described in this paper which is the oldest occurrence of this kind of thing I know of:

http://www.icir.org/floyd/papers/phase.pdf
Check out the beginning of page 37 of the pdf.

Cheers,
Michael

---

From: Stefan Holmer <[email-masked]>
Date: Wed, 5 Mar 2014 10:09:21 +0100

For delay-based CC I have considered the built-in RTT dependency of ack
clocked algorithms a feature. The longer the RTT, the longer it will take
for you to have a chance to do something about the queues you are building
up. Isn't it right that you should be a bit more careful pumping out your
packets in that case?

I guess it boils down to what we mean with fairness... Equal rates or equal
right to build up queues before backing off. Or maybe I've just gotten this
wrong. :)

/Stefan

On Tue, Mar 4, 2014 at 6:04 PM, Michael Welzl <[email-masked]> wrote:

> So I'm not so concerned about the "throw out an otherwise excellent
> solution" thing because you can have an excellent solution and *force* it
> to be RTT-independent... it's about changing the controller, e.g. via using
> the RTT itself to take it out of the equation - a pretty simple way to do
> this was described in this paper which is the oldest occurrence of this
> kind of thing I know of:
>

---

From: Michael Welzl <[email-masked]>
Date: Wed, 5 Mar 2014 20:11:38 +0000

No, you have it right - it's a trade-off. What you say here is indeed the (only?) counter-argument for RTT-independence.
We have to weigh the two against each other.

I'm not 100% sure - I mean, your argument *is* valid. I'd still lean towards RTT-independence but can live with both decisions.

Cheers,
Michael

On 5. mars 2014, at 09:09, Stefan Holmer <[email-masked]> wrote:

> For delay-based CC I have considered the built-in RTT dependency of ack clocked algorithms a feature. The longer the RTT, the longer it will take for you to have a chance to do something about the queues you are building up. Isn't it right that you should be a bit more careful pumping out your packets in that case?
> 
> I guess it boils down to what we mean with fairness... Equal rates or equal right to build up queues before backing off. Or maybe I've just gotten this wrong. :)
> 
> /Stefan
> 
>

---

From: "Xiaoqing Zhu (xiaoqzhu)" <[email-masked]>
Date: Wed, 5 Mar 2014 20:30:35 +0000

Stefan:

I agree with your argument that the longer the RTT, more careful the flow needs to be in pumping out the packets. But, why would it necessarily translate to a lower portion of bandwidth sharing *at steady state*?  Or maybe I misunderstood you somewhere?

Thanks,
Xiaoqing

________________________________
From: rmcat [[email-masked]] on behalf of Michael Welzl [[email-masked]]
Sent: Wednesday, March 05, 2014 2:11 PM
To: Stefan Holmer
Cc: Randell Jesup; rmcat WG
Subject: Re: [rmcat] WGLC for draft-ietf-rmcat-cc-requirements-02

Cheers,
Michael

On 5. mars 2014, at 09:09, Stefan Holmer <[email-masked]<mailto:[email-masked]>> wrote:

/Stefan

Cheers,
Michael

---

From: Harald Alvestrand <[email-masked]>
Date: Sun, 09 Mar 2014 20:29:40 +0100

Changing the subject to allow concern separation...

On 03/05/2014 09:30 PM, Xiaoqing Zhu (xiaoqzhu) wrote:
> Stefan:
>
> I agree with your argument that the longer the RTT, more careful the 
> flow needs to be in pumping out the packets. But, why would it 
> necessarily translate to a lower portion of bandwidth sharing *at 
> steady state*?  Or maybe I misunderstood you somewhere?

A longer time to achieve the steady state for long RTT flows is probably 
a more relevant formulation - I think that's inevitable, or close to it. 
When the stabilization time is a significant fraction of the total 
lifetime of the flow, or when it's long compared to the interval between 
changes in the equilibrium, a long-RTT flow will probably experience 
worse performance than a short-RTT flow, even if they are 
RTT-independent at equilibrium.

> Thanks,
> Xiaoqing
>
>
>
> ------------------------------------------------------------------------
> *From:* rmcat [[email-masked]] on behalf of Michael Welzl 
> [[email-masked]]
> *Sent:* Wednesday, March 05, 2014 2:11 PM
> *To:* Stefan Holmer
> *Cc:* Randell Jesup; rmcat WG
> *Subject:* Re: [rmcat] WGLC for draft-ietf-rmcat-cc-requirements-02
>
> No, you have it right - it's a trade-off. What you say here is indeed 
> the (only?) counter-argument for RTT-independence.
> I'm not 100% sure - I mean, your argument *is* valid. I'd still lean 
> towards RTT-independence but can live with both decisions.
>
> Cheers,
> Michael
>
>
>> For delay-based CC I have considered the built-in RTT dependency of 
>> ack clocked algorithms a feature. The longer the RTT, the longer it 
>> will take for you to have a chance to do something about the queues 
>> you are building up. Isn't it right that you should be a bit more 
>> careful pumping out your packets in that case?
>>
>> I guess it boils down to what we mean with fairness... Equal rates or 
>> equal right to build up queues before backing off. Or maybe I've just 
>> gotten this wrong. :)
>>
>> /Stefan
>>
>>
>>     >>> Mandate as a requirement?  Not sure; I wouldn't throw out an
>>     otherwise excellent solution that fell down some there in favor
>>     of a so-so RTT-independent solution.  Goal or a positive point in
>>     evaluation?  yes.
>>     > Ok.  I still don't see it as a hard MUST requirement here, but
>>     a goal/part of evaluation.  Let's see where the discussion goes.
>>
>>     So I'm not so concerned about the "throw out an otherwise
>>     excellent solution" thing because you can have an excellent
>>     solution and *force* it to be RTT-independent... it's about
>>     changing the controller, e.g. via using the RTT itself to take it
>>     out of the equation - a pretty simple way to do this was
>>     described in this paper which is the oldest occurrence of this
>>     kind of thing I know of:
>>

---

From: "Xiaoqing Zhu (xiaoqzhu)" <[email-masked]>
Date: Mon, 10 Mar 2014 17:28:04 +0000

Thanks for the clarification.

Then, looks like we are on the same page?  we want RTT-independence at equilibrium, and may tolerate RTT-dependence during transit.

Best,
Xiaoqing

________________________________
From: rmcat [[email-masked]] on behalf of Harald Alvestrand [[email-masked]]
Sent: Sunday, March 09, 2014 1:29 PM
To: [email-masked]
Subject: [rmcat] RTT-independence (Re: WGLC for draft-ietf-rmcat-cc-requirements-02)

A longer time to achieve the steady state for long RTT flows is probably a more relevant formulation - I think that's inevitable, or close to it. When the stabilization time is a significant fraction of the total lifetime of the flow, or when it's long compared to the interval between changes in the equilibrium, a long-RTT flow will probably experience worse performance than a short-RTT flow, even if they are RTT-independent at equilibrium.

Thanks,
Xiaoqing

From: rmcat [[email-masked]<mailto:[email-masked]>] on behalf of Michael Welzl [[email-masked]<mailto:[email-masked]>]

Cheers,
Michael

/Stefan

Cheers,
Michael

---

From: Mirja Kühlewind <[email-masked]>
Date: Wed, 12 Mar 2014 14:57:51 +0100

Hi (as individual contributor),

I'd think RTT-fairness is in general a good thing. The question would be, is 
there in rmcat an requirement for RTT-fairness that is more important than 
for other kinds of traffic? I'd actually say yes, because the quality of my 
call should not depend on the fact that my communication partner sits next 
door or on a different continent. (I know it still might, but hopefully not 
because of a RTT-fairness issue...). 

That's for me the reason why this could/should be listed explicitly in the 
requirement document. Like actually all requirements, RTT-fairness should 
only be a 'should', thus it will not be the doorkeeper to not except a 
candidate. But that's similar for all requirements. We might not be able to 
find a solution that can always fulfill all requirement, thus at the end we 
need to have a discussion which requirements are okay to break.

Mirja

On Monday 10 March 2014 18:28:04 Xiaoqing Zhu (xiaoqzhu) wrote:
> Then, looks like we are on the same page?  we want RTT-independence at
> equilibrium, and may tolerate RTT-dependence during transit.
>
> Best,
> Xiaoqing
>
> From: rmcat [[email-masked]] on behalf of Harald Alvestrand
> [[email-masked]] Sent: Sunday, March 09, 2014 1:29 PM
> To: [email-masked]
> I agree with your argument that the longer the RTT, more careful the flow
> needs to be in pumping out the packets. But, why would it necessarily
> translate to a lower portion of bandwidth sharing *at steady state*?  Or
> maybe I misunderstood you somewhere?
>
> A longer time to achieve the steady state for long RTT flows is probably a
> more relevant formulation - I think that's inevitable, or close to it. When
> the stabilization time is a significant fraction of the total lifetime of
> the flow, or when it's long compared to the interval between changes in the
> equilibrium, a long-RTT flow will probably experience worse performance
> than a short-RTT flow, even if they are RTT-independent at equilibrium.
>
> Thanks,
> Xiaoqing
>
>
>
> From: rmcat [[email-masked]<mailto:[email-masked]>] on
> behalf of Michael Welzl [[email-masked]<mailto:[email-masked]>]
> No, you have it right - it's a trade-off. What you say here is indeed the
> (only?) counter-argument for RTT-independence. We have to weigh the two
> against each other.
>
> On 5. mars 2014, at 09:09, Stefan Holmer
> <[email-masked]<mailto:[email-masked]>> wrote:
>
> On Tue, Mar 4, 2014 at 6:04 PM, Michael Welzl

---

From: Randell Jesup <[email-masked]>
Date: Thu, 20 Mar 2014 10:58:42 -0400

> need to have a discussion which requirements are okay to break.

100% agree: it can be a goal we include in evaluation, but not a hard 
blocker

---

From: Michael Welzl <[email-masked]>
Date: Thu, 20 Mar 2014 16:13:05 +0100

On 20. mars 2014, at 15:58, Randell Jesup wrote:

> 100% agree: it can be a goal we include in evaluation, but not a hard blocker

Fine by me.

(and for those who totally want it, coupled cc. should be able to force it onto the controller anyway, at least for the flows that originate from one host)

---

From: "Eggert, Lars" <[email-masked]>
Date: Mon, 31 Mar 2014 13:12:14 +0000

Hi,

On 2014-2-17, at 15:53, Eggert, Lars <[email-masked]> wrote:
> we'd like to start the working group last call for draft-ietf-rmcat-cc-requirements-02. Please send your feedback to the list.
> 
> We're letting this LC run until March 12 (after the London meeting), so there will also be a chance to discuss any feedback there.

the WGLC has concluded. Thank you all for commenting; we are expecting the editor to submit a version reflecting them shortly. Afterwards, we will forward the document to the IESG.

Lars

---

From: Randell Jesup <[email-masked]>
Date: Mon, 31 Mar 2014 11:51:36 -0400

Planning an update incorporating feedback later today.

Incorporated feedback from Magnus.  Three notes:

> I would suggest adding a reference to DASH and possibly expand it.

Done, though I had to guess at the correct way to reference an ISO spec.

> either generalized or reference this document?

The division I mention was spoken to (can't remember if it was on-list, 
or in a meeting) in the terms I gave above.  To be honest, I'd want 
something equivalent to that, and if the draft given isn't providing it 
yet we need to address that.  I'd want feedback data to have higher 
priority than audio if at all possible; if not higher then equal to 
audio.  This is complicated by there being no standard ordering of DSCP 
classes.  Thus far I'm not referencing that personal draft.  And 
"envisioned" is a very soft term.

> can increase or reduce the stream.

Yes, if there's a shared congestion context with multiple streams, then 
something is deciding how many bits of the shared resource each stream 
gets, and that's not part of this requirement.  I'd consider how the 
bits are apportioned between flows in a coupled-cc case as not being 
part of this requirement.

---

From: Randell Jesup <[email-masked]>
Date: Mon, 31 Mar 2014 13:38:10 -0400

On 3/4/2014 11:26 AM, Bernard Aboba wrote:
> [BA] I am not sure that this requirement is meaningful because of the potential influence of the competing flows.  For example, when TCP is competing with
> realtime traffic, it will tend to fill the queue to the point of inducing
> loss, and there is not much that the RMCAT algorithm can do about this - the "attempts" will be in vain.  SoI would separate the requirement into multiple parts, one stating goals inthe absence of competing traffic, and another part talking about goals in the presence of competing flows.

I separated that out into a bullet point, and mentioned there's a limit 
on what's possible to achieve.

> [BA] There are situations such as scalable video coding where the "lower
> limit" is not application-specific, because it relates to the characteristics of the base layer.  So in these situations, once you have stopped sending
> extension layers, you only have the base layer, whose characteristics may
> not be flexible because of the relationship between the base and extension
> layers.

I don't see this as affecting the requirement; we state there may be 
lower limits, and that this is "largely" application-specific (and 
"application-specific" would include a layered codec and the 
configuration of that codec).

> [BA] We need to separate routing and interface changes, because routing
> changes are typically invisible to the application, whereas interface
> changes will not be.  I would argue that reacting "quickly" to routing
> transients is a non-goal because this is a regular feature of the Internet,
> and the major requirement is to be resilient against them.   This is one
> of the reasons that Circuit Breakers is likely to be ineffective in practice- shutting down communications and requiring manual intervention in
> response to a routing transient is going to be annoying at best.
> Interface changes are a distinct issue, because information could be
> provided (either through use of bw estimates or information relating
> to the interface itself) that could help reset the parameters of the
> video encoder shortly after the interface change.

Separated them, and also mentioned that on an interface change we assume 
the algorithm can be notified.

> [BA] It is also at odds with the ability to react quickly to rate adaptation on wireless networks.

Among other things.  We like things that are inherently at odds in 
low-delay congestion control ;-) :-/

> [BA] I would argue that it is not within the power of the algorithm to avoid
> delay buildup due to competing flows.  They are what they are.  The only
> thing RMCAT can do is to decide how it wishes to behave in response.

I disagree in detail, though I agree in general.  Our algorithm will 
affect other protocols, if in no other way than how quickly they ramp up 
and exactly where they stabilize.  Since these are time-limited, we may 
have some luck in allowing moderate delay buildup during a burst, or 
perhaps simply giving in for the burst and immediately popping back up 
after it ends will work better. (Especially if the algorithm can detect 
a regular bursty flow or simply the end of a competing flow.)  For 
example, we could notice a sudden very-greedy flow, back way off, and as 
soon as we see the queue start to drain immediately try restoring our 
previous flow level instead of ramping back up.  If we immediately start 
building queues, we know it wasn't a simple burst and can switch behaviors.

So I'll keep the current text and let's see what the proposals can manage.

> [BA] Cooperative adaptation between RTP and SCTP is a tall order, particularly since the RMCAT WG is not chartered to work on SCTP congestion control.

"If possible."  This might occur at the application or 
congestion-controller level.

>          [I-D.ietf-ledbat-congestion  <http://tools.ietf.org/html/draft-ietf-rmcat-cc-requirements-02#ref-I-D.ietf-ledbat-congestion>], inflexible VoIP UDP flows).
> [BA] WiFi, with its (often broken) rate adaptation is going to be a specialchallengefor evaluation, because the loss could be due to interference or poor rate adaptation, rather than due
> to congestion.  I would probably delete this.
>

it should be evaluated with regards to those.  This is for the 
evaluation spec.  And some of those evaluations may be more useful than 
others, or easier than others.  WiFi may be problematic, but it's a HUGE 
usecase, and larger going forward.  In terms of importance, I'd likely 
put it on a par with wired and perhaps even higher (thinking to the 
future).  Of course, it may work better with newer/better/less-buggy 
wifi routing too.