To: nfinn@cisco.com, crawdad@fnal.gov
Cc: P8021@nic.hep.net
Subject: Overhead (lack of it) for idle multicast groups
Date: Sat, 13 Apr 1996 14:57:50 -0700
From: Mick Seaman <mjs@NSD.3Com.COM>


I agree with Norm here, certainly the model of application behavior I
have is that potential transmitters (very likely servers) would not
"register-to-send"/create groups which they have no intention of
transmitting on, and potential receivers (very likely end stations)
would not continue to register for traffic that they never received.

The paranoid could add non-standard smarts to the "floor
switch" to deal with latter though I believe that would not be a
useful approach.

It's important to note that the pruning in .1p allows pruning back to
source, i.e. if there are no potential receivers never send. Similarly
if there are no potential receivers at all then creation traffic can
be suppressed.

Tony (Jeffree),

Could you add as an issue/note for further work that we have to
add/create application guidelines as part of this (an appendix?) or as
part of some future scope of work (a more controllable approach to
organizing the work). This would make it clear which of the viable
strategies was being advocated and highlight any deadlock situations
which the unwary might otherwise construct.

[We talked about this a while ago, mainly in the
context of trying to get application writers for the next decade to
use multicasts to identify flows (like IP multicast mapping to LANs)
rather than using multicasts as redundant protocol identifiers - in
some cases of course they are the same, but not in the new world we are
addressing with 1p.]

[attached: P802.1-96/051 (see d96/d96n051.txt)]