Subject: Re: tunnel to Hungarnet

From: "Peter Feil" <[email-masked]>
Date: Thu, 4 Apr 1996 00:05:43 +0200

On Apr 3,  5:27pm, Erik-Jan Bos wrote:
> Subject: Re: tunnel to Hungarnet
>
> > > I've just given a look to the map of Europanet; it seems that HU is
directly
> > > connected to a router in Amsterdam. Maybe the host broodjeham.surfnet.nl
> > > could provide the feed you need.
> >
> > from the network topology point of view you are right.
> > But I am wondering if it is a good idea to load broodjeham
> > with one more tunnel: It has already more than 20 MBone
> > tunnels configured and we made the experience that more
> > than 10 tunnels on one mrouted are simply too much.
>
> Thanks for making my point, before I was able to make it :-).
>
> > Isn`t there a possibility to split up the tunnels at
> > surfnet and to use there more than one mrouted machine?
>
> Please ship one Sun SPARC 20 to me.
Did you ever ask any major workstation (or router) vendor
about this?
I am quite sure that it should be possible to get a sponsor
for the most important MBone node in Europe at the moment.
(we are very happy about having HP as sponsoring partner
 for the MERCI project; see
   http://www-mice.cs.ucl.ac.uk/mice/merci/    )  :-)))

On Apr 3,  4:31pm, Graeme Wood wrote:
> Yes but it does have multiple interfaces and it is a hefty machine so it
> should be able to cope with that load provided that the unicast routing
> routes the tunnels over the different physical interfaces. However, since
> there appears to be huge problems on the European Mbone at the moment, it
> may be that broodjeham is a place where the problems may be occuring.

Graeme,

thanks for making this point and sorry to all the other
receivers of this message in the world for broadening up this
local (European) discussion; but I think this is of general interest:

- it really looks like broodjeham.surfnet.nl is a bottleneck
  in the European Mbone at the moment; I hope that we can
  solve this thanks to some sponsors and/or to the availability
  of better network connections within Europe (there are
  some things going on: JAMES, TEN-34, MERCI, ...)
- we are running a Sun SparcStation 1000 with several network
  interfaces (including ATM) as MBone router for more than 2 months and
  we made the experience that more than 10Mbit/s of MBone
  traffic (in + out) make the system crash

--->
 - are there any experiences/studies on MBone/multicast performance
   for the systems available today?
 - does anyone know of any system that is capable of handling
   multicast traffic of more than 10Mbit/s ?

Best regards and happy Easter to everyone
--------------------------------------------------------------
Peter Feil
University of Stuttgart
National Supercomputing Center (RUS)
Communication Systems    phone : ++49-711-685 5735
Allmandring 30           fax   : ++49-711-678 7626
70550 Stuttgart          e-mail: [email-masked]
Germany
---------------------------------------------------------------

---

From: Magnus <[email-masked]>
Date: Thu, 04 Apr 1996 01:40:58 +0200

>    http://www-mice.cs.ucl.ac.uk/mice/merci/    )  :-)))

Yes. Not only HP can contribute with workstations, but this is not the way to
build the Mbone in the long run.... there is still only a handfull of points in
the topology where it is the multicast router speed which is the bottleneck
compared to that of slow and saturated links.

Broodjeham and possibly also mbone.cern.ch is the only major boxes that I know
of that have had this problem.
If there is some point where you would have many connections (not necessarily
tunnels) that needs to be interconnected I think that they should be hooked to
a few boxes (possibly REAL routers) and these should be interconnected with
native multicast on a ethernet or FDDI. Native multicast as forwarding 
mechanism
scales much better than haveing that forwarding done by a CPU.

What we should consider is how to make proper exchange points of Mbone traffic
instead of a series of crippled solutions. There is an tendensy towards 
commercial traffic on the Mbone so we should start prepareing the topology for
a production state. Haveing it _just_ working is not good enogth, we should
think on how to be able to expand it in the same way as in the unicast world.

>   some things going on: JAMES, TEN-34, MERCI, ...)

Broodjeham is one of the bottlenecks, and yes it should be splitted into two
boxes at least, but is broodjeham the ideal box topology wise for Amsterdam?

>   traffic (in + out) make the system crash

When you have a high traffic load and now a new "high-bandwidth" stream comes
in it will be duplicated onto every other VIF, since it is not yet pruned off.
Maybe it's time to demostrate this by actually create such a situation.

The CPU switching that workstations provide is certainly limited in bandwidth
when more VIFs are involved. This is just one of the scalability problems of
DVMRP (and similar protocols like PIM-DM).

>    multicast traffic of more than 10Mbit/s ?

Ever tried a bunch of Cisco's sitting on a multicast dedicated FDDI useing
native multicast?

I will make a test to kill one of my Cisco's off.

I know however that a SS10 will not survive pumping a 7 Mbps stream through it
in eather unicast or multicast (still point-to-point) without packet drops.
This may be due to the non-realtime aspects of the OS. You will need an OS 
which
has propper streamlined IP stack as well as good realtime support inside the
kernel process(es). Normal workstations does not have that yet. Doing the same
test over an Cisco 4500 comes out nicely despite the fact that the Cisco's CPU
(an R4000) is switching the packets.

It's not allways CPU power, that's my point. Propper design is better.

Magnus