[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: R: [ns] queue limit



HI ,

Oh, So it is the link Queue (ref Queue. class )  that u guys were
referring to :-) .. Sorry, I thought it was some other queue inbetween
the source and the Agent ( like TCP etc)..

My concern was the nature of traffic that finally comes into the
network...even if we use a ON-OFf source and then we have a TCP  ( with a
bounded queue inbetween TCP and source ,  that drops packets often
because of its overflow rather than the link queue overflow...) then this
queue will disrupt  the randomness of the traffic.. So thats why I was
thinking if there is any queue inbetween the source and the Agent and how
small/large it was.. !!

Thanks..

- Ganesh

Brian Lee Bowers wrote:

> 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)
> [email protected]        |       Los Alamos National Laboratory