Subject: RE: Progressing IDMR items

From: Arlie Davis <[email-masked]>
Date: Wed, 26 Feb 1997 15:14:47 -0500

RTCP puts a much greater strain than is necessary on (S,G)-state
implementations.  This is rather unfortunate.

Ideally, multicast technology scales with the number of transmitters;
the number of receivers should not matter.  RTCP + (S,G)-state breaks
this, because of the frequency of low-bandwidth (and largely low
interest) packets that come from every receiver.  It's even more ironic
that RTCP adjusts the advertise frequency; the more receivers, the
shorter the advertise frequency, and the higher the ratio of the cost of
each (S,G) entry to the bandwidth that uses the (S,G) state.

Imagine 5 million people watching a single multicast of the NFL Super
Bowl.  Instead of N routers maintaining state for a single (S,G) pair,
they have to maintain 5,000,001 (S,G) pairs, _no matter how infrequently
the receivers advertise_.  Aggravating, isn't it?

Also, truly, RTCP data isn't always that interesting.  Do I really care
that much who is listening to the same radio broadcast?  If it's a
conference, yes.  If it's a broadcast, usually no.  Do we really want to
burden precious router resources with (S,G) state that is of dubious
value?

I represent an ISP that wants to deploy multicast as a feature within
our networks and to our customers.  If the cost of (S,G) state was
related to the number of truly interesting multicast sources (conference
participant, broadcast source), then I would definitely support it.  If
(S,G) continues to be wasted, then I'll have to seek a different routing
method.

-- arlie

>-----Original Message-----
>From:	Petri Helenius [SMTP:[email-masked]]
>Sent:	Wednesday, February 26, 1997 12:42 PM
>To:	Tony Ballardie
>Cc:	[email-masked]
>Subject:	Re: Progressing IDMR items
>
>Tony Ballardie writes:
> > 
> > where we have reached consensus is that flood & prune is
> > not acceptable in the wide-area. The issue of whether (S,G)
> > state is acceptable seems to be implied by the fact that PIM 
> > still exists as a inter-domain candidate. 
> > 
> > How do ISPs feel about carrying (S,G)? I suppose the answer 
> > depends on how effectively S can be aggregated. 
> > There are also differing opinions as to whether shared trees 
> > are satisfactory over the wide area - if SPTs are considered 
> > absolutely necessary, then ISPs have no choice but to carry (S,G).
> > 
>I think carrying the S,G state is not the problem since memory is
>cheap and will get cheaper (and someday even Cisco will notice that
>:-). It's the cost of maintaining and expiring that state.
>(which can be done in clever hardware too, but I don't know of anybody
> doing it)
>
>Pete

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 26 Feb 1997 15:26:02 -0800

>> the receivers advertise_.  Aggravating, isn't it?

    One would also argue that the RTCP backoff as the group gets larger is
    more of a detriment to routers, since the (S,G) timeout will occur
    more frequently than the RTCP transmission interval. Therefore, in a
    dense-mode router, there is a malloc() for every transmission of the
    5,000,001 sources to create (S,G) state. This can't be good in any
    router both from a memory fragmentation point of view and a switching
    point of view.

>> burden precious router resources with (S,G) state that is of dubious

    This is why SPT thresholds were created in PIM. If you set the SPT
    threshold in a cisco to say 8kbps, only the active "speakers" get an
    (S,G), everyone else uses the (*,G).

    My router has this much state for the Mbone Audio group where I see
    ~20 participants in my vat window.

dino-cisco-fr>sh ip mr 224.2.0.1 sum
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned
       R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT
Timers: Uptime/Expires
Interface state: Interface, Next-Hop, State/Mode

(*, 224.2.0.1), 5d05h/00:02:54, RP 171.69.10.13, flags: SCF
  (171.69.112.115/32, 224.2.0.1), 00:16:21/00:02:51, flags: CFT
  (171.69.129.220/32, 224.2.0.1), 5d05h/00:02:56, flags: CT

Dino

---

From: Stephen Casner <[email-masked]>
Date: Wed, 26 Feb 1997 15:29:40 -0800 ()

Arlie,

> implementations.  This is rather unfortunate.

Both on the rem-conf list and in the last AVT meeting, we have had
significant discussion of the use of RTCP in large broadcast
scenarios.  I'll attempt to move this discussion back there [bcc to
mbone].

> the receivers advertise_.  Aggravating, isn't it?

With a shared-tree routing protocol, there is only (*,G) state for the
receivers because the RTCP data rate is low enough not to trigger the
formation of a source-rooted tree.

> conference, yes.  If it's a broadcast, usually no.

At the AVT meeting, we concluded that there should be additional RTP
profiles specifying alternative RTCP behavior.  It is likely that one
of those would specify that receivers would not send RTCP at all, for
use in scenarios where privacy of reception or other factors outweigh
the value of RTCP's reception feedback.

BTW, at the AVT meeting I invited the submission of proposals for
additional profiles, but I don't think any such proposals have been
submitted yet.  (Not to neglect Bernard Aboba's I-D on the issues and
the useful email on this topic.)
							-- Steve