[ns] two equal UDP CBR flows in droptail queue get different bandwidths?
ilyes.gouta at gmail.com
Thu Jun 8 23:19:47 PDT 2006
I think that the observed phenomenon depends on how the queue is
serviced too. Part of the explanation is that the MAC layer is
fetching those packets from the queue in a constant pace. And
basically this means that your network isn't loaded enough so that it
causes some "randomness" to be introduced when servicing the queue
(ex: back-off timers). That phenomenon depends on which packet caused
the queue to be full first, at which rate the packets are coming to
the queue and the bandwidth of the MAC layer.
On 6/8/06, Pedro Vale Estrela <pedro.estrela at gmail.com> wrote:
> This is an EXCELENT description of what happens in a non-randomized
> simulation, and from my experience, I fully agree on that.
> It is exactly this kind of material that would be very useful for the NS2
> Wiki, to store this information permanently!
> As such, somebody on this list please contribute it to the NS2 wiki pages!
> Pedro Vale Estrela
> > -----Original Message-----
> > From: ns-users-bounces at ISI.EDU [mailto:ns-users-bounces at ISI.EDU] On Behalf
> > Of Tyler Ross
> > Sent: quinta-feira, 8 de Junho de 2006 16:43
> > To: Eduardo J. Ortega
> > Cc: ns-users at ISI.EDU
> > Subject: Re: [ns] two equal UDP CBR flows in droptail queue get different
> > bandwidths?
> > In reality, sure. What's happening with the simulation though, is that
> > the packets are being sent at the same time. Even though you start the
> > flows sending at t=0 and t=10, when they're both sending, they're
> > sending at the exact same instant. Since internally, everything is
> > handled in a fixed order and nothing is random unless you explicitly
> > make it so, it will always drop the packets from the same source at the
> > same time. Not because it picked the packets from that source to drop,
> > but because that's just the order of things. And once you see how it
> > works for one packet being dropped, the same thing will repeat itself
> > over and over, since no variables are changing.
> > I don't know if that makes sense. Think on the level of one packet
> > (from each source). As you pointed out, the two flows have EXACTLY the
> > same characteristics. So they leave the source at the same time, they
> > take the same amount of time to travel down their respective links, and
> > they arrive at the relay node at the EXACT same time. Problem is, only
> > one packet can actually ride the next link. Yes, they will queue up
> > until the queue is full. Then what? Which one is accepted into queue?
> > Which is dropped? You know that DropTail has no fairness. So it's
> > NOT going to pick the packet from the flow that was dropped last time.
> > It's NOT going to pick one at random. So how will the simulator decide?
> > If you have an array with all the packets and you loop over them, then
> > the first one it comes across gets to join the queue. So which one gets
> > to join the queue is determined by its internal order. Since nothing in
> > the simulation is being changed in your simulation... you can do the
> > same thing 1000 times, and the same thing will happen. So the next
> > time a packet comes along, the same packet will be let through. The
> > only way to change this result is to introduce some randomness to the
> > sending order or to modify the how packets are queued.
> > An even better idea is to prevent packets from being lost in the first
> > place. :)
> > Eduardo J. Ortega wrote:
> > > I understand that Droptail knows nothing about fairness. But, on the
> > average,
> > > and given the fact that both flows have exactly the same
> > characteristics,
> > > shouldn't they experience the same average behaviour?
> > > thanks.
> > >
> > >
> > > On Wednesday 07 June 2006 08:35, Tyler Ross wrote:
> > >> This phenomenon is explained in the tutorial in Marc Greis's tutorial
> > on
> > >> the ns-2 website (see
> > >> http://www.isi.edu/nsnam/ns/tutorial/nsscript2.html ). The queue that
> > >> you're probably using is a DropTail. The DropTail queue has no concept
> > >> of fairness, so it's going to drop whatever packet happens to be there.
> > >>
> > >> If you want some kind of fairness, you can do as the tutorial suggests,
> > >> and replace DropTail with SFQ in your simulation. You will then get a
> > >> fairer split of the bandwidth. If you monitor the queue and the
> > dropped
> > >> packets, you will indeed see that they are queued and dropped in a much
> > >> more equal way.
> > >>
> > >> Eduardo J. Ortega wrote:
> > >>> Hi there:
> > >>>
> > >>> I've set up this experiment. I have two source nodes S1 and S2
> > directly
> > >>> connected to a node R1 and two destination nodes D1 and D2 also
> > directly
> > >>> connected to a node R2. Nodes R1 and R2 are connected. All links are 1
> > >>> Mb/s Full duplex with DropTail. Now, here's the thing. I set up two
> > >>> flows, one going from S1 to D1 and the other one form S2 to D2. Both
> > >>> flows are UDP CBR 1 Mb/s. Flow 1 starts at t=0 and finishes at t=20.
> > >>> flow 2 starts at t=10 and stops at t=15. Sim runs from t=0 to t=25.
> > >>>
> > >>> I'd expect that at t=10 (when flow 2 starts), both flows would
> > experience
> > >>> the same amount of packet losses, so that each one would use about
> > >>> 0.5Mb/s of the link between R1 and R2. But what really happens is that
> > >>> from t=10 to t=15, flow 2 uses all bandwidth while flow 1 loses all
> > >>> packets. Since both flows have the same parameters, shouldn't they
> > >>> receive the same share of bandwidth during that period? Or am i
> > missing
> > >>> something here?
> > >>>
> > >>> Thanks in advance.
> > >
More information about the Ns-users