Re: R: [ns] queue limit

[Brian Lee Bowers <bowersb@lanl.gov>]

On Tuesday 17 July 2001 08:34, Ganesh wrote:
> Hi,
>
> If every node has a Traffice source  ( like a CBR or FTP source
> etc..) and a Agent like TCP or UDP etc..where exactly is this queue
> u are talking about ?? Between CBR source and TCP ?? If so,
> shouldnt it be ideally very large ?? ( Please correct me if I have
> worngly understood the scenario u guys are referring to )

First:  I don't advise using CBR with TCP.  ns considers CBR traffic 
to be UDP style traffic.  If you need big transfers, use FTP.  If you 
use a CBR traffic generator, you can get strange sequence numbers in 
the trace-all file (well, OK, I guess 0 isn't all that strange, but 
when every single packet has a sequence number of 0, it starts to 
feel a little strange).

Second:  yes, you would hope that the local node would have a queue 
large enough to handle any traffic it is sending.  In many cases, the 
default size is more than enough.  For long fat networks (LFNs), it 
often is insufficient.

> 1) Can I modify the queue limits or is it fixed ?? Does it vary
> with each type of traffic source or each Agent ??

You can modify the queue-limit for each individual link.  See chapter 
7 of the ns Manual, section 7.4 specifically.

> 2) How do I know a packet was dropped because it overflowed the
> sender queue ?

Write a short script to filter the trace-all output - you only need 
to keep the dropped packets.

Below is a sample drop line (I stole the drop line from section 22.4 
of the ns Manual, then hand customized it).  The packet was dropped 
at time 1.84609 from the queue for link 2-3 (hop source is the first 
number after the timestamp, hop destination is the second number 
after the timestamp).  The packet originated at node 2 and was 
ultimately destined for node 5 (origination node is 2.0, ultimate 
destination is 5.1).  Your script might even just keep the packets 
dropped at the source node.

d 1.84609 2 3 cbr 210 ------- 0 2.0 5.1 225 610

Using a CBR generator over a LFN with TCP Reno, I had 7M ACKs 
returned and over 3M packets dropped.  The majority (VAST majority) 
of packets dropped at the source node.

--
Brian Lee Bowers        |       RADIANT Team (Summer Intern)
bowersb@lanl.gov        |       Los Alamos National Laboratory