[ns] Ping protocol in greis's tutorial

Been busy with moving to a new lab.. anyway, was checking some of the online site for ns2 earlier, I found this email quite interesting since I faced the same problem some time ago..

[ns] Ping protocol in greis's tutorial
Hajer FERJANI f.hajer at gmail.com
Fri Jan 27 00:57:31 PST 2006

* Previous message: [ns] Ping protocol in greis's tutorial
* Next message: [ns] ns-2 validation test
* Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Hi Ramya,

I'm using ns2.28 and I know that packet headers management changed a
little bit so the Marc Greis Tutorial could not work anymore.

Now, to add you new packet you have to :
- add you packet name to the enum structure containing packet names in
packet.h (under Common directory) (sorry I don't remeber its name)
- add the name of you packet as it should appears intraces in the same
file (another class just below the enum structure in the same file).

- define an offset and an access () method in the header structure of
you new agent like this :

struct hdr_newAgent{

// Contents of a newAgent message
double send_time;
double weight;
....
// Header access methods
static int offset_; // required by PacketHeaderManager
inline static int& offset() { return offset_; }
inline static hdr_newAgent* access(const Packet* p) {
return (hdr_newAgent*) p->access(offset_);
}

};


notice also that accessing the header of a protocol changed. So for
example to access the IP headerof a received packet, you should do :

struct hdr_ip *ih = HDR_IP(p);

where HDR_IP(p) is defined as:
#define HDR_IP(p) ((struct hdr_ip*)hdr_ip::access(p)).
and access(p) is the inline method of struct hdr_ip.

I think this is all,
Hope this helps.

Bye.

On 26 Jan 2006 17:53:40 -0000, ramya r wrote:
>
>
> Hi,
>
> I tried to implement the Ping protocol specified in the Greis's tutorials under the ~ns/tcl/ns-tutorial folder..
>
> As per the specifications for the necessary changes to be made in order to implement this protocol,
>
> its mentioned that..-
> -----------------------
>
> You also have to add an entry for the new ping packets in the file 'tcl/lib/ns-packet.tcl' in the list at the beginning of the file. It would look like the following piece of code.
>
> { SRMEXT off_srm_ext_}
> { Ping off_ping_ }} {
> set cl PacketHeader/[lindex $pair 0]
> -------------------------
>
> the problem i have is that i do not find any such list in ns-paclet.tcl
>
> there is one list but its found commented ie., its an old code..
>
>
> What do i do?

Overview of TCP congestion control

TCP implements a window based flow control mechanism. Roughly speaking, a window based protocol means that the so called current window size defines a strict upper bound on the amount of unacknowledged data that can be in transit between a give sender-receiver pair. Originally TCP’s flow control was governed simply by the maximum allowed window size advertised by the receiver and the policy that allowed the sender to send new packets only after receiving the acknowledgement for the previous packet.

After the occurrence of the so called congestion collapse in the Internet in the late 80’s it was realised, however, that special congestion control algorithms would be required to prevent the TCP senders from overrunning the resources of the network. In 1988, Tahoe TCP was released including three congestion control algorithms: slow start, congestion avoidance and fast retransmit. In 1990 Reno TCP, providing one more algorithm called fast recovery, was released.

Besides the receiver’s advertised window, awnd, TCP’s congestion control introduced two new variables for the connection: the congestion window, cwnd, and the slowstart threshold, ssthresh. The window size of the sender, w, was defined to be

w = min(cwnd, awnd),

instead of being equal to awnd. The congestion window can be thought of as being a counterpart to advertised window. Whereas awnd is used to prevent the sender from overrunning the resources of the receiver, the purpose of cwnd is to prevent the sender from sending more data than the network can accommodate in the current load conditions.

The idea is to modify cwnd adaptively to reflect the current load of the network. In practice, this is done through detection of lost packets. A packet loss can basically be detected either via a time-out mechanism or via duplicate ACKs.

If a packet has been lost, the receiver keeps sending acknowledgements but does not modify the sequence number field in the ACK packets. When the sender observes several ACKs acknowledging the same packet, it concludes that a packet has been lost.

The next big step...adding a new protocol

Well, you can't really do much with NS-2 if you would just like to play around with existing protocol. I guess the next big step is to test your very own protocol and see it runs in Ns-2.

To start with adding new protocol, there is an online tutorial available (here).

To begin adding new protocol, it's advised that we are familiar with Ns-2 and some C++ knowledge. (If any problem arises, refer back to "ns Notes and Documentation" (now renamed ns Manual).

I will follow the example given on the site :

Tips from the forum :

1. Make sure your protocol agent same as the ping example given in the ns tutorials. Or you can follow one more easy way i.e. look at the codings for dsdv protocol and copy the important functionality of the coding. (You will need to define command and recv functions at least).

2. Make your own directory (say myproto) in the same directory where the directory named dsdv is residing. Put your coding (say myproto.cc and myproto.h) in the directory 'myproto'.

3. Now edit Makefile and put the things in the same way as for dsdv in there.

4. Edit file ~ns/tcl/lib/ns-lib.tcl. In this file search DSDV with the first occurrence of dsdv you will see code like source mobility/dsdv.tcl. At this moment you
don't need to write separate tcl file for your protocol therefore ignore it and go the second occurrence of dsdv in the file ~ns/tcl/lib/ns-lib.tcl and you will see a code section having switch-case control. Here just copy one more body like DSDV. There is only one line of code in the body of DSDV case. Copy the same and modify it for your protocol.

For your protocol it will look like this :
DSDV {
//coding for dsdv (calling a function like dsdv-create-node)
}
MyProto {
//coding for your protocol (calling your function)
}
DSR {
//
}

remember to put space between 'MyProto' and '{' otherwise it won't work. Now go to the third occurrence of DSDV and you will see the coding which is called from the body in switch case. Here is the definition of the func.

Define your function in the same way as for dsdv is there and comment the line containing call for dsdv-start-up because at this moment your protocol is not having any such functionality.

If you will omit 4th step you will get error message like "Wrong node routing Protocol".

5. run make in ~ns directory.

6. Make a tcl script for testing your protocol and you are done.
(extracted from here)