Subject: mapping multiple multicast group addresses to a channel

From: Joseph Joy <[email-masked]>
Date: Fri, 9 Apr 1999 12:12:27 -0700

It appears that with the following provision, multiple IP multicast group
addresses may be mapped to a channel without any ambiguity or other
complications:
    The mapping (G->C) specified in an advertisement from
    a node N overrides all previously-existing mappings
     involving G OR C, sent by any nodes with node
     IDs <= nodeid(N).

Following are 2 problem scenarios presented in an earlier mail. For each
scenario I suggest how any ambiguity is resolved by the above
provision.

[6. It is not clear what needs to be done when a node that owns
 a particular channel wants to leave one multicast group address [G]
 but not the others.]
RESOLUTION: The node simply sends advertisements with the updated
set of group addresses which map to the particular channel (this
set will not include the multicast group address G). Any other node
that wants to continue sending to address G needs to allocate a new
channel or try to map G to an allocated channel that IT owns.

[7. It is not clear what needs to be done when there is overlap
 in the advertisements each of which have different sets of
 partially-overlapping multicast group addresses. Following
 is a specific scenario involving nodes N1, N2, N3,
 channels C1, C2, C3, and multicast group addresses G1, G2 and G3:
 N1 sends advertisement (G1->C1, G2->C1)
 N2 sends advertisement (G2->C2, G3->C2)
 N3 sends advertisement (G3->C3)
Assuming nodeid(N1) < nodeid(N2) < nodeid(N3), it's not clear
 what nodes N1 and N2 need to do next.]
RESOLUTION: By the provision, the true mappings are as follows:
        G1->C1, G2->C2, G3->C3.
Subsequent advertisements from N1, N2 and N3 will therefore be as follows:
 N1 sends advertisement (G1->C1)
 N2 sends advertisement (G2->C2)
 N3 sends advertisement (G3->C3)

Can anyone see any loopholes or have any objection to the provision? If
not I would like us to consider removing the CAUTION in section 10 and
adding the
(a suitably reworded) provision to the draft.

Regards,

Joseph.
-----Original Message-----
From: Hattig, Myron [mailto:[email-masked]]
Sent: Monday, April 05, 1999 11:40 AM
To: Joseph Joy; [email-masked]
Subject: RE: WG Last Call on IPv4/1394

Joseph,

Comments below where necessary. To summarize comments below,
I have two agreed upon changes to the spec, two maybe changes, and a
single yikes. Yikes = we may have to define more protocol ;-(.  A
yikes is a bad thing.

-myron

> -----Original Message-----
> 3. MCAP: multiple multicast addresses should/should not be mapped to a
> single channel.
>    In response to Peter's comments: what is an implementation
> of MCAP based
> STRICTLY on
>    this draft supposed to do if it receives an MCAP
> advertisement which maps
> multiple group
>    addresses to the same channel? What is the recommended
> action to improve
> chances
>    of interoperability?  Should it ignore the advertisement?

I agree with Joseph on this point. The purpose of the spec is to ensure
interoperability, not to promote creative thinking about future issues.
Experimental RFCs are for promoting creative solutions. The spec should
consistently state sharing channels is not supported in any way. If
Peter agrees, I'll add this to the list of changes for the spec.

> 4. MCAP: there is no provision for receivers with a lower max_rec to
> participate in an
>     established mcast session (this problem has no simple
> solution, and has
> been
>     debated in the WG before). I would like to see mention of
> the provision
> to downgrade
>     speed as Peter suggests.
On this point, I'm opposed at promoting any solutions. If we want
to explain the problem, that's great, but eluding to or suggesting any
potential solution is not the purpose of the spec.  Again, an informational
RFC listing a solution or possible solutions is the way to deal with
any future work.

> 5. MCAP: if a node currently "owning" a mcast channel needs to leave
> urgently, it must
>     induce a bus reset. This is not explicitly specified in
> the draft. The
> specific
>     scenerio I'm thinking of is if the user on a PC disables
> (via the UI)
> the
>     tcp/ip stack over 1394. In this situation the arp module
>     can't wait around for the required channel expiry times. In this
> situation,
>     I'm ok with that fact that the arp module must induce a
> bus reset. I
> don't
>     see a solution (that would fit within MCAP as currently
> defined) other
> than
>     inducing a bus reset.

I agree. While someone could infer a bus reset is required when
a node must leave urgently, it would be best to explicitly state
that action in the spec. If no one disagrees, I'll add this to
the list of changes for the spec.

>
> On a different topic...
>
> With MCAP transfer of ownership, it' appears (based purely on thought
> experiments) to be possible to get into situations when there
> is no owner of
> a
> previously allocated channel, or where a channel is
> de-allocated when it
> shouldn't.
> I hope someone in this WG can show that what I describe is
> actually a non
> issue.
>
> Following is one scenario:
>        Node N1 wants to send on ip group address G1.    It
> sends a solicit.
>        Node N2 (which is almost through winding down
> ownership of channel
> C1) sends
>              advertise (G1-> channel C1, expiry in 10 secs)
>        N1 sends advertisement (G1->C1, exp in 60 secs),
> wanting transfer of
> ownership of C1.
>        The above advertisement from N1 is lost.
>        N2 goes ahead and de-allocates C1, but N1 thinks that
> it is now the
> owner of C1.
>        A single lost packet has caused this to happen.

