Subject: Re: [Mtp] the more things change, the more they stay the same

From: David Meyer <[email-masked]>
Date: Wed, 9 Jul 2003 13:47:33 -0700

I guess the more things change, the more they stay the
	same. 

	So another thing occurred to me while reading the
	Multicast Last-Mile Solutions drafts on Greg's site: Why
	are we defining yet another ad-hoc signaling protocol
	(that is one way to looks at these proposals)? The IETF
	literature is littered with signaling proposals, some
	host-based, some router-based, at varying degrees of
	generality. 

	Straw person: why not have the host send a PATH message
	towards the source (since it knows the source) and have
	the first multicast capable router in the path send back
	the its tunnel endpoint, have the host set up GRE (or
	user space encap) to that router and ...

	What I am suggesting is we really don't have a general
	purpose host-to-router signaling protocol (well,
	maybe). So if we pick one of the current drafts (or a
	hybrid, or even new), will we have to build a new
	signaling infrastructure for the next feature not
	supported by the directly connected routers? 

	Seems like we should be able to answer this question in a
	more general way than is done in these drafts.

	Dave

_______________________________________________
routing-discussion mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/routing-discussion

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Wed, 9 Jul 2003 17:36:33 -0400

> David Meyer wrote:

Greg Shepherd wrote:
 
> Well, that is quite similar (from a straw prospective) to what I'd
> like. My personal preference is for user-space so it could be easily
> deployed. But why not just translate the destination address? 
> You know the
> receiver address so change the destination address of the 
> replicated mcast
> stream for each unicast reciever. No encap, no decap, no 
> fragmentation.

Not sure what problem we are trying to solve here. If it's the problem of end users being able to accept Class D packets, then this won't work unless IGMP is changed slightly. That is, the multicast-enabled router currently does NOT have a complete list of every member of the group. Because IGMP allows hosts on any given subnet to not send a report if they've heard someone else already respond to the router's query with a join report for their group. So to translate the Class D address to a unicast address, and replicate the packet, would need a slight mod to IGMP. But if that's a goal, I agree with Greg.

If we're trying simply to get a good count of membership, the same basic problem exists.

But I would think the fix is simple enough, although it makes IGMP or multicasting in general somewhat less scalable. Just make every host member of the multicast group respond with a report. You could even use the router's unique IP address to respond, rather than the multicast address.

If there's a need to have the source of the multicast get a current membership total, each router can in turn provide membership totals to the source address of the multicast. This still scales better than having individual hosts reply to the source!

My vote would be to allow IGMP reports to be sent by EACH member, but to still use the multicast address in the packets to the each host member. And to have the multicast routers close the gap to the source, rather than each end user.

Somehow, it hurts (me) to see RSVP signaling used as a replacement for IGMP.

Bert

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Wed, 9 Jul 2003 17:36:33 -0400

Bert

---

From: Bill Fenner <[email-masked]>
Date: Wed, 9 Jul 2003 17:04:15 -0700

On Wed, Jul 09, 2003 at 02:17:38PM -0700, Joel Jaeggli wrote:
> 
> It was never clear to me why a host to router signaling mechanism had 
> to be different from the router to router signaling mechanism.

Here's one reason: because if we had this conversation in 1993 we
would have made the host to router signalling mechanism DVMRP, or
maybe we would have been looking toward the future and made it MOSPF.

The generalization of that is the goal is to be able to evolve
the routing protocol independently of the host<>router interface.
Since there are orders of magnitudes more hosts to change than
routers when a protocol changes, this theoretically makes the
infrastructure more able to change piecemeal.

  Bill

---

From: "Naidu, Venkata" <[email-masked]>
Date: Thu, 10 Jul 2003 10:34:18 -0400

-> From: Bill Fenner [mailto:[email-masked]]
-> On Wed, Jul 09, 2003 at 02:17:38PM -0700, Joel Jaeggli wrote:
-> > 
-> > It was never clear to me why a host to router signaling 
-> mechanism had 
-> > to be different from the router to router signaling mechanism.
-> 
-> Here's one reason: because if we had this conversation in 1993 we
-> would have made the host to router signalling mechanism DVMRP, or
-> maybe we would have been looking toward the future and made it MOSPF.
-> 
-> The generalization of that is the goal is to be able to evolve
-> the routing protocol independently of the host<>router interface.
-> Since there are orders of magnitudes more hosts to change than
-> routers when a protocol changes, this theoretically makes the
-> infrastructure more able to change piecemeal.

  Another good reason is based on end-to-end principle of the Internet. 
  Core of the Internet is best effort (was intended to be, at least). 
  If we would like to support quality of service, we are supposed
  to signal more parameters in the host<>router than router<>router
  to do admission control before entering the network. So, the 
  requirements are different (light weight, not so granular signalling 
  in the core etc) from user<>router interface to router<>router 
  interface.
  
  I am not sure how much (or, how) multicasting fits into such
  end-to-end signaling principle. If I have an HDTV and paid for
  premium VoD service, will I be getting better picture, sound
  quality than my neighbor who is subscribed to a basic service ?

Venkata.

---

From: Bill Fenner <[email-masked]>
Date: Thu, 10 Jul 2003 08:14:10 -0700

