Subject: [ssm] msnip status

From: Stig Venaas <[email-masked]>
Date: Wed, 19 Oct 2005 14:48:41 +0200

Now that magma is being shut down, what is the future of
draft-ietf-magma-msnip? I know several people that are
interested in seeing this work continue. Are there any
plans for that, or has it more or less been decided that
this is not the way to go? I know there were discussions
on combining it with MRD, but don't think that went
anywhere.

Stig

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

---

From: Brian Haberman <[email-masked]>
Date: Wed, 19 Oct 2005 12:40:30 -0400

Hi Stig,
      The consensus is that msnip is not the solution people want.
Additionally, there has been no one volunteering to work on the
problem in general.

      Combining MSNIP with MRD doesn't make a lot of sense
and any such plans were abandoned.

      If you have people interested in the problem, have them bring
forth ideas.

Regards,
Brian

---

From: Hugo Santos <[email-masked]>
Date: Wed, 19 Oct 2005 18:55:05 +0100

Hi Brian,

> Additionally, there has been no one volunteering to work on the

I guess the question is why MSNIP isn't the solution people want and
what is the alternative (if there is one). If there is no alternative,
even if MSNIP isn't a perfect solution, why hasn't the work progressed?
With the MSNIP draft in MAGMA reaching -05 i guess there was some
interest in the past so it isn't perfectly clear why this draft was left
to die a graceful/ungraceful death.

> and any such plans were abandoned.

As Stig, i also saw some discussions regarding this in the MAGMA mailing
list, IIRC it involved some capability discovery that somewhere in time
people wanted to add to MRD, and wanted to re-use that in MSNIP (to
announce configured SSM ranges and others, IIRC).

>      If you have people interested in the problem, have them bring

Personally i believe it would be good to have a solution that would
allow sources to be active only when there was downstream interest
without explicit signaling between listeners and senders. So in that
sense, i'm interested in the problem.

Also, if possible, i would like to hear the original authors' ideas as
why it is or isn't a good idea to continue with this work, and why. It
would be good to have the reasons archived somewhere for future
reference. If in the other hand the original authors believe this work
should be progressed but don't have the cycles/interest to do so, please
come forward and say so there might be other people available to do so.

Best Regards,
Hugo Santos

---

From: Pekka Savola <[email-masked]>
Date: Wed, 19 Oct 2005 21:06:42 +0300 (EEST)

> sense, i'm interested in the problem.

While solving this kind of problem might be an interesting academic or 
engineering exercise, personally I'd prefer not to use the time and 
energy for this at this point.

That is because I believe there is not sufficiently high demand for 
such a protocol, and there are WAY too many multicast protocols out 
there already which aren't really all that useful to be worth 
universal implementation, deployment, etc. (at least yet).

If (SSM) multicast becomes widespread so we wouldn't be doing the work 
just for the fun of it, let's revisit the need for the protocol. 
Otherwise I think we should let it rest until the time is right.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 19 Oct 2005 16:12:04 -0700

Brian: What exactly where the points that stopped the last MSNIP draft
from moving forward ? I unfortunately don't remember the details,
and in general i'm of course annoyed that there's no good means in the
IETF to keep that last work status summary alive in case it needs to
get picked up again.

I think MSNIP tried to solve a key functionality for the SSM architecture,
and while it may be possible to ad-hoc hack something similar up once
somebody requires it, i still think that it would be good to have an
IETF recommendation for this functionality.

If we were to release an RFC, we could make it informational. I don't
think that MSNIP itself needs to be focussed on what Pekka is claiming
"universal adoption". Because it only applies to sources, it will always
tender only to comparably much fewer places than for example IGMP. 

Cheers
	Toerless

-- 
Thanks
   Toerless Eckert

---

From: Beau Williamson <[email-masked]>
Date: Wed, 19 Oct 2005 20:26:21 -0500

Well, I think the deafening silence on this topic over the last couple of 
years pretty much speaks for itself.

To a large degree, MSNIP is a solution in search of a problem.  I'd rather 
see us focus our efforts elsewhere myself.

Beau Williamson

---

From: Isidor Kouvelas <[email-masked]>
Date: Thu, 20 Oct 2005 00:51:03 -0700

FWIW I do not think that dropping the MRD option was a show stopper for 
MSNIP. The reason the work stalled was that there was no interest. I 
agree with Toerless that it was a key piece for SSM.

Isidor

---

From: Pekka Savola <[email-masked]>
Date: Thu, 20 Oct 2005 12:03:48 +0300 (EEST)

> I think MSNIP tried to solve a key functionality for the SSM architecture,

Could you elaborate a bit on what you think is this "key 
functionality" and why exactly it's "key" (e.g., specific scenarios 
you have in mind)?

I'm having difficulty understanding the (relative) importance of a 
sender being able to stay quiet if there are no receivers.  The waste 
of bandwidth and processing power at the DR (who'd just discard the 
traffic) doesn't seem to be sufficiently concinving at least in the 
scenarios I have in mind.

---

From: Isidor Kouvelas <[email-masked]>
Date: Thu, 20 Oct 2005 03:08:21 -0700

Pekka Savola wrote:
> Could you elaborate a bit on what you think is this "key functionality" 
> and why exactly it's "key" (e.g., specific scenarios you have in mind)?

As I believe was described in the draft MSNIP is important in the case 
where you have a server with a very large number of potential sessions 
but only a small number of active sessions. So if the server has content 
available on 1000 different groups and there are active receivers at any 
time only for 10 of them, the box / link you would need to drive this 
with and withhout MSNIP is totally different.

Isidor

---

From: hoerdt Mickael <[email-masked]>
Date: Thu, 20 Oct 2005 12:15:50 +0200

Hi,

MSNIP (or any logical equivalent, let call it protocol X) allows 
ressources saving at the following points of the network :

1. the DR(s).
2. the link connecting the DR to the multicast source host(s).
3. the host(s).

A possible scenario showing that protocol X is (relatively) useful would 
be the following :

. Exhaust the ressources available at any of these three points, 
sourcing multicast
  content without  protocol X.
. Activate protocol X, and replay the same scenario showing that now the 
ressources
  aren't exhausted.
 
Does it make sense to define a protocol X wich do not have to be 
deployed/implemented
in the routers, using possibily unicasting and/or pooling from the 
source ? As a multicast
application developer/coder, i would say that it depends on the SSM 
multicast service
availability....

Hoerdt Mickaël

---

From: Matthias Waehlisch <[email-masked]>
Date: Thu, 20 Oct 2005 12:29:11 +0200

hi,

On Thu, 20 Oct 2005, Pekka Savola wrote:

> I'm having difficulty understanding the (relative) importance of a sender
> being able to stay quiet if there are no receivers.  The waste of bandwidth
> and processing power at the DR (who'd just discard the traffic) doesn't seem
> to be sufficiently concinving at least in the scenarios I have in mind.
> 
  but if you change the focus to the sender the importance of saving e.g. 
processing power is increasing, especially if you think about 'small' 
mobile devices.

  also there were some ideas to use MSNIP for mobile multicast.

cheers
  matthias

---

From: Brian Haberman <[email-masked]>
Date: Thu, 20 Oct 2005 06:32:25 -0400

Toerless,
      As has already been said, the amount of community involvement in
the MSNIP work has been less than stellar.  I know of several scenarios
where resource problems are encountered due to lack of feedback to
multicast sources.  Multicast sources attached via low-speed or
wireless links is an example.

      I could get on my soapbox and rant about how the IETF work
requires active participation from many people in order to make it
successful.  And in this case, as well as others, the lack of active
participation has been the downfall.

Regards,
Brian