Subject: mTunnel

From: "Toma Belichki" <[email-masked]>
Date: Fri, 26 Sep 1997 16:19:50 +0200

Hi All,
I heard there is a Java implementation of the mrouted. The name 
should be mTunel. Could somebody point me where could I learn more 
about it.
My problem is that we want to use Hughes DirectPC (one way satellite 
connection) to connect to Mbone and the receiving station must be 
Win95.
Any other implementation of mrouted for Win95 would be in help too.
Thank you.
Toma

---

From: Yozo Toda <[email-masked]>
Date: Fri, 26 Sep 1997 22:33:38 +0900

> should be mTunel. Could somebody point me where could I learn more 

in my mail box I found the following mail.
I don't know if it's a kind of mrouted,
check if it's what you want...

-- yozo.

Subject: Re: Multicast for dialup customers?
From: Peter Parnes <[email-masked]>
To: Jin YANG <[email-masked]>
Cc: Richard Williams <[email-masked]>, [email-masked], [email-masked]
Date: Fri, 23 May 1997 12:15:47 +0200

And I at CDT have developed something called mTunnel which is a mcast tunneler that works under windows. It is a general tunneler where the user explicitly selects which sessions to tunnel. mTunnel has a built in session directory for easier tunneling and a built in HTTPd for easier installation as the interface is through the WWW.

The program and a paper describing it can be found at
<URL:http://www.cdt.luth.se/~peppar/progs/mTunnel/>

/P

---

From: Dave Thaler <[email-masked]>
Date: Fri, 26 Sep 1997 11:06:10 -0400 (EDT)

> should be mTunel. Could somebody point me where could I learn more 

There's pointers to most (all?) MBone software (including mTunnel) at:
   http://www.merit.edu/~mbone/index/titles.html

-Dave

---

From: Ross Finlayson <[email-masked]>
Date: Fri, 26 Sep 1997 09:02:02

>Any other implementation of mrouted for Win95 would be in help too.

Windows 95 (at least, with Microsoft's default TCP/IP stack) does not
support 'raw' sockets, IP-in-IP tunneling, multicast routing, etc., etc.,
so "mrouted" cannot be ported to run on it.

However, another way to connect a Windows 95 machine to the MBone (if its
Internet connection is not already MBone-connected) is via UDP-in-UDP
tunneling.  One system that does this is Peter Parnes's "mTunnel", which
you've mentioned.  Another such system is the "multikit" session browser
(which includes SDP browsing).  For details about this, please see:

	http://www.lvn.com/multikit/

(Note, in particular, the link that describes how to use a tunnel to set up
an MBone feed.)

	Ross.

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 26 Sep 1997 09:54:45 -0700 (PDT)

>> (which includes SDP browsing).  For details about this, please see:

    But of course we don't want to encourage this, right?

Dino

---

From: Ross Finlayson <[email-masked]>
Date: Fri, 26 Sep 1997 10:08:05

>    But of course we don't want to encourage this, right?

That's right.  Direct MBone connectivity is clearly the best (& right)
solution.  Ad hoc solutions (such as UDP-in-UDP tunneling) are intended
only as an stop-gap measure.  (For more reassurance, please read
"http://www.lvn.com/multikit/tunnel.html", where I emphasize this.)

Ideally, though, solutions like these will introduce an increasing number
of 'normal' users to the MBone, so they'll be left with a desire for the
'real thing' (direct MBone connectivity).

	Ross.

---

From: [email-masked] (Jeremy Hall)
Date: Fri, 26 Sep 1997 14:55:37 -0400 (EDT)

If they can make it work, they will not have insentive to make it work
correctly.

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 26 Sep 1997 13:03:50 -0700 (PDT)

>> If they can make it work, they will not have insentive to make it work

    And of course, it defeats the whole point of multicast.

    People continue to complain about content and app vendors doing push
    technology the wrong way. Well if they do go and make product that runs
    over IP multicast, the infrastructure people better give them native
    multicast and not tunneled multicast or we gain nothing.

Dino

---

From: "Jeff Young" <[email-masked]>
Date: Fri, 26 Sep 1997 17:32:19 -0400

dino,

none of us are perfect, people who live in glass houses...
and all of that.  i would agree that you gain nothing if
you're stupid enough to tunnel to every receiver of your
content.  the more rich your topology, the more you gain
correct?  i would also submit that it's easy to have rich
enough topology to cover the expensive bits, like the wan
and who cares about the lan as long as you don't congest 
on the local area?  

join the technology agnostic :-). everything has it's place
or no one would have spent the time to code it.  if i could,
i'd use sbt's and flood/prune to source few to few conversations 
in conferences and mcast games.  i'd use cbt's and sparse in one 
to many (which is still just a sbt with one source) where the clients
have to speak to a control head-end anyway.  and i'd use tunneling to reach
through firewalls (put dvmrp on your checkpoint's folks it
works great) oh and bgp4+ on the edge.  of course i'm looking to 
you to do all of this for me...  

