[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SSM, RTCP, SAP
Dear Lorenzo;
Julian's draft covers this :
draft-chesterfield-avt-rtcpssm-00.txt - and I think it has merit if you want to run
many to many type services using SSM.
I will append at the bottom what I wrote to the rem-conf list about my
thoughts about SSM RTCP for very large groups. I apologize for the
redundancy - this is really a AVT issue.
Lorenzo Vicisano wrote:
>
> 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).
>
IMHO this should not be a new protocol - it could easily be handled at the application layer.
Running these relay's sounds like a commercial matter to me. I would NOT add any router
type support for this.
Marshall
> 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
> >
---------
Subject:
Re: RTT estimation for multicast
Date:
Mon, 16 Apr 2001 12:27:07 -0400
Let's get specific. We are multicasting 3 x 38 samples (packets) per second at our high
data rate. For now we are using standard RTCP RR's. For licensing and advertising purposes it is
essential that any receiver report interval be kept to about 100 seconds
or less. (You might push that by a factor of 2, maybe, but
this will really start to impact on the business utility of these reports.
100 seconds seems a good upper bound on this.)
Our receiver reports include reports on at most 3 separate substreams, so
they are in length
IP (4 x 32 bits) + UDP (2 x 32 bits) + RR header (2 x 32 bits) + 3 x (6 x 32 bits) =
26 x 32 bits = 832 bits or 104 bytes.
If we assume a minimum reporting rate of 0.01 Hz (i.e., one per 100 seconds) then
Audience Size | Minimum Bit Rate Returned
1000 8 kbps
10,000 80 kbps
100,000 800 kbps
1,000,000 8 mbps
Now, the receiver report RTCP packet basically only
includes low order information about packet loss and jitter. (And jitter is frequently trashed anyway.)
If we were sending packets to Mars over a deep space link, this would be sufficient to
tell us everything we might want to know about packet losses. We're not, and
recently certain non-random packet loss patterns (see
http://www.multicasttech.com/rr/u_oregon.12_apr.gif for an example )
have convinced me that
more information needs to be supplied. As we discussed briefly when you came over
to our offices, one way of doing this would be to send a bit pattern for every packet that should
have been received during the RR interval.
Suppose, for example, that you are sending 38 packets per second, and the RR interval is 100 seconds.
Then the RR will cover 3800 packets (and will completely obscure the pattern shown in u_oregon.12_apr.gif).
You could then send 3800 bits (or a little fewer, as packets that should have
arrived after the last packet that did arrive will of necessity be missed), in the form
11110111110111111111011111000000000001 etc., where 1 means the packet was received, 0 means it wasn't (this represents
one second of traffic, btw.)
If you send this naively, as such a bit pattern, then the RR packet will be ~ 832 bits + (3 x 3800 bits) = 12,232 bits or
1529 bytes.
Now the minimum returned bit rate becomes
Audience Size | Minimum Bit Rate Returned
1000 120 kbps
10,000 1.2 mbps
100,000 12 mbps
1,000,000 122 mbps
This is a real hit, and suggests that more thought should be given to this area - maybe the loss bit
patterns could be compressed. either losslessly or lossily, say by applying a Walsh transform and only
sending a certain number of coefficients in order of size, or by sending the location of the largest
continuous block of dropped packet, by using runs of zeros and ones or by some other means. (A different
means would be to have the source inform the sender in the stream that the RR report rate should be changed.)
In any case, for an audience size of 100,000, the RTCP RR bit rate will be _at least_ order 1 megabit per second.
Now, for a broadcaster receiving SSM receiver reports, that's OK. Anyone with that size audience can afford
that much bandwidth. If we then set up a SSM group sending out 1 mbps of receiver reports, who would
want to receive it ? Who would want to get that much bandwidth ? My guess is, no actual receivers, and
very few monitoring groups.
My assumption is that both from the broadcasters end and the monitoring groups end, some aggregation (compression)
would be desired. The one that came to our minds was to average loss on a per AS basis, as receivers tend
to be (so far) highly clustered in terms of ASNs.
I think that you will find strong resistance on the part of broadcasters to sharing all information (including IP
addresses) for
all receivers at all time to everyone. This information is simply too valuable to assume that this will fly. (Seen any
RR from Real Networks lately ?)
I do not think that these kind of aggregated RR information (and the current RTCP RR's
represent one particular kind of aggregation) will serve to diagnose ALL network problems. That
is just not realistic. The goal should be to set up sufficient information sharing to serve as an early warning of
most problems, hopefully able to diagnose at least some, and to get this established as a BCP.
I think that it will be difficult enough to keep multicasting flowing smoothly that there is a chance
of establishing this as a principle. Otherwise I can guarantee you that such information will be treated as
proprietary and not revealed at all.
Regards
Marshall
Multicast Technologies, Inc.
10301 Democracy Lane, Suite 410
Fairfax, Virginia 22030
Phone : 703-293-9624 Fax : 703-293-9609
e-mail : tme@on-the-i.com http://www.on-the-i.com
Test your network for multicast : http://www.multicasttech.com/mt/