Subject: FYI: Experimental "directory" sessions currently being announced

From: Ross Finlayson <[email-masked]>
Date: Tue, 08 Sep 1998 16:54:09

At the MMUSIC session at the Washington DC IETF (and earlier, at the March
1996 Los Angeles IETF) I described how SDP can readily be used to announce
sessions that are themselves directories, by using a new SDP "directory"
media type - i.e. m=directory <port#> SAP SDP

As an experiment, I have begun announcing three such directory sessions:
"Test Sessions", "Lectures and Conferences", and "Music".  (I have also
begun populating the latter two directories by reannouncing some relevant
session announcements from the main SDP directory.)

To be able to launch these directory session announcements, your SDP/SAP
browser must support the "directory" media type.  At present the only
browser I know of that does this is multikit -
<http://www.live.com/multikit/> - but other browsers, such as "sdr", might
also be able to do so using a 'plug in'.  (For this to work, the browser
would need the ability to open a new directory window that uses a distinct
multicast group/port - perhaps by launching a separate instance of the
application.  I don't know whether or not "sdr" supports this...)

Feel free to experiment with announcing sessions to these directories,
and/or making new directory announcements.

Sometime soon I'll be putting together an RFC describing this new SDP media
type.

During the discussion of directory sessions in the Washington DC IETF, a
couple of issues were raised.  The first issue (raised by Dave Singer, I
believe) was a legitimate concern about the ephemeral nature of directory
announcements (as opposed to the 'hard-wired' default directory).  If you
choose to make an announcement into such a directory, you're not going to
be happy if the directory itself should suddenly stop being announced
(e.g., because the host that created the directory announcement happens to
go down).

Fortunately this problem has a straightforward solution:  If you make an
announcement A into a directory D1 that you know is also being announced as
a session in another directory D2, then in addition to announcing A in D1,
you can also participate in announcing D1 in D2.  This way, you'll be
assured that not only will your announcement A remain visible, but also
that the directory into which it's being announced will remain visible.

The second issue raised in Washington DC was a more general concern that
some people had about the possibility of the default SDP directory (&
perhaps other directories) becoming cluttered with frivilous directory
announcements.  (For instance, someone made the analogy to the rash of
silly alt.* newsgroups.)  This is something that we should keep an eye on,
although for now at least, it doesn't seem likely to be a problem.
(Unfortunately, SDP/SAP appears to be far from becoming a 'success
disaster' :-(  In the future, however, as SDP/SAP becomes just one facet of
a more general multicast data architecture, we may wish to consider
allowing a directory to impose some sort of access control (e.g., using
digital signatures) over what gets announced into it.

	Ross.

---

From: Mark Handley <[email-masked]>
Date: Tue, 08 Sep 1998 20:15:42 -0400

>...I don't know whether or not "sdr" supports this...)

You can't do this with just a plugin, but the change is pretty trivial
for sdr to support it.  I haven't done it for the reason below...

>The second issue raised in Washington DC...

Actually neither of these issues was the main objection raised in DC.
The biggest problem is to do with joining a directory and expecting to
see all the sessions associated with that directory immediately.  You
simply wont - you'll have to wait a number of minutes to see the
sessions in the new directory.

The only way to avoid this is to make use of local caches which update
you when you join the new directory, but then you end up drawing all
the traffic to your site all the time just to keep the caches
populated in case you might want to join.  Thus there's little
difference in bandwidth over just sending all the sessions to the main
SAP group.

As it is, I'd rather see tools making use of the category attribute on
a single group until we start to have a success disaster and need to
reengineer the protocols.  Even making better use of the type
attribute which lets sdr filter out all the unwanted "Test" sessions
would be a big help right now.

Cheers,
	Mark

---

From: Ross Finlayson <[email-masked]>
Date: Tue, 08 Sep 1998 20:58:23

>sessions in the new directory.

No, this is actually a red herring, because it applies to *any* SAP
directory, including the default directory.  People see the same thing when
they start their SDP/SAP browsers ("sdr" or whatever) for the first time.

Because the protocol (SAP) that these directories use doesn't provide
'instant gratification', then one could argue that a browser's user
interface should indicate this in some way - e.g., with a banner saying
something like "waiting for announcements" before the first one arrives.

But this really isn't that big a deal.  And it certainly wasn't one of the
major issues that arose when we discussed directory announcements in the DC
IETF.

	Ross.

---

From: Colin Perkins <[email-masked]>
Date: Wed, 09 Sep 1998 10:11:52 +0100

>they start their SDP/SAP browsers ("sdr" or whatever) for the first time.

It makes the problem worse, since I can't start listening for announcements
in the sub-directory until I've seen the sub-directory being announced. I'd
say it's probably not a big deal, since any domain which cares about the
startup latency will have a local proxy cache anyway... 

Colin

---

From: Mark Handley <[email-masked]>
Date: Wed, 09 Sep 1998 10:05:16 -0400

>they start their SDP/SAP browsers ("sdr" or whatever) for the first time.

SAP was always intended to be run by tools that run continuously or
get an update from a local cache on startup.  Either you leave your
sdr running, or you implement local caching servers.  We discussed a
protocol for talking to local caches several times in MMUSIC (eg
ftp://ftp.isi.edu/confctrl/minutes/slides.12.95.Z in sdap.12.95.ps
and ftp://ftp.isi.edu/confctrl/minutes/slides.3.96.tar.Z in sdap.3.96.ps).
Caches were always intended to be part of the architecture but there
were always higher priority tasks and no great community pressure to
do the local-area part.  I even wrote such a caching server and
protocol for sdr at one stage, but never quite found the time to
finish it properly :-(

The problem is that multiple groups and local caching servers are at
odds with each other.  How does a caching server know which groups to
cache in advance of your joining that directory?  The temptation will
be to cache all directories, and that's directly equivalent to using a
single group.

Mark

---

From: Rob Lanphier <[email-masked]>
Date: Wed, 09 Sep 1998 09:34:58 -0700

>protocol for sdr at one stage, but never quite found the time to

One could actually just have a web-based directory as the "cache", and then
there's no longer any need for a special protocol.  Alternatively, some
sort of mailbox-like file format would also do the trick in a pretty
straightforward fashion.

>be to cache all directories, and that's directly equivalent to using a

Hmmm, not necessarily.  I see this as being analogous to Usenet.
Certainly, many sites will want to get all of the directories, but there
may be sites out there that don't.  Furthermore, you get a certain amount
of organization by having different channels, assuming people are good
about organizing themselves (a tricky assumption, but the Usenet does o.k.
at this).

Rob