Subject: Additional comments on the SDP draft

From: [email-masked] (Ross Finlayson)
Date: Fri, 21 Apr 1995 16:49:43 -0700

Mark Handley et al,

Thanks for writing up the description of the SD protocol (& a proposal for
SDPv2).  Here some additional comments on the SDP draft.  In part these
expand upon the comments that I made (via the MBone) at the Danvers IETF.
(I apologise for taking so long to write this up.)

Subdirectories
==============
The one new feature in particular that I proposed at Danvers is
"subdirectories".  A subdirectory would use the same protocol (SDP) that the
root SD namespace uses, but would use a different group address/port.  Like
any other announcement, a subdirectory announcement would also have some
specified TTL.  We can support subdirectories simply by defining a new media
type "directory".

The major benefit of subdirectories is that they let us overcome the problem
of trying to maintain a single flat directory.  As the use of the MBone
continues to grow, the "single flat directory" approach will become
increasingly unworkable.  If the directory grows too large, we'll find that
the time period between repetitions of the same announcement will become
excessive.  Plus of course, the list of announcements in the UI will become
unwieldy.  This is already becoming a problem, especially during events such
as the IETF or WWW conferences, when we find "sd" being polluted by a
bazillion very similar, but disjoint, events - e.g., "WWW track 1 audio",
"WWW track 2 video" etc.  Instead, it would be better to be able to specify
a single "WWW" *subdirectory* in the sd root directory, and have the
individual events announced in this subdirectory.  Similarly, the cisco
folks could use a single subdirectory for their various test sessions.

Note also that any announcements that are made in a subdirectory will be
sent only to the subdirectory's group, not to the root sd group.  This is a
performance win, because typically only a subset of the nodes that have
subscribed to the sd root will also have chosen to join the subdirectory's
group (by 'opening' the subdirectory).

Like nested directories/folders in traditional file systems, subdirectories
will give individual users and/or workgroups - even within the same scope
(i.e., ttl) - more control over how they organize their namespace of
multicast sessions.  My major motivation for wanting to see this feature in
SDP is that lately I've been developing an experimental new multicast
session browser here at Sun.  (I'm hoping to someday make this
publicly-available outside Sun as well - although I can't make any promises
just yet.)  This system will (among other things) support subdirectories
(plus the ability for users to easily share announcements by copying and/or
moving them
between directories).  It is, of course, backwards-compatible with the
current SDP (in particular, we are using it right now as a replacement for
"sd"), and it would be ideal if many of its additional features (such as
subdirectories) end up being supported in SDP as well.

Some additional comments on the SDP draft:

1/ The protocol description is imprecise
========================================
(The authors would probably plead guilty to this.)  The protocol description
in the paper has an "ad hoc" feel to it, and there a number of things that
are unclear.  There really needs to be a more formal grammar.  Henning S.
(in his earlier messages) has already raised some questions about
whitespace, printable characters and "free format strings". Here some
additional questions that came to mind as I was reading the paper:
- Can there be more than one session description in a text payload?
  E.g., can I have:
	s=...
	etc.
	m=...
	s=...
	etc.
	m=...
  ?  The last paragraph on page 4 seems to suggest that this would be OK,
  but it's unclear.
- Does a "c=" in the media description portion apply just to that media, or
  would it also apply to any following media that don't have their own
  "c="?  E.g., in the following example:
	s=...
	...
	c=<connection0>
	m=<media1>
	c=<connection1>
	m=<media2>
	m=<media3>
	c=<connection3>
  what connection info is used for <media2>?  I presume it's the 'global'
  connection info <connection0> and not <connection1>, but it's not
  completely clear, and one could make a case either way.
- If each media description defines its own "c=", then does one also need to
  include a 'global' "c="?  If so, then does the latter have any meaning?
  (Presumably not)
- Similarly, if each media description defines its own "k=", then does a 
  'global' "k=", if present, have any meaning?

2/ There should be guidelines for how to choose multicast addresses
===================================================================
(Other people have mentioned this also.)  This is a general issue that
applies to all potential uses of multicast, not just SDP.  So far the only
thing that I've seen about this has been Van J discussion of the "sd"
algorithm from his SIGCOMM '94 tutorial notes.  At some point there'll need
to be some guidelines written up about this; they should then be referenced
from the SDP document.

3/ The 'grammar' often seems unnecessarily restrictive
======================================================
In many places the document still feels like it's not describing a protocol,
but instead, the behavior of the application (sd) that first implemented
it.  (In fact, I noticed that in a few places the document says "sd must..."
when it should really be saying something like "SDP-compliant applications
must...".)  This is reflected in the 'grammar' (which I put in quotes
because its definition is informal), which in places seems unnecessarily
restrictive.  For example, it seems unnecessary to restrict the order of
the ?= fields to be exactly the order given in the paper.  Instead, you
could just specify that "s=" must come first, followed by the other session
description fields in any order (but including the manditory "o=" and "c="
fields), followed by zero[*] or more media description sections.  Since many
of the fields are optional anyway, allowing them to occur in any order
doesn't make parsers any more complicated.

	[*] Note: the paper says that there must be "zero or more" media
	    description sections, but I'm not sure what it means to have a
	    advertisement with connection info (c=), but no media.  I guess
	    such an advertisement could be used for short announcements
	    (like the "Please don't start a radio session" announcement that
	    Steve Casner occasionally enters into sd).  But if the
	    connection info in such an announcement has no meaning, then
	    perhaps it shouldn't be required (or even allowed).

