Re: SSM, RTCP, SAP

[Julian Chesterfield <julian@research.att.com>]

I submitted a draft to the AVT group to specify a unicast mechanism for RTCP RRs
back to the sender. Originally this was intended just for SSM, but discussions in
Minneapolis indicated there is interest for a more generic unicast feedback.
Currently, the intention is to specify the method indicated by Lorenzo, although
a summarised reporting method in addition is being considered to cut down on some
of the information for large scale groups.

The original draft is 'draft-chesterfield-avt-rtcpssm-00.txt'. Comments from the
meeting have yet to be included in a new release.

Thanks,

Julian Chesterfield

> For RTCP, the idea floating around was to unicast the RRs back to
> the source and having the source echoing them back in the multicast
> session (either the report themselves or some digested summary of them).
> I don't know if this was ever specified 'though.
>
> I don't know of anything similar for SAP, but I don't think we should
> re-invent an ad-hoc routing protocol just for this. We should either
> use the existing ASM multicast service, if present, or SSM + application
> modifications (e.g. a set of relays that accept unicast SAP messages and
> remulticast them. Relays will have all to listen to each other
> announcements .. ect.. there are scalability concerns but seems feasible).
>
>         Lorenzo
>
> > What's the current thinking about handling RTP apps with
> > SSM; RTP apps are intrinsically multi-sender (==> Receiver Reports)?
> >
> > Similarly, what about (global) SAP?
> >
> > Given that SAP comes under the category of "bootstrap" (I guess), wouldn't
> > it be an idea to RPF flood SAP (minus the prune), and not incur any state
> > for that flood? Such a flood would result in SAP announcements flowing
> > over redundant paths, but a) they're infrequent, b) all SDRs want them
> > within the flood (mcast) scope, c) they're bootstrap so they fit within
> > a flood model.
> >
> > So, how to prevent (s,g) state for SAPs? Define a ToS bit pattern that tells
> > routers not to create fwd state for this packet??
> >
> > I'm not suggesting doing the same for RTCP RRs, since they don't
> > fall under bootstrap, and require sender/member-constrained distribution.
> >
> > thoughts?
> >
> > Tony
> >