From owner-ssm-interest@cisco.com  Mon Jul 24 17:57:01 2000
Received: from cliff.cisco.com (cliff.cisco.com [171.69.11.90])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA19280
	for <ssm-archive@odin.ietf.org>; Mon, 24 Jul 2000 17:57:00 -0400 (EDT)
Received: (daemon@localhost) by cliff.cisco.com (8.6.12/8.6.5) id OAA25768; Mon, 24 Jul 2000 14:56:26 -0700
Date: Mon, 24 Jul 2000 14:56:26 -0700
Message-Id: <200007242156.OAA25768@cliff.cisco.com>
To: ssm-archive@ietf.org
From: mailer@cisco.com
Subject: Welcome to ssm-interest
Precedence: bulk
Reply-To: mailer@cisco.com

--

Welcome to the ssm-interest mailing list!

If you ever want to remove yourself from this mailing list,
you can send mail to "mailer@cisco.com" with the following command
in the body of your email message:

    unsubscribe ssm-interest ssm-archive@lists.ietf.org

or you can use the web version of mailer at http://www-mailer.cisco.com

Here's the general information for the list you've
subscribed to, in case you don't already have it:

[Last updated on: Tue Apr 18  8:40:06 PDT 2000]
IETF discussion about the design, implementation, 
and standardization of source-specific multicast 
for IP.





From Michael@radlan.com  Wed Jul 26 01:25:52 2000
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28150
	for <ssm-archive@odin.ietf.org>; Wed, 26 Jul 2000 01:25:51 -0400 (EDT)
Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id UAA01308
	for <ssm-interest@external.cisco.com>; Tue, 25 Jul 2000 20:55:11 -0700 (PDT)
Received: from proxy3.cisco.com (localhost [127.0.0.1])
	by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with SMTP id e6Q3ssa09958
	for <ssm-interest@external.cisco.com>; Tue, 25 Jul 2000 20:54:55 -0700 (PDT)
Received: from arcturus.barak.net.il (arcturus.barak.net.il [212.150.150.40]) by proxy3.cisco.com with SMTP (MailShield v1.5); Tue, 25 Jul 2000 20:55:05 -0700
Received: from messenger.rnd.co.il ([209.88.194.205])
	by arcturus.barak.net.il (8.9.3/8.9.1) with ESMTP id FAA12638
	for <ssm-interest@external.cisco.com>; Wed, 26 Jul 2000 05:49:37 +0200 (IST)
Received: by MESSENGER with Internet Mail Service (5.5.2650.21)
	id <PT90JGSF>; Wed, 26 Jul 2000 06:49:40 +0200
Message-ID: <BA7FAB77CE0ED31196260050040C08260342C6@MESSENGER>
From: Michael Indenbaum <Michael@radlan.com>
To: "'ssm-interest@external.cisco.com'" <ssm-interest@external.cisco.com>
Date: Wed, 26 Jul 2000 06:49:27 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
X-SPAM: Yes
X-SPAM-REASON: Blank Subject Line
X-SPAM-INFO: http://wwwin.cisco.com/CustAdv/InfoSys/spam
X-SMTP-HELO: arcturus.barak.net.il
X-SMTP-MAIL-FROM: Michael@radlan.com
X-SMAP-Received-From: outside
X-SMTP-PEER-INFO: arcturus.barak.net.il [212.150.150.40]

subscribe ssm-interest




From Doron@bandwiz.com  Fri Jul 28 10:20:15 2000
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28647
	for <ssm-archive@odin.ietf.org>; Fri, 28 Jul 2000 10:20:14 -0400 (EDT)
Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id GAA08007
	for <ssm-interest@external.cisco.com>; Fri, 28 Jul 2000 06:10:57 -0700 (PDT)
Received: from proxy1.cisco.com (localhost [127.0.0.1])
	by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with SMTP id e6SDAji04072
	for <ssm-interest@external.cisco.com>; Fri, 28 Jul 2000 06:10:45 -0700 (PDT)
Received: from davis.bandwiz.com ( [212.150.220.34]) by proxy1.cisco.com with SMTP (MailShield v1.5); Fri, 28 Jul 2000 06:09:42 -0700
Received: by DAVIS with Internet Mail Service (5.5.2650.21)
	id <PWCJ0YQK>; Fri, 28 Jul 2000 16:10:26 +0200
Message-ID: <E9DC428883F3D31180F900E081107FF20891E7@DAVIS>
From: Doron Rajwan <Doron@bandwiz.com>
To: ssm-interest@external.cisco.com
Subject: Automatic Tunneling for Rapid Multicast Deployment
Date: Fri, 28 Jul 2000 16:10:26 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="ISO-8859-1"
X-SMTP-HELO: davis.bandwiz.com
X-SMTP-MAIL-FROM: Doron@bandwiz.com
X-SMAP-Received-From: outside
X-SMTP-PEER-INFO:  [212.150.220.34]


As a background for the presentation in the SSM workgroup
meeting next Tuesday, we provide below a document describing 
the automatic tunneling suggestions.

Any comment will be appreciated.

Doron Rajwan.




====================================================
 Automatic Tunneling for Rapid Multicast Deployment
====================================================



Introduction:
=============
The intent of this document is to promote rapid multicast deployment. 
A recent consensus in the multicast community is that source specific 
multicast [SSM] will be easier to deploy and so it can accelerate 
multicast acceptance. 

In order to have rapid SSM deployment throughout the network, we 
suggest a protocol that will enable multicast even if the routers near 
the receivers do not support multicast protocols. Further more, this 
protocol will work from any host, running any operating system, using 
UDP only. It will discover the nearest SSM-enabled router in the path 
to a specific source, and create a tunnel between the joining host and 
that router. This tunnel will be used in order to transfer multicast 
data for (S,G), from the router to the joining host.


Hardware support in routers:
============================
Each SSM-enabled router will have the hardware capability to create a 
tunnel to arbitrary number of hosts. When a multicast UDP packet is 
received, it will be duplicated and sent to each entry in the olist of 
(S,G), which may contain both neighboring SSM-enabled routers and 
tunnels. In the later case, the destination class-D address of the UDP 
packet will be replaced with the tunnel exit address (A), and the 
destination port will be replaced with the tunnel exit port (P). There 
is no need to encapsulate the packet inside another UDP packet.

The host can de-multiplex the group (G) from the port (P) by 
remembering each of the tunnels it created, and assigning different 
port number (P) for each tunnel coming from a specific source.

The original destination port number is gone forever, and cannot be 
used by the transmitter in order to implement de-multiplexing of any 
kind at the receivers. This limitation seems to be reasonable, and we 
do not think that packets should be encapsulated just because of it.


