Subject: MCAP node responsibilities

From: "Hattig, Myron" <[email-masked]>
Date: Fri, 9 Apr 1999 11:27:04 -0700

> Following are some clarifications on the responsibilities of
> nodes participating in MCAP that are not obvious (to me at least)
> from the spec. However, these responsibilities must be met in
> order to help ensure robust behavior. Perhaps these should
> go into the draft in some form.
>
> 1. Once a node sends an advertise for some channel C, it must
> be prepared to eventually either hand of the channel or retire
> it. It must be prepared to do this EVEN IF it doesn't know for
> sure that it is the owner. It typically will NOT know that it
> is the owner when it initiates the attempt to transfer
> ownership of a channel to itself.

> It can't "lose interest" and
> abandon channel C for any reason, once it has sent the
> advertisement for channel C. Some reasons why a node may
> be tempted to "lose interest" just after it sent an advertisement
> for channel C:
>   a) It may subsequently observe an advertisement for the same
>       group on a different channel, but sent by a node with
>       a larger NodeID.
>   b) It may subsequently decide it doesn't want to transmit
>      on the group(s) mapped to channel C.
> To restate the key point:  the node should not abandon the channel
> EVEN IF it does not know for sure that it is truly the owner of
> channel.

Okay, if the text states that once a node starts attempting to become an owner
it must complete all steps until it either becomes the owner or determines that
another node became the owner. Is this sufficient?

> 2. Once a node N1 receives an advertisement with expire time 0 (or
>    however else the going-to-be-deallocated-for-sure channel is
>    advertised), it must honor this advertisement, regardless of the
>    relative value of the node ID of the node originating the
>    advertisement. By "honor this advertisement", I mean that N1
>    should assume that the channel is invalid effective immediately,
>    and that N1 is not the owner (regardless of any prior state it
>    may have built-up about this channel).

Maybe I'm not understanding your point, but this seems like a flagrant violation
of the protocol. What am I missing ....

-myron

>
> Regards,
>
> Joseph.
> -----Original Message-----
> From: Hattig, Myron [mailto:[email-masked]]
> Sent: Tuesday, April 06, 1999 2:11 PM
> To: Joseph Joy; [email-masked]
> Subject: RE: MCAP ownership transfer
>
> ...
>
> In general we need to add a state to the leaving owner to indicate
> the leaving owner has indeed left and the channel was indeed
> deallocated.
> Owner-want-to-be(s) that missed the opportunity to acquire
> owernship must
> then allocate a channel from the IRM then use that channel in the
> mapping.
>
> Here is a simple mechanism to do this:
> 3. When the leaving node deallocates the channel it contines
> to advertise
> the mapping with an expire time of 0 for 30 seconds. The 0 expire time
> indicates the channel was deallocated. We may even change the channel
> value in the mapping to something outside the range of 0-63
> to reinforce the fact that the channel is no longer allocated. The
> want-to-be owner(s) simply starts the channel allocation/advertise
> process anew.
>
> ...
>

---

From: Joseph Joy <[email-masked]>
Date: Tue, 13 Apr 1999 14:56:11 -0700

My comments below.

> Sent: Friday, April 09, 1999 11:27 AM
> To:   Joseph Joy; [email-masked]'
> Subject:      MCAP node responsibilities
>
>
>
        [Joseph Joy]   Yes, perfect!
> of the protocol. What am I missing ....
        [Joseph Joy]   Maybe the para above needs rephrasing. Basically  we
need to make sure we don't
        run into the same situation we're trying to avoid. Let's say node N1
is sending it's last expire-time-0
        message for channel C. We don't want any other node trying to take
ownership of this channel
        at this time (if node N1 doesn't get the advertise, it will
mistakenly deallocate the channel).
        But how do we ensure that no other node will try to take ownership
of this channel once N1
        has started sending expire-time-0 advertisements? The only way I can
think of is provision 2 above.
        Other options like relying on nodes not sending advertisements if
they observe an expire-time-0
        advertisements are subject to race conditions that leave nodes
guessing who really owns the
        channel.

---

From: "Hattig, Myron" <[email-masked]>
Date: Thu, 15 Apr 1999 08:40:07 -0700

> From: Joseph Joy [mailto:[email-masked]]
> Sent: Tuesday, April 13, 1999 2:56 PM
> To:   'Hattig, Myron'; [email-masked]'
> Subject:      RE: MCAP node responsibilities
        >
        >

