Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
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 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 ofinformation 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 andfor 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 specifyingthe 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 thelike, 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 belongsto.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 |