Software support in routers:
============================
In order to create tunnels, SSM-enabled routers will be able to 
receive UDP packets, containing join and leave commands, sent directly 
to them (using their IP address and a specific port number). These 
packets will contain the source (S), the group (G), the tunnel exit 
address (A) and port (P). Upon receiving it, the router will 
acknowledge the reception, by sending UDP packet to the joining host 
(A), and add this host to the olist for (S,G).

Currently, we do not specify the suggested packet format. It can be 
[IGMPv3] in UDP, with additional port number. Also, the tunnel should 
be refreshed from time to time. 

** Assuming there is interest in this protocol, we will write an 
Internet draft specifying the exact details of this tunneling process, 
and the exact requirements from routers.


Detecting the optimal router:
=============================
How can the joining host decide which is the optimal router to create 
a tunnel to? There can be many possible methods, e.g., use manual 
configuration, use hashing from a pre-defined set of routers, and so 
on. These methods while not optimal, will work at least as good as the 
methods for setting the Rendezvous Points (RP) in PIM-SM.

Another method is to use directory services, that will be asked to map 
(client IP, source IP) to (router IP). The result will be a list of 
entries containing these fields:
1. Client IP, mask: The group of clients which this entry is applied 
to. The mask is needed because clients can have temporary IP addresses 
from the same subnet.
2. Source IP, mask: The source of the multicast packet. This will 
usually be entire AS.
3. Router IP, mask: A group of routers that the host can round-robin.
4. Expiration: Time of expiration of this entry.

** Assuming there is an interest in this protocol, we will write an 
Internet draft specifying the exact details of this DNS process. We 
can also implement this DNS service world-wide.


Detecting the optimal router using trace-route:
===============================================
We now suggest an automatic router discovery method, using 
trace-route. The joining host will use standard trace-route algorithm 
in order to locate the first router towards the source. Then, it will 
send a UDP join massage to this router, as defined above. If the 
router does not acknowledge, the host will check the next router, and 
so on, until it finds a router that is SSM-enabled. This router will 
be used for tunneling.

The application needs the ability to send UDP packets with small TTL, 
and the ability to receive ICMP error messages. If the current socket 
implementation on the host computer cannot support it, the application 
can spawn the trace-route program itself, and process it's output. 
This can be done by any host!

Optimally, this protocol should be executed for every multicast 
source. For some applications there is only a single multicast source 
with a lot of groups, so, this problem doesn't exist. Also, in some 
cases, access ISPs are connected to the backbone using a single point. 
Assuming the backbone is SSM-enabled, the output of this process is 
independent of the source address.

The routers can help in this process. When locating an optimal router 
for a given source, that router can include (in the tunnel 
acknowledgment message) a list of subnets that it supports. Then, if 
the host needs to locate a router for each of the subnets, it can use 
the same router. There is no need to execute this protocol again. In 
this case the routes might not be optimal, but they are still much 
better than the routes created using RP in PIM-SM.

This protocol is only needed in cases that there is no other option. 
If there is a multicast enabled router on the host's LAN, it can be 
detected using limited broadcast of UDP packet to the LAN. This is 
needed if the operating system is old. If both the routers and the 
operating system is up-to-date, standard [IGMPv3] can be used.


Changes to the applications:
============================
Each application should be linked with a library for multicast join 
and leave. This library will check whether the operating system 
supports [IGMPv3]. If it is supported, it will be used.

If [IGMPv3] is not supported, the library will do limited broadcast of 
UDP packet in order to see if there is a SSM-enabled router on the 
LAN. If such a router exists, it will use it to join the multicast 
group.

In all other cases, the optimal router will be detected, and a tunnel 
will be crated to that router.

** Assuming there is interest in this protocol, we will implement this 
library, as an open-source code. It will utilize the OS [IGMPv3], LAN 
limited broadcast, or create a tunnel. It will locate the router for 
the tunnel by using directory services or by the trace-route 
algorithm.


Benefits:
=========
From the application point of view, the automatic tunneling feature 
opens multicast immediately, even in the extreme case, where only the 
joining hosts and the source support it, and it is effectively 
unicast. All the application need to do is to call join / leave 
functions, and receive packets. Later, when the routers are updated, 
things will become more efficient, of course.

Automatic tunneling can initiate a process and provide an incentive 
for wide spread multicast deployment at the routers. By enabling an 
immediate multicast to applications, routers that are not multicast 
enabled will suffer a larger load, while the multicast enabled routers 
will require less computational power since they receive a fewer 
number of packets from the next-hop router. This creates a 
positive-feedback that will cause most routers, especially in the 
critical areas, to be SSM-enabled.


Removing IGMP:
==============
(This section is less critical than the sections above)

In the Internet standard multicast [ISM] model, where multicast group 
was identified using a class-D address, there was a reason of using 
one protocol between routers, and other protocol between hosts and 
routers. First, the routers needed to maintain information about the 
structure of the autonomous system (AS), and the structure of the 
multicast group delivery graph, that the host didn't care about. 
Second historical reason for IGMP was the dense-mode design, when 
there is a flat, non-switched LAN, and a big number of users who want 
to listen to the same multicast group.

We think that this is not the case today. In general, using IGMP has a 
lot of drawbacks:

1. IGMPv1 designed to be a super-set of all the information that a 
host needs to send to the designated router (DR). When the multicast 
protocols required low leave latency, IGMPv2 was created. When the 
protocols required source-specific, IGMPv3 was created. Any of these 
changes caused a redundant change in the operating system. This may 
continue forever. The basic flaw is that there is no general 
super-set, and the required information to be transferred between the 
host and the router is protocol specific.

2. There is no need for two different set of protocols. There is no 
real difference between the last hop and all other hops. One protocol 
can, and should, do it all. This way, IP multicast can be defined by a 
single specification!

3. There is a need to update the application, the operating system, 
and the first router before an application can use multicast. Using 
UDP, like we suggest above, will imply modification only to the 
application.

4. IGMP, especially [IGMPv3], is far too complicated, with too many 
messages and fields that [SSM] protocols do not need. 


Acknowledgement:
================
This document benefited a lot from discussions and specific comments 
of Radia Perlman and Jon Crowcroft. Useful discussion with Suchitra 
Raman are also acknowledged.


References:
===========
[ISM] S. Deering, "Host Extensions for IP Multicasting".
http://www.ietf.org/rfc/rfc1112.txt

[IGMPv3] B. Cain, S. Deering, I. Kouvelas, A. Thyagarajan, "Internet 
Group Management Protocol, Version 3", Work in Progress.
http://www.ietf.org/internet-drafts/draft-ietf-idmr-igmp-v3-04.txt 

