Subject: [Mipshop] CARD Discussion Query Discussion

From: "Singh Ajoy-ASINGH1" <[email-masked]>
Date: Tue, 11 Oct 2005 17:25:56 -0400

Hi, Ohba, 

Please find inline replies. I have changed subject from charter
discussion to CARD discussion. As folks have pointed out that technical
discussion is not part of MIPSHOP charter discussion. 

Regards,
Ajoy 

Although I don't still understand what is your criteria for stating
that CARD is generic CARD is generic enough for mobility related query
mechanism, I can say that CARD is at least NOT generic enough to
support heterogeneous handovers like 802.21 is dealing with for the
following reasons.

Ajoy-> I have looked at various information being considered by 802.21
and noticed that all these information can be queried using TLV based
mechanism provided by protocol such as CARD. But the Requirements and
the Preferences sub-option were not designed to express complex
relations among multiple AVPs like something used in database query.
Simplicity was one of the guidelines when CARD protocol was designed.
However, if you want to use, let say, XML scipt as a filter, you can
define an AVP for it in which the value portion becomes a generic XML
script. This approach provides flexibility to support implementations
with different level of complexity.

For example, CARD has an information filtering mechanism by based on
Preferences and Requirements Sub-Options where filtering is important
for reducing the amount of information exchanged over the air.

Ajoy-> Sure. The primary reason to use filter is to avoid sending
unnecessary information over the air. If bandwidth is not important then
you can make a generic query to receive all possible mobility related
information. 

However, when multiple AVPs are contained in the Preferences and
Requirements Sub-Options, CARD is not clear as to whether the
conditions specified by those AVPs are "AND" or "OR" conditions or
both "AND" and "OR" conditions can be mixed.  Also, the Requirements
Sub-Options do not seem to readily support inequality conditions such
as "greater than" or range of values without specifying all AVPs that
matches values in the range.  Also, I don't know how to specify a
requirement when only one AVP with multiple fields is contained in the
Requirements Sub-Option where the requirement is satisfied when only a
specific sub-field of the AVP matches the specified value. 

Ajoy-> If you need complex query like that you can encode XML script as
value of one new filter as pointed out above.

(BTW, I
don't understand why Preferences and Requirements should be
distinguished while both are just filtering conditions.)

Ajoy-> The reason to distinguish Requirements and Preferences
sub-options was again to maintain simplicity and clarity. The
Preferences sub-option is used to select a subset of attributes
interesting to the information requester. For example, you can express a
request like "give me data on channel, number of attached mobile
stations, ESSID of access points".
The Requirements sub-option is used to select a subset of neighboring
devices meeting certain criteria. For example, you can express a request
like "give me data of access points that support 802.11g interface or
3GPP". By combining Requirements and Preferences, you can create more
refined filters.

To repeat, the Requirements and Preferences sub-options were not
designed to be comparable to generic query languages or XML scripts. But
you can carry, for example, XML-script based filter as an AVP in the
sub-options.

Those issues are really important for dealing with heterogeneity.  I
think an appropriate schema language and query language are needed to
address those issues.  On the other hand, in the CARD protocol they
are not clearly addressed or just left as out of scope. 

Ajoy-> I hope by encoding XML encoded script inside a TLV encoded filter
might address your need. 

To me the current CARD protocol is proprietary solution and hard to be
applicable for supporting heterogeneous handovers.

Ajoy-> I hope my above answers might clarify some of your comments. 

Regards,
Yoshihiro Ohba

