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

From: Pieter Liefooghe <[email-masked]>
Date: Sat, 24 Feb 2001 01:40:35 +0100

(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 <[email-masked]> 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 <[email-masked]>
To: [email-masked]
<[email-masked]>
Cc: [email-masked] <[email-masked]>
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
[email-masked]
http://www.castguide.com

Quote of the day:

Any program that runs right is obsolete.

---

From: [email-masked] (Jeremy Hall)
Date: Sat, 24 Feb 2001 10:06:10 -0500 (EST)

now THIS sounds interesting.

marmaduke:~$ whois 208.197.171.112/[email-masked]
[whois.radb.net]
route:         208.192.0.0/10
descr:         UUNET, An MCI Worldcom Company
               3060 Williams Drive
               Fairfax
               VA 22031 USA
origin:        AS701
mnt-by:        MAINT-AS701
changed:       [email-masked] 19990104
source:        RADB
marmaduke:~$

now if we could say:

208.192/10 points to UUNET's database server, then UUNET has a bit more
control of who can use what tunnel server from its own space.

but be careful, it isn't always easy to know where a person is based on IP
address.  The ISP might know how it allocates addresses, but it might not
be willing to announce that to the world.  There is probably something I
am overlooking, but feel free to point it out. :)

_J

---

From: Pieter Liefooghe <[email-masked]>
Date: Sat, 24 Feb 2001 22:42:35 +0100

> now THIS sounds interesting.

Ah, thanks ;-)

> am overlooking, but feel free to point it out. :)

The client application is manually configured with the country where the
client is located. it is not infered from the location information in the DNS
system!
For the second part of your remark... are you alluding to situations where
some NATs/Firewalls are being deployed at the ISP who could "mask" the real IP
address?
In the current status of the architecture, we use the source IP address of the
HTTP query as parameter to the longest prefix match. In most Corporate and
probably many ISP cases this will be the IP address of the Firewall (NAT)
through which the HTTP query went. Hence, the query will yield ALL tunnel
database servers available in the Corporate/ISP domain. As a result of the
path characterization you will see that the "optimal" tunnel database server
will be used.
Although in an ISP with a large amount of Tunnel Servers this could mean a big
amount of Path characterisation overhead!
Maybe we need to think about an hierarchical system of tunnel database
servers. Where you have a root Tunnel Database server who can perform a HTTP
redirect towards a Tunnel database server located in the ISP domain (if one is
available ofcourse otherwise we continue to work as before!). The nice thing
about the redirection is that this redirected query remains within the ISP
domain and that it will "reveal" its real internal IP address. This real IP
address can then be used in the Tunnel Database query to better manage the
distribution of clients over the ISP's topology. In very complex ISP
architectures we could even deploy multiple "levels" of Tunnel Database
servers. And it is clear that these "private" Tunnel Database servers register
themselves dynamically with the central Tunnel Database server and that there
is some form of keep-alive checking.

This is my "quickly engineered" solution to the problem you raised....Is this
any good?

Thanks for the input,

Pieter

Quote of the day:

---

From: Jon Crowcroft <[email-masked]>
Date: Sun, 25 Feb 2001 11:10:27 +0000

i like the handover stuff - i think this is what is missing fro mthe
other auto-tunnel draft - we need to think about
a) giving on tree routers a choice about which of them is the initial
point of grafting a unicast user on
b) letting them change their minds under load....

this work helps us think about this !

i sort of envisage a hybrid between traceroute and rsvp - basically,
you send a tunnel request/join towards one of
i) a known on tree router (configured)
ii) the source (e.g. for ssm )
iii) the rp (pim sm)

as it shoots by various routers that know about the s,g, they can
respond or not, and can modify the inflight request to say so so that
upstream possible tunnel brokers can act on that....

maybe?

j.

---

From: Jon Crowcroft <[email-masked]>
Date: Mon, 26 Feb 2001 08:31:33 +0000

so here's the scoop

somewhere (in www, session advertisement, in skywriting, in DNS if we
can close that discussion:-)
a multicast address is advertised

if its SSM or its PIM SM, then the RP or source are advertised 

so a non multicast receiver can find _A_ unicast (or if anycast RPs
are used, even maybe an anycast, though i guess someone on anISP that
doesnt allow end users multicast probably doesnt let them use other
useful things too - hey, they probably are behind a nat too:-)

anyhow, so rathwerthan something complex for the end user, lets
propose this

1/ send a UMTP request to the source (if ssm) or RP (if PIM SM) p sort
of same thing