[PIM-SM] B. Fenner, M. Handley, H. Holbrook, I. Kouvelas, "Protocol 
Independent Multicast - Sparse Mode (PIM-SM)", Work in Progress.
http://www.ietf.org/internet-drafts/draft-ietf-pim-sm-v2-new-00.txt

[SSM] H. Holbrook, B. Cain, "Source-Specific Multicast for IP", Work 
in Progress.
http://www.ietf.org/internet-drafts/draft-holbrook-ssm-00.txt 

[PIM-SO] N. Bhaskar, I. Kouvelas, "Source-Specific Protocol 
Independent Multicast", Work in Progress.
http://www.ietf.org/internet-drafts/draft-bhaskar-pim-ss-00.txt 

[PIM-SS] S. Bhattacharyya, C. Diot, L. Giuliano, R. Rockell, 
"Deployment of PIM-SO at Sprint", Work in Progress.
http://www.ietf.org/internet-drafts/draft-bhattach-diot-pimso-00.txt 


Author's Address:
=================
Doron Rajwan
BandWiz Inc.
doron@bandwiz.com

Meir Feder
BandWiz Inc.
meir@bandwiz.com




From deering@cisco.com  Fri Jul 28 13:44:06 2000
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22807
	for <ssm-archive@odin.ietf.org>; Fri, 28 Jul 2000 13:44:05 -0400 (EDT)
Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.18.32])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id JAA29047
	for <ssm-interest@external.cisco.com>; Fri, 28 Jul 2000 09:38:28 -0700 (PDT)
Received: from [10.19.130.188] (deering-dsl3.cisco.com [10.19.130.188])
	by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with ESMTP id JAA17421;
	Fri, 28 Jul 2000 09:37:19 -0700 (PDT)
Mime-Version: 1.0
X-Sender: deering@ups
Message-Id: <v04220801b5a7517e824c@[10.19.130.188]>
In-Reply-To: <E9DC428883F3D31180F900E081107FF20891E7@DAVIS>
References: <E9DC428883F3D31180F900E081107FF20891E7@DAVIS>
Date: Fri, 28 Jul 2000 09:39:36 -0700
To: Doron Rajwan <Doron@bandwiz.com>
From: Steve Deering <deering@cisco.com>
Subject: Re: Automatic Tunneling for Rapid Multicast Deployment
Cc: ssm-interest@external.cisco.com
Content-Type: text/plain; charset="us-ascii"

At 4:10 PM +0200 7/28/00, Doron Rajwan wrote:
>Removing IGMP:
>==============
>(This section is less critical than the sections above)
>
>In the Internet standard multicast [ISM] model, where multicast group 
>was identified using a class-D address, there was a reason of using 
>one protocol between routers, and other protocol between hosts and 
>routers. First, the routers needed to maintain information about the 
>structure of the autonomous system (AS), and the structure of the 
>multicast group delivery graph, that the host didn't care about. 
>Second historical reason for IGMP was the dense-mode design, when 
>there is a flat, non-switched LAN, and a big number of users who want 
>to listen to the same multicast group.

Your second claimed "historical reason" is false and confused:

	(a) "Dense-mode" has nothing to do with the density of
	    receivers or presence of switches on a LAN.  Dense-
	    mode refers to the nature of the router-to-router
	    protocol, which would be just as applicable to a
	    network with no LANs or other multi-access networks
	    at all, i.e., just point-to-point links.

	(b) When IGMP was initially designed, there were two known
	    IP multicast protocols, which came to be named DVMRP and
	    MOSPF, one of which is a "dense-mode" protocol and one
	    of which is "sparse-mode".  The nature of the multicast
	    routing protocol (intentionally) had no effect on the
	    design of IGMP.

	    (I put "dense" and "sparse" in quotation marks because those
	    terms were invented much later and they are inaccurate terms
	    that lead to the kind of false conclusion that you seem to
	    have drawn.  There was *no* assumption in the design of
	    DVMRP that multicast membership would be "dense", either
	    within a single LAN or throughout the region of the network
	    that was running DVMRP.)

The *real* historical reason why IGMP is a separate protocol from the
router-to-router protocol was to allow the use of multiple, different
multicast routing protocols in different parts of the Internet, and to
allow a region to change from one multicast routing protocol to another,
without requiring any changes to the hosts or knowledge in the hosts of
which particular multicast routing protocol they happened to be
connected to on any given day.  That this was important was evident
from the experience with unicast routing protocols, where we had RIP,
OSPF, IGRP, and others all being used in different parts of the Internet;
requiring host changes whenever a unicast routing protocol was changed
or introduced would have been a major deployment hurdle, and would have
inhibited improvements in unicast routing.  And indeed IGMP accomplished
its goal: hosts that implement only IGMP can successfully be used to
receive multicast packets via DVMRP, MOSPF, PIM-DM, PIM-SM, and CBT.

>1. IGMPv1 designed to be a super-set of all the information that a 
>host needs to send to the designated router (DR).

That's exactly opposite to the truth.  The "classic" multicast routing
protocols were designed to work with the information the IGMP provided,
not the other way around.  The changes to IGMP have been driven by the
desire to correct inherent shortcomings (specifically, high leave latency)
or to enhance the multicast service model (i.e., adding support for source
filters), both of which reasons are completely independent of the "needs"
of any particular multicast routing protocol, in keeping with IGMP's
purpose.

And by the way, not all multicast routing protocols have "designated
routers" and IGMP, being routing-protocol agnostic, does not assume that
they do.

> When the multicast protocols required low leave latency, IGMPv2 was
>created. When the  protocols required source-specific, IGMPv3 was created.
>Any of these changes caused a redundant change in the operating system.
>This may  continue forever.

Any successful protocol evolves over time to correct shortcomings and
meet new needs.  After all, we are not running IPv1.  The important
observation is that IGMP has required fewer and less frequent changes
than all the various multicast routing protocols that it has
interoperated with, which is exactly as it was designed to do (given
that updating IGMP in all hosts takes far more time and effort that
updating the multicast routing protocol in the routers in one domain).

> The basic flaw is that there is no general super-set, and the required
>information to be transferred between the  host and the router is
>protocol specific.

The basic flaw in your analysis is that you misunderstand the nature and
purpose of IGMP and its evolution.  It has not evolved to provide a
"super-set" of the requirements of specific multicast routing protocols.
There has often been pressure to throw in routing-protocol-specific
features (e.g., including a "core" or "rendezvous point" address for
CBT or PIM-DM), but so far we have managed to prevent such changes,
which would be exactly contrary to IGMP's goals of keeping hosts isolated
from knowledge of the multicast routing protocol du jour.

>2. There is no need for two different set of protocols. There is no 
>real difference between the last hop and all other hops. One protocol 
>can, and should, do it all. This way, IP multicast can be defined by a 
>single specification!

