[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