>except that it's hasn't in practice because we have two things that w e 
>than have to evolve in parallel.

Indeed.  However, look at how long it's taking to get from IGMPv2 to IGMPv3
stacks.  At the time that IGMPv2 was the "sweet spot" of IGMP, i.e. the
time that all that implementation and deployment was happening, DVMRP was
the "sweet spot" of routing protocols -- PIM was this bright new opportunity
poking its head over the horizon and MOSPF was much more well developed.

If the host<>router communication was the routing protocol, all of the
end routers would *still* be trying to talk DVMRP to the hosts, and there
would be a tiny minority that talked PIM, even though PIM is ubiquitous
in the network and there are no significant bits of DVMRP routing.

Now, just because it made sense in the past doesn't mean that it still
makes sense now -- maybe PIM is the end-all and be-all and that's all we
should care about.  But it seems unlikely to me that
a) revving routing protocols in the host is any easier than revving IGMP
   in the host.
b) PIM is the only routing protocol we ever want to have.

Maybe the problem with IGMP was that it was implemented in the kernel,
and we should have let the kernel collect the membership information,
reference-count sockets and program the multicast filter and such but
then it should have notified a daemon of the memberships and the daemon
could talk whatever protocol is needed.

  Bill

---

From: Bill Fenner <[email-masked]>
Date: Thu, 10 Jul 2003 08:14:10 -0700

Bill

---

From: Radia Perlman - Boston Center for Networking <[email-masked]>
Date: Wed, 9 Jul 2003 17:29:54 -0400 (EDT)

Dave Meyer said:

>>a more general way
>>	to solve the problem (rather than cooking up a yet
>>	another special purpose solution for this case).  

What do you mean by "more general way"? Something that would
be useful for more than multicast? Something that would be
useful for more than SSM style multicast?

I'm trying to get people to be specific rather
than using vague terms like "not architecturally pure" or "yet another
special purpose mechanism",
that sound pejorative, yet don't really convey information.

>>to be different from the router to router signaling mechanism.

Yes, I agree with this. The fewer protocols that need to be defined, the
better.

Radia

---

From: Radia Perlman - Boston Center for Networking <[email-masked]>
Date: Thu, 10 Jul 2003 12:02:01 -0400 (EDT)

Re Tom Pusateri's note:

>the characteristics of the signaling should be decided first
>and then we can determine if an existing protocol will fit our needs.
Yes, exactly!
	
	   The characteristics I would like to see are:
	
	   a. Host application can send join requests without any special
	      privileges on the largest variety of operating systems. This
	      speeds deployment and puts users in control without having to
	      get approval from Administrators. This dictates that the
	      protocol be UDP or TCP based.

Can an application send a UDP or TCP based packet with router alert
in the IP header without special privileges?

I believe the packet needs to have router alert on in order for it to
have destination address=a unicast address (so non-multicast routers
will forward it normally). If router alert needs to be on, then
I suspect the daemon will have to have privileges on the host, and
there's no reason for a UDP or TCP header since it will have to
be using raw sockets.

	2. Don't make encapsulation a requirement.
	
	   This complicates the host implementation requiring it to decapsulate.
	   While this may be one way to get the multicast to the hosts,
	   simply having servers sit at the edge of a network and replicating
	   a multicast stream to a bunch of hosts by replacing the multicast
	   destination address with the hosts unicast address eliminates
	   much complication from the host application. It simply sees a
	   regular UDP unicast stream coming in.

Perhaps, though you can't simply remove "G" from the header. It has to
be preserved somewhere. So perhaps data should have a multicast header
after or instead of the UDP header that contains G, the tree root perhaps,
whatever else might be considered important.  And then the encoding need
not be IP in IP tunneling.

	3. The address the join is sent to should be specified the same way
	   as the group and the source address is learned. This will likely be
	   in the SDP description. The join address may in fact be the source,
	   or it may be an anycast address or some other invention. But we're
	   free to try different approaches and we don't lock ourselves in.
If the group is (S,G) then that meets what you're saying. If the group
is just G, then there could be a global constant anycast address (and
you have to make sure someone in your domain is advertising that address).
Or perhaps it could be a configuration parameter on the endnode (what anycast
address to use for joining groups in general (even SSM groups), or specifically
just for ASM groups.
	
	4. The join should use the router alert option in the IP header.
	   This will allow routers along the path from the receiver to
	   the source to process the unicast join or send it to a server
	   it knows about.
Ah yes. That was why I thought it would have to be raw sockets, and not
just an unprivileged UDP/TCP application. So is this in fact possible?

Radia

---

From: Radia Perlman - Boston Center for Networking <[email-masked]>
Date: Thu, 10 Jul 2003 12:02:01 -0400 (EDT)

Yes, exactly!

	

	

Radia

---

From: Bill Fenner <[email-masked]>
Date: Thu, 10 Jul 2003 10:03:49 -0700

>in the IP header without special privileges?

In the sockets interface, yes - the IP_OPTIONS socket option is not
privileged.

>be preserved somewhere.

Actually the model that Tom is talking about sounds kind of like
REUNITE (Infocom 2000), which just uses unicast address+port pairs
to identify multicast groups.

  Bill