Sure, until next year, when someone comes up with the New New Multicast
protocol.

>4. IGMP, especially [IGMPv3], is far too complicated, with too many 
>messages and fields that [SSM] protocols do not need. 

I agree that IGMPv3 is more complicated than I would wish.  But the
mismatch between what IGMPv3 provides and what SSM requires is due
to the fact that SSM provides only a limited subset of the *service model*
(*not* the multicast routing protocols) that IGMPv3 is designed for.
Sure, if you offer a less functional service, you can do it with a simpler
protocol (just as IGMPv2 is much less complex than IGMPv3).  The choice of
what service(s) to provide at what layer is, of course, the topic of the
most long-running debates in the field of data networking.  I would
appreciate it if you would acknowledge that these issues are indeed
debatable, and the fact that IGMP is not what you want does not
necessarily represent a "basic flaw" in IGMP.  And if you won't do that,
at least resist the urge to fabricate bogus "historical reasons" for
things you don't understand.

Steve



From Doron@bandwiz.com  Fri Jul 28 19:00:19 2000
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13993
	for <ssm-archive@odin.ietf.org>; Fri, 28 Jul 2000 19:00:19 -0400 (EDT)
Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id OAA06023
	for <ssm-interest@external.cisco.com>; Fri, 28 Jul 2000 14:47:34 -0700 (PDT)
Received: from proxy1.cisco.com (localhost [127.0.0.1])
	by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with SMTP id e6SLlKR00289
	for <ssm-interest@external.cisco.com>; Fri, 28 Jul 2000 14:47:20 -0700 (PDT)
Received: from davis.bandwiz.com ( [212.150.220.34]) by proxy1.cisco.com with SMTP (MailShield v1.5); Fri, 28 Jul 2000 14:46:17 -0700
Received: by DAVIS with Internet Mail Service (5.5.2650.21)
	id <PWCJ0YRH>; Sat, 29 Jul 2000 00:46:13 +0200
Message-ID: <E9DC428883F3D31180F900E081107FF20891EE@DAVIS>
From: Doron Rajwan <Doron@bandwiz.com>
To: ssm-interest@external.cisco.com
Subject: Multicast On-Demand
Date: Sat, 29 Jul 2000 00:46:09 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="ISO-8859-1"
X-SMTP-HELO: davis.bandwiz.com
X-SMTP-MAIL-FROM: Doron@bandwiz.com
X-SMAP-Received-From: outside
X-SMTP-PEER-INFO:  [212.150.220.34]


The second issue that we want to raise is multicast on-demand.

Any comment will be appreciated.

Doron Rajwan.




=====================
 Multicast On-Demand
=====================



Multicast On-Demand:
====================
In the following there is a suggestion for "multicast on-demand", 
which will allow a server to announce a multicast group that receivers 
can join, yet not to send any data until a user actually joining the 
group.

Currently, if a server plans to send multicast data, but there are no 
users that want to receive the content, the data still comes out of 
the server and is blocked at the nearest router. Thus, supporting a 
large number of streams causes a computational load and usage of 
networking resources even when the number of request streams is small. 

We propose, then, that the server will not send anything until it 
receives the first join message to that stream. This requires the 
first join message sends towards the server, should reach the server 
itself, and not just the nearest router. This gives the server the 
ability to advertise itself as if it sends information for a lot of 
multicast groups, when actually it sends it on-demand.

This limitation exists because the root of the delivery tree is the 
designated router (DR) near the source, not the source itself. In the 
[SSM] model there is no need for the first hop to be different from 
any other hop in the delivery tree. We suggest that the root of the 
delivery tree will be the source itself.

Another method to support multicast on-demand is to add a query 
protocol, allowing the source to ask the DR about the registration 
status. It can be the query mechanism in IGMP, exchanging role between 
the host and the DR. The server can query information about all the 
groups using limited broadcast on the LAN, and get response from the 
routers.


Acknowledgement:
================
This document benefited a lot from discussions and specific comments 
of Radia Perlman and Jon Crowcroft.


References:
===========
[SSM] H. Holbrook, B. Cain, "Source-Specific Multicast for IP", Work 
in Progress.
http://www.ietf.org/internet-drafts/draft-holbrook-ssm-00.txt 

[IGMPv3] B. Cain, S. Deering, I. Kouvelas, A. Thyagarajan, "Internet 
Group Management Protocol, Version 3", Work in Progress.
http://www.ietf.org/internet-drafts/draft-ietf-idmr-igmp-v3-04.txt 


Author's Address:
=================
Doron Rajwan
BandWiz Inc.
doron@bandwiz.com

Meir Feder
BandWiz Inc.
meir@bandwiz.com





From J.Crowcroft@cs.ucl.ac.uk  Sat Jul 29 05:13:20 2000
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14506
	for <ssm-archive@odin.ietf.org>; Sat, 29 Jul 2000 05:13:20 -0400 (EDT)
Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.71.163.110])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id AAA01279
	for <ssm-interest@external.cisco.com>; Sat, 29 Jul 2000 00:34:35 -0700 (PDT)
Received: from proxy2.cisco.com (localhost [127.0.0.1])
	by sj-msg-av-2.cisco.com (8.10.1/8.10.1) with SMTP id e6T7YI629663
	for <ssm-interest@external.cisco.com>; Sat, 29 Jul 2000 00:34:18 -0700 (PDT)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by proxy2.cisco.com with SMTP (MailShield v1.5); Sat, 29 Jul 2000 00:34:26 -0700
Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.02894-0@bells.cs.ucl.ac.uk>; Sat, 29 Jul 2000 08:34:11 +0100
To: Steve Deering <deering@cisco.com>
cc: Doron Rajwan <Doron@bandwiz.com>, ssm-interest@external.cisco.com
Subject: Re: Automatic Tunneling for Rapid Multicast Deployment
In-reply-to: Your message of "Fri, 28 Jul 2000 09:39:36 PDT." <v04220801b5a7517e824c@[10.19.130.188]>
Date: Sat, 29 Jul 2000 08:34:09 +0100
Message-ID: <1179.964856049@cs.ucl.ac.uk>
From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
X-SMTP-HELO: bells.cs.ucl.ac.uk
X-SMTP-MAIL-FROM: J.Crowcroft@cs.ucl.ac.uk
X-SMAP-Received-From: outside
X-SMTP-PEER-INFO: bells.cs.ucl.ac.uk [128.16.5.31]


 >>The *real* historical reason why IGMP is a separate protocol from the
 >>router-to-router protocol was to allow the use of multiple, different

um, i thought at the time that the breakthrough was in designing 
the first working example of a new communications paradigm:
receiver driven end to end protocols

