Re: Multicast Data

Dear,
would you please answer straight one question ?
(So we can discuss some facts and not what we imagine is happening in
the other people heads ?)

Topology:

S -- RS -/- RP -/- RD -- D

S: source of mcast (say, vlc mcasting a movie)
RS: router serving S, mcast enabled with sparse
RP: the RP for the group in question (say group G)
RD: router serving D, mcast enabled with sparse
D: the recipient (say, vlc playing the movie)

No other clients involved.
Now, T0 (that is , time zero) S starts bcasting the movie.
At T1, 30 seconds after T0, D starts "playing" the data mcasted to group
G port X.

*Question*
How much time will lapse until D starts viewing video ?

1) No time, it will start immediatelly (less than 5 seconds)
2) No time, video will not start
3) Some 2 1/2 minutes
4) None of the above

-Carlos

Kambiz Agahian @ 12/04/2010 11:39 -0300 dixit:
> OOOK!
>
> Now I know where your problem is:
>
> No timers expire if you have a live Multicast source - why?
>
> If your Windows multicast server sends Multicast packets to its segment but no
> receiver is known to the RP, his closest router (say R1) receives a (S,G)
> Register-stop message from the RP and it stops shooting encapsulated packets
> towards the RP.
>
> R1 also gets rid of the "registering" flag for the (S ,G) entry. It also
> discards all other packets from your Windows server.
>
> Now, what do you reckon?
>
> Does R1 removes the (S,G)? any timers to expire? no.
>
> Actually the IETF has done a nice job here; although your timer is still
> counting down but as soon as you reach T=0 IF your Multicast source is still
> sending data IT RECREATES the entry and the little (S,G) never gets removed;
> again as long as your source is alive.
>
> How about the Register process?
> As soon as R1 automagically recreates the (S,G) because of the existence of
> multicast stream it sends another Register message towards the RP.
>
> How about the Stop register message?
> Same concept as before. The RP (if no receivers still out there) does send a
> Stop reg. message towards R1.
>
> Then again, if you don't shut down your Windows server you see the registering
> process every 3 minutes but the logic behind it is the fact that R1 maintains
> the (S,G) - again if there is a live Multicast source.
>
> Problem?
> Many students try to test this using Ping and they lose the (S,G)! eager to
> test? use IP SLA to simulate a multicast source or a larger ping.
>
> HTH
> --------------------------
> Kambiz Agahian
> CCIE (R&S)
> CCSI, WAASSE, RSSSE
> Technical Instructor
> CCBOOTCAMP - Cisco Learning Solutions Partner (CLSP)
> Email: kagahian_at_ccbootcamp.com
> Toll Free: 877-654-2243
> International: +1-702-968-5100
> Skype: skype:ccbootcamp?call
> FAX: +1-702-446-8012
> YES! We take Cisco Learning Credits!
> Training And Remote Racks: http://www.ccbootcamp.com
> OEQ Voice Waiver: http://www.ccbootcamp.com/noeqvoice.html
> OEQ R&S Waiver: http://www.ccbootcamp.com/noeqrs.html
> OEQ Commercial: http://www.ccbootcamp.com/noeq.mpg
>
>
>
>
> -----Original Message-----
> From: Carlos G Mendioroz [mailto:tron_at_huapi.ba.ar]
> Sent: Mon 4/12/2010 2:31 AM
> To: Tharindu Rukshan Bamunuarachchi
> Cc: Kambiz Agahian; ccielab_at_groupstudy.com
> Subject: Re: Multicast Data
>
> Yes, you can:
>
> ip pim sparse sg-expiry-timer
>
> To adjust the (S, G) expiry timer interval for Protocol Independent
> Multicast sparse mode (PIM-SM) (S, G) multicast routes (mroutes), use
> the ip pim sparse sg-expiry-timer command in global configuration mode.
> To restore the default setting with respect to this command, use the no
> form of this command.
>
> Default, as I said, is 180 seconds, or 3 minutes.
>
> But I would think about what is the problem and see if changing this
> is the better way to go about it. If S -> RP traffic does not generate
> any problems in your setup, I might just join the RP to the group to
> keep the mcast path established.
>
> -Carlos
>
> Tharindu Rukshan Bamunuarachchi @ 11/04/2010 22:51 -0300 dixit:
>> hm ...
>>
>> okay, so if i join the tree after starting the show (e.g. after 20
>> seconds) ... as RP does not keep potential sources ... i wont receive
>> multicast data until 3 minutes timeout.
>>
>> is it possible to minimize 3 minutes ...
>> __
>> tharindu rukshan
>> blog.tharindu.info <http://blog.tharindu.info>
>>
>>
>>
>> On Fri, Apr 9, 2010 at 5:28 PM, Carlos G Mendioroz <tron_at_huapi.ba.ar
>> <mailto:tron_at_huapi.ba.ar>> wrote:
>>
>> I'd prefer you making the effort and ask what is that is unclear.
>> But there are lots of cases in multicast where things get fixed
>> after some timeout, and it happens to be 3 minutes by default.
>> The RP keeps no info on potential sources if there are no receivers
>> for a group, and will kill the registration attempt w/o joining in
>> that case.
>>
>> Makes sense ?
>>
>> Tharindu Rukshan Bamunuarachchi @ 9/04/2010 8:31 -0300 dixit:
>> > bit unclear about last point .... please clarify further if you
>> can ....
>> > __
>> > btharindu.blogspot.com <http://btharindu.blogspot.com>
>> >
>> >
>> >
>> > On Fri, Apr 9, 2010 at 4:01 PM, Carlos G Mendioroz
>> <tron_at_huapi.ba.ar <mailto:tron_at_huapi.ba.ar>> wrote:
>> >
>> >> Adding to that that has been said:
>> >> -yes, you can loose first, second, third... any, cause Mcast runs
>> >> over UDP and there are no L4 delivery warranties. Actually, there
>> >> are very few L7 protocols that have assured delivery over mcast.
>> >>
>> >> -registration does not stop when S (source router) receives join
> from
>> >> RP, so there can be many packets going unicast to RP.
>> >> RP tells S to stop registration after it receives direct mcast
>> from S,
>> >> so no packets lost in between.
>> >>
>> >> -sending can start before receivers have joined the RP, in which
> case
>> >> the RP will stop registration w/o joining the source. Then you it
>> will
>> >> start a slow "flapping", trying to register every 3 mins, and being
>> >> call to silence untill a receiver shows up.
>> >>
>> >> I guess you can loose up to 3 minutes of the show if nobody was
>> >> listening and you are late to the start :)
>> >>
>> >> -Carlos
>> >>
>> >>
>> >>
>> >> Kambiz Agahian @ 9/04/2010 3:44 -0300 dixit:
>> >>> Hi Tharin,
>> >>>
>> >>> Good point!
>> >>> First off, I'm hoping that my interpretation of your question is
>> correct
>> >>> anyway correct me if your question if not exactly this but
>> actually the
>> >>> problem is that almost all resources (including most pages on
>> cisco.comand
>> >>> juniper.com <http://juniper.com> as well as the RFC!) focus on
>> the "second" action taken by
>> >> the RP
>> >>> after receiving the registration request! and the first (but the
>> less
>> >>> important action) is somehow ignored (or underestimated)....
>> >>>
>> >>> Here is the process (briefly):
>> >>>
>> >>> Your Windows 2003 Media server starts sending the Multicast
>> packets of
>> >> (analog
>> >>> term : broadcasting) "The Family guy". The first Mcast packets
>> hit their
>> >>> gateway and the DR of that segment tries to get a hold of the RP
>> to kick
>> >> off
>> >>> the registration process. You know the encapsulation process
>> (the actual
>> >> mcast
>> >>> content inside a unicast packet - right?) so the RP gets the first
>> >> capsule and
>> >>> "extracts" the multicast content. At this stage the RP has to
>> take two
>> >>> actions:
>> >>>
>> >>> 1- It sends the extracted Multicast packet down the tree based
>> on the
>> >> (*,G).
>> >>> Where did you get that from? my Visa client had talked to his DR
>> and his
>> >> DR to
>> >>> his upstream then to his upstream...all the way up to the RP to
>> indicate
>> >> his
>> >>> interest. So before getting the first packet (the capsule) as you
>> >> mentioned
>> >>> the RP does know that I'm waiting to watch Quagmire (there is a
>> receiver
>> >> down
>> >>> there). In fact the (*,G) is on the RP waiting for the source to
>> come up.
>> >>>
>> >>> 2- The RP then tries to join the group and now everyone knows
> what's
>> >> gonna
>> >>> happen afterwards...I save some key strokes.
>> >>>
>> >>> Well, as you see (the first action), even the first packet
>> (probably the
>> >> first
>> >>> frame of the Fox ad!) is delivered by the RP to (*,G) to ensure
>> nothing's
>> >>> going to be missed.
>> >>>
>> >>> HTH
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> Kambiz Agahian
>> >>> CCIE (R&S)
>> >>> CCSI, WAASSE, RSSSE
>> >>> Technical Instructor
>> >>> CCBOOTCAMP - Cisco Learning Solutions Partner (CLSP)
>> >>> Email: kagahian_at_ccbootcamp.com <mailto:kagahian_at_ccbootcamp.com>
>> >>> Toll Free: 877-654-2243
>> >>> International: +1-702-968-5100
>> >>> Skype: skype:ccbootcamp?call
>> >>> FAX: +1-702-446-8012
>> >>> YES! We take Cisco Learning Credits!
>> >>> Training And Remote Racks: http://www.ccbootcamp.com
>> >>> OEQ Voice Waiver: http://www.ccbootcamp.com/noeqvoice.html
>> >>> OEQ R&S Waiver: http://www.ccbootcamp.com/noeqrs.html
>> >>> OEQ Commercial: http://www.ccbootcamp.com/noeq.mpg
>> >>>
>> >>>
>> >>> -----Original Message-----
>> >>> From: nobody_at_groupstudy.com <mailto:nobody_at_groupstudy.com> on
>> behalf of Tharindu Rukshan Bamunuarachchi
>> >>> Sent: Thu 4/8/2010 10:04 PM
>> >>> To: ccielab_at_groupstudy.com <mailto:ccielab_at_groupstudy.com>
>> >>> Subject: Multicast Data
>> >>>
>> >>> hi Experts,
>> >>>
>> >>> In sparse-mode, AFAIK first packet is forwarded to RP as
>> unicast. (In
>> >>> Register Unicast process).
>> >>>
>> >>> Is there any possibility to lose first packet without being
>> delivered to
>> >>> destination. (assuming destination is already subcribed to
> multicast
>> >> tree)?
>> >>>
>> >>> __
>> >>> btharindu.blogspot.com <http://btharindu.blogspot.com>
>> >>>
>> >>>
>> >>> Blogs and organic groups at http://www.ccie.net
>> >>>
>> >>>
>> _______________________________________________________________________
>> >>> Subscription information may be found at:
>> >>> http://www.groupstudy.com/list/CCIELab.html
>> >>>
>> >>>
>> >>> Blogs and organic groups at http://www.ccie.net
>> >>>
>> >>>
>> _______________________________________________________________________
>> >>> Subscription information may be found at:
>> >>> http://www.groupstudy.com/list/CCIELab.html
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >> --
>> >> Carlos G Mendioroz <tron_at_huapi.ba.ar <mailto:tron_at_huapi.ba.ar>>
>> LW7 EQI Argentina
>> >
>> >
>> > Blogs and organic groups at http://www.ccie.net
>> >
>> >
>> _______________________________________________________________________
>> > Subscription information may be found at:
>> > http://www.groupstudy.com/list/CCIELab.html
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>>
>> --
>> Carlos G Mendioroz <tron_at_huapi.ba.ar <mailto:tron_at_huapi.ba.ar>>
>> LW7 EQI Argentina
>>
>>
>
> --
> Carlos G Mendioroz <tron_at_huapi.ba.ar> LW7 EQI Argentina
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
>
>
>
>
>

-- 
Carlos G Mendioroz  <tron_at_huapi.ba.ar>  LW7 EQI  Argentina
Blogs and organic groups at http://www.ccie.net