Subject: Re: (ION) MARS implementations?

From: Mohsen Souissi <[email-masked]>
Date: Tue, 23 Feb 1999 19:31:17 +0100

Hi Grenville and all,

I'm currently implementing MARS (RFC 2022) and there's something I
don't understand well.

In section 6.1.2 (middle of page 44):

"If a single group was being joined or left:

      mar$flags.punched is set to 0.

      If the joining (leaving) node was already (is still) considered a
						^^^^^^^^^

      member of the specified group, the message is retransmitted
      privately back to the cluster member.  Otherwise the message is
      retransmitted on ClusterControlVC."

I'm just wondering if "(is still)" shouldn't be replaced by "(no longer)".

If the original version is to be kept (i.e, "is still" is correct),
could anybody explain to me the "leave" case?

Thanks beforehand,

Mohsen.

-- 
Mohsen SOUISSI

***********************************************************************
*                         IPv6 Project, INRIA                         *
***************************************+*******************************
* 		  mailto:[email-masked]                      *
*                 http://duvel.inria.fr/souissi/		      *
* Tel.:  +33 1 39 63 52 54       |  Fax:     +33 1 39 63 58 66        *
*--------------------------------+------------------------------------*
* INRIA - Domaine de Voluceau-Rocquencourt - B.P. 105 -               *
* 78153 Le Chesnay Cedex, FRANCE                                      *
***********************************************************************

X-Info: To unsubscribe, email [email-masked]' with
X-Info: 'unsubscribe ion' in the body of the message.

---

From: Mohammed Hendaz <[email-masked]>
Date: Tue, 23 Feb 1999 15:00:44 -0500

Hi,

the "is still" expression is correct ... The idea here, i.e. the 
server decision of forwarding the MARS_LEAVE (or MARS_JOIN) to either
the corresponding cluster member or through the CCVC, tackles the case 
in which more than one application (process) have joined the same single
group. So the Server should keep track of that, and if the leaving node
"is still" member of the specified group, i.e., there's still some 
applications (processes), other than the one that has just left, which
are still joining the same group, the server will not 
forward the MARS_LEAVE through the CCVC, so the senders to that single
group (multicast address) would not drop the cluster member from their
p2mp VC, and the other applications at the the leaving member would 
still receive the multicast trafic to that group.

Hope this helps.

--
Mohammed.

PS: I've developped a MARS implememtation for LINUX, that you can 
find at: 

http://snad.ncsl.nist.gov/~hendaz/NIST-MARS/

It's not complete yet, but better than starting form the scratch ;-)

------------------------------------------------------------------------
Mohammed Hendaz					Phone: 	+1-301-975-5410
National Institue of Standards 			Fax:	+1-301-590-0932	
and Technology	
Internetworking Technologies Group		[email-masked]
------------------------------------------------------------------------

---

From: Anil Grovor <[email-masked]>
Date: Wed, 24 Feb 1999 08:52:05 +0530

Hi,

This needs to be seen in the following context :

A Join or Leave can happen for a range (block), as well as for a single
group. RFC 2022 explicitly allows this kind of an overlap.

The "is still" thus implies that a previous block join/leave already had
this group member which is now being singly joined/left.

The RFC on similar related issues is indeed somewhat subjective, and my
team went through a detailed specification and design while implementing
RFC 2022 (MARS Client, Server & MCS) as a portable stack. 

Please let me know if you need any further clarifications / information

Thanks

Anil Grovor

-- 

________________________________________________________________

Anil Grovor                        email : [email-masked]
Manager, Engineering               vmail : 408-432-9200 x132
Telecom / Networking               voice : 408-432-0269 x404
Duet Technologies                  phone : +91-11-91-567002
My eCode:AnilGrovor                http://AnilGrovor.eCode.com
________________________________________________________________
X-Info: To unsubscribe, email [email-masked]' with
X-Info: 'unsubscribe ion' in the body of the message.

---

From: Mohsen Souissi <[email-masked]>
Date: Wed, 24 Feb 1999 11:16:38 +0100

Hi Mohammed and all,

[email-masked] said:
> the corresponding cluster member or through the CCVC, tackles the 
> case  in which more than one application (process) have joined the 
> same single group. So the Server should keep track of that, and if 
> the leaving node "is still" member of the specified group, i.e., 
> there's still some  applications (processes), other than the one that 
> has just left, which are still joining the same group, the server 
> will not  forward the MARS_LEAVE through the CCVC, so the senders to 
> that single group (multicast address) would not drop the cluster 
> member from their p2mp VC, and the other applications at the the 
> leaving member would  still receive the multicast trafic to that 
> group. 

If I understand you well, the server (mars) is supposed to keep a sort of 
reference counter for processes attached to a given interface (cluster 
member).

I have got two comments on that :