2/ the source (or RP) propagates the request down the tree (by
multicast, of course)

3/ the first on tree router that does IP to UDP tunnels says "OK/ACK", and
propgstes this new message up the tree to say "i'm handling it" and
down the tree too (deal with interdomain routers somewhere there
somehow...)

4/ the on tree router handling it send s the unicast response to the
user and starts forwarding data....

5/ UMTP leaves are sent direct to this ontree router.

Handovers:

ontree router is now taking place of the SSM source (or RP) in the
example above.....follow procedure again, but with a bit in the UMTP
header to say "handover" ....

Scope: might want to scope how far up and down a tree a handover can
go....

Management:-) 

ontree UMTP capable routers may want to load balance - to this end,
they need to exchange load information. easy. they can all do
multicast. so
i) we assign a new group/rp, or one of them is a source/distribution
point.
ii) we build an IP-multicast tree of on-data-tree UMTP-capable routers
from the RP or "designated root" (actually, its a strict subtree of
the data tree)
iii) we map at the UMTP points on it, the additional branches and mark
the UMTP degree (a single number, for each UMTP-capable router)

this can be used to do some balancing if we want....(how to do
balancing is subject for further study - for example, it aint obvious
at all:-)

now i know some Big Router Vendors might say that this is tricky to do
in their boxes - but theres nothign to stop someone selling a
streaming server that also peers via the IGP and then runs PIM, and
then does this stuff.....

if we don't like/support UMTP, then any other IPmc to unicast
techniquee can also apply (fill in this form here:- [...] )

comments?

 >>upstream possible tunnel brokers can act on that....

 cheers

   jon

---

From: Hugh LaMaster <[email-masked]>
Date: Wed, 28 Feb 2001 13:17:00 -0800 (PST)

> useful things too - hey, they probably are behind a nat too:-)

And, once they discover all this tunnel traffic, they'll probably
start filtering it.  I'm guessing that the success of UMTP depends 
on "anISP" being slow on the uptake  ;-)
 
> anyhow, so rathwerthan something complex for the end user, lets

The end-user still has to have a UMTP-enabled app, though, right?
I think that will add complexity for the end user, not to mention
the app developers.  Do UMTP-enabled versions of, say, vic and vat
exist today?  Do existing apps offer automatic switchover (start
with multicast, switch to UMTP if nothing happens?)  How do they
learn about available sources&groups?

> they need to exchange load information. easy. they can all do

If you want any large transit providers to support this, I think 
handover/load-balancing would be key, and would have to work with 
an auxiliary router off to the side, for the following reason:

I find it very unlikely that transit providers will want to support 
the tunnel replication on their core GSR/M40/whatever routers.
So, I don't think it is worth doing unless the load-balancing/off-loading
stuff is there from the beginning.  Probably, a provider would want 
to provide the replication in an auxiliary router adjacent to an 
edge peering router.  In real hardware terms, they might park a 7200-class
router next to the peering GSR or M40 in order to support the tunnel
replication.

They would probably also control access very carefully so as not
to carry tunnels over their backbones-- only provide for tunnels
coming out to the local ISP.

So, I'm picturing a tier-1 provider putting this adjacent to their
peering router for "anISP", without any cooperation from "anISP",
and thus, sending lots of streams out the interface to "anISP".
This usage model could work, because, the Tier-1 provider could
realize a (multicast-enabled) savings in their own backbone.  
I'm just wondering what "anISP" will do when it sees N tunnels 
coming in that interface.

I'm also wondering about DoS (sometimes inadvertant, as we know) -- 
it is probably necessary for the peering router to switch-forward 
the tunnel requests to the helper box rather than having to process
them locally in any way.  Some of the new capabilities boxes have
to forward traffic differently on the basis on IP header information,
mostly developed to support web activities, might be usable for this.

> then does this stuff.....

The problem is that all the fast core boxes are designed to separate
forwarding decisions from route and other processing, and use
some combination of distributed multi-CPU software forwarding
and/or ASIC-etc enabled hardware switching.  There is just no way
to drive a bunch of today's OC-48's and OC-192's cost-effectively
in a pure-software router.  So, it is a big deal to ask the router 
operating system to catch all the packets of a certain type and 
process them in software, and it opens up the possibility of DoS,
on-purpose, or perhaps accidentally.  If the core router could
dumbly forward all request packets to a nearby helper, I would 
think that would help a lot.

> techniquee can also apply (fill in this form here:- [...] )

