Subject: RE: [Mipshop] Re: Architectural Considerations for Handover InformationServices (was: Re: CARD Discussion Query Discussion)

From: "Gupta, Vivek G" <[email-masked]>
Date: Fri, 14 Oct 2005 06:01:23 -0700

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: [email-masked] [mailto:[email-masked]] On
Behalf Of James Kempf
Sent: Thursday, October 13, 2005 3:58 PM
To: Yoshihiro Ohba
Cc: [email-masked]; [email-masked]; 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop

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

---

From: "Singh Ajoy-ASINGH1" <[email-masked]>
Date: Fri, 14 Oct 2005 11:04:46 -0400

I also think simple TLV based approach should be good. 

Regards,
Ajoy 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Gupta, Vivek G
Sent: Friday, October 14, 2005 8:01 AM
To: James Kempf; Yoshihiro Ohba
Cc: [email-masked]; [email-masked]; Rajeev Koodli;
Petrescu Alexandru-AAP021
Subject: RE: [Mipshop] Re: Architectural Considerations for Handover
InformationServices (was: Re: CARD Discussion Query Discussion)

BR,
-Vivek

-----Original Message-----

it

involved

the
the
simple
prefer
DNS, 
successor 
need 
reason, 

the

            jak

---

From: "Singh Ajoy-ASINGH1" <[email-masked]>
Date: Sat, 15 Oct 2005 23:33:46 -0400

Subir, 

Please find inline replies. 

Regards,

Ajoy   

           Along that line  more data on XML will be  better for
understanding which query 
             language is good for .21 IS .  All along we have said  that
XML is a candidate query lanaguage given the  type of model 
             and flexibility we need to support in .21 IS  framework.
It will be good if you share some of  your practical experience 
             and related informtion on XML as well.. 

Ajoy-> I think the following link does talk about performance issue
associated with XML.   

http://www.zapthink.com/report.html?id=ZAPFLASH-11162004 

Personally I have not done any work in the XML performance analysis, but
I have looked 

at other compression technologies and have herd concerns raised about
the 

performance impact of various compression mechanism such as SIP
compression on mobile devices. 

 Also is it not true that XML is already on the mobile devices?  

Ajoy-> At least I am not aware of availability of XML at L2, L2.5  and
L3 protocol layer processing. Typically 

L2 and L2.5 processing is done by DSP and I am not aware of any XML
component in that. However. 

I am aware of the fact that WAP has used some variation of XML also
known WML. But it has NOT been considered 

very successful technology either. Also, available channel bandwitdh for
handover signaling may not be as much as 

availablefor WAP data path. 

. 

My  feeling is that we don't have enough data so that we can say that
XML is bad. 

Ajoy-> See above link. Although above link is not related to mobile
devices, but definitely provides some interesting data about XML.

For example it states that size of XML encoded message can be 10 to 50
times bigger than binary encoded message.