the separation of inter-domain and intra-domain routing for multicast
is not a function of IGMP at all, and is not made easier or harder by
it....the problems of interdomain in terms of distributing receiver
membership and the existinence of senders in domains has dogged us for
some time and was at least to some extent  exacerbated by the
existence of dense mode protocols, but not anything to do with the
host group model or its management as far as i can se...

sender 
 >>multicast routing protocols in different parts of the Internet, and to
 >>allow a region to change from one multicast routing protocol to another,
 >>without requiring any changes to the hosts or knowledge in the hosts of
 >>which particular multicast routing protocol they happened to be
 >>connected to on any given day.  That this was important was evident
 >>from the experience with unicast routing protocols, where we had RIP,
 >>OSPF, IGRP, and others all being used in different parts of the Internet;
 >>requiring host changes whenever a unicast routing protocol was changed
 >>or introduced would have been a major deployment hurdle, and would have
 >>inhibited improvements in unicast routing.  And indeed IGMP accomplished
 >>its goal: hosts that implement only IGMP can successfully be used to
 >>receive multicast packets via DVMRP, MOSPF, PIM-DM, PIM-SM, and CBT.
 >>
 >>>1. IGMPv1 designed to be a super-set of all the information that a 
 >>>host needs to send to the designated router (DR).
 >>
 >>That's exactly opposite to the truth.  The "classic" multicast routing
 >>protocols were designed to work with the information the IGMP provided,
 >>not the other way around.  The changes to IGMP have been driven by the
 >>desire to correct inherent shortcomings (specifically, high leave latency)
 >>or to enhance the multicast service model (i.e., adding support for source
 >>filters), both of which reasons are completely independent of the "needs"
 >>of any particular multicast routing protocol, in keeping with IGMP's
 >>purpose.

i guess the only case where this isn't 100% is the debate about adding
msaks, which in abny case just supports your argument, since the
debate largely went against addign them:-)
 >>
 >>And by the way, not all multicast routing protocols have "designated
 >>routers" and IGMP, being routing-protocol agnostic, does not assume that
 >>they do.
 >>
 >>> When the multicast protocols required low leave latency, IGMPv2 was
 >>>created. When the  protocols required source-specific, IGMPv3 was created.
 >>>Any of these changes caused a redundant change in the operating system.
 >>>This may  continue forever.
 >>
 >>Any successful protocol evolves over time to correct shortcomings and
 >>meet new needs.  After all, we are not running IPv1.  The important
 >>observation is that IGMP has required fewer and less frequent changes
 >>than all the various multicast routing protocols that it has
 >>interoperated with, which is exactly as it was designed to do (given
 >>that updating IGMP in all hosts takes far more time and effort that
 >>updating the multicast routing protocol in the routers in one domain).
 >>
 >>> The basic flaw is that there is no general super-set, and the required
 >>>information to be transferred between the  host and the router is
 >>>protocol specific.
 >>
 >>The basic flaw in your analysis is that you misunderstand the nature and
 >>purpose of IGMP and its evolution.  It has not evolved to provide a
 >>"super-set" of the requirements of specific multicast routing protocols.
 >>There has often been pressure to throw in routing-protocol-specific
 >>features (e.g., including a "core" or "rendezvous point" address for
 >>CBT or PIM-DM), but so far we have managed to prevent such changes,
 >>which would be exactly contrary to IGMP's goals of keeping hosts isolated
 >>from knowledge of the multicast routing protocol du jour.

this is a misrepresentation of the change proposed in simple - the
change there was to the address format and had no efect on the
operation of IGMP, only on its payload (and then no more than IPv6
does:-)
 >>
 >>>2. There is no need for two different set of protocols. There is no 
 >>>real difference between the last hop and all other hops. One protocol 
 >>>can, and should, do it all. This way, IP multicast can be defined by a 
 >>>single specification!
 >>
 >>Sure, until next year, when someone comes up with the New New Multicast
 >>protocol.

yep....
 >>
 >>>4. IGMP, especially [IGMPv3], is far too complicated, with too many 
 >>>messages and fields that [SSM] protocols do not need. 
 >>
 >>I agree that IGMPv3 is more complicated than I would wish.  But the
 >>mismatch between what IGMPv3 provides and what SSM requires is due
 >>to the fact that SSM provides only a limited subset of the *service model*
 >>(*not* the multicast routing protocols) that IGMPv3 is designed for.
 >>Sure, if you offer a less functional service, you can do it with a simpler
 >>protocol (just as IGMPv2 is much less complex than IGMPv3).  The choice of
 >>what service(s) to provide at what layer is, of course, the topic of the
 >>most long-running debates in the field of data networking.  I would
 >>appreciate it if you would acknowledge that these issues are indeed
 >>debatable, and the fact that IGMP is not what you want does not
 >>necessarily represent a "basic flaw" in IGMP.  And if you won't do that,
 >>at least resist the urge to fabricate bogus "historical reasons" for
 >>things you don't understand.
 
this is a bit harsh steve - someoen could understand the apparent
current technical state but get the history wrong - aerguing that they
are technically wrong _because_ they dont know the history is not a
good way to debate what may otherwise be a valid contribution...

i think whats being proposed might be thought of as IGMPbis in the
same way that SSM supports IP Multicast Servicebis -with an
appropriate applicability statement (for both the host group
management and the subset routing protocl) I dont see why this is
a totally bad idea, history notwithstanding...

 cheers

   jon
history is bunk - ford
ford is dead - god
god is dead - nietcsze
god is ford - huxley
landrover is ford - bmw



From Doron@bandwiz.com  Sat Jul 29 10:28:16 2000
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03577
	for <ssm-archive@odin.ietf.org>; Sat, 29 Jul 2000 10:28:15 -0400 (EDT)
Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id FAA22616
	for <ssm-interest@external.cisco.com>; Sat, 29 Jul 2000 05:49:26 -0700 (PDT)
Received: from proxy1.cisco.com (localhost [127.0.0.1])
	by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with SMTP id e6TCnDF03640
	for <ssm-interest@external.cisco.com>; Sat, 29 Jul 2000 05:49:13 -0700 (PDT)
Received: from davis.bandwiz.com ( [212.150.220.34]) by proxy1.cisco.com with SMTP (MailShield v1.5); Sat, 29 Jul 2000 05:48:07 -0700
Received: by DAVIS with Internet Mail Service (5.5.2650.21)
	id <PWCJ0YS2>; Sat, 29 Jul 2000 15:48:47 +0200
