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

From: Mirja Kühlewind <[email-masked]>
Date: Tue, 28 Oct 2014 16:15:45 +0100

Hi Ingemar, hi Zahed,

I have a couple of questions/comments (as an individual contributor) on your 
draft. This is not a full review as I'm just addressing a couple of aspects 
which came to my mind immediately when reading (in random order).

1) RTCP feedback
- You might want to think about which calculations should be done at the 
receiver and which at the sender. For LEBDAT it is proposed to calculate the the 
OWD at the receiver but you could probably even find a way to calculate the 
average (queuing) delay at the receiver and e.g. send the feedback only once an 
RTT. In fact if you implement a maximum increase rate, as in LEDBAT, of one 
packet per RTT, it's fine if you only update once per RTT as smaller updates 
will not open a packet window.

- If you don't need a reliable transport, you don't actually need a real 
ack-number. All you need is the number of newly received bytes no matter if in 
order or not. However, later on (at the end of section 4.1.1.1) you say loss 
could be detected by holes in the sequence number space. For actually detecting 
'holes' you would even need something like SACK. I guess you instead assume dup 
ACK as in TCP...? Again I don't think it is needed to copy TCP completely..

- RFC6679 specifies ECN feedback for RTP

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

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)?
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...

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.

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

- 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?

- In general I'm not too sure about the idea of interrupting video (also audio?)...

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?

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?

So far...

Mirja

---

From: Ingemar Johansson S <[email-masked]>
Date: Wed, 29 Oct 2014 09:31:29 +0000

Hi

Many thanks for the comments/questions. 
My, hopefully comprehensible, answers inline below, marked with [IJ]. 

/Ingemar

> -----Original Message-----
> From: Mirja Kühlewind [mailto:[email-masked]]
> Sent: den 28 oktober 2014 16:16
> To: Zaheduzzaman Sarker; Ingemar Johansson S; [email-masked]
> Subject: Comments on draft-johansson-rmcat-scream-cc-03
> 
> Hi Ingemar, hi Zahed,
> 
> draft. This is not a full review as I'm just addressing a couple of aspects which
> came to my mind immediately when reading (in random order).
> 
> 1) RTCP feedback
> receiver and which at the sender. For LEBDAT it is proposed to calculate the
> the OWD at the receiver but you could probably even find a way to calculate
> the average (queuing) delay at the receiver and e.g. send the feedback only
> once an RTT. In fact if you implement a maximum increase rate, as in LEDBAT,
> of one packet per RTT, it's fine if you only update once per RTT as smaller
> updates will not open a packet window.
[IJ] So far I have focused on getting SCReAM robust. For various reasons I ended 
up with all processing  in the sender and timely feedback. But it is possible that one 
can do as you suggest above. The ACK-clocking may need to be solved in some 
other way then as it becomes necessary to predict how many new bytes the next ACK will 
acknowledge in order to keep a steady stream of packets. 
But that can maybe be solved, also in cases where OWD increases suddenly
it is possible to send an early feedback. 
Question is how much one can save with this in terms of RTCP overhead?. 
Digged in the LTE  simulation logs. I ran the simulations with a video source that 
had a max bitrate of 1.5Mbps. 
I use reduce sized RTCP for the feedback and a full compound RTCP is transmitted 
every 2 seconds, AVP regular mode with 70kbps RTCP BW is used. 
I get an RTCP bitrate of maximum 14kbps, in practise one feedback is transmitted 
roughly once per video frame. 14kbps is not too much to worry about and it is definitely 
much less than 70kbps.
But it can perhaps become an issue if the bandwidth in the two directions are 
highly assymetric or in certain conferencing scenarios.

> 
> - If you don't need a reliable transport, you don't actually need a real ack-
> number. All you need is the number of newly received bytes no matter if in
> could be detected by holes in the sequence number space. For actually
> detecting 'holes' you would even need something like SACK. I guess you
> instead assume dup ACK as in TCP...? Again I don't think it is needed to copy
> TCP completely..
[IJ] I would say that one get something like TCP SACK, instead of acknowledgement 
of byte sequences. The loss detection is given by the ACK list. 
I don't use TCP dupACK counting, instead I use a margin to cover possible reordering. 
For instance, if sequence number SN is the highest acknowledged sequence number
the the algorithm looks for loss indications for SN-5 or earlier. The benefit with an ACK 
list is that already there get support for retransmission and similar functionality as 
RFC4585 Generic NACK.

> - 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. 
> this case you just need sent-out timers and there is no self-clocking
[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. 

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

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

> window. At the same time you would want to increase the target. That
> doesn't sound very stable...
> 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
[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. 

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

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

---

From: Mirja Kühlewind <[email-masked]>
Date: Wed, 29 Oct 2014 19:31:04 +0100

Hi Ingemar,

see inline..

> highly assymetric or in certain conferencing scenarios.
My point just was if it is possible to reduce overhead without (strong) 
performance degradation, we should do that. However, if there are good reasons 
to do it this way, you should (simply) state these reasons.

> list is that already there get support for retransmission and similar functionality as
Ah now that I look at Figure 1 that's clear. The text is less clear...

> rule that bytes in flight must still be satisfied.
I'd interpret the terminology here differently. If you don't use the ack arrival 
as trigger to send out new packets but use timers instead, that's not 
self-clocked anymore. As you have a congestion window it's still the packet 
conservation principle but you don't use the ack clock.

> source with limited bitrate, while the file transfer has "unlimited" source bitrate.
Okay, I'm okay to have a higher value that 0.5 but you should reason it and I'm 
not sure if saying you've tested it in a couple of scenarios is enough of 
reasoning. Is there an explanation why Scream has to be more aggressive (in the 
decrease behavior)...?

> if for instance the competing flow has completed.
Ah, so that's one or the other condition have to be true not both at the same 
time...? I would split this up because the first one is the condition to raise 
owd_target while the second might reduce owd_target, right?

> some questions around the behavior/performance in WiFi access, and I am too
I know audio has a much lower rate but should also be congestion controlled. And 
interrupting the video can also be very annoying especially if you do that very 
often. Maybe you have to put a limit how often this probing is done.

> window validation but then on a longer timescale.
Why don't you just increase cwnd instead on sending packets even though cwnd 
would not allow to do so. Where is the difference?
ALLOWED_INCREASE was meant to limit the burstiness. As you use pacing this is 
not a problem for you anyway. However I would prefer to still have 
ALLOWED_INCREASE set to high value instead of removing it completely.
Did you also try to use GAIN because this would be the right parameter, I believe.

> delay gradient algorithms that can do equally well. It can be a good idea to split
Also re-inserting the code in the appendix is probably still helpful...

Mirja