Subject: M-Bone losses into the UK

From: "Mr J.C. Evans" <[email-masked]>
Date: Fri, 22 Nov 1996 10:57:02 +0000 (GMT)

Hello,

I've noticed that Janet M-Bone feed has changed route recently
(missing surfnet.nl). However we're still seeing a large loss on the
sauce-atm.uio.no -> lea.cs.ucl.ac.uk -> noc.ulcc.ja.net links.

Here's a mtrace done at 10:45 GMT, Friday 22nd November on the
NASA feed to here (The University of Liverpool, UK). I noticed a similar
from the recently IEEE London conference.

Any ideas ?

Best wishes,

Jonathan

  Source        Response Dest    Packet Statistics For     Only For Traffic
128.102.84.134  138.253.32.15    All Multicast Traffic     From 128.102.84.134
     |       __/  rtt  331 ms    Lost/Sent = Pct  Rate       To 224.2.206.143
     v      /     hop  223 s     ---------------------     --------------------
128.102.84.150  arcbone.arc.nasa.gov 
     |     ^      ttl   32        0/97   =  0%   9 pps     0/87   =  0%   8 pps
     v     |      hop   62 s      0/369  =  0%  11 pps     0/340  =  0%  10 pps
192.203.230.242 mbone2.nsi.nasa.gov 
     |     ^      ttl   33        0/252  =  0%  25 pps     0/87   =  0%   8 pps
     v     |      hop  392 ms     0/837  =  0%  27 pps     0/340  =  0%  10 pps
192.203.230.241 mbone.nsi.nasa.gov 
     |     ^      ttl   64       -1/621  =  0%  62 pps    -1/87   =  0%   8 pps
     v     |      hop -565 ms    -1/1969 =  0%  63 pps     0/340  =  0%  10 pps
192.42.110.249 
131.119.0.197   paloalto-mbone1.bbnplanet.net 
     |     ^      ttl   65        1/698  =  0%  69 pps     1/88   =  1%   8 pps
     v     |      hop   37 ms   -10/2171 =  0%  70 pps     1/340  =  0%  10 pps
128.167.252.196 collegepk-mbone1.bbnplanet.net 
     |     ^      ttl   66        4/1229 =  0% 122 pps     0/87   =  0%   8 pps
     v     |      hop   12 ms    13/3850 =  0% 124 pps     0/339  =  0%  10 pps
199.94.207.2    cambridge1-mbone1.bbnplanet.net 
     |     ^      ttl   67      141/1289 = 11% 128 pps    -1/87   =  0%   8 pps
     v     |      hop   10 s    442/4043 = 11% 130 pps     1/339  =  0%  10 pps
198.67.134.250  schnell.ebone.net 
     |     ^      ttl   68        2/1312 =  0% 131 pps     0/88   =  0%   8 pps
     v     |      hop  106 s     -4/4103 =  0% 132 pps    -4/338  =  0%  10 pps
192.36.148.206  stockholm.mbone.ebone.net 
     |     ^      ttl   69      101/1743 =  6% 174 pps     5/88   =  6%   8 pps
     v     |      hop -116 s    317/5403 =  6% 174 pps    16/342  =  5%  11 pps
129.240.202.42 
129.240.202.82  sauce-atm.uio.no 
     |     ^      ttl   70        0/1773 =  0% 177 pps     0/83   =  0%   8 pps
     v     |      hop  -16 s     60/5499 =  1% 177 pps     1/326  =  0%  10 pps
128.16.48.10   
128.16.64.24    lea.cs.ucl.ac.uk 
     |     ^      ttl   71      635/1792 = 35% 179 pps    23/83   = 28%   8 pps
     v     |      hop   16 s   2269/5500 = 41% 177 pps    97/325  = 30%  10 pps
193.63.94.25    noc.ulcc.ja.net 
     |     ^      ttl   72       80/1157 =  7% 115 pps     0/60   =  0%   6 pps
     v     |      hop  105 s    228/3231 =  7% 104 pps     0/228  =  0%   7 pps
193.63.94.99    mbone.ulcc.ja.net 
     |     ^      ttl   73       15/401  =  4%  40 pps     1/60   =  2%   6 pps
     v     |      hop -171 s     64/1301 =  5%  41 pps    15/228  =  7%   7 pps
193.63.105.99   mbone.mcc.ja.net 
     |     ^      ttl   74        0/210  =  0%  21 pps     0/59   =  0%   5 pps
     v     |      hop   65 s      0/494  =  0%  15 pps     0/213  =  0%   6 pps
