Subject: Re: Loss rate in US/E-Bone link

From: John Hawkinson <[email-masked]>
Date: Mon, 11 Nov 1996 19:04:22 -0500 (EST)

> And I keep seeing very high pkt loss rates on the bbnplanet.net routers.
> Right now receiving the Stanford Channel the mtrace path through
> paloalto-mbone1.bbnplanet.net (192.42.110.249) shows a pkt loss
> rate of 85%.

It would be quite helpful if you would forward the mtraces to us.
[email-masked] would be a reasonable place to do so.

The mtrace you cited shows high packet loss overall, but
very low packet loss for the group in question:

128.167.252.196 collegepk-mbone1.bbnplanet.net 
     |     ^      ttl   32     1221/1602 = 76% 160 pps     2/261  =  1%  26 pps
     v     |      hop   54 ms 15955/21066= 76% 152 pps    19/3485 =  1%  25 pps
137.39.43.34    MBONE1.UU.NET  

(Please don't leave out the other end -- when you quoted the mtrace
you left out the MBONE1.UU.NET line).

In general you cannot trust the numbers on the left-hand side of an
mtrace -- they are statistics for all groups going through a router,
but tend to buggy or blatantly wrong with some implementations.

I believe Jonathon was complaining about the transatlantic hops that
saw collectively 53% packet loss:

194.68.128.50   stockholm.mbone.ebone.net 
     |     ^      ttl   67      941/2368 = 40% 236 pps    87/237  = 37%  23 pps
     v     |      hop  -47 s  12018/31284= 38% 226 pps  1271/3188 = 40%  23 pps
193.148.15.2   
192.87.106.102  broodjeham.surfnet.nl 
     |     ^      ttl   68      360/1639 = 22% 163 pps    26/150  = 17%  15 pps
     v     |      hop   46 s   4815/22054= 22% 159 pps   429/1917 = 22%  13 pps
193.63.94.99    mbone.ulcc.ja.net 

That packet loss almost certainly real.

I believe Cisco's implementation (which BBN Planet uses) has a
higher-than-average incidence rate of problems with the all-groups
statistics, so this may be why you're seeing high loss. Again, it is
very hard to tell without more data.

Also, please recall that loss reported by mtrace is a link
characteristic, not a node characteristic -- you need to identify both
endpoints when you refer to something -- the best way to do that is
just include the entire mtrace verbatim.

I believe the 1% loss between uunet and us was a transient problem
that is now corrected, but I'm not completely certain of that.

--jhawk
  John Hawkinson

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 11 Nov 1996 16:33:05 -0800

>> very hard to tell without more data.

    Just our implementation? The problem is that an outgoing LAN interface on
    one router will most likely have a packet count <= to an incoming LAN 
    interface packet count on another router because there may be many 
    forwarders on the LAN for different sources and groups.

    Isn't this a general mtrace statistics problem? BTW, which isn't true
    for the statistics per (S,G) (modulo PIM-DM duplicates).

Dino

---

From: John Hawkinson <[email-masked]>
Date: Mon, 11 Nov 1996 19:59:05 -0500 (EST)

>     forwarders on the LAN for different sources and groups.

That is a problem, but it is not the problem on the particular link
that was cited, which was a tunnel.

>     Isn't this a general mtrace statistics problem?

That is correct. The next version of mtrace will not display
these stats by default, but will require a command-line option.

--jhawk