Node Packet Buffer

[Janaka Wijekoon]

Dear all,

I am implementing a routing protocol and it needs packet buffer information of a certain router.
Therefore, I checked the ns-3 coding and the doxygen to find information about a packet buffer in a node(router).
However, while I was looking for the ns-3 node's coding, I found that ns-3 doesn't have a packet buffer to to queue incoming packets to a certain node.

What I wanted to clarify is that, does ns-3 have a packet buffer and, is it located in a separate place or separate module?
If ns-3 does not actually have a packet buffer, what is the best place that the group suggest to implement a packet buffer to ns-3 nodes(routers).

According to my understanding, I found that the following method will be a one way to implement a packet buffer. Please correct me if I am going along a wrong path.

I found that all packets are coming to a certain node either *"Node::PromiscReceiveFromDevice"* or *"Node::NonPromiscReceiveFromDevice"* based on our node and interface configuration.
Then the packets are forwarded to the protocol handler, which is *"Node::ReceiveFromDevice"* and the registered routing protocol will handle the packet accordingly.

In that case, I thought to implement a packet buffer and add packets to the packet queue in the *"Node::NonPromiscReceiveFromDevice"* method.
Then serve packet according to some queue model in *"Node::ReceiveFromDevice"* method. 
Is this method correct or wrong?
There are some minor problems that I omitted in this email.

If some one can guide me that will be a great help.

Regards,
JaNa

[Tommaso Pecorella]

Hi,

your analysis is correct. Yet, it is flawed: incoming packet buffers are a myth.
What follows is applicable to ns-3 AND real systems.

When a packet is received by a NetDevice, the corresponding callback is fired. It may be NonPromiscReceiveFromDevice and it may be *also* PromiscReceiveFromDevice (they could be called both).

This, in turns, will call other functions to handle the packet, and the packet is "consumed" by the upper layer.

If the node is a router, the packet will be analyzed and, depending on the routing and forwarding protocols, it will be placed in the outgoing queue of another NetDevice.

It is pretty obvious that the IS a "buffer" for the incoming packet, but it is just one packet long.

The reason is different between ns-3 and a real system.

In ns-3 the CPU time is not modeled. While the transmission protocols will make the time advance, the CPU time required to process a packet is not modeled. As a consequence, all the packets are processed in no time.

In a real system this is not true. While you are deciding what to do with a packet, another one may arrive. In this case you need an input queue, but not in ns-3, simply because it would be always empty.

In order to see something in this input queue, you'd need to model the processing delay. Either it will be either empty or with one packet.

In a real system the input queue (buffer) exists, but it is not relevant either. If that buffer would be "decently" full (average more than 1), then the only conclusion would be: the router has been designed by an imbecile, the CPU is severely limited.

A different (totally different) approach is what happens in a switch. There you can decide to have the buffers in the input lines, and use a backpressure system from the output line to pick the packets. But it is "simply" a method to place the output queues in the input lines. Well, input and output and "mixed mode" queues are a larger topic, but it basically works like that.

Summarizing: you could place some queues in the input lines, but without a system to manage the packets in the correct way, they'll be always empty. Moreover, the queue size is always extremely dependent on HOW you implement the backpressure system.

Simply queueing a packet because the CPU is busy analyzing the previous one will make the queue almost always empty, and it will be just a (bad) measure of the incoming traffic. E.g., 1Gbps NIC with 100Mbps incoming traffic, average queue size 0.1 packets. Unless the CPU is really clogged (which is very difficult to simulate in ns-3).

I hope this helps,

T.

PS: you said "serve packet according to some queue model". THIS is the point: the model. If you have a model... you're extremely lucky and you can go ahead. You need a shim layer between the NetDevice and the upper layers. The easiest thing is to check the sixlowpan module, it does exactly that.

[JaNa]

Hi T,

Yeah thank you very much for your detailed explanation.
Well, "queues are a larger topic, but it basically works like that" I agree with that one.

I totally can understand your explanation and, yeah it really helps me a lot.
According to your explanation and my previous email, If I add packet to a queue in the  *"NonPromiscReceiveFromDevice"* or *"PromiscReceiveFromDevice"* and call the "*ReceiveFromDevice"* according to a certain service rate, I guess that the queue can be implemented.

Based on  the service rate (Which I will decide either randomly or normally), if I serve the queued packets in the "*ReceiveFromDevice"* and send it to the upper layer, then, I guess we can observe some delay between packets and some un-treated packets in the Queue as well.
I guess that is the "You need a shim layer between the NetDevice and the upper layers" you are mentioning in your reply( please correct me if I am wrong).

I did kind of same approach to a streaming server which I was implemented based on the UDP-echo server and now the server is actually working according random services rates. In the mean time, client is sending packets based on the Poisson distribution and, sure I can see the Mue and Lambda are changing and the queue also have some packets buffered. Ill check the same approach to the node and check what happen. Fingers are crosses and lets see.. 

Moreover, I'll look in to the "sixlowpan module" and I'll get some idea how to do that.

While I Implementing the Queue for ns-3 node, if I get some questions I'll let you guys know and after I finishes the implementation, I will let you guys too.
 

Best,

JaNa

 

--
You received this message because you are subscribed to the Google Groups "ns-3-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ns-3-users+...@googlegroups.com.
To post to this group, send email to ns-3-...@googlegroups.com.
Visit this group at http://groups.google.com/group/ns-3-users.
For more options, visit https://groups.google.com/d/optout.

--
Best Regards..

    """""""""""
:)   JaNa     :) 
    """""""""""

[JaNa]

Hi T and other ns-3 users,

Well, as I raised the question, the ns-3 doesn't had a node packet buffer ( or a packet Queue).
Yet, as I mentioned, I was working for implementation of a packet buffer as a shim layer between the net device and the protocol layer.

As my experiment results suggested me, the implementation was a success.
I mentioned in the previous email that I'll post the coding if I successfully implement the buffer to ns-3 router.

In the implementation, as I was suggesting in the first email, both  *"Node::PromiscReceiveFromDevice"* and *"Node::NonPromiscReceiveFromDevice"*

was altered to buffer the packet in to the Queue. The packet queue is defined and implemented on the "node-packet-queue.h/cc".

Further, I was defined a event to schedule a function to serve ( or send the packet to the upper layer) in each second according to a defined service rate.

all the files are attached to the email.

If some one also wanted to implement a packet buffer, please feel free to use the coding. And, if there are any other concerns regarding the implementation,

please feel free to contact me (jan...@west.sd.keio.ac.jp)

Regards,

JaNa

On Mon, Aug 4, 2014 at 2:50 PM, Tommaso Pecorella <tomm...@gmail.com> wrote:

--

You received this message because you are subscribed to the Google Groups "ns-3-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ns-3-users+...@googlegroups.com.
To post to this group, send email to ns-3-...@googlegroups.com.
Visit this group at http://groups.google.com/group/ns-3-users.
For more options, visit https://groups.google.com/d/optout.