Subject: Status of SAP - particularly compression + authentication

From: Bill Fenner <[email-masked]>
Date: Fri, 16 Apr 1999 11:01:17 -0700

Is there anyone working on the SAP specification?  I have two issues
that are not addressed by the November 1996 draft-ietf-mmusic-sap-00.ps,
which is the most recent specification for SAPv1 that I know of.

1) Compression algorithm.  The spec says to use the gzip format
(RFC 1952).  The gzip format is simply a wrapper for the DEFLATE
algorithm (RFC 1951), and contains a fairly large header with
data that's not useful in the context of SAP.  The zlib format
(RFC 1950) is another wrapper around the DEFLATE algorithm which
has the following advantages:
- Smaller header
- Easier to implement (there's a reference zlib implementation)

In addition, the only program that creates compressed SAP that I know
of (Real's G2 server) sends zlib format.

Does anyone have any objection to changing the specification to use
zlib format instead of gzip format?

2) Compression + authentication order.  The spec does not explicitly
say in what order compression and authentication should be performed.
Since authentication information can be large, it makes sense to
me to allow it to be part of the compressed payload, but it's
possible that implementations could choose a different order.

Does anyone have any objections to specifying that the order of
operations for transmission is authenticate, compress, encrypt,
and the order for reception is decrypt, uncompress, authenticate?

On the larger issue of the SAP spec itself, is it appropriate to
try to make these changes in the 2.5 year old SAPv1 spec and
maybe advance it, or should we incorporate all of the missing
info into the SAPv2 spec and focus efforts there?

Thanks,
  Bill

---

From: Peter KIRSTEIN <[email-masked]>
Date: Sun, 18 Apr 1999 13:10:19 +0200

>which is the most recent specification for SAPv1 that I know of.

I think that we are responsible, and I will ask Colin to look at this.

Peter
>info into the SAPv2 spec and focus efforts there?

Peter

X*********************************************************************X
* Prof Peter Kirstein		   Telephone:  +44 171 380 7286	
* Department of Computer Science   Fax:        +44 171 387 1397
* University College London        Telex:      28722
* Gower Street                     Internet:   [email-masked]
* London 
* WC1E 6BT                      
* U.K			URL    : http://www.cs.ucl.ac.uk/staff/kirstein
X*********************************************************************X

---

From: Colin Perkins <[email-masked]>
Date: Sun, 18 Apr 1999 16:10:49 +0100

>which is the most recent specification for SAPv1 that I know of.

I volunteered to act as editor at the last IETF, and hope to get a revised
draft out before the next meeting.

>zlib format instead of gzip format?

Seems sensible to me...

>and the order for reception is decrypt, uncompress, authenticate?

Again, seems okay.

>info into the SAPv2 spec and focus efforts there?

I was aiming for a merger of the two documents, since the v2 spec is
backwards compatible anyway.

Cheers,
Colin

---

From: Ross Finlayson <[email-masked]>
Date: Sun, 18 Apr 1999 16:21:30

>draft out before the next meeting.

-----
Colin (cc. "confctrl"),

As you're updating the SAP spec, please note also some comments/suggestions
of my own.  (I first posted this around the end of February, but thought
I'd repeat this, in case it fell through the cracks.)

	Ross.

------- my earlier msg ------------
I'm not sure what the status of the SAP spec is these days, or who's
working on it, but from reading the version at
<ftp://ftp.isi.edu/confctrl/docs/draft-ietf-mmusic-sap-00.txt> - the only
version I could find - I noticed some unclear wording that should be fixed
before the spec advances further.

The issue concerns the method that a SAP announcer uses to compute the
delay between successive announcements for an advertisement.

The spec curretly says:

"The time period between one announcement and its repetition is dependent
on two factors - the scope (TTL) of the session, and the number of other
sessions currently being announced by other session directory instances."

[This is OK]

Then later,

"Session announcers in the same scope band can normally  be  expected  to
hear  your announcements, and reduce their data rates accordingly.  Thus
you should calculate the available bandwidth for  your  session's  scope
band  by  dividing  the  appropriate  limit above by the number of other
                                                                   ^^^^^
announcers in your scope band.  This gives you  your  bandwidth  alloca-
^^^^^^^^^^
tion,  which, given the size of your data packets, can be used to derive
the base interval for announcements."

The problem is the phrase "other announcers".  Instead, it should be
"different advertisements (including your own)".  Note that the formula
following this:

         interval =MAX(300, (8*no_of_ads*ad_size)/limit)

is correct, because it uses a variable named "no_of_ads".  It would be
clearer, however, if the formula referred directly to the "available
bandwidth" (say, B) that was defined above; this would make the formula:

         interval =MAX(300, (8**ad_size)/B)

A second, related issue that needs to be clarified in the spec concerns how
to handle the case where the same announcement is being advertised by more
than one party.  This can be useful, for instance, if the advertisement is
for a multi-source session, where the sources are distributed, and you want
to increase the likelihood of everyone seeing the announcement.  (In this
case, each source might wish to participate in the advertising of the
session.)

To address this case, the spec should make it clear that the available
bandwidth for announcing this session is shared by all of its announcers -
not allocated to each announcer individually.  So, with this in mind, the
available bandwidth *per announcer* - to be used for calculating the delay
interval - should be defined as:

    limit
B = -----------------------------------------------------------------------
    (# of different advertisements)*(# of announcers for our advertisement)

	Ross.