Message-ID: <E9DC428883F3D31180F900E081107FF20891F9@DAVIS>
From: Doron Rajwan <Doron@bandwiz.com>
To: Steve Deering <deering@cisco.com>
Cc: ssm-interest@external.cisco.com
Subject: RE: Automatic Tunneling for Rapid Multicast Deployment
Date: Sat, 29 Jul 2000 15:48:46 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
X-SMTP-HELO: davis.bandwiz.com
X-SMTP-MAIL-FROM: Doron@bandwiz.com
X-SMAP-Received-From: outside
X-SMTP-PEER-INFO:  [212.150.220.34]


Steve Deering is right about the separation between protocols. We were not
involved in the creation of IGMP, only read the IGMP RFC itself. So we
probably misunderstood this point.

By the "dense-mode" we meant that the query mechanism used by IGMP is
efficient in the case that several hosts on the same LAN listen to the same
multicast group at the same time. Our claim is that this will not be the
typical case for SSM. Maybe part of the IGMP complexity is to provide this
ability, which is not needed for the SSM.

Our purpose in this document is to promote something in which we all share a
common interest, i.e. quick multicast deployment. For this we propose to
design a generic multicast tunnel protocol, sending IGMPv3-in-UDP packets,
etc. We are ready to implement the host side of the protocol, and make it
available as an open-source. This protocol will meet both goals: separation
and quick deployment. This is the important thing in our comments. The
remarks on IGMP are not a necessary important part of that, and so in order
to avoid dis-focusing on the goal we re-submit the document without the IGMP
part.

Any comment will be appreciated.

Doron Rajwan.




====================================================
 Automatic Tunneling for Rapid Multicast Deployment
====================================================



Introduction:
=============
The intent of this document is to promote rapid multicast deployment. 
A recent consensus in the multicast community is that source specific 
multicast [SSM] will be easier to deploy and so it can accelerate 
multicast acceptance. 

In order to have rapid SSM deployment throughout the network, we 
suggest a protocol that will enable multicast even if the routers near 
the receivers do not support multicast protocols. Further more, this 
protocol will work from any host, running any operating system, using 
UDP only. It will discover the nearest SSM-enabled router in the path 
to a specific source, and create a tunnel between the joining host and 
that router. This tunnel will be used in order to transfer multicast 
data for (S,G), from the router to the joining host.


Hardware support in routers:
============================
Each SSM-enabled router will have the hardware capability to create a 
tunnel to arbitrary number of hosts. When a multicast UDP packet is 
received, it will be duplicated and sent to each entry in the olist of 
(S,G), which may contain both neighboring SSM-enabled routers and 
tunnels. In the later case, the destination class-D address of the UDP 
packet will be replaced with the tunnel exit address (A), and the 
destination port will be replaced with the tunnel exit port (P). There 
is no need to encapsulate the packet inside another UDP packet.

The host can de-multiplex the group (G) from the port (P) by 
remembering each of the tunnels it created, and assigning different 
port number (P) for each tunnel coming from a specific source.

The original destination port number is gone forever, and cannot be 
used by the transmitter in order to implement de-multiplexing of any 
kind at the receivers. This limitation seems to be reasonable, and we 
do not think that packets should be encapsulated just because of it.


Software support in routers:
============================
In order to create tunnels, SSM-enabled routers will be able to 
receive UDP packets, containing join and leave commands, sent directly 
to them (using their IP address and a specific port number). These 
packets will contain the source (S), the group (G), the tunnel exit 
address (A) and port (P). Upon receiving it, the router will 
acknowledge the reception, by sending UDP packet to the joining host 
(A), and add this host to the olist for (S,G).

Currently, we do not specify the suggested packet format. It can be 
[IGMPv3] in UDP, with additional port number. Also, the tunnel should 
be refreshed from time to time. 

** Assuming there is interest in this protocol, we will write an 
Internet draft specifying the exact details of this tunneling process, 
and the exact requirements from routers.


Detecting the optimal router:
=============================
How can the joining host decide which is the optimal router to create 
a tunnel to? There can be many possible methods, e.g., use manual 
configuration, use hashing from a pre-defined set of routers, and so 
on. These methods while not optimal, will work at least as good as the 
methods for setting the Rendezvous Points (RP) in PIM-SM.

Another method is to use directory services, that will be asked to map 
(client IP, source IP) to (router IP). The result will be a list of 
entries containing these fields:
1. Client IP, mask: The group of clients which this entry is applied 
to. The mask is needed because clients can have temporary IP addresses 
from the same subnet.
2. Source IP, mask: The source of the multicast packet. This will 
usually be entire AS.
3. Router IP, mask: A group of routers that the host can round-robin.
4. Expiration: Time of expiration of this entry.

** Assuming there is an interest in this protocol, we will write an 
Internet draft specifying the exact details of this DNS process. We 
can also implement this DNS service world-wide.


Detecting the optimal router using trace-route:
===============================================
We now suggest an automatic router discovery method, using 
trace-route. The joining host will use standard trace-route algorithm 
in order to locate the first router towards the source. Then, it will 
send a UDP join massage to this router, as defined above. If the 
router does not acknowledge, the host will check the next router, and 
so on, until it finds a router that is SSM-enabled. This router will 
be used for tunneling.

The application needs the ability to send UDP packets with small TTL, 
and the ability to receive ICMP error messages. If the current socket 
implementation on the host computer cannot support it, the application 
can spawn the trace-route program itself, and process it's output. 
This can be done by any host!

Optimally, this protocol should be executed for every multicast 
source. For some applications there is only a single multicast source 
with a lot of groups, so, this problem doesn't exist. Also, in some 
cases, access ISPs are connected to the backbone using a single point. 
Assuming the backbone is SSM-enabled, the output of this process is 
independent of the source address.

The routers can help in this process. When locating an optimal router 
for a given source, that router can include (in the tunnel 
acknowledgment message) a list of subnets that it supports. Then, if 
the host needs to locate a router for each of the subnets, it can use 
the same router. There is no need to execute this protocol again. In 
this case the routes might not be optimal, but they are still much 
better than the routes created using RP in PIM-SM.

This protocol is only needed in cases that there is no other option. 
If there is a multicast enabled router on the host's LAN, it can be 
detected using limited broadcast of UDP packet to the LAN. This is 
needed if the operating system is old. If both the routers and the 
operating system is up-to-date, standard [IGMPv3] can be used.


Changes to the applications:
============================
Each application should be linked with a library for multicast join 
and leave. This library will check whether the operating system 
supports [IGMPv3]. If it is supported, it will be used.

If [IGMPv3] is not supported, the library will do limited broadcast of 
UDP packet in order to see if there is a SSM-enabled router on the 
LAN. If such a router exists, it will use it to join the multicast 
group.

In all other cases, the optimal router will be detected, and a tunnel 
will be crated to that router.