193.63.108.100  noc.dl.ja.net  
     |     ^      ttl   75        0/137  =  0%  13 pps     0/59   =  0%   5 pps
     v     |      hop    7 ms     0/421  =  0%  13 pps     0/213  =  0%   6 pps
138.253.134.19  mbone.liv.ac.uk 
     |     ^      ttl   76        0/126  =  0%  12 pps     0/59   =  0%   5 pps
     v     |      hop  238 s      0/398  =  0%  12 pps     0/213  =  0%   6 pps
138.253.32.15   ss10-15.eeng.liv.ac.uk Not forwarding
     |      \__   ttl   77          0            0 pps       59           5 pps
     v         \  hop  -26 ms       0            0 pps       213          6 pps
138.253.32.15   138.253.32.15

=============================================================================
Jonathan Evans
Department of Electrical Engineering and Electronics
The University of Liverpool                     E-Mail: [email-masked]
PO Box 147                                      Fax: (+44)-(0)151-794-4540
LIVERPOOL   L69 3BX                             Tel: (+44)-(0)151-794-2000
United Kingdom (UK)                                                  Ext.4609
=============================================================================

---

From: Rich Williams <[email-masked]>
Date: Fri, 22 Nov 1996 10:07:01 -0500 (EST)

I'm sure this question has been asked before.. I can't seem to get SDR
to launch the tools. I have put c:\mbone in the path but still can't seem
to get it working. Any help is appreciated!

rw

---

From: Graeme Wood <[email-masked]>
Date: Fri, 22 Nov 1996 16:11:41 +0000 (GMT)

> to get it working. Any help is appreciated!

You also need to set HOME=c:\mbone

=============================================================================
Graeme Wood                                 Email: [email-masked]
Unix Systems Support                        Phone: +44 131 650 5003
The University of Edinburgh                 Fax:   +44 131 650 6552
-----------------------------------------------------------------------------
Scottish MICE National Support Centre       Email: [email-masked]
for your multimedia conferencing support    WWW:   http://mice.ed.ac.uk/mice/
=============================================================================

---

From: John Henson <[email-masked]>
Date: Fri, 22 Nov 1996 14:45:42 -0500 (EST)

I've been trying to connect to an DEC running Mrouted, this machine is on 
the same network.  The other machines subnet mask is different than mine. 
Does this present a problem?  If so (or if not) could someone send me an 
example of an /etc/mrouted.conf that sets up mrouting for this scenario.

Thanks, 

John

---

From: "Mark L. Fausett" <[email-masked]>
Date: Fri, 22 Nov 1996 10:45:32 -0800

I don't know about Win95, but under NT4.0 on the version of sdr from ucl
(sdrtest?) I eventually gave up and binary patched the line that looks
for the tool using the split PATH to split instead an environment
variable called BATH, set BATH to the appropriate path for the NT
install and *then* things worked ok.  Seems that no matter what I set
PATH to in NT it would not appear in the env of tcl.

mf

---

From: Bill Fenner <[email-masked]>
Date: Fri, 22 Nov 1996 12:04:46 PST

In message <[email-masked]> you
 write:
>Does this present a problem?

Yes.  You need to use either the "netmask" or "altnet" commands to
make sure that both mrouters are aware of the physical configuration
of the network.  You can cause forwarding loops otherwise.

  Bill

---

From: Mark Handley<[email-masked]>
Date: Fri, 22 Nov 96 15:27:54 -0500

>sauce-atm.uio.no -> lea.cs.ucl.ac.uk -> noc.ulcc.ja.net links.

The problem appears to have been due to the rate limiting in mrouted -
the rate-limiter on lea.cs.ucl.ac.uk was set to 512Kbps.  Increasing
it cures the loss from lea.cs.ucl.ac.uk to noc.ulcc.ja.net but may
well simply have moved the loss further downstream:

  Source        Response Dest    Packet Statistics For     Only For Traffic
128.16.64.19    128.16.64.19     All Multicast Traffic     From 128.16.64.19
     v       __/  rtt   31 ms    Lost/Sent = Pct  Rate       To 224.2.0.1
128.16.64.24    lea.cs.ucl.ac.uk 
     v     ^      ttl   24        1/2017 =  0% 201 pps     0/1    = --%   0 pps
193.63.94.25    noc.ulcc.ja.net 
     v     ^      ttl   25      131/2016 =  6% 201 pps     0/1    = --%   0 pps
193.63.94.99    mbone.ulcc.ja.net 

