Hi, Jakko and all:

Please see my response provided below [RRR].

In Osaka, it was told that the multicast of MGA is a problem because of bandwidth consumption. However, using of MGA in a unicast mode does not pose any problems with respect to the bandwidth consumption.

That is why, the post-Osaka emails were sent by to clarify the meeting minutes.

Therefore, MGA can be implemented using multicast or unicast method as desired by implementation. In this respect, I have also mentioned the work that is being done in 3GPP. They also embraced the mobile IP concept where both agent solicitation (similar to our GRQ) and agent advertisement (similar to our proposed MGA) are used. 3GPP has also proposed to use the agent advertisement message (similar to our proposed MGA) as "unicast" method as a mechanism to reduce the bandwidth consumption.

In this respect, as I was told in the Osaka meeting, I have clarified why MGA is an excellent proposal to interwork with mobile IP and 3GPP system if one wants to use mobile H.323 in the upper layer.

Furthermore, MGA is not a mandatory, but is an OPTIONAL message. If one does not like to use, they may not use it.

The conclusion is that both GRQ and MGA message will complement each other as the agent solicitation and agent advertisement message complement each other in mobile IP (as well as 3GPP), and thereby opens the way for interworking between mobile H.323 and mobile IP (when H.323 is implemented over the IP layer).

Without any mechanisms like MGA in H.323, mobility in H.323 will be highly "INCOMPLETE" and the mobile H.323 standard will almost be "meaningless" when the interworking with lower "mobile IP" layer is concerned. I do believe that we should NOT let it happen to the mobile H.323 standard.

I like to see that people should provide any "technical" reasons in this "public" email reflector (that is received by the SG16 people worldwide) why MGA is not acceptable. I will provide justification for each email and we will go from there.

Best regards, Radhika R. Roy

-----Original Message----- From: Jaakko Sundquist [mailto:jaakko.sundquist@nokia.com] Sent: Monday, July 10, 2000 3:16 AM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: [H.323 Mobility:] A new H.323 Annex H Draft

Hi Radhika et al,

Let's try to start a bit of discussion...

It is nice to see that you and Mr. Kumar had a communication related to GRQ and you have included in the contribution.

Yes, actually Mr. Kumar raised this point already in Osaka, but it seems to have been kind of lost in the conversations. At least I did not quite grasp this issue at that time. It does seem a perfectly valid point though (if someone has a counter-argument, please inform us).

[RRR] I also think that it is a reasonable idea. If other members have any counter arguments, please let us know.

I wonder what happened to the emails that I sent to the SG16 email "public" reflector related to MGA message! I have not seen any counter arguments related to this in the email reflector. I like to see that MGA message is also included (with both unicast and multicast option as suit the implementation).

Your emails did arrive, or at least I saw them. The reflector seems to have been quite quiet recently, perhaps some people are having their holidays (I did, before I had time to comment on your emails). As for the MGA issue. I think we had a quite good discussion on that in Osaka and it seemed to me that really no one else was in favor of the idea. Most people, including myself, came to the conclusion that the MGA scheme would be less efficient instead of being more efficient than multicasting GRQs. Thus far I haven't seen anything that would convince me otherwise (I don't remember exactly, what you said in your last email about the MGA, but I did read it and did not find any new arguments in favor of the MGA). Furthermore, I think that having two alternate multicasting schemes for gatekeeper discovery would only lead to difficulties both in making an explicit and robust annex as well as in implementation of the mobile H.323 system described in the annex.

[RRR] Please see my reply provided above. Please provide your or other members' "TECHNICAL" arguments against my explanations provided above instead of "simply" saying that you are not "convinced" or something like that. This is a qualitative statement and does not provide any technical explanations.

I would also appreciate that you should start discussing in the email reflector before any further update is made in the document so that we can participate in the process for updating the document. The discussion can be formulated as follows:

1. What you want to propose and why
2. Pros and cons of the proposals
3. Invite comments from the members
4. Update the document based on item 3

As you mentioned, I have tried to do steps 1 and 2 in the emails I have sent to the reflector. The idea behind this approach of me sending a draft (or editor's draft, if you will) every once in a while is step 3. By sending a whole new draft, I'm trying to force people to react to the changes. Step 4 will naturally be done after the discussions about the changes. You said that you will produce your comments on the new draft soon, good, that is precisely want I wanted (step 3). I hope others will do the same.

[RRR] I already provided my initial comments before going to the Osaka meeting with respect to your initial draft that was produced by you. Your original draft has not been changed much since then what has been in pre-Osaka meeting. If you look into those comments sent by me via emails and during the conference calls before the Osaka meeting, you may have a feel what I have to say. However, it is a valid point that I have to make my time to provide comments on your latest draft.

-Jaakko

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com