Subject: SSM, RTCP, SAP

From: "Tony Ballardie" <[email-masked]>
Date: Thu, 19 Apr 2001 21:36:28 +0100

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

---

From: Lorenzo Vicisano <[email-masked]>
Date: Thu, 19 Apr 2001 13:59:27 -0700

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

---

From: Julian Chesterfield <[email-masked]>
Date: Thu, 19 Apr 2001 15:08:30 -0700

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

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 19 Apr 2001 18:31:35 -0400

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.

> 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

> > fall under bootstrap, and require sender/member-constrained distribution.
---------
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 : [email-masked]     http://www.on-the-i.com         

 Test your network for multicast : http://www.multicasttech.com/mt/

---

From: Lorenzo Vicisano <[email-masked]>
Date: Thu, 19 Apr 2001 15:48:31 -0700

Marshall,

> Running these relay's sounds like a commercial matter to me. I would NOT add 

I had in mind an application-level solution too, no router support:
the router support is ASM, where available.

	Lorenzo

---

From: Bill Nickless <[email-masked]>
Date: Thu, 19 Apr 2001 18:49:17 -0500

>Similarly, what about (global) SAP?

SAP was developed before the web.  I believe the web makes SAP obsolete, so 
we shouldn't worry about supporting it as a special case.

===
Bill Nickless    http://www.mcs.anl.gov/people/nickless      +1 630 252 7390
PGP:0E 0F 16 80 C5 B1 69 52 E1 44 1A A5 0E 1B 74 F7     [email-masked]

---

From: Mark Handley <[email-masked]>
Date: Thu, 19 Apr 2001 17:22:33 -0700

>we shouldn't worry about supporting it as a special case.

I don't think SAP is completely obsolete, but I also don't think it's
very useful for global groups.  SAP is best used for admin-scoped
multicast groups, where you want the people who can receive the
session to be the only people who receive the announcement.  The web
can't easily satisfy this requirement.

Admin-scoping doesn't apply for SSM, and I don't think SAP is relevant
for SSM either. For SSM groups, using RTSP/SDP or HTTP/SDP makes much
more sense.

 - Mark

---

From: Hugh LaMaster <[email-masked]>
Date: Thu, 19 Apr 2001 17:33:45 -0700 (PDT)

> announcements .. ect.. there are scalability concerns but seems feasible).

I see no reason not to use ASM-based SAP for announcements, but,
the canonical announcement mechanism for SSM would be the web,
would it not?

--
 Hugh LaMaster, M/S 233-21,    Email: [email-masked]
 NASA Ames Research Center     Or:    [email-masked]
 Moffett Field, CA 94035-1000  Or:    [email-masked]
 Phone: 650/604-1056           Disc:  Unofficial, personal *opinion*.

---

From: Gregory Shepherd <[email-masked]>
Date: Thu, 19 Apr 2001 19:44:59 -0700 (PDT)

> can't easily satisfy this requirement.

http is not only used for globally available content. An enterprise's
intranet could just as easily advertise internal sessions as it does
internal static content.
 
> for SSM either. For SSM groups, using RTSP/SDP or HTTP/SDP makes much

True, there is no assigned SSM scoped range, but if/when IGMPv3 is
ubiquitous on the enterprise desktop, then coorporate 'talking head'
sessions could be best served by the mechanisms of SSM BUT in the admin
scoped range. This would only require the network administer to extend the
SSM defined range for the enterprise to include all or a portion of the
admin scoped range. Both JunOS and IOS provide for the default SSM range
(232/8) and any config'd extensions to that range. No SAP required.

Greg

---

From: Jon Crowcroft <[email-masked]>
Date: Fri, 20 Apr 2001 08:47:10 +0100

what about a GRA solution?

In message <[email-masked]>, Lorenzo Vicisano ty

 >>the router support is ASM, where available.

 cheers

   jon

---

From: Marshall Eubanks <[email-masked]>
Date: Fri, 20 Apr 2001 05:56:18 -0400

Dear Jon;

   What did you have in mind ?

         Marshall

--

---

From: Marshall Eubanks <[email-masked]>
Date: Fri, 20 Apr 2001 06:12:16 -0400

Dear Jon;

Jon Crowcroft wrote:
> 
> well, depends what GRA support is there, but one possibility for
> RTCP reports from receivers on an SSM tree is to design a new RTCP
> report (with GRA router alert) that is self describing w.r.t
> summarising responses routers (like PGM nack aggregation) reporting
> a summarised loss bitmap, a highest and lowest loss rate, and so
> forth...
> 

I could see where that might make a lot of sense in a TRACK
type RMT. Interesting.

Marshall

> In message <[email-masked]>, Marshall Eubanks typed:
> 
>  >>Dear Jon;
>  >>

---

From: Jon Crowcroft <[email-masked]>
Date: Fri, 20 Apr 2001 11:02:26 +0100

cheers

   jon

---

From: Colin Perkins <[email-masked]>
Date: Thu, 19 Apr 2001 17:07:35 -0400

>I don't know if this was ever specified 'though.

There was some discussion of this in AVT at the last IETF - see
draft-chesterfield-avt-rtcpssm-00.txt

Colin