Hi, Jaakko:

You are right that someone else should also take part in the technical discussion other than the two of us. Editor's main role is to perform moderation while providing fair chances for all.

First of all, mobile IP did a very good argument while they designed the protocol, and bandwidth argument has been one of them. One of the points has been that bandwidth can be changed if the frequency of the "agent discovery" (similar to our MGA)message is changed. If you look into specs of mobile IP very carefully, you can see it (If needed, I can discuss with you in great detail what mobile IP did in the upcoming August'00 meeting). Even mobile IP folks prefer that "agent discovery message (similar to our MGA)" should be used instead of "agent solicitation (similar to our GRQ)." they have placed restrictions in using the "agent solicitation (similar to our GRQ)" message in mobile IP, but not for the "agent discovery message (similar to our MGA)" message.

However, 3GPP folks did not like this. They like to use mobile IP's "agent discovery" message, but do not like multicast. So, they like to use "agent discovery" message using the unicast method. They have designed an implementation method how "unicast" should be done. As a result, they have created a "pseudo dynamic" environment for agent discovery. I guess that their primary concern has been to save the bandwidth not by reducing the frequency of the message, rather by making the situation less dynamic for the mobile environment using unicast method so that only bare minimum bandwidth is used.

I am inviting technical comments from all members if they have any concerns related to the MGA message as proposed by AT&T contributions.

Best regards, Radhika R. Roy

-----Original Message----- From: Jaakko Sundquist [mailto:jaakko.sundquist@nokia.com] Sent: Wednesday, July 12, 2000 4:10 AM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: [H.323 Mobility:] About GK discovery

Hi Radhika et al,

You're right, there is no point in continuing this discussion without other members' participation in it. I'll just make a couple of short points and then wait for hopefully somebody else to make their comments.

Therefore, all wireless environment is NOT bandwidth restrictive.

Nor is wireline, of course. The point was that when you introduced the idea of the MGA, your argument was that it would SAVE bandwidth. In fact, as far as I could understand, this was the only argument you had for the use of MGA. Now you are saying that, although the MGA probably uses more bandwidth than the GRQ scheme, it is alright, because in some networks, the bandwidth is not so scarse.

We discussed the idea of the MGA in Osaka and if you can remember, none of the participants of the discussion were supporting the addition of this message to H.323 (or RAS, to be more specific). When the bandwidth issue was discussed, I remember that you were asked to produce some data or information that would support the idea that in some cases the MGA would save bandwidth. So far you have not done so. So, as I said earlier, I'm happy to include the MGA in the annex, if you are able to convince, not only me, but other memebers interested in the issue, about the merits of the MGA scheme. Unfortunately this discussion hasn't been participated by the others so far.

The idea of better interworking with mobile IP might be a reason for introducing the MGA. However, you yourself asked for technical reasoning and now I'm asking the same from you. Modelling other protocols is often a good guide in protocol design (and we surely have used it), but my opinion (and I feel it is shared by many others) is that just saying that because some other protocol has some, in this case alternate, mechanisms for doing something, is not a technical reason for adding exactly the same mechanisms to our protocol. You are asking me to explain why mobile IP uses these two mechanisms, but I think it is you who should explain that and furthermore explain why both of these are needed in H.323.

Now, let's open the discussion for other members, I can see that this dialogue is not leading us anywhere.

-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