Mr.L's TG configuration feature

[Li Li]

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 at nokia.com]
Sent: Wednesday, July 12, 2000 4:10 AM
To: ITU-SG16 at 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 at mailbag.intel.com

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