| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi Subir,
Sure scope of 802.21 is broader than existing mobility protocol. Who is denying that? Btw, no one is opposed to the possibility of enhancing any mobility protocol or defining new protocol if required. Also, what is wrong about sharing view of 802.21 when MIPSHOP is going to define a protocol that would cater need of 802.21 itself? Also, please note that there was question about XML versus TLV encoding in MIPSHOP discussion. Straw poll was mentioned in that context. See below the email thread.
Regards, Ajoy
From: Subir Das [mailto:subir@RESEARCH.TELCORDIA.COM]
Why are we discussing .21 straw poll here? I
think we are not addressing the point
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
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 last802.21 meeting. I guess there was straw poll as well. Do you have anyresult of straw poll? It may be good data point about 802.21's viewabout XML versus TLV. Regards,Ajoy -----Original Message-----From: mipshop-bounces@ietf.org [mailto:mipshop-bounces@ietf.org] OnBehalf Of Michael.G.Williams@nokia.comSent: Thursday, October 13, 2005 6:38 PMTo: Kempf@docomolabs-usa.com; yohba@tari.toshiba.comCc: mipshop@ietf.org; gabriel_montenegro_2000@yahoo.com;rajeev@iprg.nokia.com; Petrescu Alexandru-AAP021Subject: RE: [Mipshop] Re: Architectural Considerations for HandoverInformationServices (was: Re: CARD Discussion Query Discussion) Colleagues, A couple of points regarding the issue of chartering / standardizing forFMIP needs, and getting .21 & MIPSHOP to work together... We are at the draft stage in 802.21 and need proposals to modify thedraft. .21 is counting on the solution in the IETF to becompatible/interoperable with the IEEE solution. Sorry to be so highlevel on that statement. .21 requires an IS solution that solves problems for more than justFMIP. Perhaps the issues of IE representation and query language can beseparated to some degree? For example, if an alternative query languageexists today that would be useful, could it be used against the XMLrepresentation? .21 has expressed needs for extensibility and flexibility. The approachof schemas and dynamic semantic agreements is one way to enable thosetraits. The issues of bandwidth & latency have been raised in both fora, but dowe 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] OnBehalf Of ext James KempfSent: Thursday, October 13, 2005 3:58 PMTo: Yoshihiro OhbaCc: mipshop@ietf.org; gabriel_montenegro_2000@yahoo.com; Rajeev Koodli;Petrescu Alexandru-AAP021Subject: [Mipshop] Re: Architectural Considerations for HandoverInformationServices (was: Re: CARD Discussion Query Discussion)
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'sjust not a problem with today's bandwidths, IMHO. We're not talkingabout 9.6 kbps links anymore. And I'm not saying that there should be noquery language, just that it should be simple.
Well, I know (from having implemented it with SLP) that it is hard. Itis much easier to haul over what you need and process it locally. Whathappens is the query typically ends up getting stuff you don't wantanyway, regardless of how careful you are in constructing it, so youtypically need to postprocess anyway. So why bother to have all the codeand complexity of trying to do the automatic query construction?Application developers then don't bother to use the complex querylanguage, so you end up having this substantial chunk of code in theprotocol processing that isn't used most of the time.
No, it needs to be done here too. You're claiming that you want an XMLprotocol with complex query language. I disagree, based on my experiencewith SLP and LDAP, that this is really any value in a system-levelapplication like network information services. Regardless of what 802.21wants, we need something that provides network information for FMIP, andif we are going to try to get the two applications to work together, weneed to come up with a protocol that satisfies both. Anybody else have an opinion? jak _______________________________________________Mipshop mailing listMipshop@ietf.orghttps://www1.ietf.org/mailman/listinfo/mipshop _______________________________________________Mipshop mailing listMipshop@ietf.orghttps://www1.ietf.org/mailman/listinfo/mipshop _______________________________________________Mipshop mailing listMipshop@ietf.orghttps://www1.ietf.org/mailman/listinfo/mipshop |