Re: [rmcat] Comments on draft-johansson-rmcat-scream-cc-03

[Dave Taht <[e-mail]>]

On Wed, Oct 29, 2014 at 2:31 AM, Ingemar Johansson S
<[e-mail]> wrote:
> Hi
>
> Many thanks for the comments/questions.
> My, hopefully comprehensible, answers inline below, marked with [IJ].
>


>>
>> - RFC6679 specifies ECN feedback for RTP
> [IJ] Yes, thing is that I am looking more at the accurate ECN for TCP in TCP as one
> anyway has access to timely and frequent feedback in SCReAM. This may however
> change if one can get less frequent fedback to work.

I have to admit that at lower rates (sub 10mbit) ecn is giving me headaches.

What I have been fiddling with lately is doing overload protection, dropping
one or more packets, then marking the delivered packet, at really low rates,
under overload. I have no idea what will happen on many tcps if a drop
is followed by a mark...

>>
>> 2) self-clocking
>> In the intro you say scream is self-clocked but the transmission scheduling
>> (section 4.1.2) says '[packets] are scheduled at intervals given by t_pace'. In
>> this case you just need sent-out timers and there is no self-clocking
>> anymore...?
> [IJ] The pacing is set such that new RTP packets are clocked at intervals given by the
> estimated bandwidth, given by the CWND and the RTT, and the size of the most
> recently transmitted RTP packet. The pacing is there to break up coalescing tendencies
> that I have seen in simulations. It does not do away with the self-clocking as the basic
> rule that bytes in flight must still be satisfied.
>
>>
>> 3) Variables
>> It's hard to follow all the variables you introduce. I would propose to have a
>> section where you introduce all variables at once. Further, just based on the
>> fact that there are quite a lot variables, would it be possible to reduce the
>> number of variables (and thereby even simplify the algorithm without a large
>> performance degradation)?

It might help to twist your brain into thinking about tcp as per laminar.

http://www.ietf.org/archive/id/draft-mathis-tcpm-tcp-laminar-01.txt

When matt first wrote that, I thought he was crazy. Now I am not so sure.

>> Due to my thesis a recently re-read a lot of the congestion control evaluation
>> and design literature and there is actually (e.g. in Jain's 'Congestion
>> Avoidance in Computer Networks...') also some kind of requirement for
>> simplicity because this allows better assessment of question on robustness.
>> So for me personally my next step is to review my own algorithm (in my
>> thesis) and try to make to make it simpler and evaluate how much
>> performance this would cost...
> [IJ] You are right, I will try to do this better next time, a section with all the
> variables in one place is probably a good start.
> Some parts of the algorithm can actually be stripped away, for instance the
> OWD trend computation is there to reduce the jitter, also there are parts in
> the video rate control parts that can be removed. The end result may be
> more jitter but it may be easier to understand the algorithm description
> May reintroduce the pseudo code later on as it may make things more
> comprehensible.
>
>>
>> 4) loss decrease by 0.8
>> Why 0.8? Also, and i know this is often not correctly done in most existing
>> algorithms (in TCP Cubic), you should decrease by at 0.5 after Slow Start, as
>> you have doubled the window before. However as you don't slow start that
>> often, that's probably not a real problem.
> [IJ] This is set based on experimentation against TCP (NewReno) based file
> transfers over the same CoDel or PIE AQM equipped bottleneck.
> If I set the CWND scale in SCReAM to 0.5 i.e reduce by 50% istf 20% I see that the file
> transfer outcompetes SCReAM. I believe this happens because SCReAM has a video
> source with limited bitrate, while the file transfer has "unlimited" source bitrate.

Delighted to see you fiddling with pie and codel. These are the ns2 models?

FQ solves this fairly well. ¨DRR++¨ had some insight as well for more
bursty flows.

First hit off of this

https://www.google.com/search?client=ubuntu&channel=fs&q=DRR%2B%2B+thesis&ie=utf-8&oe=utf-8

>>
>> 5) Conditions for owd_target adjustments
>> - I not sure I really understand the conditions:
>> "
>>     o  owd_mem > owd_target
>>
>>     o  owd_target > owd_target_lo
>> "
>>
>> The first condition, is actually the condition where LEDBAT decreases the
>> window. At the same time you would want to increase the target. That
>> doesn't sound very stable...
>> The second condition I don't understand because you start with
>> owd_target=owd_target_lo but then you never increase it if it is not larger
>> than owd_target_lo... so you never increase...?
> owd_mem is an average OWD. Normally this should not exceed owd_target
> too much or too often but in case this happens it may be an indication of competing
> flows and that the owd_target may need to be increased, depending on outcome of the
> subsequent algorithm steps.
> The second condition indicates that the owd_target is raised to make SCReAM cope with
> competing flows. In that case it is necessary to check if it is possible to reduce owd_target
> if for instance the competing flow has completed.
>
>>
>> - One minor comment on the same section (4.1.1.7): you say the average
>> OWD should be zero (after restart) but you mean the queuing delay should
>> be zero (because the OWD includes the end-to-end delay), right?
> [IJ] OWD in this draft is the one way extra delay. i.e only the queuing delay,
>  guess I need to clarify this.
>>
>> - In general I'm not too sure about the idea of interrupting video (also
>> audio?)...
> [IJ] No audio is not interrupted as it is not transmission scheduled by SCRaAM.
> Only video is interrupted, one can argue how good it is but I have yet to find
> another method that can make SCReAM work well against competing TCP over
> tail drop links and that at the same time does not create self-inflicted congetsion
> in wireless access such as LTE (and possibly even WiFi).
> Possibly the shared bottleneck detection (SBD) can be useful here ?. There was
> some questions around the behavior/performance in WiFi access, and I am too
> among the curious.
>
>>
>> 6) transmission decision
>> Could you explain the the second condition (in section 4.1.2.1) a little more.
>> The idea is that you increase faster (than one packet per RTT) if the delay is
>> low...? LEDBAT already provides variables for this kind of usage, by GAIN and
>> ALLOWED_INCREASE. Would it be an option to use these variables instead?
> [IJ] This section does not deal with the update of the CWND, instead it provides
> with the ability to transmit RTP packets even though bytes in flight exceeds CWND
> under certain conditions.
> About CWND updates : Initially I tried to use the LEDBAT algorithm as is.
> In the end I had to set ALLOWED_INCREASE to a very high value to avoid that
> it limited CWND growth to much so I ended up removing the line
> cwnd = min(cwnd, max_allowed_cwnd) completely. The problem is the source
> (bitrate) limitation properties of the video coder,
> because of this the congetsion window is not always used to its full extent.
> The CWND is however limited by means of congestion
> window validation but then on a longer timescale.
>
>>
>> 7) One very general comment: Maybe it would be an option to separate the
>> framework and the congestion control even more (in different documents)
>> so that one could even use different congestion control schemes...? Or are
>> there any reasons why explicitly LEDBAT is needed?
> [IJ] I based the algorithm on LEDBAT, there could be other concepts like
> delay gradient algorithms that can do equally well. It can be a good idea to split
> up in several drafts.
>>
>> So far...

I do personally find actual code and patches easier to understand.

>>
>> Mirja
>



-- 
Dave Täht

thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks