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
Hi Varun, This looks interesting - it would be nice to see self-fairness performance as well. What model did you use for the codec in ns2 (EvalVid or mpeg_traffic or other) ? 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 ...) Thanks, Piers On 2 Aug 2012, at 08:47, Varun Singh wrote:
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@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
Hi Piers, comments inline. On Thu, Aug 2, 2012 at 9:14 PM, Piers O'Hanlon <p.ohanlon@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
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).
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%2... as a guideline for the implementation. Regards, Varun
Thanks,
Piers
On 2 Aug 2012, at 08:47, Varun Singh wrote:
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@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
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@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%2... as a guideline for the implementation.
-- Randell Jesup randell-ietf@jesup.org
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@alvestrand.no [mailto:rtp-congestion-bounces@alvestrand.no] On Behalf Of Varun Singh Sent: Thursday, August 02, 2012 11:48 AM To: rtp-congestion@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@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
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@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@alvestrand.no [mailto:rtp-congestion-bounces@alvestrand.no] On Behalf Of Varun Singh Sent: Thursday, August 02, 2012 11:48 AM To: rtp-congestion@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@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
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@alvestrand.no [mailto:rtp-congestion-bounces@alvestrand.no] On Behalf Of Varun Singh Sent: Thursday, August 09, 2012 3:54 AM To: Mo Zanaty (mzanaty) Cc: rtp-congestion@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@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@alvestrand.no [mailto:rtp-congestion-bounces@alvestrand.no] On Behalf Of Varun Singh Sent: Thursday, August 02, 2012 11:48 AM To: rtp-congestion@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@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
participants (5)
-
Bill Ver Steeg (versteb) -
Mo Zanaty (mzanaty) -
Piers O'Hanlon -
Randell Jesup -
Varun Singh