Subject: [pim] why register message is needed?

From: Hitoshi Asaeda <[email-masked]>
Date: Fri, 24 May 2002 18:32:39 +0200 (MEST)

I encountered a primitive doubt.

Why does PIM-SM require Register message as an encapslated "data"?
I mean why sender's DR only sending some message to RP, like "I have
sender(s) on my LAN. His address is brahbrah", is not sufficient?
And after the DR thinks the sender stops sending (this can be handled
with some configurable timer), it sends "He seems to finish" to RP.

Someone may say immediate data forwarding is needed, but IMO, the
difference is not so big. Moreover, the amount of encapslated packet
traffic (including unneeded packet) and performance for
en/decapslation are significant.

Comments?
--
Hitoshi Asaeda
_______________________________________________
pim mailing list
[email-masked]
http://catarina.usc.edu/mailman/listinfo/pim

---

From: Liming Wei <[email-masked]>
Date: Fri, 24 May 2002 09:46:18 -0700 (PDT)

> From: Hitoshi Asaeda <[email-masked]>
> 

This is all good if there is no need to support SAP/SDR-like
applications.

-Liming

---

From: Hitoshi Asaeda <[email-masked]>
Date: Fri, 24 May 2002 18:56:37 +0200 (MEST)

> This is all good if there is no need to support SAP/SDR-like

Sorry, I cannot understand...
--
Hitoshi Asaeda
_______________________________________________
pim mailing list
[email-masked]
http://catarina.usc.edu/mailman/listinfo/pim

---

From: Liming Wei <[email-masked]>
Date: Fri, 24 May 2002 10:06:16 -0700 (PDT)

> Sorry, I cannot understand...

Say, if the source sends only one packet every 6 minutes, the
receivers will never receive any packets from the source since, it
deterministicly loses the first packet before the SPT is setup. By the
time the second packet is sent (6 minutes later), the SPT state is
already expired.

Another source-active-notification-without-data-encapsulated will not help.

-Liming

---

From: John Zwiebel <[email-masked]>
Date: Fri, 24 May 2002 11:26:44 -0700

As Liming said, these are all good questions, and you could also
apply these same questions to MSDP encapsulation, which is
becoming something that isn't working well.  Especially for things
like the SDR app for the same reasons Liming outlined.

The choices made for PIM go back to the initial paradigm decisions
made years ago.  The choice when Steve first worked on multicast
was that the network would be able to accept any multicast packet
and get it to where ever it needed to go.  When you are talking about
a dense-mode protocol this works fine.  But when you have a
sparse-mode protocol, especially one that is suppose to support
both a shared-tree and shortest path trees, this paradigm fails.

There has been some discussion on how a multicast RTS/CTS might
be set up so that the source wouldn't send until the network
gave permission.  Basically, the idea would be that the network
requires some period of time to set up the forwarding trees and once
the trees have been set up, then the source would start sending.

MSNIP tries to address part of this by having a "reverse IGMP".

However, since the beginning, application developers seem to have
been unwilling to make modifications that would support an
RTS/CTS (or if not the app developers, the great "someone").  And
there has been some resistance from the protocol developers because
it isn't clear what the apps are suppose to really do, meaning, is
there such a thing as a multicast application that can not drop
any data when setting up the forwarding trees.  Video and audio,
do not require delivery of the first transmitted packets because
the user just wants to see what is happening now, the stuff that
happened before is unimportant.

Source Specific Multicast is one way of getting around this because
the receiver knows about the source before the receiver makes its
first communication with the last-hop router (ie, before it sends
the IGMP report).  SSM separates setting up of the shortest tree from
delivery of data.  If you know in advance when the source is going to
start sending, the SPT can be set up and you won't miss a thing.

SSM is "the answer" for many protocol developers.

OTOH, there are a number of App developers who like things
just the way they are now with ASM and they have expressed
an unwillingness to migrate toward SSM for their specific
application.

Your point about the time that it takes to set up the
SPT is small assumes that it will be acceptable that some
packets are lost.  And in an interdomain environment, that
means that a lot of packets will not reach the receiver.

Well, those same app developers who don't want to move to
SSM, don't want any packets to be lost, and they don't want
to receive any duplicate packets.

So, the direction to go is not clear.  What is really necessary to
simplify multicast routing to make it more robust, while at the
same time meeting the expectations of the apps?

How much are the apps willing to add more control structures or
deal with new protocols to meet their requirements?  In other words,
how can the protocol developers communicate to the app developers
the problems inherent in multicast routing which make it impossible
to provide the kind of service (I perceive, I could be wrong) they claim
they want?

z