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

From: [email-masked] (Ross Finlayson)
Date: Thu, 4 May 1995 12:34:23 -0700

> >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.  
> 
> 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.

Yes, it's true that a variety of announcement/discovery schemes could be used.
(For instance, we used a client-server multicast naming mechanism in the
V-System about 10 years ago, although back then it was used on a LAN only.)

Note though, that there's a fundamental tradeoff (between bandwidth
consumption, number of different announcements, and freshness of
information) that applies no matter which particular scheme is used.
Bits need to traverse the Internet from the announcers to the recipients
somehow, whether it's by having the announcers 'push', by having the
recipients 'pull', or some combination thereof.

In any case, I still contend that it will be impractical to support, using a
single SD group, very large numbers of announcements over the scope of the
global Internet.  Although, as you've noted, this won't be as true for lower
TTLs (because of their tolerance of higher bandwidth).  But I guess we'll
just have to see how this all works out...

	Ross.

---

From: Mark Handley <[email-masked]>
Date: Thu, 04 May 95 21:06:49 +0100

>recipients 'pull', or some combination thereof.

Agreed.  However, scaling benefits only occur when filtering occurs
along the path.  You suggested one mechanism for this -
subdirectories.  I think this creates other problems - address
allocation clashes.

Basically we agree on what the problem is - we disagree on when it
will hit us.

>just have to see how this all works out...

I believe that we will have a problem with annoucement bandwidth or
with annoucement freshness - I also believe that this problem is
further off than two other problems:

  - lack of bandwidth for the sessions themselves in the current Mbone.
    This I hope will be solved by a combination of hierarchical
    multicast, administrative scoping and general bandwidth increases in
    the internet.  If not, then this whole discussion is irrelevant
    anyway!

  - problems finding relevant sessions amongst irrelevant sessions
    whilst still finding out about new topics.  This was the purpose of
    having a "subject" or "category" field in SDP.

I believe that by making a strong distinction between the description
and the announcement protocols, we can wait a little while to solve
the announcement problem.  Thus we'll be doing so in the light of an
Mbone significantly different from todays.  I don't want to attempt to
prejudge what the actual Mbone solutions will be.  I believe that with
careful use, the existing annoucement protocol will last long enough
to see what the transition brings, and thus give us a much better idea
of the possible solutions.  What I want to do now is attempt to smooth
the growth by (partially) solving the second of the two problems in
SDP.

I know the first problem will bite us eventually - I just don't
believe we know enough about the future of the Mbone to suggest the
right solution today, and I also don't believe the problem is critical
right now either.

Mark