Traffic Shaper / Leacky bucket

[igrandi]

Dear all,

I need a traffic shaper module on ns3. This module will enable to
limits the throughputs that it sent on each of its interface. This
module is an implementation of the concept of the leaky bucket: so
it'll be similar to a buffer with a leaking rate. The routing layer of
teh ingress node is probing the state of the network frequently and
set the leaky rate accordingly. Any ideas how I could have implement
this design?

Regards,
Imad

[Antti Mäkelä]

On Jul 30, 11:39 am, igrandi <imad.gra...@googlemail.com> wrote:
> I need a traffic shaper module on ns3. This module will enable to
> limits the throughputs that it sent on each of its interface. This
> module is an implementation of the concept of the leaky bucket: so
> it'll be similar to a buffer with a leaking rate. The routing layer of

I'd probably make it a Queue (right now only one that exists is
TailDrop).

If you are going this route, please share your design. Especially if
it includes full CBWFQ functionality :)

[igrandi]

Thank you for your answer. Could you please give further details: i
did't get how it could be done using a queue; i think that i need
rather a new net device. For the traffic shaper that i would build,
the global throughput of a set of flows ( for my case the flows that
take a certain path in an IP domain) needs to be limited: so if a
buffer is attributed to each set/class of flows, what i won't is not
how to prioritize the packets of each buffer but how to make sure that
the throughput of each class is bellow a certain value even if the
flows from the other classes are idled.
My knowledge of traffic shaping as well as scheduling techniques are
limited, so if an analogy between the two exists could you please
explain it further?

Regards,
Imad

[Antti Mäkelä]

On Jul 30, 7:10 pm, igrandi <imad.gra...@googlemail.com> wrote:
> Thank you for your answer. Could you please give further details: i
> did't get how it could be done using a queue; i think that i need
> rather a new net device. For the traffic shaper that i would build,

Right now, all NetDevices work thus:

When they receive a packet from higher layer, they call their
Queue's Enqueue-function.
If line is idle (clear to send), they immediately call Dequeue and
send out the packet.
If the line is busy, at next opportunity the device Dequeues next
packet from queue.

It's up to the Queue implementation to decide what packet comes back
to the NetDevice for it to send out. Thus, a Queue class can easily
act as whatever you need - priority queuing, RED, WRED, etc.

So basically, what happens to the packet after between Enqueue and
Dequeue is a black box - Droptail treats them as a simple FIFO buffer,
but the designs can obviously be much more complex.

I've myself created a priority queuing Queue class that is in fact
nothing more than three normal DropTail queues - upon Enqueue, it
decides based on packet contents which "sub-queue" it stores it in,
and upon Dequeue, it just checks what is the highest priority non-
empty queue.

So Queuing is simply a black box for netdevices. You don't need to
create your own device for traffic shaping.

You might take a look at the patch in http://www.nsnam.org/bugzilla/show_bug.cgi?id=920
- it doesn't implement the PQ as a separate queue yet - you see, I
originally followed your line of thinking and patched
PointToPointNetDevice directly. I really should make an updated patch
that instead inherits from Queue class...

[igrandi]

Thank you for your answer, very useful.
However i still have one point not clair in my mind: let's consider a
simple example with two flow classes, and suppose a burst of packets
from the first class came while the second class is momentally idle.
In this case when the first packet will arrive it'll be enqueued and
dequeued then a timer is set according to how long it will take to
finish transmitting the first packet. Meanwhile the other packets from
the burst will be enqueued in the buffer. When the transmission timer
of the first packet expires the net device will call the queue and ask
for the next packet to be transmitted. What i actually want is, if for
example the maximum allowed rate of the class is half the bandwidth of
the link, the second packet won't be sent immediately and will wait
(even if it's the only one or has the priority) in order to not
exceed the maximum allowed rate, so how could the queue make this
happens? if my understanding is correct, without changing the net
device, after the first packet is transmitted, the queue will be
called and has two option : to say that it's empty or to return the
packet to be transmitted immediately; it can't differ the time of
transmission neither specify when it should be called again.

Thank you in advance for your answer.

>   You might take a look at the patch inhttp://www.nsnam.org/bugzilla/show_bug.cgi?id=920

[Antti Mäkelä]

On Jul 30, 11:31 pm, igrandi <imad.gra...@googlemail.com> wrote:
> for the next packet to be transmitted. What i actually want is, if for
> example the maximum allowed rate of the class is half the bandwidth of
> the link, the second packet won't be sent immediately and will wait
> (even if it's the only one or  has the priority)  in order to not
> exceed the maximum allowed rate, so how could the queue make this
> happens? if my understanding is correct, without changing the net
> device, after the first packet is transmitted, the queue will be
> called and has two option : to say that it's empty or to return the
> packet to be transmitted immediately; it can't differ the time of
> transmission neither specify when it should be called again.

You are correct about that if you do *strict* bandwidth limits,
where the bandwidth of a specific class can not, even if there's room,
exceed specified limit that such a case requires a bit more awareness
from the NetDevice.

If the limit is loose and a class can exceed the limit if there's
room then there's obviously no issue.

Anyway, yes, you are correct, you need to make a change to the
NetDevice that it understands a "defer" state in addition to empty. A
hack-ish solution without the need to alter NetDevices would probably
be to return some sort of "dummy" packet from the queue but just would
take up space and time...

Anyway, even with strict bandwidths, I think the changes to
NetDevices are pretty minimal. In TransmitComplete() where the
NetDevice asks the queue if there's any more packets, it could perhaps
do a call to some sort of method of with return value Time, e.g.

class strictqueue{
Time GetNextSendTime()
};

and it would return a zero if the next packet can be sent
immediately, and a non-zero if deferred, then you'd just schedule the
transmission to the time returned..