Re: Status of SAP

Ross Finlayson <finlayson@live.com> Mon, 19 April 1999 00:37 UTC

Return-Path: <owner-confctrl>
Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id RAA07773 for confctrl-outgoing; Sun, 18 Apr 1999 17:37:13 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id RAA07768 for <confctrl@zephyr.isi.edu>; Sun, 18 Apr 1999 17:37:12 -0700 (PDT)
Received: from proxy3.ba.best.com (root@proxy3.ba.best.com [206.184.139.14]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id RAA05793 for <confctrl@ISI.EDU>; Sun, 18 Apr 1999 17:37:11 -0700 (PDT)
Received: from mg134-203.ricochet.net (mg134-203.ricochet.net [204.179.134.203]) by proxy3.ba.best.com (8.9.3/8.9.2/best.out) with SMTP id RAA17063; Sun, 18 Apr 1999 17:35:35 -0700 (PDT)
Message-Id: <3.0.5.16.19990418162130.0bef633e@shell7.ba.best.com>
X-Sender: rsf@shell7.ba.best.com
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (16)
Date: Sun, 18 Apr 1999 16:21:30 -0000
To: Colin Perkins <C.Perkins@cs.ucl.ac.uk>
From: Ross Finlayson <finlayson@live.com>
Subject: Re: Status of SAP
Cc: confctrl@ISI.EDU
In-Reply-To: <1322.924448249@cs.ucl.ac.uk>
References: <Your message of "Fri, 16 Apr 1999 11:01:17 PDT." <199904161801.OAA12810@windsor.research.att.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

At 04:10 PM 4/18/99 +0100, Colin Perkins wrote:
>I volunteered to act as editor at the last IETF, and hope to get a revised
>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.