[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [ns] issues on ErrorModel AGAIN!
Since the outrage of our mail server, sorry for this very late mail.
> -----Original Message-----
> From: jahn-isi [mailto:[email protected]]
> Sent: Thursday, July 12, 2001 7:59 AM
> To: Hong Bin Liao
> Cc: NS-2, USERS (E-mail)
> Subject: RE: [ns] issues on ErrorModel AGAIN!
>
>
> I am not sure why the code for inserting random delay after
> dropping a packet
> is there. But it turns out that the test suites for executing
> that code are
> three, test-suite-session.tcl, test-suite-mixmode.tcl, and
> test-suite-srm.tcl.
>
There are also several other tests with error module by grep 'lossmodel'
in tcl/test.
These test suites only test insert-loss which inserts the error model
before the queue. IMHO, it can not simulate the link error model. The
packet loss is different from packet error.
> And they want to call the queue resume function after some
> random delay
> whose average is the transmission delay after dropping some specified
> packets. In these three test scenario files, they set the
> packet type to
> drop by using the command "drop-packet" when they set the drop-target
> with the null agent. I guess that this code is just for their
> experiments. I
> am not sure why. Is there anybody who knows why??
>
The average delay is only half of the transmission delay rather than the
transmission delay since uniform(r) only generates random value from [0,
r) uniformly.
After checking the CVS log of errmodel.cc, it is changed at revision
1.38 to use bandwidth_ to determine when to resume the queue (however,
it use the random value between [0,transmission delay), WHY?). Before
that revision, the error module resumes the queue handler after
0.000001s.
> But normally when packets are delivered over target which is a neigbor
> after the error module decides whether or not the packets
> will have errors.
> So, other test suites are not affected by this code at all.
>
No true. The test suite never test the error model using link-lossmodel.
For network with link error, e.g. wireless network, the error model is a
key issue for the simulation.
HongBin
07/18/2001
> -jahn
>
>
>
>
> > -----Original Message-----
> > From: Hong Bin Liao [mailto:[email protected]]
> > Sent: Wednesday, July 11, 2001 10:22 AM
> > To: jahn-isi
> > Cc: NS-2, USERS (E-mail)
> > Subject: RE: [ns] issues on ErrorModel AGAIN!
> >
> >
> > Hi,
> > Sorry if the problem I stated is not so clear.
> >
> > the queue in ns-2 is resumed after a packet is transmitted, i.e.
> > after txtime() in delay.h (8. * hdr_cmn::access(p)->size() /
> > bandwidth_). However, after an error model is inserted
> before the link
> > module, it will drop packet after detecting it is
> corrupted. Then, the
> > error module try to schedule the handler to resume the queue after
> > Random::uniform(8.0 * ch->size() / bandwidth_) seconds, that means a
> > corrupted packet will trigger the queue resume handler
> earlier than a
> > correct packet. In the other word, a corrupted packet will take less
> > bandwidth than a correct packet.
> >
> > Hongbin
> > 07/11/2001
> >
> > > -----Original Message-----
> > > From: jahn-isi [mailto:[email protected]]
> > > Sent: Wednesday, July 11, 2001 1:48 AM
> > > To: Hong Bin Liao
> > > Subject: RE: [ns] issues on ErrorModel AGAIN!
> > >
> > >
> > > I am not sure that I can understand your stated problem.
> > > -jahn
> > >
> > > -----Original Message-----
> > > From: Hong Bin Liao [mailto:[email protected]]
> > > Sent: Tuesday, July 10, 2001 11:53 AM
> > > To: jahn-isi
> > > Cc: NS-2, USERS (E-mail)
> > > Subject: RE: [ns] issues on ErrorModel AGAIN!
> > >
> > >
> > > In the NS-2 implementation, error model is insert before the queue
> > > module or the link module. For the insertion before the link
> > > module, if
> > > a corrupted packet is immediately dropped and the resume
> > > handler of this
> > > packet are invoked after a random period between 0 to
> (PacketSize/BW).
> > > This means a corrupted packet consumes less bandwidth
> than a correct
> > > packet. There is also another fatal issue for time
> continuous error
> > > model, since a corrupted packet takes less flight time
> than a correct
> > > packet, it cause more burst error than error model with
> bit, byte, etc
> > > as the error unit.
> > >
> > > -hongbin
> > >
> > > > -----Original Message-----
> > > > From: jahn-isi [mailto:[email protected]]
> > > > Sent: Saturday, July 07, 2001 5:21 AM
> > > > To: Hong Bin Liao
> > > > Cc: [email protected]
> > > > Subject: RE: [ns] issues on ErrorModel AGAIN!
> > > >
> > > >
> > > > I am not sure why there is a delay before notifying the packet
> > > > corruption to the module called the error model.
> > > >
> > > > But, corrupted packets are immediately sent to the
> specified target
> > > > (which is a neigbor node's link layer or the next low layer
> > > > in wireless networks)
> > > > without any delay after scheduing the notification event
> > > > with some arbitrary
> > > > delay.
> > > >
> > > > You can see this flow by using a gdb debugger.
> > > > -jahn
> > > >
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: [email protected]
> > > > [mailto:[email protected]]On Behalf Of Hong Bin Liao
> > > > Sent: Friday, July 06, 2001 6:01 PM
> > > > To: NS-2, USERS (E-mail)
> > > > Subject: [ns] issues on ErrorModel AGAIN!
> > > >
> > > >
> > > > Hi, Folks
> > > > I sent the following letter several days
> before. I got no answer
> > > > for it. IMHO, it's very fatal issue on the correctness of
> > > model of the
> > > > systems. Could anyone give me answer of it?
> > > >
> > > > Hi, folks
> > > > after reading the source code of errmodel.cc, I
> wonder why the
> > > > resume handler should be delayed for a random period
> between 0 to
> > > > (PacketSize/BW). why not this packet with error is delayed
> > > > for a period
> > > > (PacketSize/BW)?
> > > > The former cause more burst error when error
> unit is bit, byte
> > > > or time (in two/multi state error model).
> > > >
> > > >
> > > > HongBin L.
> > > > 07/06/2001
> > > >
> > > >
> > >
> >
>