Subject: Re: Changes since draft 15

From: Myron Hattig <[email-masked]>
Date: Tue, 14 Sep 1999 07:45:22 -0700

9.7 says:

"If other multicast source(s) are using the same channel mapping and
observe an expiration time less than or equal to 30 seconds, they SHALL
commence transmitting MCAP advertisements for the channel mapping with
refreshed expiration times greater than or equal to 30 seconds that
maintain the channel mapping. Any contention that occurs between
multiple sources that attempt to claim ownership of the channel mapping
SHALL be resolved as described in 9.6. "

I think I finally see the problem that you see .... this section says "Any
contention"
that implies contention when two nodes use the idential mapping with
same channel number as well as when the mapping in question use
different channels. Then in section 9.6, it only talks about channel
mappings
with different channels. Thus 9.6 cannot apply to the case when the channel
are the same. I disagree with this interpretation of the text, but I'll talk
off-line
with Peter for a proposed solution.

WRT the "YIKES" in the last mail ... I don't think an interruption of ip
mcast
service is a concern. First if advertisments are lost then other ip mcast
packet will probably also be lost (lost advertisements are the source for
the uncommon case of transfer of ownership when a new channel
must be allocated). Second, ip mcast protocols should be designed
with packet loss in mind. Third, there will be a small number of nodes
attempting to become owners. Even if an incredibly large number
of nodes, say 20, attempt to become owners, that is only 40-100
packets. 40-100 packets is on the same order of magnitude of packets
as the number generated after a bus reset.

-myron

---

From: Grenville Armitage <[email-masked]>
Date: Tue, 14 Sep 1999 11:34:32 -0400

Myron Hattig wrote:
        [..]
> Second, ip mcast protocols should be designed
> with packet loss in mind.

Whilst this may be true in principle, its not an excuse for a link
layer to have a known-yet-avoidable packet drop characterstic. Loss
ought to be from queuing and/or line noise. Other sources are just
glitches, and "yikes!" appears to be a fair reaction.

cheers,
gja
________________________________________________________________________
Grenville Armitage                            http://mh005.infi.net/~gja
Bell Labs Research, Lucent Technologies

---

From: Thomas Narten <[email-masked]>
Date: Tue, 14 Sep 1999 12:46:19 -0400

> glitches, and "yikes!" appears to be a fair reaction.

I agree completely. There is at least one place in the draft where
more care could be taken to insure that packet losses don't take place
unnecessarily. For example, in section 9.4:

> When no other multicast source has established a channel mapping for the
> group address, the intended multicast source may attempt to allocate a
> channel number from the isochronous resource manager's
> CHANNELS_AVAILABLE register according to the procedures described in
> IEEE P1394a. If the channel number allocation is successful, the
> multicast source SHALL advertise the new channel mapping(s) as soon as
> possible; once such an advertisement has been made, the multicast source
> may transmit IP datagrams using the channel number obtained.

I could imagine that it takes a short amount of time (10s of
milliseconds?? -- the exact time depends on various factors such as
the implementation) from when a node received an MCAP message to when
it is actually prepared to receive packets on a new channel (e.g., the
1394 device has to be told to do this via an ioctl or something). It
certainly wouldn't hurt (and might well help) for the sender to NOT
send on the new channel until a short amount of time (100ms?) after
sending the advertisement before actually transmitting on that
channel. But as the text is written now, no such delay is suggested or
required. So it seems possible, if not likely, that some packets will
be lost when switching to a non-default channel.

Thomas