Re: Snoop in ns2.1

[Hari Balakrishnan <hari@desolation.CS.Berkeley.EDU>]

>>> Amit Saxena said:
 > 
 > Hi,
 > 
 > 	I am trying to plot the arrival packet sequence number versus 
 > time with and without snoop (for the following network)
 > 
 > s(0) ---------------------- n(0) - - - - - - - - - - - -n(1)
 >       10 Mb,1ms,droptail           2Mb,3ms,droptail
 >   
 > When I analyse the output trace files for either case (i.e with and 
 > without snoop) I am unable to find any difference and furthermore I cannot 
 > find any retransmissions taking place due to errors in the wireles link.
 > 
 > I have used the Exponential Error Model. The snoop.tcl file used was 
 > the one which came with ns2.1.
 > 
 > Command line used was 
 > 
 > > ns snoop.tcl -e 0.001 -eu time -stop 5 -ll Snoop -r  (with snoop)
 > > ns snoop.tcl -e 0.001 -eu time -stop 5 -r            (without snoop)
 > 
 > Am I missing something or is it that the default trace file does not 
 > reflect any retransmissions which may occur ?

The trace file does (should) reflect losses, but not retransmissions
by any link-layer protocol.  Corruption-induced losses are shown in
the lines with the letter 'l' in the first column.  The columns that
have 'r' as their first letter correspond to packets being received at
the link layer.

The reason for your not seeing any performance difference for the runs
above is that the error rate you've chosen corresponds to an
exponentially distributed rate of 1 every 0.001s = 1 every 1 ms.  This
is an awfully high error rate for this link, since the delay and
transmission time for any packet is much higher than that.  So what's
happening is that almost every packet in most runs gets clobbered,
thereby preventing much progress.

Having said that, I'm surprised that your trace files for the 2 runs
are identical.  They shouldn't be, because snoop also has a local
retransmission timer that kicks in based on it's estimation of the
last link's rtt and rtt variance.  The values for srtt and rttvar are
initialized to some defaults in snoop.tcl.  I just ran the 2 cases and
while the performance is roughly similar in most runs, the trace files
are quite different.

The bottom line is that these error rates are too high and in all runs
most, if not all, packets will be lost on the link, independent of the
protocol used.

ns snoop.tcl -e 32768 -eu byte [-ll Snoop] -r
ns snoop.tcl -e .300 -eu time [-ll Snoop] -r

would be more realistic things to try out.  The first one has
expon. dist errors with a mean of 32KB, and the second is an expon. 

Let me know if you have any more questions or comments.

Thanks,
Hari.

PS:

 >  PS : I had read a message on the mailing list that there may be new 
 > documentation 
 >       available on using error models over the weekend. Could someone 
 >       please point me to this ? 

Yes, this was promised and I will put it together soon...  Comments on
how to use snoop and the error models and what the different
paramaters mean are in tcl/ex/snoop.tcl