Subject: [rmcat] NADA question that didn't get asked due to time

From: Randell Jesup <[email-masked]>
Date: Thu, 01 Aug 2013 14:08:19 -0400

This jabber question didn't get to be echoed due to time (about NADA):

When competing against TCP with droptail, do you kinow why the first 
NADA flow doesn't change when a second was added?

Was there some floor that stopped it from driving into the ground? What 
are the dynamics of the resultant steady-state transfer characteristics 
between TCP and NADA flows?  Have you tried two TCP flows?

-- 
Randell Jesup
[email-masked]

---

From: Luca De Cicco <[email-masked]>
Date: Sun, 4 Aug 2013 10:55:56 +0200

Dear all,

I got a question about the slides:

what's the bottleneck buffer size used in the simulations?

Have you checked the performance of a NADA flow with a single TCP flow
using a drop tail queue with different buffer sizes?

Best,
--
Luca De Cicco, PhD, Eng.
Politecnico di Bari
Dipartimento di Elettrotecnica ed Elettronica
Via Re David, 200 - Bari - ITALY
Office: +39 080 596 3851
http://c3lab.poliba.it/index.php/LDC

On Thu, Aug 1, 2013 at 8:08 PM, Randell Jesup <[email-masked]> wrote:
> When competing against TCP with droptail, do you kinow why the first NADA
> flow doesn't change when a second was added?
>
> Was there some floor that stopped it from driving into the ground? What are
> the dynamics of the resultant steady-state transfer characteristics between
> TCP and NADA flows?  Have you tried two TCP flows?
>
> --
> Randell Jesup
> [email-masked]
>

---

From: "Xiaoqing Zhu (xiaoqzhu)" <[email-masked]>
Date: Mon, 5 Aug 2013 19:20:24 +0000

Hi Randell,

Sorry that we didn't get to this question during the presentation, due to time constraints. Please find the answers below, inline.

Thanks,
Xiaoqing

On Aug 1, 2013, at 1:08 PM, Randell Jesup wrote:

> When competing against TCP with droptail, do you kinow why the first NADA flow doesn't change when a second was added?

When the TCP flow becomes active at 20s in our simulation, queuing delay quickly rises from below 50ms to around 200ms (corresponding to a full queue). That explains the quick drop in rate in the first NADA flow. At time t=40s, when the second NADA flow becomes active, the queuing delay remains the same (since it's already at full queue), and the flows experience slightly higher packet losses. As a result, first NADA flow only reduces its rate slightly. Instead, the TCP flow backs off its rate to accommodate the new NADA flow.

I am attaching the both the queueing delay trace (qdelay.png) and the trace on one-way delay and composite congestion signal (delay.png) to help explain this.

>
> Was there some floor that stopped it from driving into the ground?

We set the R_min for NADA flows to be 100Kbps in these simulations. When all three flows (2 NADA flows and 1 TCP) are active over the 4Mbps link, the NADA flows get 0.7Mbps and 1.4Mbps respectively, so they are not hitting the floors yet.

> What are the dynamics of the resultant steady-state transfer characteristics between TCP and NADA flows?

As can be observed from the delay traces, the queue is mainly driven by the saw-tooth behavior of the TCP flow, and NADA flows basically converge on the rate dictated by the composite congestion signal (delay + loss).   Is that what you are asking for in this question?

> Have you tried two TCP flows?
>

Good suggestion. Not yet.

---

From: "Xiaoqing Zhu (xiaoqzhu)" <[email-masked]>
Date: Mon, 5 Aug 2013 19:27:16 +0000

Dear Luca, 

Please find our answer as below. 

Thanks,
Xiaoqing

> what's the bottleneck buffer size used in the simulations?

The bottleneck buffer size is set to 100 packets with a typical packet size of 1000 bytes. Over a 4Mbps link, that corresponds to 200ms of delay when the queue is full. 

> using a drop tail queue with different buffer sizes?

We only have results for NADA against TCP over Droptail with the current buffer size (slide #15 in our presentation).  

Haven't tried with varying the buffer size -- thanks for the suggestion.