Hi, Jaakko:
Let me clarify few things as follows:
1. All RAS messages are OPTIONAL. 2. H.323 mobility is applicable for all networking environment: Wireless [pico-, micro-, macro-cell]), wireless LAN, and/or wire-line network.
Therefore, all wireless environment is NOT bandwidth restrictive.
So, all H.323 entities are supposed to understand all RAS messages following the same principles. That is, if one does not like to use MGA, they will use GRQ (a simple timeout mechanism will do this). Please see how mobile IP is using these mechanisms. We do not need to re-INVENT the wheel.
With respect to unicast implementation, kindly see how 3GPP is implementing mobile IP's "agent advertisement (similar to our MGA)" message. As I told you in my earlier emails sometime ago, the unicast method becomes psedo-dynamic considering the mobile environment.
Last of all, it would be helpful to understand why mobile IP is using both "agent solicitation (like our GRQ)" and "agent advertisement (like our MGA)" for their solutions. Please also see why 3GPP has also accepted the mobile IP's both messages in their bandwidth restrictive environment. 3GPP's wireless networking environment will be one of our targets for implementation of our mobile H.323 solution. Mobile H.323 solution will NOT fly if the lower layer mobility (like 3GPP's mobile IP, IETF mobile IP) solution is NOT complemented or supported.
H.323 mobility solution MUST provide a "hook" to interwork with the mobile IP.
As an editor, I suggest to take a break for now and let other members participate in technical discussions because you are doing both - writing all you stuffs directly into the document as if you are making it a Rapporteur contribution as well opposing other contributions. The question is: Who will act moderator when there are disputes?
I would not raise this question if you would explain why IETF and 3GPP folks are using both "agent solicitation (like our GRQ)" and "agent advertisement message (like our proposed MGA)" of mobile IP to solve the mobility problems.
Best regards, Radhika R. Roy
-----Original Message----- From: Jaakko Sundquist [mailto:jaakko.sundquist@nokia.com] Sent: Tuesday, July 11, 2000 6:27 AM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: [H.323 Mobility:] About GK discovery
Hi again Radhika et al,
The discussion seems to be directed only to the MGA issue, but that's fine... I would like to encourage other members to join in as well.
Maybe I should at first clarify the situation that I am thinking of when we discuss these different gatekeeper discovery methods. The general case in a global mobile H.323 system would be that when a terminal changes location so that it needs to find a new gatekeeper, it does not have any knowledge of the part of the H.323 system it is about to attach to. In other words, it does not know the addresses of any gatekeepers to which it should register (obviously) nor would it know which gatekeeper discovery method is used (or which is the default one) in this environment. Similarly, of course, the gatekeepers in that part of the H.323 system are unaware of the new terminal and the default gatekeeper discovery method that it wishes to use, before the terminal sends some message (e.g. the GRQ) to them.
The rest of my comments (identified with [Jaakko:]) below.
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.
[Jaakko:] In Osaka we discussed mostly the case in which the last link towards the terminals is a radio link, e.g. the cellular access network case. I think it was quite clearly stated that multicasting the MGA message to all radio channels would be a waste of bandwidth (which is always scarce in radio links) compared to the GRQ method in which the multicasting is done only once per a terminal location change. How would you use unicasting in this case? In particular to whom would you unicast the MGA? If we think about other types of media, i.e. non-wireless terminal access, the situation may be somewhat different in some cases. Ultimately the normal ethernet uses broadcasting anyway, so multicasting the MGA to all terminals in a segment would consume the same amount of bandwidth as unicasting the message to one of the terminals. In this case the bandwidth consumption would be a function of the frequency of the multi/unicasted MGA messages, whereas when using the GRQ method the bandwidth consumption would be a function of the location changes of the terminal. Thus, the MGA method would be more efficient only when terminal location changes occur more frequently on average than the frequency at which the MGA is sent. When remembering that the period between two consecutive MGA messages should not be too long so that the terminal does not need to wait for it too long when it changes location, the MGA method does not seem to be more efficient very often. Also, this reasoning applies only to cases in which multicasting and unicasting consume the same amount of bandwidth. If this is not the case, the situation becomes even worse for the MGA method. I do not understand what you mean by "using the MGA in a unicast mode". To whom it is unicasted? Who unicasts it? When is it unicasted? (See my description of the general GK discovery situation above.)
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.
[Jaakko:] Do you have any pointers to the documents of 3GPP for this issue? I would be very interested to take a look at them. As I do not understand the concept of unicasted MGAs, I do not see how bandwidth consumption could be reduced.
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.
[Jaakko:] If I understand correctly, the 3GPP is thinking of using mobile IP protocol in some way to provide a certain level of mobility. Now, I do not see, how the inclusion of MGA (or any other message) would help the interworking of mobility enhanched H.323 and mobile IP. The agent advertisement and the agent solicitation are messages of the mobile IP protocol. Thus the H.323 layer is not aware nor can use these messages. Or am I totally wrong when I think that you can not send an MGA message inside mobile IP's agent advertisement message? Or what do you mean by the MGA helping when interworking with mobile IP? Surely, it does not help in any way just to have similar methods (or messages) in the upper (H.323) layer as in the lower (mobile IP) layer, if these have no connection with each other.
Furthermore, MGA is not a mandatory, but is an OPTIONAL message. If one does not like to use, they may not use it.
[Jaakko:] Yes, but even an optional message must have some practical use, or in this case a clear advantage, at least in some cases (preferably cases that would actually apply in a reasonbly big portion of real life implementations), compared to the multicasted GRQ. For example, if I would bring in a contribution proposing a new optional message called IA (Ilves Advertisement), which would contain the text: "Ilves is the best!", would you be happy to accept that? That message would probably make the fans of my favorite ice-hockey team very happy, but I doubt, if that is a big enough purpose for introducing such a big change in the protocol as adding a message is, even if the message is optional. Furthermore, I strongly believe that a multicasting scheme (i.e. multicasted GRQs or the MGA scheme) is necessary in a real global mobile H.323 system for discovering the visited GK. (Mr. Kumar proposed in Osaka schemes involving either the User inputting the location or the Home GK being able to tell the address of the Visited GK. I don't think that either of these is a good enough or scalable method for global usage. See my comments of the general GK discovery case.) Thus, if we have two alternate multicasting methods for the GK discovery, which one should the terminal try first? If the terminal expects to use the MGA, how long should it wait for the MGA message, before sending the GRQ, i.e. how long should the default period between the MGAs be? If the default period is short, the terminal does not have to wait long, but in this case the bandwidth consumption of MGAs becomes large, because of frequent transmissions. The terminal is not reachable while it is waiting for the MGA, so the period can not be very long either. On the other hand, if multicasting GRQs is the default GK discovery method, no terminal will wait for the MGA anyway. If the terminal can be configured to use either of these methods, the gatekeepers will always have to implement both methods and so the MGA will actually not be optional for the gatekeepers. So, my question is: What is the problem that the GRQ method has and that would be solved by using the MGA? I will be happy to include the method in the standard, if you can show that there is a clear advantage in using it (in a way that also others beside me accept the reasoning).
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).
In my opinion, we do not need both methods. Again, how would the inclusion of MGA open the way for interworking between mobile H.323 and mobile IP?
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.
[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 have a problem here. You say that I only provide "non-technical" or "qualitative" arguments. That may have been true in my last email, but I found it a bit difficult to provide new technical arguments, when I did not actually find any new technical arguments supporting the use of MGA in your email (the one you sent right after Osaka). Perhaps I just did not understand something, so could you clarify your statements a bit? In the same manner, I could ask you to explain in technical terms, why H.323 will be "INCOMPLETE" without the MGA (just using mobile IP as a model is not a technical argument) and what exactly is the mobile H.323 to mobile IP interworking that you are talking about? Your original argument for using the MGA was that the method saves bandwidth. That argument was counter-argumented quite heavily in Osaka and I haven't seen a single technical argument from you that would prove otherwise. When I used the phrase: "I'm still not convinsed" I was meaning just that. I'm sorry, if I did not make myself clear, but I just did not want to write the same arguments used in Osaka once again. I hope that I have produced better technical arguments in this email.
Anyway, let's continue the discussion and perhaps address other issues as well, after you have produced your comments on the new 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