The mbone is simply busy.  I think we're going to be regretting the
512Kbps default rate limiter in mrouted a lot in the near future.

BTW, if you notice sdr filling in very slowly, this may be the cause -
sdr (for historical reasons) uses a port in the mrouted "low priority"
range so gets preferencially dropped - we've seen it quite often
recently here at MIT.

Mark

---

From: Joseph Porrovecchio <[email-masked]>
Date: Fri, 22 Nov 1996 16:19:56 -0500

> > to get it working. Any help is appreciated!

My win95 notebook set-up is similar to what you descibe above.
winsdr.exe andassociated  mbone tools are in a directory called
c:\mbone.  My winsdr appears to be locating the tools.

regards,

-- 
Joseph Porrovecchio

ONet Networking
Customer Support/Network Specialist
4 Bancroft Ave. Rm. 101
Toronto, Ontario M5S 1C1
Info: (416) 978-4589 Office: (416) 978-0188
http://enfm.utcc.utoronto.ca/~joseph
-----------------------------------------------------------------------
           "Poor Molly! qui non trovi il pai con fleva!"

                                            Giovanni Pascoli, - "ITALY"  
-----------------------------------------------------------------------

---

From: Petri Helenius <[email-masked]>
Date: Fri, 22 Nov 1996 23:37:57 +0200 (EET)

> 512Kbps default rate limiter in mrouted a lot in the near future.

We got hit by this locally a lot before we moved into the PIM-land
where there is no default limits. The problem is that the limit does
not count your local traffic (scoped) traffic any differently than
anything else so by default you're hitting it more and more
often. People who care do set it to at least 2Mbps or disable it altogether.
 > range so gets preferencially dropped - we've seen it quite often
If Bill is reading this he might want to stop the rate limiting by
default since there really is no one size that fits all.

Pete

---

From: Bill Fenner <[email-masked]>
Date: Fri, 22 Nov 1996 16:47:05 PST

>default since there really is no one size that fits all.

You're right, it was a poor decision to introduce the default rate-limit.
The next version of mrouted will not have a default.  (But might require
an explicit rate-limit specification in the mrouted.conf, even if it's 0).

  Bill

---

From: Petri Helenius <[email-masked]>
Date: Sat, 23 Nov 1996 13:48:35 +0200 (EET)

> an explicit rate-limit specification in the mrouted.conf, even if it's 0).
Sounds like a reasonable compromise between functionality and
configurability. The only downside of this is that you'll end up with
a horde of messages of 'I upgraded my mrouted 3.8 and now my mrouted
does not come up' even when there is a message logged about 'Missing
rate-limit configuration' to syslog.

Pete

---

From: Jon Crowcroft <[email-masked]>
Date: Sun, 24 Nov 1996 15:21:10 +0000

i guess we said when PC tools got released, we'd see the mbone take on
www:-)
 >well simply have moved the loss further downstream:

time to implement some sort of segmentation of the session name space
at least? a la attributes, or usenet like?
 
 >range so gets preferencially dropped - we've seen it quite often

 jon

---

From: Petri Helenius <[email-masked]>
Date: Sun, 24 Nov 1996 20:29:45 +0200 (EET)

> at least? a la attributes, or usenet like?
Do you really think that multicast traffic is the cause of congestion
on these links? I don't. The problem is unicast-replication based
conference tools, media 'streaming' applications and that kind that
get used regardless of whether they are 'network friendly' or not. If
the MBone is more lossy than direct unicast path, guess what gets
used? With the end result of everything going downhill.

Both the companies producing these applications and the users need to
be educated and MBone should be readily available for consumption by
both mentioned parties.

Pete

---

From: Petri Helenius <[email-masked]>
Date: Sun, 24 Nov 1996 20:29:45 +0200 (EET)

Pete

---

From: Jon Crowcroft <[email-masked]>
Date: Mon, 25 Nov 1996 08:56:21 +0000

>used? With the end result of everything going downhill.
 
in general, i completeley agree...

 >be educated and MBone should be readily available for consumption by
 
...and concur.......

see
ftp://cs.ucl.ac.uk/darpa/book.ps
for a draft of something that is trying to do this...

cheers

 jon

---

From: John Henson <[email-masked]>
Date: Mon, 25 Nov 1996 12:18:57 -0500 (EST)

Bill, 

Any idea what this means? And could you possibly send me an example of an 
mrouted.conf with the 'subnet' or 'altnet' options configured.  

Thanks,

John