UMTP seems like a lot of work to develop/debug/deploy.  I think
the same level of effort applied to deploying native multicast
might bring more multicast users online.  Has anybody attempted
to survey the Tier-2/3 providers about what they think about
UMTP multicast vs. native multicast?

--
 Hugh LaMaster, M/S 233-21,    Email: [email-masked]
 NASA Ames Research Center     Or:    [email-masked]
 Moffett Field, CA 94035-1000  Or:    [email-masked]
 Phone: 650/604-1056           Disc:  Unofficial, personal *opinion*.

---

From: Ross Finlayson <[email-masked]>
Date: Wed, 28 Feb 2001 15:33:11 -0800

>The end-user still has to have a UMTP-enabled app, though, right?

One possible approach is for each multicast application to support UMTP (or 
whatever UDP-based tunneling protocol ends up being defined for automatic 
tunneling).  Another possible approach is for the helper app, shell or 
plugin that *launches* the application to support this tunneling 
protocol.  For example, if you launch your application from a SDP session 
browser, then this browser can perform the tunneling itself.  The browser 
receives incoming tunneled traffic, and re-multicasts it locally (i.e., 
with TTL 0) where it can be received by existing multicast applications 
(without modifying them).

For example, the "multikit" multicast session browser (available for free 
from <http://www.live.com/multikit/>) already has a tunneling option, and 
several people have used this to tunnel multicast sessions over 
non-multicast-capable routers. (In this case, the tunneling isn't 
automatic; instead, the user has to explicitly specify a UMTP 'slave' 
(e.g., a liveGate server) that's located on a separate, multicast-enabled 
network.)

>Do UMTP-enabled versions of, say, vic and vat exist today?

No, although - as noted above - they can (& do) work without change by 
having the launcher tool do the tunneling.

>Do existing apps offer automatic switchover (start
>with multicast, switch to UMTP if nothing happens?)

No, although "multikit" sort of does the reverse: It lets the user start up 
a (non-automatic) tunnel explicitly, but turns it off if it detects that 
it's not necessary.

In practice, I don't think that deploying application support for multicast 
tunneling is going to be a significant hurdle.  The most widely deployed 
media players (e.g., RealPlayer and Windows Media Player) already have 
mechanisms for automatically downloading new plugins on demand.  (Ditto for 
web browser plugins.)  Just as long as we don't require *OS* 
upgrades...  In contrast, the biggest hurdle is going to be to persuade the 
router vendors to bundle tunneling slave support with their PIM-SSM 
implementations.

>So, it is a big deal to ask the router

Agreed.  Router vendor buy-in is (obviously) essential here, and the 
tunneling protocol should be designed with ease of router support in 
mind.  (For example, we've already heard some feedback that it's easier for 
routers to send tunneled multicast packets to the end nodes using 
encapsulation (IP/UDP) rather than header rewriting+adding a trailer (which 
is what UMTP's "DATA" command does now).

One possibly useful way to proceed now would be to break the problem up 
into three parts:
1/ The UDP-based *signalling* protocol that end nodes (tunnel 'masters') 
would use to join (with periodic keep-alives) and leave multicast 
groups.  This could be something similar to UMTP's "JOIN_GROUP" and 
"LEAVE_GROUP" commands.
2/ The UDP-based *data delivery* protocol that tunnel 'slaves' (ideally, 
compliant routers) would use to deliver multicast data to the end 
nodes.  (This might just be a simple encapsulation protocol.)
3/ One or more possible 'router behaviors' that would implement automatic 
tunneling.  The current draft talks about one such 'behavior': "Upstream 
router interception".  This seems like the simplest behavior to support, 
but one could imagine extending it to support things like more complicated 
hand-off, etc...

The key point here is that we can define the end-user signalling and 
delivery protocols (1/ and 2/) for automatic tunneling, while leaving room 
for some flexibility as to how routers actually implement this (i.e., 3/).

>might bring more multicast users online.

Perhaps, but its effort that would be applied in different places.  There's 
nothing to prevent us from attacking both fronts; in fact, there are good 
reasons why we should do this.  There are lots and lots of legacy first-hop 
routers out in the Internet that don't support native multicast.  They are 
never going to get upgraded to support multicast unless we provide some 
incentive.  The availability of UDP-tunneled multicast (which allows all of 
these users to experience multicast sessions ASAP) can provide such an 
incentive, by creating demand for the deployment of native support (to 
improve performance).  "Build it, and they will come" :-)

         Ross.