[R-C] Fairness of RRTCC and TCP

[Randell Jesup]

On 8/2/2012 6:10 PM, Varun Singh wrote:
> Hi Piers,
>
> comments inline.
> On Thu, Aug 2, 2012 at 9:14 PM, Piers O'Hanlon <p.ohanlon at gmail.com> wrote:
>> Hi Varun,
>>
>> This looks interesting - it would be nice to see self-fairness performance
>> as well. What model did you use for the

Yes, the graphs looked very interesting as a start.

> The second set of experiments 2 RTP and TCP, which is not exactly
> evaluating for self fairness but the last two graphs show the two RTP
> flows stacked on top of one another.
>
>> codec in ns2 (EvalVid or mpeg_traffic or other) ?
>>
>
> I dont use either but, I'd have to use EvalVid_RA for this because
> AFAIK EvalVid does only fixed rate. On the other hand, we have an
> implementation which connects ns2 to a real codec over IPC, but the
> simulations take a lot of time and therefore preferred to do just
> packet simulations in the first iteration.
>
> In these simulations, I simplify and use equal sized frames instead of
> a group of pictures (I would have to run more simulations to vary GoP
> and measure its impact and didn't want to pick a wrong GoP for these
> preliminary results).

For interactive traffic, GOPs should be irrelevant(**): recoveries occur 
as a result of loss; simple recovery is some level of IDR/iframe, more 
complex are slice repairs or using older or long-term reference frames. 
  And if the RTT is low(*), the loss might be repaired with a 
retransmit.  All other frames should be deltas (pframes).

A first level approximation would be to simulate it sending an 
IDR/iframe only after being informed of a loss by the receiver.  Also, 
the size of the iframe is relevant too - fixed-quantization iframes can 
cause problems.

Complex recoveries will cause much smaller bandwidth spikes, so iframe 
recovery is worst-case (and what is actually done in the webrtc.org code 
today, ignoring NACK/re-xmits).

Obviously, using a real implementation (at least codec + 
rtp/rtcp/control) will produce a more accurate result - but this should 
be a reasonable approximation.

>
>> I (and probably others) would be interested to have access to the ns2 RRTCC implementation - would it possible to release the source code? (Though I'd be surprised if Google haven't already implemented it in ns2/3 already as well ...)
>
> The code is currently still work in progress as I am also
> experimenting with other types of congestion indicators/algorithms
> (and would need some more time for cleanup) but, I have been using
> http://code.google.com/p/webrtc/source/browse/#svn%2Ftrunk%2Fsrc%2Fmodules%2Fremote_bitrate_estimator
> as a guideline for the implementation.
>

-- 
Randell Jesup
randell-ietf at jesup.org