Subject: Re: SDP "category" or "thread" field

From: [email-masked] (Ross Finlayson)
Date: Wed, 3 May 1995 14:14:04 -0700

I think we're getting a bit ahead of ourselves here.  Assuming that we want
a "category" field in SDP (and I'm not yet completely convinced that we do),
then any policies about how it might be structured are really higher-level
(presentation layer) issues that could be defined separately, not as part of
SDP.  Also, I think it would be unwise to try to enforce a particular
structure on such a field until we've had some experience with how it might
used.  As far as SDP is concerned, the "category" field, if it exists, could
be defined just as an string, or perhaps a list of strings (in anticipation
of the equivalent of crossposting).

There's also a more fundamental network protocol issue that we need to get a
grip on first.  The need to limit the bandwidth taken up by session
announcements imposes a practical limit on the number of announcements that
can be posted to a single session directory multicast group (within any
particular scope).   If the number of different announcements within a
single group/scope grows too large, then the average time interval between
repetitions of the same announcement will become excessive - it will take
too long for a newly-started client to find out about a fresh announcement,
or for clients to recover from lost packets in general.  The bandwidth
limits mentioned in Mark's recent SDP draft seem a bit low to me, but even
if they were bumped up a bit, it's hard to forsee how any single session
directory group could practically support anything remotely close to, say,
100 different announcements at large TTLs.  So I don't see much point
spending too much energy speculating about large numbers of announcements
with elaborate hierarchically-structured category fields.

Although multiple directory groups seem like the only way to scale SDP to
large numbers of announcements, I can see why it might make sense to impose
some sort of structure on the announcements that are present in a single
directory.  (E.g., it would be nice if a SDP client could recognize all of
the "IMS" announcements in the current "sd" directory as being part of a
collection; ditto for the "IETF" sessions, when they occur.)  So I suppose
that an optional "category" field might make sense.  But as I noted earlier,
it seems premature to try to impose any structure on such a field until we
have some experience with its use.

	Ross.

---

From: Mark Handley <[email-masked]>
Date: Thu, 04 May 95 12:01:11 +0100

>of the equivalent of crossposting).

I'm not completely convinced about category fields either, which is
why I raised it on the list.  However, having another text field with
free format may not add too much to the existing free format fields.

If we do have such a field, and define it as a list of strings, then I
would suggest that this is then a set of keywords to all intents and
purposes.

Either way, such a field is of little use to application writers
unless it has some definition as to the meaning of its contents.
You might as well attempt to parse the session name and information.

>or for clients to recover from lost packets in general.  

But you're assuming exactly sd's distribution model.  There's lots of
things that can be done to improve on sd's model (for example client
proxy caching).  It's also possible that sd's model will simply be
replaced - Van has suggested a client-server model which may be
adopted some time in the future.

I think it's important to distinguish between SDP - for describing
sessions - and the session directory announcement protocol (SDAP?).
We may replace SDAP, but still want to retain SDP.  Thus SDP should be
"complete" without taking the distribution model into account to gain
extra semantic information.  Hence the discuss about categorisation.

>The bandwidth

The current figures may be too low.  It's easier to increase them
later than to reduce them!

Currently for 100 typical announcements with short text descriptions
(ie 200 bytes per announcement) at ttl 127, you get 1.8 announcements
per session per hour.  With client proxy caching for fast startup,
this is sufficient for most pre-announced sessions.  If you allow more
b/w when a session is created and when it is about to become active,
then this improves further.

Many more sessions are likely to be at lower ttl's.

Thus I reckon the current model scales beyond the limits of the
current Mbone and certainly beyond the limits of a UI to present the
data properly.

>directory.  

Multiple session groups will be necessary, but I reckon they'll come
through hierarchical multicast and administrative scoping, not through
arbitrary choices of session directories.  Thus they don't affect
whether or not a category field is necessary.

>(E.g., it would be nice if a SDP client could recognize all of

The IETF sessions are a bad example.  IETF Channel 1 audio, IETF
Channel 1 GSM Audio, IETF Channel 1 Video and IETF Channel 1
Whiteboard should all be one announcement, albeit with multiple
multicast addresses and multiple ttls.  SPDv2 as it's written at the
moment allows this.  It's up to the client to allow the user to start
up only a subset of the media.

The IMS sessions are a better example.  That's the sort of grouping
I'd like to see, but don't believe we can do properly with the
existing spec.

Mark