Yikes!!!  More mail to come on this topic.

---

From: "Hattig, Myron" <[email-masked]>
Date: Thu, 15 Apr 1999 09:13:20 -0700

Joseph,

As you said there are two issues here: resolving ownership (7 below)
and deallocating the channel (6 below).

Resolving ownership can easily be done as you've described below in 7.

Channel deallocation is more difficult. I don't understand your proposed
solution in 6) below.

This is my current understanding. It is difficult
because two separate nodes may own a mapping using the same channel. The
leaving node would be forced to cross reference information with other
mappings to know whether or not to deallocate the channel. From our recent
discussions, it is somewhat complex ensuring an owner and owner-want-to-be
properly deallocate a channel. Complicating the situation with multiple IP
mcast addrs to a single channel is something the WG did not want to tackle
for now.

Instead, I hope to talk to implementers over time to benefit from
implementation
experience. For example, if we learn that implementations have nodes
maintain
a database of all mappings, whether the node is uses the mapping or not,
then we
may be able to tackle the multiple IP mcast addrs mapped to single channel
problem.

Regardless, please explain your point 6 below.

-myron

> From: Joseph Joy [mailto:[email-masked]]
> Sent: Friday, April 09, 1999 12:12 PM
> To: 'Hattig, Myron'; [email-masked]'
> Subject: mapping multiple multicast group addresses to a channel
>
>
>
> not I would like us to consider removing the CAUTION in
> section 10 and adding the

---

From: Joseph Joy <[email-masked]>
Date: Fri, 16 Apr 1999 12:22:47 -0700

I guess before we go any further down this path of evolving
this protocol on the fly we need to decide whether it is
worthwhile to solve the multiple-groups mapped to a channel problem
completely in the current ip/1394 specification. It may well
be worth while (as Myron suggests) that we leave out this feature
completely from this specification, or (as Peter suggests),
allow advertisements but not transfer of ownership when
multiple groups are mapped to a channel. I notice that there is
a separate discussion thread on that.

I clarify point 6 below, but we can shelve further discussion on this
topic until further notice.

Let me first state two requirements which
I didn't list earlier:
1. Only the node owning a particular channel assigns the mapping
   of group addresses to that channel.
2. All multicast group addresses that need to be mapped to a particular
   channel must be sent in the SAME advertisement message.

If an owning node wants to relinquish ownership of a channel, it simply
does so -- it starts sending advertisements with decreasing expiries, etc.

Elaborating on point 6....
Let node N1 own channel C1, and lets say it currently maps groups G1,G2 to
C1.
Let node N2 want to send on G2. Consider the following sequence:

N1: (sends advertisement) (G1,G2)->C1;exp=60
// N1 uses C1 for sending to G1 and G2
// N2 uses C1 for sending go G2
...
// N1 now decides that it wants to stop sending to G2, but
// continue sending on G1, so it sends the following advertisement...
N1: (G1)->C1;exp=60
// N2 (which doesn't own C1) must now allocate a new channel
// if it wants to continue sending to G2. It allocates channel
// C2 and sends the advertisement....
N2: (G2)->C2;exp=60
N1: (G1)->C1;exp=60
... etc.

There are two quirks with the above scheme:
1. Nodes that don't own a channel but are nevertheless sending
   on it (like node N2 above) do not get any advance warning that
   the specific mapping (G2->C1 above) they were using has
   gone away. The channel itself won't go away for another 30
   seconds at least -- just the specific mapping.
2. If many nodes were sending on a group G mapped to channel C,
   whose owner decides to stop sending on G, they will all
   try to acquire a new channel -- there could be some thrashing
   involved here.

Both the above issues can be solved (nodes can set a random timer
between 0 and 10 seconds after which they will try to allocate
a timer if they don't see an advertisement they could use; during this
time, they can continue to send on the old channel). However that's
enough on-the-fly protocol design for now :-)

Regards,

Joseph.

-----Original Message-----
From: Hattig, Myron [mailto:[email-masked]]
Sent: Thursday, April 15, 1999 9:13 AM
To: Joseph Joy; [email-masked]'
Subject: RE: mapping multiple multicast group addresses to a channel

Joseph,

-myron

---

From: "Hattig, Myron" <[email-masked]>
Date: Fri, 16 Apr 1999 15:23:00 -0700

> Sent: Friday, April 16, 1999 12:23 PM
> completely in the current ip/1394 specification.

Until we've established a need, I'd like to postpone this work. We can even
work
on separate IDs now, but allow the current IPv4/1394 spec to move forward.

Does anyone disagree?

-myron