[R-C] Fairness of RRTCC and TCP

Tue Aug 14 16:05:20 CEST 2012

Sorry for being late to the discussion, but I have been on vacation for the last week.

This is a very interesting study, and I encourage more work like this as we move the analysis forward. As we think about these issues, we should consider using a variety of middlebox buffer management algorithms in the analysis. As we discussed over the last several weeks, we do not have control over the middleboxes and we need to work with a range of buffer management algorithms. 

So- I will start a new thread introducing testing methodology. I do not want to hijack this thread, so I will start a new thread with my detailed thoughts on how we can test the various algorithms against tail drop , RED, WRED and CoDel. I think that doing simulation is a valuable first step, but testing in the flesh is also a large part of the required activity. Ahmed Mansy (copied) and I have done some similar work to see how MPEG DASH flows interact with the various buffer management schemes, and we can leverage these test setups in this analysis. Not surprisingly, the way that the application sends data into the TCP session actually has a major impact on the nature of the cross traffic, and thus on the interactions of the flows. I will lay out some of the details in that new thread.

Bill VerSteeg

-----Original Message-----
From: rtp-congestion-bounces at alvestrand.no [mailto:rtp-congestion-bounces at alvestrand.no] On Behalf Of Varun Singh
Sent: Thursday, August 09, 2012 3:54 AM
To: Mo Zanaty (mzanaty)
Cc: rtp-congestion at alvestrand.no
Subject: Re: [R-C] Fairness of RRTCC and TCP

Hi Mo,

The figure is one of 30 runs and the start times of TCP in each run
was after 30 sec (just to allow rtp to rampup). Since these are short
TCP flows, if there is available bandwidth the flow will complete
quickly (as observed by the small blip in the first 60s). The number
of TCP flows increase with time, and we don't enable all tcp flows at
once but they start as per the wait times.

IMO, the RRTCC takes some time to rampup so initially it doesn't
starve out the TCP. However, mid-simulation when each RRTCC is at
2mbps then your analysis is correct that the TCP just goes from slow
start to congestion avoidance, but as more tcp flows enter the system
they start to push back (more apparent in the 100ms scenario).

I am running some more simulations with tcp starting earlier and
observe how rrtcc competes in that scenario. I will report these in
the coming weeks.

Regards,
Varun

On 8.8.2012, at 5.39, "Mo Zanaty (mzanaty)" <mzanaty at cisco.com> wrote:

> Hi Varun,
>
> Do the TCP flows not start until ~60s after the RRTCC flows start? Or does RRTCC completely starve out all TCP flows until it fully saturates the entire link bandwidth? The latter appears to be the case in the last 2 slides (2xRRTCC+10xTCP), since there is a brief blip of TCP before 60s. Does this mean the queue (50 packets) filled very early at startup and sent all the TCPs from slow start to congestion avoidance while RRTCC continued exponential increase?
>
> Thanks,
> Mo
>
> -----Original Message-----
> From: rtp-congestion-bounces at alvestrand.no [mailto:rtp-congestion-bounces at alvestrand.no] On Behalf Of Varun Singh
> Sent: Thursday, August 02, 2012 11:48 AM
> To: rtp-congestion at alvestrand.no
> Subject: [R-C] Fairness of RRTCC and TCP
>
> Hi,
>
> Following up on the discussion of fairness between interactive
> real-time flows and TCP.
> I've implemented the RRTCC in NS-2 and attached within are the
> preliminary results.
>
> The scenarios that we simulated are:
> 1. RRTCC flow shares a bottleneck with short TCP.
> 2. two RRTCC flows share a bottleneck with with short TCP flows.
>
> The short TCP flows are modelled as on/off flows. The size of the data
> is obtained from a uniform distribution between 100KB and 1.5MB, and
> the idle periods are obtained from an exponential distribution with
> the mean as 10.
>
> The results are available as a short presentation at: http://bit.ly/rrtcc-tcp
>
> I would appreciate any comments and/or feedback.
>
> Cheers,
> Varun
> _______________________________________________
> Rtp-congestion mailing list
> Rtp-congestion at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/rtp-congestion
_______________________________________________
Rtp-congestion mailing list
Rtp-congestion at alvestrand.no
http://www.alvestrand.no/mailman/listinfo/rtp-congestion