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

From: zaid <[email-masked]>
Date: Thu, 22 Feb 2001 22:39:25 -0500

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

I hope you are right. We (This community) also have to consider the
high
probability that as a result of this draft no (ISP) will deploy
multicast natively .
Another sad and high probability is that ISPs start blocking that kind
of traffic and start charging for it under the flag of multicast
services.

Thanks,
Zaid

-----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.

---

From: [email-masked] (Jeremy Hall)
Date: Fri, 23 Feb 2001 08:00:20 -0500 (EST)

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

_J

---

From: Pieter Liefooghe <[email-masked]>
Date: Fri, 23 Feb 2001 17:22:14 +0100

> 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 <[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.
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]

Abstract

         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: Ross Finlayson <[email-masked]>
Date: Fri, 23 Feb 2001 10:58:53 -0800

>3: unicast and multicast topologies are congruent

The proposal ("UDP tunneling with router interception") does *not* require 
that the unicast and multicast topologies are identical - only that they 
overlap in places.  (The tunneling for each recipient takes place from the 
first upstream router at which they overlap.)

I agree that this doesn't help much for very asymmetrical networks (such as 
satellite downlinks), but fortunately these networks are likely to be 
multicast-enabled anyway.

         Ross.

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 23 Feb 2001 12:14:47 -0800

>>          Ross.

    Ross, some quick comments:

    o Indicate the packet format encoding for join and prune messages. If they
      are simply IGMPv3 over UDP, indciate that.
    o Be very clear that the Router-Alert option is used for control packets
      from master to slave. This is what Jeremy freaked on. 
    o Indicate that data packets from the slave to the master do not need to
      be UDP checksummed. Or else, this won't get deployed. Routers doing 
      complete packet checksums in the data path is a non-starter.
    o Be more clear about "data packets from the master are processed like 
      any other multicast packet in the router". This is certaily not true.
      Multicast routers do RPF checks based on incoming interface. Packets
      coming over the UDP tunnel need different handling. And make sure the
      host/master doesn't UDP checksum the packet either.
    o Indicate how TTL and TOS header bits are handled. That is, is the UDP
      tunnel 1-hop or more. And if more than 1, you need a mechanism find out.
    o What is the source IP address of the UDP encapsulated packet forwarded
      by the encapsulating router.
    o And as always with tunnels. How do you propose to deal with MTU issues
      since an additional 28 bytes are added to the data packet.
    o Also, justify why you're not using GRE. 24 bytes of overhead is better
      than 28 plus there are 1000s of deployed routers that support GRE
      tunneling. Some doing it in hardware.

Dino

---

From: Leonard Giuliano <[email-masked]>
Date: Fri, 23 Feb 2001 12:49:10 -0800 (PST)

*>         
*>" (I'm hoping that this will help break the logjam that has held back
*>the widespread adoption of multicast...) "
*>         
*>I hope you are right. We (This community) also have to consider the
*>high probability that as a result of this draft no (ISP) will deploy
*>multicast natively . Another sad and high probability is that ISPs
*>start blocking that kind of traffic and start charging for it under
*>the flag of multicast services.
*>         

That may be an initial reaction, but I think a good argument could be made
that this sort of tunneling would finally provide an ISP a good incentive
to deploy multicast natively.  If such a thing existed, multicast enabled
ISPs could finally attract content providers by saying that they could
multicast on their network and expect it to actually reach people.  It
would benefit the multicast enabled networks by eliminating duplicated
unicast traffic across their backbone at a cost of tunnels at the edge
(would be interesting to see what this cost will be).  Non-enabled
networks would see that traffic is being tunneled and duplicated over
their network, and have a strong incentive to deploy natively.  Content
providers would be able to multicast content and expect someone to
actually get it, and thereby create more content.

A cool idea as long as the cost of these tunnels is reasonable.

---

From: Ross Finlayson <[email-masked]>
Date: Fri, 23 Feb 2001 14:10:14 -0800

Dino, thanks for the comments.

>    o Indicate the packet format encoding for join and prune messages.

The packet format for these packets is UMTP, which is defined in a separate 
Internet Draft <draft-finlayson-umtp-05.txt>.  The tunneling draft makes 
this clear, I hope!  (In reality, the actual tunneling protocol that ends 
up getting used might end up being a 'UMTP-light', as the current UMTP was 
designed for arbitrary multicast (SSM or ISM) tunneling between arbitrary 
end nodes - and so is (arguably) a little heavier-weight than needed here.)

>       from master to slave.

No go.  The scheme *has* to be usable by existing users, without operating 
system changes (e.g., the millions of people running Windoze 9x) - 
otherwise it's of little value, IMHO.  The control packets sent by end-user 
machines need to be regular UDP packets.  Routers will need to trap these 
control packets based upon their destination UDP port; they can't rely on 
the "Router-Alert" option.

>       be UDP checksummed.

OK, fair enough.

>       any other multicast packet in the router". This is certaily not true.

Yes, that's not true - and in fact I don't say this anywhere.  I think you 
may have misread the last paragraph of section 4.

>       tunnel 1-hop or more.

Potentially many-hop.  Remember, the end-user (master) application just 
sends out regular UDP packets, addressed to the SSM 
source.  Non-multicast-capable routers forward these as many times as 
necessary, until a multicast/tunneling-capable router is reached.

>       by the encapsulating router.

The draft currently doesn't say anything about this.  UMTP, as currently 
defined, uses source IP addresses for authentication, in which case the 
router would need to set the source IP address of the tunneled DATA packet 
to the SSM source.  But if it would be better for the router to use its own 
IP address instead, then that's something that could be changed...

>       since an additional 28 bytes are added to the data packet.

For now at least, I don't propose doing anything about this.  If 
fragmentation happens, then tough :-)

>       tunneling. Some doing it in hardware.

Right, but can GRE work on top of UDP (and if so, can it be implemented in 
applications, without OS changes)?  And does it contain control packets 
(JOIN_GROUP, LEAVE_GROUP, etc.)?  That's why a dedicated UDP-based 
multicast tunneling protocol (UMTP) is used.

         Ross.