Information Service discussion
Being suggested by our Chair, let me forward some email exchanges in
IETF MIPSHOP. I think we need to discuss this kind of thing in
802.21.
Yoshihiro Ohba
----- Forwarded message from James Kempf <Kempf@docomolabs-usa.com> -----
X-VirusChecked: Checked
X-Env-Sender: kempf@docomolabs-usa.com
X-Msg-Ref: server-12.tower-53.messagelabs.com!1129134927!66195540!1
X-StarScan-Version: 5.4.15; banners=-,-,-
X-Originating-IP: [216.98.102.225]
X-SpamReason: No, hits=3.1 required=7.0 tests=MSGID_DOLLARS
From: James Kempf <Kempf@docomolabs-usa.com>
To: Yoshihiro Ohba <yohba@tari.toshiba.com>,
Singh Ajoy-ASINGH1 <ASINGH1@motorola.com>
Cc: Yoshihiro Ohba <yohba@tari.toshiba.com>,
Rajeev Koodli <rajeev@iprg.nokia.com>, mipshop@ietf.org,
gabriel_montenegro_2000@yahoo.com,
Petrescu Alexandru-AAP021 <alexandru.petrescu@motorola.com>
Subject: Architectural Considerations for Handover Information Services (was: Re: CARD Discussion Query Discussion)
X-UIDL: ~F$#!$,S!!kkY"!gZ'"!
Yoshi,
>I think generic query is needed to support heterogeneous handovers in
>an efficient, flexibile and extensible way, but to me CARD is not
>designed for that since it does not support a schema language and a
>query language.
>
My experience from SLP is that people don't want this kind of complexity for
a system level network service that is terminal to network. They typically
want to do the query processing on the client side. We're not talking about
something like Google here, but rather something more like the information
that's involved in subnet configuration, with perhaps a little more
information involved.
>Any protocol can be extended to carry data that was not supposed to be
>carried in its original design. You may want to argue in the same way
>that CARD can carry LDAP queries if you need LDAP (and which would
>make CARD less reastic solution). BTW, if you want to carry XML, use
>of http (or http over TLS if you need a secure channel) would be much
>easier to deploy.
I know there are some people in 802.21 that want a full text search service,
but I believe that would be a mistake, and I think it would actually hinder
deployment on the terminal. SLP did have such a full query service and it
has not seen wide deployment, neither did UpNP, which actually did used
HTTP. The only place where I think an XML/HTTP solution would be attractive
is between some near-access network element, like an AR or AP, and a server
back in the network that is aggregating the handover services information,
as an alternative to LDAP, COPS, or some other such protocol. Then the AR or
AP could serve the information to the terminal in a lighter weight fashion.
In addition, I don't think an XML/HTTP solution would satisfy FMIP's needs.
If 802.21 does decide on a complex XML/HTTP solution, I would support
returning to the simple ICMP options approach used in the current
Experimental draft for FMIP. In my opinion, this would be a lost opportunity
for some needed consolidation of functionality in handover services.
jak
----- End forwarded message -----
----- Forwarded message from Yoshihiro Ohba <yohba@tari.toshiba.com> -----
From: Yoshihiro Ohba <yohba@tari.toshiba.com>
Subject: Re: Architectural Considerations for Handover Information Services
(was: Re: CARD Discussion Query Discussion)
To: James Kempf <Kempf@docomolabs-usa.com>
Cc: Yoshihiro Ohba <yohba@tari.toshiba.com>,
Singh Ajoy-ASINGH1 <ASINGH1@motorola.com>,
Rajeev Koodli <rajeev@iprg.nokia.com>, mipshop@ietf.org,
gabriel_montenegro_2000@yahoo.com,
Petrescu Alexandru-AAP021 <alexandru.petrescu@motorola.com>
User-Agent: Mutt/1.5.11
X-UIDL: G6L"!F@8"!5$a"!W+<!!
Hi James,
On Wed, Oct 12, 2005 at 09:35:26AM -0700, James Kempf wrote:
> Yoshi,
>
> >I think generic query is needed to support heterogeneous handovers in
> >an efficient, flexibile and extensible way, but to me CARD is not
> >designed for that since it does not support a schema language and a
> >query language.
> >
>
> My experience from SLP is that people don't want this kind of complexity
> for a system level network service that is terminal to network. They
> typically want to do the query processing on the client side. We're not
> talking about something like Google here, but rather something more like
> the information that's involved in subnet configuration, with perhaps a
> little more information involved.
I agree that we are not talking about Google like searching scheme
where the client just enters keywords to search for particular
information (please see below also on this). Also, I am in line with
the discussion on handover information service where the client would
do query processing. Speaking about 802.21 IS where heterogeneity is
dominant, I have a different opinion about the last sentence: the
"little more information" part in your comment could be more important
and it could be actually "much more information".
>
> >Any protocol can be extended to carry data that was not supposed to be
> >carried in its original design. You may want to argue in the same way
> >that CARD can carry LDAP queries if you need LDAP (and which would
> >make CARD less reastic solution). BTW, if you want to carry XML, use
> >of http (or http over TLS if you need a secure channel) would be much
> >easier to deploy.
>
> I know there are some people in 802.21 that want a full text search
> service, but I believe that would be a mistake, and I think it would
> actually hinder deployment on the terminal. SLP did have such a full query
> service and it has not seen wide deployment, neither did UpNP, which
> actually did used HTTP. The only place where I think an XML/HTTP solution
> would be attractive is between some near-access network element, like an AR
> or AP, and a server back in the network that is aggregating the handover
> services information, as an alternative to LDAP, COPS, or some other such
> protocol. Then the AR or AP could serve the information to the terminal in
> a lighter weight fashion.
There is some misunderstanding about 802.21 here. No one in 802.21 is
developing a solution for a full text search.
Yoshihiro Ohba
>
> In addition, I don't think an XML/HTTP solution would satisfy FMIP's needs.
> If 802.21 does decide on a complex XML/HTTP solution, I would support
> returning to the simple ICMP options approach used in the current
> Experimental draft for FMIP. In my opinion, this would be a lost
> opportunity for some needed consolidation of functionality in handover
> services.
>
> jak
>
>
>
>
----- End forwarded message -----
----- Forwarded message from James Kempf <Kempf@docomolabs-usa.com> -----
X-VirusChecked: Checked
X-Env-Sender: kempf@docomolabs-usa.com
X-Msg-Ref: server-4.tower-97.messagelabs.com!1129154507!48853978!1
X-StarScan-Version: 5.4.15; banners=-,-,-
X-Originating-IP: [216.98.102.225]
X-SpamReason: No, hits=3.1 required=7.0 tests=MSGID_DOLLARS
From: James Kempf <Kempf@docomolabs-usa.com>
To: Yoshihiro Ohba <yohba@tari.toshiba.com>
Cc: Yoshihiro Ohba <yohba@tari.toshiba.com>,
Singh Ajoy-ASINGH1 <ASINGH1@motorola.com>,
Rajeev Koodli <rajeev@iprg.nokia.com>, mipshop@ietf.org,
gabriel_montenegro_2000@yahoo.com,
Petrescu Alexandru-AAP021 <alexandru.petrescu@motorola.com>
Subject: Re: Architectural Considerations for Handover Information Services (was: Re: CARD Discussion Query Discussion)
X-UIDL: /F-"!:_,!!_A(!!JFn"!
>>My experience from SLP is that people don't want this kind of complexity
>>for a system level network service that is terminal to network. They
>>typically want to do the query processing on the client side. We're not
>>talking about something like Google here, but rather something more like
>>the information that's involved in subnet configuration, with perhaps a
>>little more information involved.
>
>I agree that we are not talking about Google like searching scheme
>where the client just enters keywords to search for particular
>information (please see below also on this). Also, I am in line with
Sorry, I should have made this clearer. I was not speaking of the actual
search syntax. Actually, I believe that is quite equivalent to what one
would want. I was talking about the volume of information behind the search.
The experience I was mentioning with SLP is that people don't want complex
query semantics (AND, OR, LESS-THAN, etc.) in the network. They want to do
that on the client side. And, since the volume of information is typically
not high for network information services like IS, using a simple query
semantics and sending all the information typically isn't such a problem.
>the discussion on handover information service where the client would
>do query processing. Speaking about 802.21 IS where heterogeneity is
>dominant, I have a different opinion about the last sentence: the
>"little more information" part in your comment could be more important
>and it could be actually "much more information".
>
>>
>>>Any protocol can be extended to carry data that was not supposed to be
>>>carried in its original design. You may want to argue in the same way
>>>that CARD can carry LDAP queries if you need LDAP (and which would
>>>make CARD less reastic solution). BTW, if you want to carry XML, use
>>>of http (or http over TLS if you need a secure channel) would be much
>>>easier to deploy.
>>
>>I know there are some people in 802.21 that want a full text search
>>service, but I believe that would be a mistake, and I think it would
>>actually hinder deployment on the terminal. SLP did have such a full
>>query
>>service and it has not seen wide deployment, neither did UpNP, which
>>actually did used HTTP. The only place where I think an XML/HTTP solution
>>would be attractive is between some near-access network element, like an
>>AR
>>or AP, and a server back in the network that is aggregating the handover
>>services information, as an alternative to LDAP, COPS, or some other such
>>protocol. Then the AR or AP could serve the information to the terminal
>>in
>>a lighter weight fashion.
>
>There is some misunderstanding about 802.21 here. No one in 802.21 is
>developing a solution for a full text search.
>
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.
jak
----- End forwarded message -----
----- Forwarded message from Yoshihiro Ohba <yohba@tari.toshiba.com> -----
From: Yoshihiro Ohba <yohba@tari.toshiba.com>
Subject: Re: Architectural Considerations for Handover Information Services
(was: Re: CARD Discussion Query Discussion)
To: James Kempf <Kempf@docomolabs-usa.com>
Cc: Yoshihiro Ohba <yohba@tari.toshiba.com>,
Singh Ajoy-ASINGH1 <ASINGH1@motorola.com>,
Rajeev Koodli <rajeev@iprg.nokia.com>, mipshop@ietf.org,
gabriel_montenegro_2000@yahoo.com,
Petrescu Alexandru-AAP021 <alexandru.petrescu@motorola.com>
User-Agent: Mutt/1.5.11
X-UIDL: XW+!!$`["!LU$"!j9""!
On Wed, Oct 12, 2005 at 03:01:46PM -0700, James Kempf wrote:
> >>My experience from SLP is that people don't want this kind of complexity
> >>for a system level network service that is terminal to network. They
> >>typically want to do the query processing on the client side. We're not
> >>talking about something like Google here, but rather something more like
> >>the information that's involved in subnet configuration, with perhaps a
> >>little more information involved.
> >
> >I agree that we are not talking about Google like searching scheme
> >where the client just enters keywords to search for particular
> >information (please see below also on this). Also, I am in line with
>
> Sorry, I should have made this clearer. I was not speaking of the actual
> search syntax. Actually, I believe that is quite equivalent to what one
> would want. I was talking about the volume of information behind the
> search. The experience I was mentioning with SLP is that people don't want
> complex query semantics (AND, OR, LESS-THAN, etc.) in the network. They
> want to do that on the client side. And, since the volume of information is
> typically not high for network information services like IS, using a simple
> query semantics and sending all the information typically isn't such a
> problem.
Your observation would be true for homogeneous handovers where "same
as me" type of information would be sufficient. In fact, 802.11e
neighbor report is being developed in such a design policy. However,
for heterogeneous handovers, different type of query like "different
from me, with specific degree" is more important, the volume of
information can be high unless queries are defined and constructed
very carefully. I believe query with rich semantics plays an
important role here, and that is why a schema is defined in 802.21.
>
> >the discussion on handover information service where the client would
> >do query processing. Speaking about 802.21 IS where heterogeneity is
> >dominant, I have a different opinion about the last sentence: the
> >"little more information" part in your comment could be more important
> >and it could be actually "much more information".
> >
> >>
> >>>Any protocol can be extended to carry data that was not supposed to be
> >>>carried in its original design. You may want to argue in the same way
> >>>that CARD can carry LDAP queries if you need LDAP (and which would
> >>>make CARD less reastic solution). BTW, if you want to carry XML, use
> >>>of http (or http over TLS if you need a secure channel) would be much
> >>>easier to deploy.
> >>
> >>I know there are some people in 802.21 that want a full text search
> >>service, but I believe that would be a mistake, and I think it would
> >>actually hinder deployment on the terminal. SLP did have such a full
> >>query
> >>service and it has not seen wide deployment, neither did UpNP, which
> >>actually did used HTTP. The only place where I think an XML/HTTP solution
> >>would be attractive is between some near-access network element, like an
> >>AR
> >>or AP, and a server back in the network that is aggregating the handover
> >>services information, as an alternative to LDAP, COPS, or some other such
> >>protocol. Then the AR or AP could serve the information to the terminal
> >>in
> >>a lighter weight fashion.
> >
> >There is some misunderstanding about 802.21 here. No one in 802.21 is
> >developing a solution for a full text search.
> >
>
> 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.
Regards,
Yoshihiro Ohba
>
> jak
>
>
>
----- End forwarded message -----
----- Forwarded message from James Kempf <Kempf@docomolabs-usa.com> -----
X-VirusChecked: Checked
X-Env-Sender: kempf@docomolabs-usa.com
X-Msg-Ref: server-6.tower-94.messagelabs.com!1129237516!0!1
X-StarScan-Version: 5.4.15; banners=-,-,-
X-Originating-IP: [216.98.102.225]
X-SpamReason: No, hits=3.1 required=7.0 tests=MSGID_DOLLARS
From: James Kempf <Kempf@docomolabs-usa.com>
To: Yoshihiro Ohba <yohba@tari.toshiba.com>
Cc: Yoshihiro Ohba <yohba@tari.toshiba.com>,
Singh Ajoy-ASINGH1 <ASINGH1@motorola.com>,
Rajeev Koodli <rajeev@iprg.nokia.com>, mipshop@ietf.org,
gabriel_montenegro_2000@yahoo.com,
Petrescu Alexandru-AAP021 <alexandru.petrescu@motorola.com>
Subject: Re: Architectural Considerations for Handover Information Services (was: Re: CARD Discussion Query Discussion)
X-UIDL: c4)#!pGi"!JU$!!j;7!!
----->> Sorry, I should have made this clearer. I was not speaking of the
actual
>>search syntax. Actually, I believe that is quite equivalent to what one
>>would want. I was talking about the volume of information behind the
>>search. The experience I was mentioning with SLP is that people don't
>>want
>>complex query semantics (AND, OR, LESS-THAN, etc.) in the network. They
>>want to do that on the client side. And, since the volume of information
>>is
>>typically not high for network information services like IS, using a
>>simple
>>query semantics and sending all the information typically isn't such a
>>problem.
>
>Your observation would be true for homogeneous handovers where "same
>as me" type of information would be sufficient. In fact, 802.11e
>neighbor report is being developed in such a design policy. However,
>for heterogeneous handovers, different type of query like "different
>from me, with specific degree" is more important, the volume of
>information can be high unless queries are defined and constructed
>very carefully. I believe query with rich semantics plays an
>important role here, and that is why a schema is defined in 802.21.
>
But I don't believe the volume of information will be high enough to justify
a complex query language. How much really is there to say about next link
characteristics that could help intertechnology handover? Our experience
with SLP was that nobody wanted this capability for service discovery unless
the amount of data available in the network database runs to megabytes, such
as with an LDAP directory, and even then, as with DNS, it is often
unnecessary if the information itself is straightforward and fairly limited
in scope. It is especially hard to construct complex queries automatically.
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.
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"?
jak
----- End forwarded message -----
----- Forwarded message from Yoshihiro Ohba <yohba@tari.toshiba.com> -----
From: Yoshihiro Ohba <yohba@tari.toshiba.com>
Subject: Re: Architectural Considerations for Handover Information Services
(was: Re: CARD Discussion Query Discussion)
To: James Kempf <Kempf@docomolabs-usa.com>
Cc: Yoshihiro Ohba <yohba@tari.toshiba.com>,
Singh Ajoy-ASINGH1 <ASINGH1@motorola.com>,
Rajeev Koodli <rajeev@iprg.nokia.com>, mipshop@ietf.org,
gabriel_montenegro_2000@yahoo.com,
Petrescu Alexandru-AAP021 <alexandru.petrescu@motorola.com>
User-Agent: Mutt/1.5.11
X-UIDL: ;pl"!MFS"!?mW"!">,!!
On Thu, Oct 13, 2005 at 02:05:15PM -0700, James Kempf wrote:
>
> ----->> Sorry, I should have made this clearer. I was not speaking of the
> actual
> >>search syntax. Actually, I believe that is quite equivalent to what one
> >>would want. I was talking about the volume of information behind the
> >>search. The experience I was mentioning with SLP is that people don't
> >>want
> >>complex query semantics (AND, OR, LESS-THAN, etc.) in the network. They
> >>want to do that on the client side. And, since the volume of information
> >>is
> >>typically not high for network information services like IS, using a
> >>simple
> >>query semantics and sending all the information typically isn't such a
> >>problem.
> >
> >Your observation would be true for homogeneous handovers where "same
> >as me" type of information would be sufficient. In fact, 802.11e
> >neighbor report is being developed in such a design policy. However,
> >for heterogeneous handovers, different type of query like "different
> >from me, with specific degree" is more important, the volume of
> >information can be high unless queries are defined and constructed
> >very carefully. I believe query with rich semantics plays an
> >important role here, and that is why a schema is defined in 802.21.
> >
s/802.11e/802.11k/ in my text above, sorry.
> But I don't believe the volume of information will be high enough to
> justify a complex query language. How much really is there to say about
> next link characteristics that could help intertechnology handover? Our
> experience with SLP was that nobody wanted this capability for service
> discovery unless the amount of data available in the network database runs
> to megabytes, such as with an LDAP directory, and even then, as with DNS,
> it is often unnecessary if the information itself is straightforward and
> fairly limited in scope. It is especially hard to construct complex queries
> automatically.
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.
> 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.
>
> 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.
Regards,
Yoshihiro Ohba
>
> jak
>
>
>
----- End forwarded message -----
----- Forwarded message from James Kempf <Kempf@docomolabs-usa.com> -----
X-VirusChecked: Checked
X-Env-Sender: kempf@docomolabs-usa.com
X-Msg-Ref: server-13.tower-74.messagelabs.com!1129244287!62174956!1
X-StarScan-Version: 5.4.15; banners=-,-,-
X-Originating-IP: [216.98.102.225]
X-SpamReason: No, hits=3.1 required=7.0 tests=MSGID_DOLLARS
From: James Kempf <Kempf@docomolabs-usa.com>
To: Yoshihiro Ohba <yohba@tari.toshiba.com>
Cc: Yoshihiro Ohba <yohba@tari.toshiba.com>,
Singh Ajoy-ASINGH1 <ASINGH1@motorola.com>,
Rajeev Koodli <rajeev@iprg.nokia.com>, mipshop@ietf.org,
gabriel_montenegro_2000@yahoo.com,
Petrescu Alexandru-AAP021 <alexandru.petrescu@motorola.com>
Subject: Re: Architectural Considerations for Handover Information Services (was: Re: CARD Discussion Query Discussion)
X-UIDL: IR^"!TX\"!&6:!!T'~!!
>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
----- End forwarded message -----
----- Forwarded message from Yoshihiro Ohba <yohba@tari.toshiba.com> -----
From: Yoshihiro Ohba <yohba@tari.toshiba.com>
Subject: Re: Architectural Considerations for Handover Information Services
(was: Re: CARD Discussion Query Discussion)
To: James Kempf <Kempf@docomolabs-usa.com>
Cc: Yoshihiro Ohba <yohba@tari.toshiba.com>,
Singh Ajoy-ASINGH1 <ASINGH1@motorola.com>,
Rajeev Koodli <rajeev@iprg.nokia.com>, mipshop@ietf.org,
gabriel_montenegro_2000@yahoo.com,
Petrescu Alexandru-AAP021 <alexandru.petrescu@motorola.com>
User-Agent: Mutt/1.5.11
X-UIDL: l<$"!6+?!!<&H!!5a)!!
On Thu, Oct 13, 2005 at 03:58:05PM -0700, James Kempf wrote:
> >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.
We may think about why SIP compression is invented.
>
> >>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.
I would care the degree of postprocess, though I would much care
getting too much unnecessary information over the air.
>
> >>
> >>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.
I don't think the two applications need to work together if
requirements on the two are different. I will disagree if someone
claims that requirements on the two must be the same. BTW, I am
claiming that a query language that works with a schema language is
needed. Whether it should be XML-based or not is not the essential
issue to me (but I don't think SLP and LDAP are better than XML from
deployment perspective.)
Yoshihiro Ohba
>
> Anybody else have an opinion?
>
> jak
>
>
>
----- End forwarded message -----
----- Forwarded message from James Kempf <Kempf@docomolabs-usa.com> -----
X-VirusChecked: Checked
X-Env-Sender: kempf@docomolabs-usa.com
X-Msg-Ref: server-8.tower-75.messagelabs.com!1129305814!61873778!1
X-StarScan-Version: 5.4.15; banners=-,-,-
X-Originating-IP: [216.98.102.225]
X-SpamReason: No, hits=3.1 required=7.0 tests=MSGID_DOLLARS
From: James Kempf <Kempf@docomolabs-usa.com>
To: Yoshihiro Ohba <yohba@tari.toshiba.com>
Cc: Yoshihiro Ohba <yohba@tari.toshiba.com>,
Singh Ajoy-ASINGH1 <ASINGH1@motorola.com>,
Rajeev Koodli <rajeev@iprg.nokia.com>, mipshop@ietf.org,
gabriel_montenegro_2000@yahoo.com,
Petrescu Alexandru-AAP021 <alexandru.petrescu@motorola.com>
Subject: Re: Architectural Considerations for Handover Information Services (was: Re: CARD Discussion Query Discussion)
X-UIDL: <Np!!@&l"!n^~!!fL'#!
>>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.
>
>We may think about why SIP compression is invented.
>
There is no reason why the protocol must use text. The only reason SIP does
is because it evolved from SMTP. Arguably, text makes sense for SMTP because
the protocol is carrying email, but for SIP it is just a historical
accident.
NED and CARD leave the choice of representation up to the definer of the
information element. FMIP uses a compact binary representation, 802.21 IS
could use that too if the size of the messages is a concern.
jak
----- End forwarded message -----