Re: New Internet Draft on automatic (end-user) tunneling for SSM

[Pieter Liefooghe <pieter@info.vub.ac.be>]

(Repost of my own message from feb. 23th 17:00 GMT+1, which never got
through to the list!? - if you receive it multiple times - sorry)
Ross et al.,

I think that a tunneling solution should be:

1. As generic as possible.
    It should not be limited to SSM. From the moment we do have enough
people who have access to it, I really think that we will be seeing some
collaborative tools that do use IP multicast....One very nice
application could be: Multicast Napster. ;-)
2. As transparent as possible.
    An ideal solution should not require any modification to the network
infrastructure (Hey, why is IP Multicast so slow in being deployed !?).
And preferably, we don't want any modification to the applications; If
we have to wait till we have a new generation of tunnel enabled
applications we are going to wait a long time!
3. The least intrusive as possible.
As noted, you cannot expect a router to SNOOP on every UDP packet! You
don't want to touch that Router that after several hours - and probably
days - is finally running PIM-SM & MSDP the way it should. ;-)
4. Require No modification to the Multicast paradigm.
You can't expect the unicast and multicast topologies to be congruent,
IP multicast flows in the reverse direction as unicast, and in some
situations there is simply no such return path (cfr. Satellite links
etc.), but also peering agreements force ISPs and Carriers to have such
topologies.

This is why I think the solution, I have been working on, is a more
reasonable attempt at the problem.

Full details are available in a paper that was presented at the IEEE
Local Computer Network Conference in Tampa, FL November 2000 and which
is available for download from: http://telecom.vub.ac.be/LCN00.pdf
Note: Some things did change over the past couple of months as a result
of the ongoing development/research in this area! The attached paper
contains an error in the formula for the metric: it should use (Loss)/10
and NOT (1-Loss)/10!

But for those in a hurry, here is a little summary:

1. Deploy in the "IP Multicast cloud" several Application level (e.g.
UDP) Tunnel Servers (Or add a Tunnel Server Service to routers?)
Ideal places: ISPs who want to "try" IP multicast without too much
effort.
2. Let these Tunnel Servers register themselves in a central Tunnel
Database server. The Registration Message contains information about the
Network(s) for which this server wants to act as tunnel server and the
country in which it is located.
This Tunnel Database will hence contain a list with the available Tunnel
Servers.
3. An end-user uses a modified Session Directory application. (or uses a
new generation of multicast application where the tunneling is
integrated.)
    This application is modified in such a way that whenever it detects
that there is no native IP multicast, it sends out a query message
towards the central Tunnel Database server. This (HTTP) query contains
the IP address of the client and the Country where the client is
located. At the Tunnel Database server we first perform a longest prefix
match between the Client IP address and the network address ranges
provided for each tunnel server. If such entries do exist, this yields
one or more tunnel servers located in the "Network" of the end-user. If
this is not the case, we locate all Tunnel servers in the Country of
that client. If there are no tunnel servers for that country, we try to
locate a server in the "Region" of the country. (e.g. End-user in
Belgium, but no Tunnel Server in Belgium would get a list of Tunnel
Servers in - lets say - France and Holland.) If we don't find such a
Tunnel Server in the region a default one is provided. (currently
Located in my lab ;-) )
As a result of this query we get the addresses of one or more tunnel
servers.
4. If we have multiple potential tunnel servers, we determine the "Best
Tunnel Server to use.
    The Best Tunnel server is determined by using a "TCP-Friendly"
measurement of the Packet Loss, Delay and Throughput along the path
between the client and the potential Tunnel Server. We use these
parameters in a formula, which yields us a metric of the path between
the client and the server. (cfr.paper)
    During the measurement we already tunnel between the client and a
randomly chosen Tunnel Server (or we use the previously used Tunnel
Server if this is again in the list).
    The end-user is hence immediately "connected" to the Multicast
Network!
5. After the measurement round we set up a tunnel towards the "Best"
tunnel server and we do a "session hand-over" between the "temporary"
tunnel and the final tunnel.
6. If this is integrated in a Session Directory tool it is now possible
to launch any existing IP Multicast application without modification
because the session directory tool knows which multicast address/port
numbers will be used by the application and hence is capable of
triggering the tunneling of these sessions at launch time. All received
data is re-multicasted locally at the end-user.

