Subject: Re: Changes since draft 15

From: "Hattig, Myron" <[email-masked]>
Date: Mon, 13 Sep 1999 14:02:53 -0700

> Based on the above, my concern would appear to be that "transfer" is a
> misleading term. I had assumed "transfer" means, node X owns channel
> x, but wants to give it up, and one wants some other node, Y to become
> owner for x with no apparent disruption in service (i.e., the channel
> mapping for IP multicast group Z to channel x does not change).

It is not clear this will disrupt service anymore than the service is
already disrupted by lost packets. See below comments.

> What I
> read the above as saying is that "transfer" really means the owner
> deallocates it, then someone else (all nodes simutaneiously??
> yikes!!) allocate a new channel, then there is conflict
> resolution.

This is one scenario, but not the common scenario. The common scenario
is a "transfer" where the mapping identifier (the ip multicast address)
and all the associated values (1394 channel) remain identical. The
uncommon scenario where the 1394 channel number changes still uses
the same IP multicast address as the identifier. Thus, as I read the
text, the term "transfer" still applies.

> Meanwhile, IP multicast service would appear to be
> severerly effected until the dust settles.

I don't think the IP multicast service will be affected, certainly
not severely. Multicast apps in general (as far as I know) are
designed with loss in mind because generally multicast uses udp.
In the common case that uses the same channel, no loss will occur.
The uncommon case occurs when MCAP msgs are lost, it is likely other
packets will be lost so its hard to say adds further interruption
or not.

> Is how transfer is
> intended to work? (This would seem rather inconsistent with the text,
> but the above explanation seems to suggest that.)

I don't see the inconsistency; maybe others can point this out.

-myron

---

From: "Hattig, Myron" <[email-masked]>
Date: Mon, 20 Sep 1999 17:05:51 -0700

I can't see any great benefit or harm. If no one else has input,
then let's plan on changing it so the channel owner does not
send until 100 millisecs after sending an advertisement. As
suggested this will only apply to the initial transmission
of IP mcast data, not to overlapped or redundant channels.

-myron