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(a)mailbag.intel.com