** Assuming there is interest in this protocol, we will implement this 
library, as an open-source code. It will utilize the OS [IGMPv3], LAN 
limited broadcast, or create a tunnel. It will locate the router for 
the tunnel by using directory services or by the trace-route 
algorithm.


Benefits:
=========
From the application point of view, the automatic tunneling feature 
opens multicast immediately, even in the extreme case, where only the 
joining hosts and the source support it, and it is effectively 
unicast. All the application need to do is to call join / leave 
functions, and receive packets. Later, when the routers are updated, 
things will become more efficient, of course.

Automatic tunneling can initiate a process and provide an incentive 
for wide spread multicast deployment at the routers. By enabling an 
immediate multicast to applications, routers that are not multicast 
enabled will suffer a larger load, while the multicast enabled routers 
will require less computational power since they receive a fewer 
number of packets from the next-hop router. This creates a 
positive-feedback that will cause most routers, especially in the 
critical areas, to be SSM-enabled.


Acknowledgement:
================
This document benefited a lot from discussions and specific comments 
of Radia Perlman and Jon Crowcroft. Useful discussion with Suchitra 
Raman are also acknowledged.


References:
===========
[ISM] S. Deering, "Host Extensions for IP Multicasting".
http://www.ietf.org/rfc/rfc1112.txt

[IGMPv3] B. Cain, S. Deering, I. Kouvelas, A. Thyagarajan, "Internet 
Group Management Protocol, Version 3", Work in Progress.
http://www.ietf.org/internet-drafts/draft-ietf-idmr-igmp-v3-04.txt 

[PIM-SM] B. Fenner, M. Handley, H. Holbrook, I. Kouvelas, "Protocol 
Independent Multicast - Sparse Mode (PIM-SM)", Work in Progress.
http://www.ietf.org/internet-drafts/draft-ietf-pim-sm-v2-new-00.txt

[SSM] H. Holbrook, B. Cain, "Source-Specific Multicast for IP", Work 
in Progress.
http://www.ietf.org/internet-drafts/draft-holbrook-ssm-00.txt 

[PIM-SO] N. Bhaskar, I. Kouvelas, "Source-Specific Protocol 
Independent Multicast", Work in Progress.
http://www.ietf.org/internet-drafts/draft-bhaskar-pim-ss-00.txt 

[PIM-SS] S. Bhattacharyya, C. Diot, L. Giuliano, R. Rockell, 
"Deployment of PIM-SO at Sprint", Work in Progress.
http://www.ietf.org/internet-drafts/draft-bhattach-diot-pimso-00.txt 


Author's Address:
=================
Doron Rajwan
BandWiz Inc.
doron@bandwiz.com

Meir Feder
BandWiz Inc.
meir@bandwiz.com




From deering@cisco.com  Sat Jul 29 12:16:20 2000
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03617
	for <ssm-archive@odin.ietf.org>; Sat, 29 Jul 2000 12:16:20 -0400 (EDT)
Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id HAA16205
	for <ssm-interest@external.cisco.com>; Sat, 29 Jul 2000 07:54:40 -0700 (PDT)
Received: from proxy1.cisco.com (localhost [127.0.0.1])
	by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with SMTP id e6TEsSO16913
	for <ssm-interest@external.cisco.com>; Sat, 29 Jul 2000 07:54:28 -0700 (PDT)
Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.18.32]) by proxy1.cisco.com with SMTP (MailShield v1.5); Sat, 29 Jul 2000 07:53:24 -0700
Received: from [10.19.130.188] (deering-dsl3.cisco.com [10.19.130.188])
	by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with ESMTP id HAA27871;
	Sat, 29 Jul 2000 07:53:30 -0700 (PDT)
Mime-Version: 1.0
X-Sender: deering@ups
Message-Id: <v04220800b5a8982857f6@[171.70.84.51]>
In-Reply-To: <1179.964856049@cs.ucl.ac.uk>
References: <1179.964856049@cs.ucl.ac.uk>
Date: Sat, 29 Jul 2000 07:55:49 -0700
To: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
From: Steve Deering <deering@cisco.com>
Subject: Re: Automatic Tunneling for Rapid Multicast Deployment
Cc: Doron Rajwan <Doron@bandwiz.com>, ssm-interest@external.cisco.com
Content-Type: text/plain; charset="us-ascii"
X-SMTP-HELO: popcorn.cisco.com
X-SMTP-MAIL-FROM: deering@cisco.com
X-SMAP-Received-From: outside
X-SMTP-PEER-INFO: popcorn.cisco.com [171.69.18.32]

At 8:34 AM +0100 7/29/00, Jon Crowcroft wrote:
> >>The *real* historical reason why IGMP is a separate protocol from the
> >>router-to-router protocol was to allow the use of multiple, different
>
>um, i thought at the time that the breakthrough was in designing 
>the first working example of a new communications paradigm:
>receiver driven end to end protocols

Perhaps, but that wasn't the purpose at the time.

>the separation of inter-domain and intra-domain routing for multicast
>is not a function of IGMP at all, and is not made easier or harder by
>it....

You misunderstood what I said, Jon.  The purpose of IGMP was to isolate
hosts from knowledge of the multicast routing protocols, *not* to separate
multicast routing protocols  from each other.

>i guess the only case where this isn't 100% is the debate about adding
>msaks, which in abny case just supports your argument, since the
>debate largely went against addign them:-)

Indeed.  No smiley meeded.

> >>The basic flaw in your analysis is that you misunderstand the nature and
> >>purpose of IGMP and its evolution.  It has not evolved to provide a
> >>"super-set" of the requirements of specific multicast routing protocols.
> >>There has often been pressure to throw in routing-protocol-specific
> >>features (e.g., including a "core" or "rendezvous point" address for
> >>CBT or PIM-DM), but so far we have managed to prevent such changes,
> >>which would be exactly contrary to IGMP's goals of keeping hosts isolated
> >>from knowledge of the multicast routing protocol du jour.
>
>this is a misrepresentation of the change proposed in simple - the
>change there was to the address format and had no efect on the
>operation of IGMP, only on its payload

I wasn't talking about any changes proposed to IGMP for SSM (which can
in fact be done in a way that does no protocol-specific violence to IGMP).
I was talking about the criticism of IGMP as supporting the super-set of
various protocol-specific requirements.

