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

Re: [Q] nlost_ of LossMonitor



Dear Seniors

During tracking the reason of descrepancy below, I found this. I'm not sure this is an 
intended feature of NS-2.

1. 
This ghost "drop" is due to the packet sequence number gap. When the receiver asserts 
the subscription (of a multicast session), this receiver expects the seq no of the first 
packet be "0." 

2.
However, due to the initial 'broadcasting' of DVMRP, the sequence number is somewhat 
increased, say 542. 

3.
After the receiver starts its subscription, it finds the sequence gap, and it regards that gap
as number of lost packets.  This is the exact reason of below descripancy.

4. 
According to RFC1889 - RTP: A Transport Protocol for Real-Time Applications, the initial
sequence number is random --> This implies, the LossMonitor *SHOULD NOT* expect 
the incoming sequence number, at the first moment. It should check the sequence gap
from the second incoming packet.  

5. 
By the way, there is another interesing phenomenon. I don't know this is the way real-world
acts or not. 
My LossMonitor generated graft packets for a multicast session before the real receiving.
And this graft packets cause the increment of RTP sequence number of that session. :)
Is this correct ?

6.
In order to fix this problem ,
Due to the reason of No.3, I have to do : $lossmonitor set seqno_ -1
Due to the reason of No.5, I have to do : $lossmonitor set seqno_ -8  (Number of graft packets?
Not sure.  Since my tracefile shows number of graft packets is 9 while set seqno_ -8 works correctly)


Can I listen to your opinion, sir.


Jiwoong Lee @KAIST



----- Original Message ----- 
From: Lee Jiwoong <[email protected]>
To: <[email protected]>
Sent: Wednesday, October 27, 1999 7:16 AM
Subject: [Q] nlost_ of LossMonitor


> Dear Seniors
> 
> My LossMonitor is saying : there is some lost packets. The number of them is 542,
> during the runtime of ns-2. (Of course I made it say that info).
> 
> But trace-all file doesn't include any "DROP" information. nam-traceall file doesn't either.
> 
> Is this a possible phenomenon ? I'm not able to find the cause of drop and dropping node.
> 
> (FYI, The link BW is ENOUGH, I included 802_3 in simulation. It seems drop does nothing
> with lan, though.)
> 
> ---
>  Jiwoong Lee @ KAIST EE
>  
>