1) The client already uses the reference counter within IGMP protocol (you 
may have a look at `in_delmulti' routine in BSD code, 
/usr/src/sys/netiniet/in.c )
This indeed allows the cluster member's interface to send a 
`igmp_leavegroup' to mars client as soon as there are no more processes 
participating in that group. MARS client will then "transform" it in 
`mars_leave' and send it to mars.
So I think that MARS should remove a mars client from the specified group 
as soon as that client requests it.

2) Further more, the server has no way to identify/distinguish processes 
so it cannot handle a reference counter. We can imagine a single 
application that sends more than one mars_join because it didn't get 
acknowledgement from mars. And in this case it would be a mistake if the 
mars incremented the reference count at each time.

Thus, the "is still" expression in RFC 2022 still makes me confused :-)

Hope this was clear and thank you in advance,

Mohsen.
-- 
Mohsen SOUISSI

---

From: Mohammed Hendaz <[email-masked]>
Date: Thu, 25 Feb 1999 17:09:04 -0500

Hi Mohsine,

See my comments below.

> as soon as that client requests it.

I don't think it's in the spirit of MARS that IGMP will manage the
clients membership, IGMP is rather for the BMA networks (e.g. ethernet),
and MARS was spesified for ATM which is a NBMA network.

If you take a look at section 6.1.2:

   If a single block covering 2 or more groups was being joined or left:

      A copy of the original MARS_JOIN/LEAVE is made. This copy then has
      its <min,max> block replaced with a 'hole punched' set of zero or
      more <min,max> pairs.  The 'hole punched' set of <min,max> pairs
      covers the entire address range specified by the original
      <min,max> pair, but excludes those addresses/groups which the
      joining (leaving) node is already (still) a member of due to a
      previous single group join.

this implies that it's expected from the Client to send several 
MARS_JOIN/MARS_LEAVE involving the same groups (multicast addresses). If 
the membership control (i.e., by just sending only one JOIN/LEAVE for 
each group) was supposed to be done at the Client side, the "hole
punched" set mentionned in the paragraph above would be done by the
Client whenever it's asked to JOIN/LEAVE a single block containing
groups having already and still being joined by other processes.

I think that your confusion with the "is still" expression comes from
the fact that you've taken as a hypothesis that it's the Client that 
will control several JOIN/LEAVE of the same groups (with IGMP), and 
therefore you interprated the following paragraph:

   If a single group was being joined or left:

      If the joining (leaving) node was already (is still) considered a
      member of the specified group, the message is retransmitted
      privately back to the cluster member.  Otherwise the message is
      retransmitted on ClusterControlVC.

as to be just how the sever would react to retramsmitted JOIN/LEAVE 
message whose the copy sent by the Server back to the joining/leaving 
client was lost. That's why you come up with "no longer", since it's the 
expression which makes sence based on your hypothesis. Right?

> mars incremented the reference count at each time.

If we allow the Client to send several JOIN/LEAVE for the same groups,
we should be able to make the difference between that case and the one 
of the retransmission that you've mentionned. But section 5.2.2 doesn't
mention anything which distinguishes a retramsmitted message from
an original one, so i would recommend to use the mar$flags.sequence
to do that, e.g. "0" for an original message and "1" for a 
retransmission. (I know that the RCF said that this fied is never
modified or checked by a MARS (5.2.2) :-) ).

PS: having said all that, you can always give the MARS implementation
the flavor you want ...

-- 
Mohammed

---

From: Francis Dupont <[email-masked]>
Date: Tue, 02 Mar 1999 15:02:35 +0100

=> I believe it is *not* supported by the MARS protocol: a client
either is or is not a member of a group, any membership of internal
processes must be managed by the client, not by the MARS.

   But section 5.2.2 doesn't
   
=> but this is a very different protocol...

[email-masked]

---

From: Mohammed Hendaz <[email-masked]>
Date: Tue, 02 Mar 1999 10:51:16 -0500

> processes must be managed by the client, not by the MARS.

Section 6.1.2:

      ^^^^^^^^^^^^^^^^^^^^^^^^^^

How would you explain the underlined text?

In my last message, i wrote (concerning the membership of internal 
processes):

If the membership control (i.e., by just sending only one JOIN/LEAVE for 

Any comments??

> => but this is a very different protocol...

I like the word "very" ;-).

-- 
Mohammed.

---

From: Anil Grovor <[email-masked]>
Date: Thu, 04 Mar 1999 12:56:37 +0530

Hi,

I have observed a number of mails on the "is still" phrase in RFC 2022
(Multicast Address Resolution Server) after my last clarification on
24th Feb.

Here's an attempt to clarify through an example. My attempt is to do
this as briefly as possible, without delving into related details.

Consider the following scenario :

Client C1 is a member of MGa & MGb multicast groups
Client C2 is a member of MGa multicast group

C1 wants to send data to MGc 
	- C1 sends MARS Request to Server
	- Server sends a MARS_NACK as there are no members in MGc

C2 joins MGc with Layer 3 flag ON

C1 again wants to send data to MGc
	- C1 sends MARS Request to Server
	- Server replies with the address of C2
	- C1 establishes a Data P2MP VC with C2 
	- C1 sends data after VC established

C2 joins MGc with Layer 3 flag OFF (used by router apps for listening to
traffic)
	- MARS Server responds on private P2P VC with C2 
	  (because C2 has earlier joined, though with Layer 3 flag ON,
	   and informing on Cluster Control VC will cause C1 to add C2
	   again to the Data P2MP VC for group MGc. Note that other
           clients are not reqd to know, for information rcvd on 
	   cluster control VC w.r.t new joins, as to whether the join
           is with Layer 3 flag ON or OFF)

C2 Leaves MGc with Layer 3 flag ON
	- MARS Server responds on private P2P VC with C2
	  (because informing on the cluster control VC will cause C1 to drop C2
from Data P2MP VC for group MGc, where as C1 still wishes to listen to
the traffic as a router application)

Since RFC 2022 has defined the MARS Layer 3 flag in MARS_JOIN &
MARS_LEAVE messages to be of type boolean, and has defined this flag as
OFF for router application joins, all other Layer 3 applications on a
client node shall issue MARS_JOINs for the same group with the Layer 3
flag ON. Thus, the server does not have any mechanism to differentiate
between applications on clients (other than router applications, which
typically, join a range, and join with Layer 3 flag OFF).

This differentiation based on Layer 3 flag, is required by the server to
respond appropriately to MARS_GROUPLIST_REQs. This message is a
replacement for IGMP messaging, as per RFC 2022, in the context of
multicast over ATM.

Hence, "is still" is the right phrase, and the messaging on private P2P
VC has to be done under the conditions specified.

Please let me know if you need further information.

Thanks

Grovor

--