Subject: Re: Changes since draft 15

From: "Hattig, Myron" <[email-masked]>
Date: Mon, 13 Sep 1999 12:10:24 -0700

In the original response to this comment we found a bug in the
algorithm. The new line of text fixes the bug. We thought this
was the issue but it sounds like there is still an issue with
the text being unclear. I think the current text is clear and
accurate, but as with the note from Ganesh, my previous
context predisposes me to think this.

Direct responses to Thomas's comments:

> > > 9.7 Transfer of channel ownership
> >
> > I don't understand how this works. Specifically:
> >
> > > 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. If the original
> owner observes an
> >
> > But section 9.6 says if two nodes advertise the same group, all but
> > the highest numbered one shuts up. This doesn't resolve
> anything.  It
> > specifically doesn't say anything about looking at the
> expiration time
> > and doing something if the time is less than 30.
> >
> > Or is the term "transfer" misleading? Seems like what this algorithm
> > does is let the owner deallocate, then eventually someone else will
> > allocate a new (and different) one. Is that what is meant by
> > "transfer"? If so, the text about 30 seconds doesn't seem to do
> > anything.
>
> Paragraph 2 of version -18 of the document was changed to address my
> comment via the addition of the line marked by {+ ... -}:

I think the bug fix in draft 18 addresses this concern.

> > Multicast channel owners SHALL monitor MCAP advertisements
> in order to
> > detect overlapped channel mappings. {+MCAP advertisements
> whose expiration
> > field has a value less than 60 SHALL be ignored for the purpose of
> > overlapped channel detection.+} When an overlapped channel
> mapping is
> > detected, the owner with the largest physical ID (as
> determined by the
> > least significant six bits of source_ID from the GASP header) is NOT
> > REQUIRED to take any action. The owner(s) with smaller physical IDs
> > SHALL cease transmission of MCAP advertisements for the overlapped
> > channel number. As soon as these channel mapping(s) are no
> longer valid,
> > their owners SHALL deallocate any unused channel numbers as
> described in
> > 9.8 below.
>
> However, my understanding of "overlapped channel detection" is that it
> refers to the case where the same IP multicast address has been
> assigned different 1394 channels (i.e., if two nodes independently
> allocate a 1394 channel for the same IP multicast group).  In
> contrast, the transfer of ownership case refers to a situation where
> there is only one channel allocated. So it appears to me that the
> change doesn't really address my concern.

This sounds like a concern other than the one stated above, or perhaps
we misinterpreted your original concern when we found a bug in the text.
Regardless, I think the text adequately handles this concern. Here is
the explanation:

9.4 describes the first time ownership when a node allocates a channel
to create a mapping and become an owner.

9.6 describes contention resolution for when two nodes allocate
a separate channel and attempt to become owners of a mapping.
(The winning node has the largest phy id.)

9.7 describes how ownership transfers from an old owner to a
new owner. This assumes there is more than one node that wants
ownership; this occurs when there are multiple senders of
an IP mcast group address.

9.8 describes the steps an owner takes to disown a mapping.

There is a inter-relationship between all four things.
Contention resolution (9.6) may occur during first time
ownership (9.4) or when ownership transfers (9.7).

During the transfer of ownership (9.7) it was possible for
the channel to be deallocated by the old owner and the new
owner to still think the channel was alloced; thus, the
new owner would advertise a deallocated 1394 channel. This
occurred if some packets got lost by either the new owner
or the old owner.

The solution stated (I think as of version 15) in the spec
relates to the old owner advertising mappings with a expire
time of zero in section 9.8; this is done for 30 seconds.
The advertisement with the expire time of zero tells all
nodes the 1394 channel will indeed be deallocated so stop
using it. 9.7 states the new owner(s) proceed by allocating
a new channel then determining ownership through contention
resolution (9.6).

Thomas's direct concern was that section 9.6 addressed the
case with multiple different channels and 9.7 only deals with
the case of a single channel. As described, 9.7 transitions
to a case with multiple channel when the old owner
deallocates the channel and the new owner(s) must allocate
a new channel.

Does this help? Can or should the text be improved?

-myron

---

From: Thomas Narten <[email-masked]>
Date: Mon, 13 Sep 1999 15:35:21 -0400

> Does this help? Can or should the text be improved?

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). 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. Meanwhile, IP multicast service would appear to be
severerly effected until the dust settles.  Is how transfer is
intended to work? (This would seem rather inconsistent with the text,
but the above explanation seems to suggest that.)

Thomas