and btw, 

have you made these feelings
about tunneling known to the L2tp folks?  i'm in seattle
right now, just a stone's throw away :-).

Jeff Young
[email-masked]

> Return-Path: [email-masked] 
> Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160])
> 	by postoffice.Reston.mci.net (8.8.5/8.8.5) with SMTP id QAA15634;
> 	Fri, 26 Sep 1997 16:18:53 -0400 (EDT)
> Received: by zephyr.isi.edu (5.65c/5.61+local-29)
> 	id <AA25185>; Fri, 26 Sep 1997 13:05:08 -0700
> Received: by zephyr.isi.edu (5.65c/5.61+local-29)
> 	id <AA25165>; Fri, 26 Sep 1997 13:04:37 -0700
> Received: from tnt.isi.edu by zephyr.isi.edu (5.65c/5.61+local-29)
> 	id <AA25159>; Fri, 26 Sep 1997 13:04:35 -0700
> Received: from flipper.cisco.com (flipper.cisco.com [171.69.63.10])
> 	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id NAA18495
> 	for <[email-masked]>; Fri, 26 Sep 1997 13:04:30 -0700 (PDT)
> Received: (dino@localhost) by flipper.cisco.com (8.8.4-Cisco.1/8.6.5) id NAA10682; Fri, 26 Sep 1997 13:03:50 -0700 (PDT)
> Date: Fri, 26 Sep 1997 13:03:50 -0700 (PDT)
> Message-Id: <[email-masked]>
> From: Dino Farinacci <[email-masked]>
> To: [email-masked]
> Cc: [email-masked], [email-masked], [email-masked]
> In-Reply-To: <[email-masked]> ([email-masked])
> Subject: Re: mTunnel
> Sender: [email-masked]
> Precedence: bulk
> Content-Type: text
> Content-Length: 439
>

---

From: Petri Helenius <[email-masked]>
Date: Sat, 27 Sep 1997 00:41:23 +0300 (EEST)

> 'real thing' (direct MBone connectivity).
Which will make us to a full circle for ISP's asking for "real"
multicast inter domain protocol ?

Pete

---

From: Ross Finlayson <[email-masked]>
Date: Fri, 26 Sep 1997 14:47:36

>    And of course, it defeats the whole point of multicast.

Well, gee, I guess the same could be said about "mrouted" tunnels :-)

I think some people may be misunderstanding the purpose (& effect) of
liveGate and other similar tunneling mechanisms.

The ISPs - that run the server end ("liveGate") of the tunnel - must still
be on the MBone.  (I.e., the ISPs still have an incentive to get themselves
an MBone feed.)  Similarly, the client machines must be multicast capable
(e.g., Win 95), and get to run most of the usual applications that use
multicast (e.g., "vat", "vic").