On Tue, Oct 11, 2005 at 08:55:26AM -0400, Singh Ajoy-ASINGH1 wrote:
> 
> 
> -----Original Message-----
> From: Yoshihiro Ohba [mailto:[email-masked]] 
> Sent: Monday, October 10, 2005 8:53 PM
> To: Singh Ajoy-ASINGH1
> Cc: Rajeev Koodli; [email-masked]; James Kempf;
> [email-masked]; Petrescu Alexandru-AAP021
> Subject: Re: [Mipshop] new charter
> 
> On Mon, Oct 10, 2005 at 04:20:25PM -0400, Singh Ajoy-ASINGH1 wrote:
> > 
> > Ajoy-> CARD provides generic query mechanism that can be used by
> mobile
> > node to query various mobility related information required for
proper
> > network selection. In my view, L2->L3 is nothing but one example of
> > information query.  IMHO, this does not belong to FMIP and better
left
> > to protocol such as CARD. 
> 
> I am not sure what is the definition of "generic" in the above text.
> As far as I understand, a more generic query mechanism (than CARD) is
> based on an information schema language together with a query language
> that works for querying information defined using the schema language.
> 
> Ajoy-> I am not comparing CARD query mechanism with XML. If folks
think
> XML is more appropriate then we will go with XML. CARD is generic
enough
> for mobility related query mechanism. 
> 
> Yoshihiro Ohba
> 
> > 
> > If CARD provides target AR selection or router - router
neoighborhood 
> > map population, that could be useful.
> > 
> > Ajoy-> CARD provides a mechanism for information query that can be
> used
> > by network selection purpose. Target network selection itself is
> > implementation.  
> > 
> > 
> > Regards,
> > 
> > -Rajeev
> > 
> > 
> > 
> > 
> > > 
> > > Regards,
> > > Ajoy 
> > > 
> > > -----Original Message-----
> > > From: Rajeev Koodli [mailto:[email-masked]] 
> > > Sent: Monday, October 10, 2005 2:31 PM
> > > To: Singh Ajoy-ASINGH1
> > > Cc: Petrescu Alexandru-AAP021; [email-masked]; James Kempf;
> > > [email-masked]
> > > Subject: Re: [Mipshop] new charter
> > > 
> > > 
> > > 
> > > Singh Ajoy-ASINGH1 wrote:
> > > 
> > > 
> > >>Ajoy-> I am confused why FMIPv6 needs to define Information
Service
> > >>protocol. 
> > > 
> > > 
> > > It does not.
> > > It continues to use the PrRt* messages, perhaps with a harmonized 
> > > message structure defined by the "handover information exchange"
> > > protocol.
> > > 
> > > -Rajeev
> > > 
> > > 
> > > 
> > >>I guess FMIPv6 was defined to take care of routing aspect of 
> > >>Fast Mobile/IP. CARD was deigned for Information Query Response
and
> > >>Context Transfer protocol was defined to transfer context from one
> AR
> > > 
> > > to
> > > 
> > >>other. 
> > >>
> > >>
> > >>
> > 
> > _______________________________________________
> > Mipshop mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/mipshop
> > 
> > 
> 
> 

_______________________________________________
Mipshop mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 11 Oct 2005 21:34:58 -0400

On Tue, Oct 11, 2005 at 05:25:56PM -0400, Singh Ajoy-ASINGH1 wrote:
> mechanism provided by protocol such as CARD. 

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.

> But the Requirements and

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.

Yoshihiro Ohba

---

From: "James Kempf" <[email-masked]>
Date: Wed, 12 Oct 2005 09:35:26 -0700

Yoshi,

> designed for that since it does not support a schema language and a

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.

> of http (or http over TLS if you need a secure channel) would be much

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

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 12 Oct 2005 16:43:28 -0400

Hi James,

On Wed, Oct 12, 2005 at 09:35:26AM -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
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".

> 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

> Experimental draft for FMIP. In my opinion, this would be a lost 
> opportunity for some needed consolidation of functionality in handover 
> services.
> 
>            jak
> 
> 
> 
>

---

From: "James Kempf" <[email-masked]>
Date: Wed, 12 Oct 2005 15:01:46 -0700

> 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.

> 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

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 12 Oct 2005 19:23:48 -0400

On Wed, Oct 12, 2005 at 03:01:46PM -0700, James Kempf wrote:
> 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.

> 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

---

From: "James Kempf" <[email-masked]>
Date: Thu, 13 Oct 2005 14:05:15 -0700

----->> Sorry, I should have made this clearer. I was not speaking of the 
actual
> 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.

> service provided by it, not directly on the area the service belongs

I'm not sure I understand your point. What do you mean by "the area the 
service belongs"?

            jak

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 13 Oct 2005 18:23:59 -0400

> >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.

> I'm not sure I understand your point. What do you mean by "the area the 

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

---

From: "James Kempf" <[email-masked]>
Date: Thu, 13 Oct 2005 15:58:05 -0700

> proactively make handover decisions, then the information volume can

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.

> I believe automatic query construction can be made for any query

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.

>> >>with complex query semantics in the network haven't been very 
>> >>successful
>> >>in
>> >>attraction to motivate people to use LDAP for directory services 
>> >>instead
>> >>of

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

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 13 Oct 2005 20:01:54 -0400

> just that it should be simple.

We may think about why SIP compression is invented.  

> 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.

> 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

---

From: "James Kempf" <[email-masked]>
Date: Fri, 14 Oct 2005 09:03:32 -0700

> 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

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 14 Oct 2005 16:39:41 -0400

I started a new thread on 802.21 mailing list to bring this
discussion there.  We can discuss the issue here also (but let me
avoid cross-posting.)

On Fri, Oct 14, 2005 at 09:03:32AM -0700, James Kempf wrote:
> 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.
> 

Yes, it is a concern, but we need to look at the issue carefully by
partitioning the issue into multiple parts:

Carrying too much unnecessary information is the major concern.  Only
meaningful information should be carried.  Query language and schema
will help a lot to address this issue.  This requirement is
theoretically independent of how information is encoded, but
practically they are closely related in many cases.

Given that the first requirement is satisfied, then how information is
encoded is the second concern.

Some people seem to focus only on the second aspect without being
paying much attention to the first aspect, which is wrong, I think.

And separately, there is extensibility and flexibility requirements in
802.21, which is functionally more important than the size of the
messages.

Yoshihiro Ohba