> >>I agree that IGMPv3 is more complicated than I would wish.  But the
> >>mismatch between what IGMPv3 provides and what SSM requires is due
> >>to the fact that SSM provides only a limited subset of the *service model*
> >>(*not* the multicast routing protocols) that IGMPv3 is designed for.
> >>Sure, if you offer a less functional service, you can do it with a simpler
> >>protocol (just as IGMPv2 is much less complex than IGMPv3).  The choice of
> >>what service(s) to provide at what layer is, of course, the topic of the
> >>most long-running debates in the field of data networking.  I would
> >>appreciate it if you would acknowledge that these issues are indeed
> >>debatable, and the fact that IGMP is not what you want does not
> >>necessarily represent a "basic flaw" in IGMP.  And if you won't do that,
> >>at least resist the urge to fabricate bogus "historical reasons" for
> >>things you don't understand.
> 
>this is a bit harsh steve - someoen could understand the apparent
>current technical state but get the history wrong - aerguing that they
>are technically wrong _because_ they dont know the history is not a
>good way to debate what may otherwise be a valid contribution...

I didn't argue that they were technically wrong, just that they were
historically wrong and that they were out-of-line in claiming that IGMP
was technically wrong ("flawed").  There is no "right" or  "wrong" in
protocol design, only engineering trade-offs, and indeed theirs may well
be a valid and valuable contribution.  They shouldn't need to appeal to
imagined history to explain its merits.

>i think whats being proposed might be thought of as IGMPbis in the
>same way that SSM supports IP Multicast Servicebis -with an
>appropriate applicability statement (for both the host group
>management and the subset routing protocl) I dont see why this is
>a totally bad idea, history notwithstanding...

Nor do I, nor did I say that is was.  My flame was against their shoddy
analysis of IGMP, not against their own proposal.

Steve




From callback123@altavistausa.com  Sat Jul 29 15:00:39 2000
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04113;
	Sat, 29 Jul 2000 15:00:39 -0400 (EDT)
From: callback123@altavistausa.com
Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id KAA18274;
	Sat, 29 Jul 2000 10:49:38 -0700 (PDT)
Received: from proxy3.cisco.com (localhost [127.0.0.1])
	by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with SMTP id e6THnMQ11233;
	Sat, 29 Jul 2000 10:49:23 -0700 (PDT)
Received: from  (max1-3.newyork.corecomm.net [209.81.238.131]) by proxy3.cisco.com with SMTP (MailShield v1.5); Sat, 29 Jul 2000 10:49:34 -0700
Subject: Re: From Lorraine,as promised,I can lower your bill
Date: Sat, 29 Jul 2000 14:45:43
Message-Id: <328.468058.339698@altavistausa.com>
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"
X-SPAM: Yes
X-SPAM-REASON: Suspicious TO Address
X-SPAM-INFO: http://wwwin.cisco.com/CustAdv/InfoSys/spam
X-SMTP-HELO: altavistausa.com
X-SMTP-MAIL-FROM: callback123@altavistausa.com
X-SMAP-Received-From: outside
X-SMTP-PEER-INFO: max1-3.newyork.corecomm.net [209.81.238.131]


<html>

<head>
<title>Untitled Document</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
</head>

<body bgcolor="#FFFFFF">
<div align="center">

<p><a href="http://members.hometown.aol.com/_ht_a/hellotel88/myhomepage/lowrates"><img
src="http://members.hometown.aol.com/_ht_a/hellotel88/myhomepage/lowrates/telephone.gif"
width="250" height="203" border="0"></a> <br>
Today, everyone knows the impact of the Internet.<br>
But not everyone nows how to cut their phone bill in 1/2. Just a Few examples!!!!</p>

<p>Uk $.04&nbsp;&nbsp;&nbsp;&nbsp; France $.06&nbsp;&nbsp;&nbsp; UAE&nbsp; $.31
&nbsp;&nbsp; Saudi Arabia $.59&nbsp;&nbsp;&nbsp;&nbsp; Denmark $.04
&nbsp;&nbsp;&nbsp;&nbsp; Sweden $.05</p>

<p><a href="http://members.hometown.aol.com/_ht_a/hellotel88/myhomepage/lowrates"><font
size="4">Click Here Now. </font></a></p>

<p>If you do not have flash please go to<br>
<a href="http://www.macromedia.com">www.macromedia.com</a><br>
to download it.</p>
</div>
</body>
</html>



From l.wood@eim.surrey.ac.uk  Sat Jul 29 16:38:01 2000
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15446
	for <ssm-archive@odin.ietf.org>; Sat, 29 Jul 2000 16:38:00 -0400 (EDT)
Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id MAA03085
	for <ssm-interest@external.cisco.com>; Sat, 29 Jul 2000 12:20:03 -0700 (PDT)
Received: from proxy3.cisco.com (localhost [127.0.0.1])
	by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with SMTP id e6TJJmQ17588
	for <ssm-interest@external.cisco.com>; Sat, 29 Jul 2000 12:19:48 -0700 (PDT)
Received: from prue.eim.surrey.ac.uk (prue.eim.surrey.ac.uk [131.227.76.5]) by proxy3.cisco.com with SMTP (MailShield v1.5); Sat, 29 Jul 2000 12:20:00 -0700
Received: from petra.ee.surrey.ac.uk ([131.227.88.13] ident=eep1lw)
	by prue.eim.surrey.ac.uk with esmtp (Exim 3.03 #1)
	id 13Ic9B-0005Ao-00; Sat, 29 Jul 2000 20:19:45 +0100
Date: Sat, 29 Jul 2000 20:19:42 +0100 (BST)
From: Lloyd Wood <l.wood@eim.surrey.ac.uk>
X-Sender: eep1lw@petra.ee.surrey.ac.uk
Reply-To: L.Wood@eim.surrey.ac.uk
To: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
cc: ssm-interest@external.cisco.com
Subject: Re: Automatic Tunneling for Rapid Multicast Deployment
In-Reply-To: <1179.964856049@cs.ucl.ac.uk>
Message-ID: <Pine.GSO.4.21.0007292015070.19149-100000@petra.ee.surrey.ac.uk>
Organization: speaking for none
X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/
X-no-archive: yes
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-SMTP-HELO: prue.eim.surrey.ac.uk
X-SMTP-MAIL-FROM: l.wood@eim.surrey.ac.uk
X-SMAP-Received-From: outside
X-SMTP-PEER-INFO: prue.eim.surrey.ac.uk [131.227.76.5]

On Sat, 29 Jul 2000, Jon Crowcroft wrote:

>  >>The *real* historical reason why IGMP is a separate protocol from the
>  >>router-to-router protocol was to allow the use of multiple, different
> 
> um, i thought at the time that the breakthrough was in designing 
> the first working example of a new communications paradigm:
> receiver driven end to end protocols

...but TCP is receiver driven! ( ack clocking, receiver windows,
Savage demonstrating subtle effects of receiver control, etc.) er,
what am I missing?

L.

> history is bunk - ford
> ford is dead - god
> god is dead - nietcsze
> god is ford - huxley
> landrover is ford - bmw

dhjgfdsifg is alidaodahdl - crocrowft

<L.Wood@surrey.ac.uk>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>