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

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

Jeremy Hall wrote:

> Hi,
>
> Am I to understand this right, multicast routers are suppost to snoop ALL
> UDP traffic that matches this port and process switch it?
>
> Are you making the assumption that
>
> 1: the source is reachable from the receiver unicastly
>
> 2: somewhere unicast and multicast align
>
> 3: unicast and multicast topologies are congruent

Jeremy,

All the issues you mentioned are - as far I understand that draft - true!

I think that a 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 the attached paper that was presented at the
IEEE Local Computer Network Conference in Tampa, FL November 2000.
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, Content Providers, Carriers who did turn IT on.
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.
(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.
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.

IEEE_LC00_Final.pdf