As another example, the inheritance rules seem somewhat ad hoc.  The paper
says that the "c=", "a=" and "k=" fields are the only ones that can be
redefined in media descriptions.  But one could make a case for allowing
some of the other fields (most notably "i=" and "b=") to be redefined also.
(For instance, one might want to attach additional (short) descriptions to
specific media specs.)  Mikko Tsokkinen made similar comments, I think.

4/ Evolution/extension mechanisms are not defined
=================================================
It's a mistake to try to close the door on possible future extensions.
Instead, it's better to have a small number of well-defined extension
mechanisms handy, just in case.  Otherwise, people will just end up defining
their own extension mechanisms (whether we like it or not), and we'll end up
in a similar mess to the one that the HTML people are in right now.

There are at least three possible avenues for evolution/extensions, each of
which should be addressed in the paper:
1/ Evolving the protocol.
  Here we already have real problems, because there's no version number
  field anywhere.  Big mistake!  In fact, because there's no version number
  field, interoperability between SDPv1 and SDPv2 is going to be a problem,
  because there's at least one incompatible difference between the two
  versions - namely, the different timestamp formats.  You will need to
  explain how (or even whether) SDPv1 and SDPv2 will interoperate.  If you
  don't intend them to interoperate - i.e., if you anticipate the root SDPv2
  directory using a different group address/port than the root SDPv1
  directory - then that would give you the freedom to make otherwise
  incompatible changes in SPDv2 (including adding a version field).
2/ Adding new media types.
  We should anticipate that more media types will be defined.  (E.g., We've
  recently seen one called "mumble", and earlier in this message I proposed
  "directory".)  The paper should probably include some guidelines about
  when to define a new media type vs. define a new attribute for an
  already-defined media type.  For instance, having a new media type
  "mumble" is almost certainly a mistake.  Instead, it should have been
  called "text", with "mumble" being the format (i.e., "a=fmt:mumble").
3/ Adding new attributes.
  We can't prevent people from defining their own attributes, but we might
  want to try to maintain a clear separation between the names of 'official'
  attributes and the names of unofficial/experimental attributes.  E.g., we
  might recommend something like x-<name> in the latter case.
  
5/ We need "unique ids" for announcements
=========================================
Section 5.1, paragraph 1 discusses the need to recognize distinct
announcement packets (perhaps with different group ids and/or ttls) as
really belonging to the same 'logical' announcement.  This implies the need
to be able to uniquely identify (logical) announcements.  To date the
implication has been that the session name (i.e., the "s=" field) is the
unique id, but this is an inadequate solution.  First, it means that the
session name can't being changed (e.g., to fix a typo), without creating a
new announcement.  (We've already seen this happen in "sd".)  Second (and
more importantly), we have the potential for name clashes - e.g., suppose
someone creates a session called "test", restricted just to their local
scope, and then someone else (outside this scope) decides to create their
own "test" session with a TTL that just happens to overlap the first
session's scope.

Instead, I suggest that (logical) announcements be identified by a
combination of (i) the "originator" (i.e., "o=") field, and
(ii) a creation timestamp (a new, manditory, field).

6/ The treatment of time is inconsistent
========================================
It seems awkward to use completely different representations for start/end
times and for repeat times.  Since you're already planning to change the
start/end timestamp format for SDPv2, you might consider making it more like
the repeat time format (except, of course, that start/end times would not be
allowed to use "*" and "," to indicate multiple times).  Similarly, you
might want to consider having "start time" and "duration" rather than
"start time" and "end time".