Does anyone oppose this?

-myron

---

From: "Hattig, Myron" <[email-masked]>
Date: Thu, 15 Apr 1999 08:57:24 -0700

Joseph,

Just to make sure we're still on the same page.
The current proposed solution is to send advertisement
for 30 seconds with expire time = 0, then dealloc
the channel after that 30 second period.

I think addresses your concern:

Once the expire time = 0 advertisement is sent, then
no node can use that particular mapping ever again.
By coincidence, a node that wishes to own a mapping
with that particular IP mcast addr may allocate another
channel from the IRM and it may be the same channel,
but despite the number being the same, this is not the
same channel mapping.

In other words, if some other node wishes to own a mapping
to the multicast address that is part of the mapping with the
expire time of 0, the node wishing to own the mapping would
have to allocate a new channel, thus creating a new mapping.

This avoids a deallocated channel from being used because the
owner-want-to-be must allocate the channel from the IRM once
the expire time of a mapping equal 0. Also note that the
owner-want-to-be should be keeping its own expire time
and know (based on its own expire time) that the mapping has
expired.

Make sense?

-myron

        > [Joseph Joy]   Maybe the para above needs rephrasing.
        > Basically  we need to make sure we don't
        > run into the same situation we're trying to avoid. Let's say
        > node N1 is sending it's last expire-time-0
        > message for channel C. We don't want any other node trying to
        > take ownership of this channel
        > But how do we ensure that no other node will try to take
        > ownership of this channel once N1
        > has started sending expire-time-0 advertisements? The only
        > way I can think of is provision 2 above.
        > Other options like relying on nodes not sending
        > advertisements if they observe an expire-time-0
        > advertisements are subject to race conditions that leave
        > nodes guessing who really owns the
        > channel.
        >
        >

---

From: Joseph Joy <[email-masked]>
Date: Thu, 15 Apr 1999 12:09:06 -0700

Myron, I understand your proposal. A subtle ambiguity
still (I believe) exists. In my earlier mail,
I suggested one way to resolve the ambiguity
(without being very specific on what the
ambiguity was).In the following, I suggest another,
and I try to be clearer by providing specific scenarios.

Node N1 is current owner of channel C.
Node N2 is an owner-to-be of channel C.
G is a multicast group address.

Consider the scenarios first. Later I discuss the
specific behavior that must be followed by nodes.

Scenario 1 (successful handoff with 1 lost pkt).
...
N1: G->C;exp=20
N1: G->C;exp=10
N2: G->C;exp=60 <lost>// N2 tries go get ownership of C,
                      // message is lost.
N1: G->C;exp=0
N2: G->C:exp=60       // EVEN though N2 got N1's
                      // exp=0 msg, it MUST assume
                      // that it (N2) now owns C.
                      // N1 gets this message and stops
                      // sending any more exp=0 msgs.
------------------------------------------
Scenario 2 (another successful handoff with 1 lost pkt).
N1: G->C;exp=10
N2: G->C;exp=60       // N2 tries to get ownership of C
N1: G->C;exp=0 <lost> // (at the "same time" as the above
                      // N1 sends it's 1st exp=0 message,
                      // which is lost.
N2: G->C:exp=60       // N2 sends its 2nd advertise
                      // message. N1 gets it and
                      // stops sending further exp=0
                      // messages.
------------------------------------------
Scenario 3 (FAILED handoff with 1 lost pkt)
N1: G->C;exp=10
N1: G->C;exp=0
N1: G->C;exp=0
N1: G->C;exp=0
N2: G->C:exp=60 <lost>// This is a PROTOCOL VIOLATION
                      // by N2. N2 has just
                            //
N1: deallocates channel
N2: G->C;exp=60       // N2 thinks it owns C, but it
                       // doesn't!

The above scenarios illustrate that simple blanket
rule "if you see an expire-0 message, stop sending
advertisements" doesn't work (see scenario 1).
On the other hand, we definitely don't want
a node coming in late and even though it observes
an exp=0 advertisement tries to gain
ownership (Scenario 3).

I think the following provision should suffice
(it's different from the one I suggested in
my earlier email):
        A node should only try to gain ownership
        of a channel if it is sure that the current
        owner will not deallocate it within 30 seconds.
        Once a node sends an advertisement to try to
        gain ownership, it must follow through the
        process even if it receives one or more
        exp=0 messages [see Scenario 1].

> Sent: Thursday, April 15, 1999 8:57 AM