Subject: Re: Re: [pim] why register message is needed?

From: "P.Jhingran" <[email-masked]>
Date: 25 May 2002 19:22:33 -0000

hi all,
Even i have been thinking on this since long...
well i also feel that ideally register pkt encapsulation and 
decap. has too much of over head...thinking in mind that most of 
the vendors provide a threshold of zero...or one as one can 
call...
Meaning that once the RP finds a source it forms a SPT with the 
SDR...
and with this its better to introduce a message similar to "NULL" 
register message ...which can trigger the formation of a SPT 
between the RP and the SDR...or may be a new message which holds 
only the Source and Group address..alone.
And the app developers can send some kind of test data which does 
the above .before sending the actual data...
i have seen one such multicast site on the net...sorry i don't 
remembet its name...
The only advantage of register messages comes when a remote SDR 
tries to inject data packets in the multicast domain while the 
path between the SDR and the RP is not fully pim-sm enabled...and 
that too is the threshold at RP is very high..but i don't think 
any one does this in practice...
and what can be the need of sending data packets once per 6 
mins...or even 2 mins...
Its useless to drag a concept which has not much practiacal 
importance...besides adding more pages to the draft...
regards,
Prashant

On Fri, 24 May 2002 Liming Wei wrote :
> > From: Hitoshi Asaeda <[email-masked]>
> >
> > > > 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.
> > >
> > > This is all good if there is no need to support 
>SAP/SDR-like
> > > applications.
> >
> > 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
>_______________________________________________
>pim mailing list
>[email-masked]
>http://catarina.usc.edu/mailman/listinfo/pim

_________________________________________________________
Click below to visit monsterindia.com and review jobs in India or 
Abroad
http://monsterindia.rediff.com/jobs

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

---

From: Liming Wei <[email-masked]>
Date: Sat, 25 May 2002 14:47:47 -0700 (PDT)

Prashant, it helps to read John Zwiebel's message again on this issue.
PIM is designed to support the "internet standard multicast" ISM. The
applications like SDR conform to that service model, and we have no
choice but to support it. Note that SDR is just one well known
application people like to use as examples. Other more widely-deployed
application(s) (in terms of size of user population) doing that may
exist, while less known in this circle.

But lets lighten up a bit and remember that there is
IGMPv3/SSM/PIM-SM, making all these issues moot. In the quest for a
better or more easily implementable protocol, we should not (do not
need to) break things that were working before.

-Liming
------------
> From: "P.Jhingran" <[email-masked]>
> Reply-To: "P.Jhingran" <[email-masked]>
> 
> hi all,

---

From: John Zwiebel <[email-masked]>
Date: Tue, 28 May 2002 11:53:17 -0700

> need to) break things that were working before.

Liming:

One would think this would be an easy sell.  How many OS do you 
know that have IGMPv3 installed as standard?  Windows XP is the
answer.

Yes, you can build a FreeBSD kernel with it, and supposedly there's
a Linux patch, but they aren't there.  In fact, the Linux patch 
is (according to an email exchange I've had on Linux.org)...

   Last time i saw IGMPv3 patches was some from sprint labs
   posting and if i recall they were not SMP safe.

Then there has been the discussion I've had with some I2 folks
who like their application just the way it is and don't want
to migrate to SSM.

And... there is the question of what to do with an IGMPv3 (S,G)
report received for a non-SSM group (ie outside of 232/8).  Either
I've chosen some incorrect terms resulting in a huge misunderstanding,
or I'm not getting back responses that make sense to me.  Some
individuals are adamant that such a join should be interpreted by
PIM as a (*,G) join or should be ignored.  

Let me state again, that there is no reason a last-hop router should
be prevented from establishing a shortest-path tree no matter what
group range is being used.  There is no reason to not include
the source address in the SAP description of the session so that
an "SSM-aware" application can join directly to the source by-passing
the shared-path.  (There may, of course, be administrative reasons,
but those should be interpreted by the network manager in control
of his network.)

NOTE: I said "SSM-aware", meaning an application that can 
take advantage of IGMPv3.

Anyway, the discussion is moot unless we "finish" the job and
get IGMPv3 into Linux and FreeBSD (from which I understand it
will 'automagically' appear in Darwin -- ie MacOSX).  It appears
that app developers think it is "just too hard".  (I don't mean
that in a nasty way, rather that the impression I have 
developed is that app developers don't want to deal with
something that they are not sure is useful.  Good point.)

So, if SSM is going to go anywhere, we need to do a much
better job of selling it.

z

---

From: Marshall Eubanks <[email-masked]>
Date: Tue, 28 May 2002 15:47:40 -0400

As we bring up video channels, we plan to mirror them in SSM.
If the various _players_ as well as the OS's will support them, we
will drop the ASM support. My guess is that this will take a year to
happen.

Regards
Marshall

--

T.M. Eubanks
Multicast Technologies, Inc
10301 Democracy Lane, Suite 410
Fairfax, Virginia 22030
Phone : 703-293-9624       Fax     : 703-293-9609
e-mail : [email-masked]
http://www.multicasttech.com

Test your network for multicast :
http://www.multicasttech.com/mt/
  Status of Multicast on the Web  :
  http://www.multicasttech.com/status/index.html

---

From: Greg Shepherd <[email-masked]>
Date: Tue, 28 May 2002 13:53:26 -0700 (PDT)

> will drop the ASM support. My guess is that this will take a year to

Marshall,

I really think you're doing the right thing here. You may also want to
consider making the SSM stream a higher quality feed as an incentive. In
fact, this is similar to some ideas to incent mcast deployment I've tossed
around with others; create a short 'demo' unicast stream at a much lower
bitrate, a link to a screen-shot of the higher bitrate mcast feed, and end
the demo with some hype-text to create a buzz.

"I want my McastTV!!"

Sure, and we'll get David Bowie to give the plug. ;-)

Greg

---

From: "Marshall Eubanks" <[email-masked]>
Date: Tue, 28 May 2002 22:33:04 -0400

John;

   I asked Dave Singer about this, and you are correct. 
OS X will get IGMPv3 when the underlying BSD kernel gets it.

                           Marshall

On Tue, 28 May 2002 11:53:17 -0700
 John Zwiebel <[email-masked]> wrote:
<snip>

---

From: Hitoshi Asaeda <[email-masked]>
Date: Wed, 29 May 2002 10:24:33 +0200 (MEST)

#Oh, subject was changed.:)

> OS X will get IGMPv3 when the underlying BSD kernel gets it.

In fact, I've done IGMPv3 host-side implememtation for
NetBSD-current.
It is still on testing together with some alpha testers (so I didn't
announce some major mailing-list), but I believe it supports complete
functions, basic and advanced APIs, IPv4 and Protocol-Independent
APIs, many improvements, etc...
It has done from scratch. It was opened with BSD copyright.

But, due to NetBSD's historical kernel's spec, just a few parts are
not working well. (In fact, this is mainly a problem for MLDv2's
implementation.) Now, we are discussing about it in a mailing list for
netbsd kernel developer.:)
Of course, I'll fix everything after NetBSD's policy is fixed.
--
Hitoshi Asaeda
_______________________________________________
pim mailing list
[email-masked]
http://catarina.usc.edu/mailman/listinfo/pim