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

[jhall@UU.NET (Jeremy Hall)]

now THIS sounds interesting.

marmaduke:~$ whois 208.197.171.112/28@radb.ra.net
[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:       juzer@uu.net 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

In the new year, Pieter Liefooghe wrote:
> (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.
>