10:45:06.533 mrouted version 3.8 
10:45:06.591 Getting vifs from kernel interfaces
10:45:06.592 installing ec0 (206.186.51.66 on subnet 206.186.51.64/27) as vif #0 - rate=0
10:45:06.593 Getting vifs from /etc/mrouted.conf
10:45:06.595 can't forward: only one enabled vif

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

---

From: Bill Fenner <[email-masked]>
Date: Mon, 25 Nov 1996 09:09:25 PST

In message <[email-masked]> you
 write:
>Any idea what this means?
>

mrouted needs to have multiple vif's to forward traffic.  It it has only
one interface, then there is no place to forward traffic from or to.

>And could you possibly send me an example of an 

Here's the mrouted.conf I use on my home network.  I have only two hosts
on my network, but it is bridged over an ISDN line to a bigger subnet at
work.  Since it's bridged, the netmask on the interface is 255.255.252.0:

de0: flags=ca43<UP,BROADCAST,RUNNING,ALLMULTI,SIMPLEX,LINK2,MULTICAST> mtu 1500
        inet 13.0.208.199 netmask 0xfffffc00 broadcast 13.0.211.255

But the bridge is configured to block multicast, so for the purposes of
multicast, there really are only two machines on it.  So I use both
netmask and altnet; netmask to make the router think that it's the only
machine on the subnet, and altnet to tell it about the other one:

phyint de0 netmask 0xffffffff altnet 13.0.208.200/32

Another example is in a big routed network that uses proxy-ARP (perhaps
because it was transitioned from a big bridged network); so the interface
netmask is 255.255.0.0 but in reality, it is effectively on a 255.255.255.0
network.  Then you just do

phyint le0 netmask 0xffffff00

Or, if you have a normal routed network except someone put a bridge between
two of the subnets.  Then you use "altnet" to describe the other subnet that
the bridge goes to:

phyint le0 altnet 191.118.25.0/24

  Bill

---

From: Marc MERLIN <[email-masked]>
Date: Mon, 25 Nov 1996 13:08:12 -0800 (PST)

> one interface, then there is no place to forward traffic from or to.

Actually if you  could explain why this  is a problem, I  would be grateful.
Waht  I mean  is:  what is  wrong  with me  having a  PC  running linux  and
receiving a  tunnel on one interface,  and sending back traffic  to my local
net in multicast mode on the same interface.

For now, I  can fool mrouted by  creating a IP alias on  the same interface,
but it looks strange. Is there something I am obviously doing wrong?

Talking about  this, can anyone  provide me  with a tunnel  to 204.80.101.2?
(we  have connectivity  through  ISI, which  is  MCI upstream  if  I am  not
mistaken). I tried to contact [email-masked]  who's supposed to be the contact
for  ISI, but  I never  got any  answer (I  guess he  is either  an outdated
contact, or too busy to deal with me).

Thanks,
Marc

---

From: Bill Fenner <[email-masked]>
Date: Mon, 25 Nov 1996 13:45:35 PST

In message <[email-masked]> Marc MERLIN wrote:
>Bill Fenner:

I should think it's obvious; if you only have one interface (e.g. just
an ethernet and no tunnels), then you don't have anywhere to forward to
or from.

>net in multicast mode on the same interface.

Nothing, there are probably hundreds of mrouted's configured that way.  Since
a tunnel counts as a vif, mrouted has multiple vif's and runs fine.

  Bill

---

From: Marc MERLIN <[email-masked]>
Date: Mon, 25 Nov 1996 15:40:14 -0800 (PST)

> >> mrouted needs  to have multiple  vif's to  forward traffic.  It  it has
> >> only one interface,  then there is no place to  forward traffic from or
> >> to.
> >
> I should think it's obvious; if you  only have one interface (e.g. just an
> ethernet and  no tunnels), then you  don't have anywhere to  forward to or
> from.

Actually I'm not sure  why the same interface and IP  can't receive a tunnel
and multicast to a subnet at the same time. At little bit like with the same
IP I can do  ppp and ethernet (and route between the two),  but I agreee, in
that example, there are two interfaces. I guess the reason must be linked to
routing, meaning  Unix can't  route betweem  two places  coming on  the same
interface and the same IP.
 
> >What I  mean is:  what is  wrong with me  having a  PC running  linux and
> Nothing, there  are probably  hundreds of  mrouted's configured  that way.
> Since a tunnel counts as a vif, mrouted has multiple vif's and runs fine.

Ok, at least it will work :-)

Thanks,
Marc