What the tunneling mechanism does is fill a vacuum: Many users currently
access the Internet (i) through portmasters (etc.) that do not support
multicast routing, and (ii) using client OSs that, while multicast-capable,
cannot support mrouted.  Now, one might argue, I suppose, that the vacuum
is being filled by something that still sucks :-), and I wouldn't disagree
with this, except to note that this (large) class of users has *no* other
way to access the MBone.  Giving them this mechanism to access the MBone is
a Good Thing for MBone deployment, for at least three reasons:
1/ They'll ask their ISP to get connected to the MBone (if it's not already).
2/ If their Internet connection is through a portmaster (e.g., Cisco or
Ascend) that supports multicast routing, but (for whatever reason) is not
turned on, they'll ask their ISP to turn multicast routing on.  (Then,
they'll end up not needing tunneling at all.)
3/ Finally, if they end up with no other choice but to use the tunneling
mechanism, then the ISP will have an incentive to upgrade their portmasters
(because the tunneling necessarily involves duplicate unicast traffic on
their internal networks, to service their tunnel clients).

To simply do nothing for this huge class of users - except waiting until
they eventually get full MBone connectivity - is exactly the wrong
approach.  In contrast, the people who are delivering content and apps to
these users aren't 'waiting'.  Instead, they're already filling the vacuum
by giving them *end-to-end unicast*, which ends up being far worse for the
net than ISP<->client tunneling.

	Ross.

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 26 Sep 1997 15:01:12 -0700 (PDT)

>> you to do all of this for me...  

    No different than usual huh :-)

>> right now, just a stone's throw away :-).

    There is a conflict between doing multicast and VPNs (via the use of
    tunnels). We've seen this problem with VLANs and ELANs too. Topology 
    abstraction might be nice on paper but it kills your bandwidth real quick.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 26 Sep 1997 15:02:43 -0700 (PDT)

>> multicast inter domain protocol ?

    You should be quite aware that IDMR is working on this, modulo vendor
    interim hacks to get you something sooner.

Dino

---

From: Petri Helenius <[email-masked]>
Date: Sat, 27 Sep 1997 01:21:05 +0300 (EEST)

> multicast (e.g., "vat", "vic").

Is this livegate stuff something one can pick up and use or will I
need to go shop somewhere? What OS it will run on? An URL would be nice.
 > is being filled by something that still sucks :-), and I wouldn't disagree

If you put a vacuum in an atmosphere, it'll suck by definition. That's
how they invented the vacuum cleaner :-)
(however the wording was left little bad since it does not have any vacuum)

Pete

---

From: Petri Helenius <[email-masked]>
Date: Sat, 27 Sep 1997 01:26:45 +0300 (EEST)

>     abstraction might be nice on paper but it kills your bandwidth real quick.
On the other hand, "optimizing" on the topology abstraction will kill
your access-control and security real quick. My personal opinion is
that doing multicast shortcuts between LISes is a very bad idea. There
is plenty of stuff to be done in the CPE's to better utilize p2mp
functionalities in the l2 topologies, like FUNI would do for frame
based techologies and ATM has already done for cells. Mixing these two
worlds gives even greater benefits. I promise to fill the country or
the continent with this stuff as soon as somebody ships it, any
vendors having this, feel free to contact me.

I should give you some of the pin's I have from Ericsson. They read:
"ATM -- Freedom of bandwidth"      1/2 :-)

Pete

---

From: Petri Helenius <[email-masked]>
Date: Sat, 27 Sep 1997 01:29:49 +0300 (EEST)

>     interim hacks to get you something sooner.
Yes, and I appreciate the job IDMR contributors are doing on this,
BGMP is the solution that left me a good feeling for a change :-)
However, depending how much Win98 will use native IP multicast (and
depending how you read the literature it might do a lot) the circle
might not be complete soon enough.

The buzzword to look for is "True Webcasting". (if my command of
english serves me correctly)

Pete

---

From: Ross Finlayson <[email-masked]>
Date: Fri, 26 Sep 1997 15:41:05

>need to go shop somewhere? What OS it will run on? An URL would be nice.

http://www.lvn.com/liveGate/

	Ross.