Re: [rmcat] 5 tuples and rmcat-cc-requirements-01

Randell Jesup <randell-ietf@jesup.org> Wed, 22 January 2014 19:23 UTC

Message-ID: <52E01A75.30007@jesup.org>
Date: Wed, 22 Jan 2014 14:22:29 -0500
From: Randell Jesup <randell-ietf@jesup.org>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: rmcat@ietf.org
References: <CAA93jw7FDddn2n23fm=rdUsDyGakNfyLkJDgNjoC43fSc4GnSA@mail.gmail.com> <52C17E9F.8060703@alvestrand.no> <CAA93jw4g7bBrxJFfhqVkq0EpezBTY+hahhAJyt5wh=1zTs1EiA@mail.gmail.com> <52C60213.9000401@alvestrand.no> <F737F9D9-4253-4813-A34A-3EAF5915D52F@ifi.uio.no> <CAA93jw6MZ9PObAMvkceAmJhzBkVnPBM9SeRM+m=s7QXAQAv_Rw@mail.gmail.com> <07E05385-225C-4CD9-868C-E86992447BDD@ifi.uio.no> <CAA93jw7nZ3DQ3anrD8FMs-EXW7hM4P-JV3iHrNooQnt3pg_qWA@mail.gmail.com>
In-Reply-To: <CAA93jw7nZ3DQ3anrD8FMs-EXW7hM4P-JV3iHrNooQnt3pg_qWA@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [rmcat] 5 tuples and rmcat-cc-requirements-01
Precedence: list

On 1/4/2014 3:54 PM, Dave Taht wrote:
> On Sat, Jan 4, 2014 at 5:28 AM, Michael Welzl <michawe@ifi.uio.no> wrote:
>
>> Personally, I would be cautious about drawing conclusions from experiments with things that we know to be moving targets. For example, I can't see that you would be able to get an answer to the questions we're discussing here from experimenting with Chromium today.
> I long ago drew a conclusion that current networks have way too much
> buffering for any form of congestion control we know of to work right
> for videoconferencing vs deployed tcps on cable, wifi, 3g and LTE.
> Some hope on DSL & gpon. DSL because most that I have tried already
> have some form of aqm or packet scheduling, gpon as it seems pretty
> good on uploads, and not horrible on downloads.

No realtime flow in the current environment (buffering, greedy TCP) can 
do really well; see the papers and notes from the IAB Realtime 
Congestion Control Workshop that occurred with the BOF for RMCAT 
(Vancouver a year and a half ago).  TCP will try to eat your lunch 
eventually unless someone separates it out (even if there's no 
buffering), unless you're nasty and refuse.  In droptail/etc esp. with 
bloat, this is Bad, as TCP will put you in a queue.  With AQM, you may 
lose but the queuing won't be bad, and you'll see loss you can react 
to.  (And note that current experiments likely haven't tuned the loss 
behavior for AQM yet, though the requirements say they'll need to.)

>
> As for experimentation, certainly answers can be obtained from the
> moving targets!

Just be careful to remember the moving targets may not be stable or 
indicative of the behavior envisioned by the requirements.

>
> Chromium is open source, so anybody can hack on it. I got a build done
> last night. Adding in the bits of code and packet handling I'm
> discussing experimenting with is fairly trivial. (finding where to add
> it and working through the overlarge set of c++ abstractions is thus
> far proving difficult.)
>
> I am interested in the following experiments:
>
> finding the "right" rate quickly

A known flaw in Google's algorithm currently.  My old algorithm 
(Worlgate/Ojo) was very aggressive at the start of a flow and would 
overshoot, then notice queuing developing and back off fast to drain.  
After ~30 seconds it got more conservative about putting it's toes over 
the apparent available bandwidth (high water); when recovering from 
local dips it would be moderately aggressive up to the high-water-mark 
for a stable flow with no delay buildup. Startup behavior was discussed 
a lot 2 years ago on rtcweb.  Also, people who do HD conferences on 
high-bandwidth links and local LANs really, really want to start much 
higher (and adapt up faster).

> dealing with non-congestive (e.g. wifi) losses

Yup.  I used to allow a small amount of loss, then apply modifiers on 
top of apparent delay over a loss threshold (progressively).  You 
generally don't know the cause of a loss (especially in AQM).

> improving recovery after a congestive loss
> better analysis via rtp on separate tuples
> looking at the effects of various proposed classification schemes, and
> how to detect if they are preserved end to end
> what ecn could be used for (and testing for end to end preservation also)
> looking at the interactions of what network types exist today
> (dsl,cable, wifi, 3g) in general

Yup, all interesting.

> looking at aqm and packet scheduling vs drop tail behaviors.

Absolutely and called for in the requirements and the testing doc from 
Varun.

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

[rmcat] 5 tuples and rmcat-cc-requirements-01 Dave Taht
Re: [rmcat] 5 tuples and rmcat-cc-requirements-01 Harald Alvestrand
Re: [rmcat] 5 tuples and rmcat-cc-requirements-01 Michael Welzl
Re: [rmcat] 5 tuples and rmcat-cc-requirements-01 Dave Taht
Re: [rmcat] 5 tuples and rmcat-cc-requirements-01 Harald Alvestrand
Re: [rmcat] 5 tuples and rmcat-cc-requirements-01 Michael Welzl
Re: [rmcat] 5 tuples and rmcat-cc-requirements-01 Dave Taht
Re: [rmcat] 5 tuples and rmcat-cc-requirements-01 Michael Welzl
Re: [rmcat] 5 tuples and rmcat-cc-requirements-01 Dave Taht
Re: [rmcat] 5 tuples and rmcat-cc-requirements-01 John Leslie
Re: [rmcat] 5 tuples and rmcat-cc-requirements-01 Michael Welzl
Re: [rmcat] 5 tuples and rmcat-cc-requirements-01 Michael Welzl
Re: [rmcat] 5 tuples and rmcat-cc-requirements-01 Michael Ramalho (mramalho)
Re: [rmcat] 5 tuples and rmcat-cc-requirements-01 Michael Welzl
Re: [rmcat] 5 tuples and rmcat-cc-requirements-01 Ingemar Johansson S
Re: [rmcat] 5 tuples and rmcat-cc-requirements-01 John Leslie
Re: [rmcat] 5 tuples and rmcat-cc-requirements-01 Randell Jesup
Re: [rmcat] 5 tuples and rmcat-cc-requirements-01 Randell Jesup
Re: [rmcat] 5 tuples and rmcat-cc-requirements-01 Randell Jesup
Re: [rmcat] 5 tuples and rmcat-cc-requirements-01 Dave Taht
Re: [rmcat] 5 tuples and rmcat-cc-requirements-01 Mirja Kuehlewind
Re: [rmcat] 5 tuples and rmcat-cc-requirements-01 Randell Jesup