Subject: Asynchronous streams, GASP and the BCM

From: Peter Johansson <[email-masked]>
Date: Thu, 13 May 1999 01:06:31 EDT

In a message dated 99-05-12 07:01:17 EDT, [email-masked] writes:

<<Could somebody be kind enough to explain why it is better to overload an
existing transaction code in order to implement asynchronous multicast as
asynchronous stream, get the IRM involved into the picture, define the GASP
sub-format, and finally use a fixed channel number for "asynchronous stream
broadcast", instead of defining a new transaction code for asynchronous
multicast, that has a multicast ID in the header, with ID 0 reserved for
"asynchronous stream broadcast", possibly one or more bits to control
propagation over bridges, and anything else that might be desired from this
feature?>>

I think there are several questions embedded here...

First, the question of a new transaction code. Do you want existing hardware
to be able to receive asynchronous multicast? This was a non-negotiable
design goal at the time asynchronous streams were proposed. If you accept
that initial condition AND have a cleaner solution than GASP and the BCM,
please suggest it.

Incidentally, the multicast ID, with one value reserved for default broadcast
and a number of control bits to manage cross-bridge propagation adds no
functionality not already available in GASP/BCM---so you need to demonstrate
clear superiority, not simply "another way to do things."

Second, P1394.1 has heard proposals about a new transaction code (or extended
transaction code) and has given them a favorable reception. But these new
facilities would be for new hardware, ONLY. I don't think anyone is averse to
creating a new transaction code when it appears to be an appropriate solution.

Peter Johansson

Congruent Software, Inc.
98 Colorado Avenue
Berkeley, CA  94707

(510) 527-3926
(510) 527-3856 FAX

[email-masked]