The protocol is based on UMTP (the protocol also used in the "New
Internet Draft on automatic (end-user) tunneling for SSM"), but
"enhanced" to allow dynamic tunneling through a firewall (cfr. paper).
Probably we will also need one or more extra fields to carry the Source
address in case of a SSM multicast session.

The architecture described in the paper also contains a part about how
you can locate a SAP/SDP Proxy and how you can retrieve cached SDP
Session Announcements from it and also how you can use it as a remote
announcer of SDP Sessions. - But this is probably less interesting for
the mboned working group -

zaid <zalbanna@MCI.NET> also made the remark that : " We (This
community) also have to consider the high probability that as a result
of this draft no (ISP) will deploy multicast natively ".
At least, with my solution you give all unicast end-users the
POSSIBILITY to access IP multicast content. The mere fact that they do
have this possibility will trigger Content Providers in sending out in
an IP multicast format.
Hence after some time - and with the right publicity and enough
interesting content - you will automatically have enough people who are
using it. If the deployment/management cost of Native IP multicast drops
below the cost of the "wasted" bandwidth, we will immediately see that
ISPs will start to deploy IP multicast natively!
Another nice thing about this solution is that it can be deployed
gradually, and this without modification to the Network infrastructure!

A typical scenario could look like this: An ISP wants to differentiate
itself from all the others and starts to offer this "new" IP Multicast
service (for FREE..the money will come later from the saved bandwidth
when native IP multicast is deployed).
They can do this easily because they only need to enable IP multicast on
one router (Hey, they could even - at first - simply use a DVMRP
tunnel!).
They only deploy one (or more) Tunnel Database servers at that location.
All tunnel end-users of that ISP will - by the mere property of the
longest prefix match query in the Tunnel Database- start to use these
Tunnel Servers. The clients are automatically load balanced over the
"cluster" of tunnel servers.

When an ISP sees an increased demand for tunnels, the ISP has two
options: Add an extra Tunnel Server or deploy native IP multicast! The
choice between these will be "influenced" by the ratio between the
deployment/management cost of IP multicast and the cost of the wasted
bandwidth.

But probably people from the ISP community on these lists could give
their point of view on this deployment strategy?

Ok, these are my ideas on this topic. I do hope people find it
interesting enough to discuss this any further.... If enough interest, I
even might consider coming to the next IETF meeting to present this. ;-)

Bye,

Pieter
-----Original Message-----
From: Ross Finlayson <finlayson@live.com>
To: mboned@network-services.uoregon.edu
<mboned@network-services.uoregon.edu>
Cc: ssm-interest@external.cisco.com <ssm-interest@external.cisco.com>
Date: Thursday, February 22, 2001 10:11 PM
Subject: New Internet Draft on automatic (end-user) tunneling for SSM


I have just written (with Radia Perlman and Doron Rajwan) a new
Internet Draft:

      Accelerating the Deployment of Multicast Using Automatic
Tunneling

                <draft-finlayson-mboned-autotunneling-00.txt>

Abstract

Many Internet users currently cannot participate in wide-area IP
multicast sessions, because their first-hop routers (or beyond) do not
support IP multicast routing.  We describe an application level
(UDP-based) tunneling mechanism that allows non-multicast-connected
users - with no modification to their operating systems - to
automatically receive a large class of multicast sessions, pending the
deployment of multicast in their upstream routers.
-----------

We'll be giving a presentation on this during the MBONED WG session at
the
Minneapolis IETF.  The I-D should get announced shortly; in the
meantime,
you can find a copy online at <http://www.live.com/autotunneling.txt>.

(I'm hoping that this will help break the logjam that has held back
the
widespread adoption of multicast...)

         Ross.



--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Pieter Liefooghe
Research Assistant
Vrije Universiteit Brussel (INFO/TW)
Digital Telecom Dept.
Pleinlaan 2
1050 Brussel
BELGIUM
Tel: +32-2-629.29.77
Fax: +32-2-629.28.70
pieter@info.vub.ac.be
http://www.castguide.com

Quote of the day:

Any program that runs right is obsolete.