Also, the "repeat time" format needs to have a way of specifying the year,
and maybe it should also support a granularity of < 1 minute (although I
don't care so much about this).

7/ Miscellaneous comments:
==========================
- I didn't buy your argument on p4, paragraph 1 about the need to define the
  protocol with strict order and formatting rules, so that errors could
  easily be detected if a message is transformed by an email agent.  Another
  point of view is that the protocol should be designed to be *tolerant* of
  transformation by email agents.  The most typical such transformation
  would be the insertion of newline characters.  This implies that it might
  have been better if <newline> were *not* be treated as an end of record
  marker, but instead, just as white-space (like in HTML).

- Do we really need "h="?  The "o=" field seems to make it redundant.
  (I think someone brought up this point at Danvers also.)

- p7. Make clearer: "The value should be between 1025 and 65535 *inclusive*"
	
- p13. (the recommended bandwidth limits for announcements)
  How were these numbers arrived at?  You should probably give some more
  justification for these numbers, and perhaps also rules of thumb that
  could be used if it is ever decided to upgrade these numbers in the future
  (e.g., to reflect increased bandwidth capacities).
  
- P13. In your example, I think you mean "For TTL *64* or above" (not 63).

I closing, I hope my comments haven't come across as sounding too critical.
I'm really glad to see the SD protocol written up; there are just some loose
ends that need to be tied up before we progress to the next version.

	Ross.

---

From: Mark Handley <[email-masked]>
Date: Sat, 22 Apr 95 13:01:35 +0100

>(I apologise for taking so long to write this up.)

Thanks for the lengthy comments - in general they reflect the attitude
the small group of us took in the 2nd of the two sessions in Danvers
(which unfortunately wasn't multicast).

The most important point that came from the 2nd meeting was that we
don't believe compatibility with SDP v1 should be critical in the
design of SDP v2.  This allows a number of changes that we couldn't
otherwise make.

>Subdirectories

This also came up in the afternoon meeting wrt administrative scoping
by multicast address.  Bill Fenner pointed out that if this is to
become widespread then a session directory tool will need to listen to
several multicast addresses (corresponding to different scopes).  If
that's going to be the case, then subdirectories as you mention them
are a simple extension.  However, they then complicate the issue of
multicast address allocation (if you have several subdirectories
within the same scope).  Unless you listen to all the subdirectories
you won't know which addresses are in use unless you allocate an
address range to the subdirectory itself.  

Strictly speaking this is not actually an SDP issue but and SDP *tool*
issue.  Maybe we should actually split the draft into two drafts.

>1/ The protocol description is imprecise

Hmm, you're right it's ambiguous.  Again it's a question of the
description protocol vs the transmission mechanism.  The text protocol
describes a single session description.  The current sd transmission
mechanism only puts one session description in a packet.  However, it
you were transfering them by some other means you may put several
session descriptions in a "message".  

>  completely clear, and one could make a case either way.

It's hierarchical.  Global fields are inherited by media fields unless
overridden.  It does say as much on page 5, but we can always make it
more explicit.

>  include a 'global' "c="?  If so, then does the latter have any meaning?

The expectation is that this is not done.  The first media field does
not have a c= field, but inherits the global one.  It's likely we're
going to change "c" and "t" fields anyway.

>  'global' "k=", if present, have any meaning?

See above.  However in this case, it's also possible that the global key
might be used by explicit conference control.

>2/ There should be guidelines for how to choose multicast addresses

Agreed.

>because its definition is informal), 

actually I did forward a EBNF grammar (though it does contain some errors and will be revised).  It was just too late for the draft.

>which in places seems unnecessarily

I'm slightly confused by this.  Allowing the fields to be in any order
doesn't make *session descriptions* any less restrictive, unless you
allow implied semantics to the field ordering, which I think is a very
bad idea.

We've had cases with sd where someone edited their sd cache and
accidentally merged two sessions (by deleting the s= line).  If we
specify a field ordering then this is simply not parsed.

>	    perhaps it shouldn't be required (or even allowed).

It's there for making announcements to reserve a multicast address and
provide contact data for a session where the rest of the announcement
is encrypted.

>specific media specs.)  Mikko Tsokkinen made similar comments, I think.

I agree about "b=", but this requires some refinement anyway, as we
discussed in Danvers.  I'm still unconvinced by the argument that
media fields benefit from having "i" fields to the extent that it's
worth adding the extra complexity to UIs to deal with it.  The
exceptions to this are to label individual streams where there are
(say) two video streams in one session and you want to use pruning to
select between the two.  Maybe there's a case for a "media name"
field, but this is different from an "i" field in that it should be
very short.

>4/ Evolution/extension mechanisms are not defined

Originally SPDv1 was meant to be a subset of SDPv2.  I'm moving away
from this idea, and I'm going to suggest a number of changes that will
mean that SDPv1 messages will not be parsed be an SDPv2 tool (without
extra legacy code or a gateway).  Given this, and the rule about
unknown fields rendering the announcement void, we can always add a
version number later if it's needed.  However, I don't feel strongly
about this - I'm only trying to keep the field count down.  

>  called "text", with "mumble" being the format (i.e., "a=fmt:mumble").

I agree with you entirely here.

>  might recommend something like x-<name> in the latter case.

Yes, I agree with you there.  It's also important that there is a
database kept somewhere of attributes (experimental or otherwise) and
their meaning.  Common ones will clearly be defined in the protocol
spec, but this won't be the case for experimental ones.

...
>(ii) a creation timestamp (a new, manditory, field).

The issue of o=, h=, and unique ids is going to be revised.  I
strongly dislike using the session name as part of the id.  A
timestamp is one solution to this problem.  I'm looking at a few
others too.

>6/ The treatment of time is inconsistent

The concensus of the meeting in danvers was to move the start and stop
times to a redefined t field.  

>ends that need to be tied up before we progress to the next version.

I agree.  That's the purpose of an ID!  When I've had time to produce
a new draft draft, I'll circulate it to the list.  I hope this will be
in the next week or two.

Thanks for your comments,

Mark