Straw poll
was mentioned in that context. See
below the email thread.
Regards,
Ajoy
From:
Subir Das [mailto:subir@RESEARCH.TELCORDIA.COM]
Sent: Friday, October
14, 2005
3:59 PM
To:
STDS-802-21@LISTSERV.IEEE.ORG
Subject: Re: [802.21]
[Mipshop]
Re: Architectural Considerations for Handover InformationServices (was:
Re:
CARD Discussion Query Discussion)
Why are we
discussing .21 straw poll here? I
think we are not addressing the point
that Mipshop chairs wanted to know from .21 folks about their charter
(in
particular
.21 related text). Instead, we are discussing many other things that
are not
very
relevant at this stage, IMO. I think Michael Williams, vice chair
of .21 has nicely
stated the 802.21's objectives. I agree with him and to me also the
scope
of .21 IS
is broader than any specific mobility protocol related IS.
Regards,
-Subir
I
also think simple TLV based approach should be good.
Regards,
Ajoy
-----Original
Message-----
From:
mipshop-bounces@ietf.org [mailto:mipshop-bounces@ietf.org]
On
Behalf Of Gupta, Vivek G
Sent:
Friday, October 14, 2005 8:01 AM
To:
James Kempf; Yoshihiro Ohba
Cc:
mipshop@ietf.org; gabriel_montenegro_2000@yahoo.com;
Rajeev Koodli; Petrescu Alexandru-AAP021
Subject:
RE: [Mipshop] Re: Architectural Considerations for
Handover InformationServices (was: Re: CARD Discussion Query Discussion)
I
agree with most of James' comments here.
Queries
can be implemented in many ways and that's why I am
not sure we need to *standardize* a particular/specific query
language/mechanism.
Having
something simple like just TLV as a starting point for
different IEs allows others to build on top of this and come up with
appropriate mechanisms as necessary.
BR,
-Vivek
-----Original
Message-----
From:
mipshop-bounces@ietf.org [mailto:mipshop-bounces@ietf.org]
On
Behalf Of James Kempf
Sent:
Thursday, October 13, 2005 3:58 PM
To:
Yoshihiro Ohba
Cc:
mipshop@ietf.org; gabriel_montenegro_2000@yahoo.com;
Rajeev Koodli; Petrescu Alexandru-AAP021
Subject:
[Mipshop] Re: Architectural Considerations for
Handover InformationServices (was: Re: CARD Discussion Query Discussion)
>
It is obviously more hard and inefficient for the client
to process
>
high volume of raw data provided by the networks to
extract a piece of
>
information in which the mobile is interested and choose
an
>
appropriate network, than to construct a semantic query
to retrieve
>
only necessary information it is really interested
in. The raw data
>
can be order of hundred kilobytes if there are 10 MAC
types each has
>
20 or more neighboring point of attachments each
advertising hundreds
>
of bytes of information and most of the data could be
just garbage and
>
for the client and it is wastful in terms of both
bandwidth and
>
processing resources. If the mobile is moving at a
high-speed, then
>
information on "neighbors of neighbors" needs
to be obtained to
>
proactively make handover decisions, then the
information volume can
>
be more.
>
But
at 100 Mbps (802.11n speed) 100K is just 1 msec.
Even at 11 Mbps, its still only 100 msec. if there's no contention for
the
link. It's just not a problem with today's bandwidths, IMHO. We're not
talking
about 9.6 kbps links anymore. And I'm not saying that there should be
no query
language, just that it should be simple.
>>
Since I don't think typical users want to be
bothered with specifying
>>
the details of querying for handover services
information,
it
>>
seems that automatic query construction would be
required. Most users
>>
want
>>
some kind of symbolic or summary information, if
they need to be
involved
>>
in an intertechnology handover decision.
>
>
I believe automatic query construction can be made for
any query
>
methods.
>
Well,
I know (from having implemented it with SLP) that it is
hard. It is much easier to haul over what you need and process it
locally. What
happens is the query typically ends up getting stuff you don't want
anyway,
regardless of how careful you are in constructing it, so you typically
need to
postprocess anyway. So why bother to have all the code and complexity
of trying
to do the automatic query construction? Application developers then
don't
bother to use the complex query language, so you end up having this
substantial
chunk of code in the protocol processing that isn't used most of the
time.
>>
>>
It is much easier to just ask for the available
information, then do
the
>>
processing on the client. I can't see the amount of
information on
>>
handover services being so large that it would be
unreasonable to
>>
send over
the
>>
wireless link, especially given the trend toward
increased bandwidth.
>>
>>
>>I actually mean "using complex query
semantics" not "full text".
>>
>>Systems
>>
>>with complex query semantics in the network
haven't been very
>>
>>successful in the network information
services area. For example,
>>
>>DNS has very
simple
>>
>>query semantics. LDAP has very complex query
semantics. People
prefer
>>
>>DNS.
>>
>>Query semantics is naturally not the only
reason why they prefer
DNS,
>>
>>of
>>
>>course, but having complex query semantics
has not proved such a
>>
>>compelling attraction to motivate people to
use LDAP for directory
>>
>>services instead of DNS (though LDAP was for
a time considered to
>>
>>be a possible
successor
>>
>>to
>>
>>DNS). There are other examples I could cite,
and I don't think we
need
>>
>>to
>>
>>get into a debate here about this particular
example. For this
reason,
>>
>>I
>>
>>believe that having a simple query
semantics, using keywords or the
>>
>>like,
>>
>>is a better solution than complex queries.
>>
>
>>
>I believe a solution depends on the detailed
requirements on the
>>
>service provided by it, not directly on the area
the service belongs
>>
>to.
>>
>
>>
>>
I'm not sure I understand your point. What do you
mean by "the area
the
>>
service belongs"?
>
>
I mean the area of network information services.
>
>
BTW, I think this kind of discussion should be done in
802.21 where
>
Information Service for heterogenious handovers is being
defined.
>
No,
it needs to be done here too. You're claiming that you
want an XML
protocol
with complex query language. I disagree, based on my
experience
with
SLP and LDAP, that this is really any value in a
system-level
application
like network information services. Regardless of
what 802.21
wants,
we need something that provides network information
for FMIP, and
if
we
are going to try to get the two applications to work
together, we
need
to
come
up with a protocol that satisfies both.
Anybody
else have an opinion?
jak
_______________________________________________
Mipshop
mailing list
Mipshop@ietf.org
https://www1.ietf.org/mailman/listinfo/mipshop
_______________________________________________
Mipshop
mailing list
Mipshop@ietf.org
https://www1.ietf.org/mailman/listinfo/mipshop
Singh Ajoy-ASINGH1 wrote:
Hi Michael,
I think the issue of TLV and XML was discussed during 802.21 meeting.
But it appears to me that more folks supported the idea of TLV in last
802.21 meeting. I guess there was straw poll as well. Do you have any
result of straw poll? It may be good data point about 802.21's view
about XML versus TLV.
Regards,
Ajoy
-----Original Message-----
From: mipshop-bounces@ietf.org [mailto:mipshop-bounces@ietf.org] On
Behalf Of Michael.G.Williams@nokia.com
Sent: Thursday, October 13, 2005 6:38 PM
To: Kempf@docomolabs-usa.com; yohba@tari.toshiba.com
Cc: mipshop@ietf.org; gabriel_montenegro_2000@yahoo.com;
rajeev@iprg.nokia.com; Petrescu Alexandru-AAP021
Subject: RE: [Mipshop] Re: Architectural Considerations for Handover
InformationServices (was: Re: CARD Discussion Query Discussion)
Colleagues,
A couple of points regarding the issue of chartering / standardizing for
FMIP needs, and getting .21 & MIPSHOP to work together...
We are at the draft stage in 802.21 and need proposals to modify the
draft.
.21 is counting on the solution in the IETF to be
compatible/interoperable with the IEEE solution. Sorry to be so high
level on that statement.
.21 requires an IS solution that solves problems for more than just
FMIP.
Perhaps the issues of IE representation and query language can be
separated to some degree? For example, if an alternative query language
exists today that would be useful, could it be used against the XML
representation?
.21 has expressed needs for extensibility and flexibility. The approach
of schemas and dynamic semantic agreements is one way to enable those
traits.
The issues of bandwidth & latency have been raised in both fora, but do
we have the empirical support for both sides of the issue?
Best Regards,
Michael
-----Original Message-----
From: mipshop-bounces@ietf.org [mailto:mipshop-bounces@ietf.org] On
Behalf Of ext James Kempf
Sent: Thursday, October 13, 2005 3:58 PM
To: Yoshihiro Ohba
Cc: mipshop@ietf.org; gabriel_montenegro_2000@yahoo.com; Rajeev Koodli;
Petrescu Alexandru-AAP021
Subject: [Mipshop] Re: Architectural Considerations for Handover
InformationServices (was: Re: CARD Discussion Query Discussion)
It is obviously more hard and inefficient for the client to process
high volume of raw data provided by the networks to extract a piece of
information in which the mobile is interested and choose an
appropriate network, than to construct a semantic query to retrieve
only necessary information it is really interested in. The raw data
can be order of hundred kilobytes if there are 10 MAC types each has
20 or more neighboring point of attachments each advertising hundreds
of bytes of information and most of the data could be just garbage and
for the client and it is wastful in terms of both bandwidth and
processing resources. If the mobile is moving at a high-speed, then
information on "neighbors of neighbors" needs to be obtained to
proactively make handover decisions, then the information volume can
be more.
But at 100 Mbps (802.11n speed) 100K is just 1 msec. Even at 11 Mbps,
its still only 100 msec. if there's no contention for the link. It's
just not a problem with today's bandwidths, IMHO. We're not talking
about 9.6 kbps links anymore. And I'm not saying that there should be no
query language, just that it should be simple.
Since I don't think typical users want to be bothered with specifying
the details of querying for handover services information, it seems
that automatic query construction would be required. Most users want
some kind of symbolic or summary information, if they need to be
involved in an intertechnology handover decision.
I believe automatic query construction can be made for any query
methods.
Well, I know (from having implemented it with SLP) that it is hard. It
is much easier to haul over what you need and process it locally. What
happens is the query typically ends up getting stuff you don't want
anyway, regardless of how careful you are in constructing it, so you
typically need to postprocess anyway. So why bother to have all the code
and complexity of trying to do the automatic query construction?
Application developers then don't bother to use the complex query
language, so you end up having this substantial chunk of code in the
protocol processing that isn't used most of the time.
It is much easier to just ask for the available information, then do
the processing on the client. I can't see the amount of information
on handover services being so large that it would be unreasonable to
send over the wireless link, especially given the trend toward
increased bandwidth.
I actually mean "using complex query semantics" not "full text".
Systems
with complex query semantics in the network haven't been very
successful in the network information services area. For example,
DNS has very simple query semantics. LDAP has very complex query
semantics. People prefer DNS.
Query semantics is naturally not the only reason why they prefer
DNS, of course, but having complex query semantics has not proved
such a compelling attraction to motivate people to use LDAP for
directory services instead of DNS (though LDAP was for a time
considered to be a possible successor to DNS). There are other
examples I could cite, and I don't think we need to get into a
debate here about this particular example. For this reason, I
believe that having a simple query semantics, using keywords or the
like, is a better solution than complex queries.
I believe a solution depends on the detailed requirements on the
service provided by it, not directly on the area the service belongs
to.
I'm not sure I understand your point. What do you mean by "the area
the service belongs"?
I mean the area of network information services.
BTW, I think this kind of discussion should be done in 802.21 where
Information Service for heterogenious handovers is being defined.
No, it needs to be done here too. You're claiming that you want an XML
protocol with complex query language. I disagree, based on my experience
with SLP and LDAP, that this is really any value in a system-level
application like network information services. Regardless of what 802.21
wants, we need something that provides network information for FMIP, and
if we are going to try to get the two applications to work together, we
need to come up with a protocol that satisfies both.
Anybody else have an opinion?
jak
_______________________________________________
Mipshop mailing list
Mipshop@ietf.org
https://www1.ietf.org/mailman/listinfo/mipshop
_______________________________________________
Mipshop mailing list
Mipshop@ietf.org
https://www1.ietf.org/mailman/listinfo/mipshop
_______________________________________________
Mipshop mailing list
Mipshop@ietf.org
https://www1.ietf.org/mailman/listinfo/mipshop