Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [802.21] Limit response message length



Eleanor,

Sorry for my delayed response.  I checked D03 draft, LB#1b comments
and associated contributions.

- For TLV query, D03 supports queries to ask less information for a
large number of networks, but does not seem to support queries to ask
detailed information on less number of networks.  However, there is a
contribution (21-06-0827-01-0000-TLV-indicating-network-types.doc)
that defines some TLVs used for specifying particular link types and
particular access networks to reduce the number of networks to be
contained in the response.

- For RDF query, D03 supports queries to ask any level of details on
any number of networks.

Regards,
Yoshihiro Ohba


On Wed, Jan 03, 2007 at 09:29:05AM -0000, Hepworth, Eleanor wrote:
> 
> Hi Yoshi,
> 
> A quick follow up question from my side:
> 
> Given that the information we can include in a response will have size
> limits applied to it, for every query we have a choice of either:
> 
> *) providing information about a small number of networks in a lot of
> detail (e.g. for as many networks as possible provide all the IEs
> requested by the user)
> 
> *) provide less information about a larger number of networks (e.g. for
> all possible networks provide as many of the requested IEs as possible)
> 
> The choice of which of these options should be supported by an
> Information Server may be something that the user wants to influence.
> 
> (This is assuming that we want to support delivery of partial results -
> as Qiaobing mentioned, this is something that probably needs further
> discussion.)
> 
> Can the flitering techniques you mention below provide ways to construct
> messages on either of the principles mentioned above, and is there
> anyway for the user to influence what filters are applied when
> constructing the response?
> 
> (If this is all answered somewhere in D03.00, please feel free to point
> me at the appropriate section, I'm still in the process of re-reading it
> for LB#1b;o)
> 
> Thanks
> 
> Ele
> 
> > -----Original Message-----
> > From: stds-802-21@ieee.org [mailto:stds-802-21@ieee.org] On 
> > Behalf Of Yoshihiro Ohba
> > Sent: 18 December 2006 20:45
> > To: Centonza, Angelo
> > Cc: STDS-802-21@listserv.ieee.org
> > Subject: Re: [802.21] Limit response message length
> > 
> > 
> > Hi Angelo,
> > 
> > On Mon, Dec 18, 2006 at 10:47:17AM -0000, Centonza, Angelo wrote:
> > > Dear All,
> > > 
> > > We thought about this issue within Tgu and came up with some 
> > > ideas/suggestions on how to manage size limit from a MIH 
> > prospective.
> > > 
> > > What Cheng Hong says is correct: we cannot assume that the length 
> > > limit imposed by the access network can be controlled.
> > > 
> > > Also, this limit should not be assumed to be fixed: it may vary 
> > > according to the type of access network, the way the access 
> > network is 
> > > implemented and/or the type of network environment, e.g. 
> > > highly/scarcely populated areas.
> > > 
> > > On the basis of the above a mechanism shall be in place within MIH 
> > > that allows for discovery of the access network size limit 
> > (GAS size 
> > > limit in the case of 802.11). As proposed by Dave Stephenson, the 
> > > length limit for GAS Query Responses could be part of the 
> > > Advertisement Protocol IE and would apply to the GAS Query 
> > Response.  
> > > The latter is due to the assumption that query messages are 
> > relatively 
> > > small in size and are unlikely to exceed size limits. 
> > Therefore, MIH 
> > > should be capable to acquire such size limit from GAS (in 
> > the case of 
> > > 802.11) and apply such limit to the response size.  As far as I 
> > > understand, this should be in line with what Yoshi was proposing.
> > 
> > Yes.
> > 
> > > 
> > > On the other size, Qiaobing raised another very good point. 
> >  What do 
> > > we do if the response is still larger than the maximum size limit 
> > > allowed by the access network?  It is not clear that 
> > issuing an error 
> > > message is the most efficient solution as the STA would probably 
> > > generate a new query once a response error is received.  In fact, a 
> > > STA keeping on querying the IS due to "exceeded response 
> > size limit" 
> > > errors would probably have a worst effect than the IS 
> > sending an over 
> > > large response.
> > 
> > An implementation should be able to refrain from generating 
> > error messages for persistent errors.  This is a general 
> > error handling issue to mitigate DoS attack.
> > 
> > > 
> > > 
> > > The solution we would like to propose for this problem is to 
> > > prioritise the IE requested by the MIHF in the STA so that if the 
> > > ensemble of IEs to be sent by the IS as a response exceeds 
> > the access 
> > > network response size limit, the IS can formulate a shorter 
> > response 
> > > by filtering out the IEs with lower priority.  If the IEs 
> > filtered out 
> > > by the IS are essential for the STA a new query can be generated in 
> > > order to retrieve these extra information. Such 
> > prioritisation could 
> > > be achieved for example by adding a priority field for each 
> > IE in the 
> > > MIH query message or it could be deduced by the order IEs 
> > are listed 
> > > in the query message.
> > > 
> > > By prioritising the IEs requested and by allowing the IS to 
> > adapt the 
> > > response to the maximum size made available by the access 
> > network the 
> > > STA can at least receive the most important information 
> > needed rather 
> > > than having its query cancelled.  This could help limiting 
> > the number 
> > > of successive queries and the traffic load generated by MIH.
> > 
> > There are several filtering techniques defined for TLV queries:
> > 
> > - Definition of three-level containers for incremental query
> > 
> > - Definition of reporing template TLV for per-IE-type filtering.
> > 
> > - Optional inclusion of TYPE_IE_NETWORK_TYPE and 
> > TYPE_IE_OPERATOR_IDENTIFIER IEs for exact-match filtering on 
> > network-type and operatior-id.
> > 
> > First I would like to know whether those techniques already 
> > defined in 802.21 D3.0 are still not sufficient to reduce 
> > query response size for TLV query.
> > 
> > Note that RDF query uses a standard query language (i.e., 
> > SPARQL) that provides more detailed filtering conditions to 
> > reduce the size of response, and thus no additional filtering 
> > technique is needed for RDF query.
> > 
> > Regards,
> > Yoshihiro Ohba
> > 
> > 
> > > 
> > > Kind Regards,
> > > 
> > > Angelo
> > > 
> > >    
> > > 
> > > -----Original Message-----
> > > From: Cheng Hong [mailto:Hong.Cheng@SG.PANASONIC.COM]
> > > Sent: 18 December 2006 05:16
> > > To: STDS-802-21@listserv.ieee.org
> > > Subject: Re: [802.21] Limit response message length
> > > 
> > > Hi Yoshi, and all,
> > > 
> > > Regarding the message length issue, I have a few points of 
> > > clarification and comments:
> > > 
> > > - Firstly, the access network (e.g. 802.11), not the IS 
> > Server, has a 
> > > length limit on info transported using L2 mechanism. Generally, we 
> > > cannot assume this limit can be controlled/prior-known by 
> > the MIH IS 
> > > Server. In order to prepare the response properly, the IS Server 
> > > should be made aware of this length limit (either through STA or 
> > > access network directly). Dave Stephenson presented something 
> > > regarding this point during Tgu joint session in Dallas.
> > > 
> > > - Secondly, whether the above limit applies depends on 
> > which mechanism 
> > > is used, rather than which state the STA is in. For 
> > example, Tgu GAS 
> > > mechanism is designed to support unauthenticated STA (at state 1). 
> > > However, it does not preclude a State 3 STA using it. But, 
> > if a STA is 
> > > using data plane transport or L3 transport, the limit would 
> > not apply, 
> > > since it will be treated as data traffic by the access network.
> > > 
> > > - As for the length limit from the STA (as in your proposal), it is 
> > > purely a MIH protocol issue. It may provide the IS Server 
> > length limit 
> > > info from STA point of view. However, it does not directly 
> > solve the 
> > > (above mentioned) access network length limit problem. As 
> > pointed out 
> > > by Michael, one possible way is to allow network to piggyback the 
> > > access network length limit to the message you proposed. Another 
> > > possibility is for the STA to obtain the length limit info from 
> > > broadcast/beacon of the network, and reflect that in the 
> > info element 
> > > you proposed. I think all the above require some changes to 
> > the access 
> > > network functions, and therefore, we might want to talk to Tgu 
> > > regarding the proposed changes/requirements.
> > > 
> > > Cheers
> > > 
> > > Cheng Hong
> > > 
> > > 
> > > 
> > > > -----Original Message-----
> > > > From: stds-802-21@ieee.org [mailto:stds-802-21@ieee.org] 
> > On Behalf 
> > > > Of
> > > > Yoshihiro Ohba
> > > > Sent: Saturday, December 16, 2006 7:21 AM
> > > > To: Qiaobing Xie
> > > > Cc: STDS-802-21@listserv.ieee.org
> > > > Subject: Re: [802.21] Limit response message length
> > > > 
> > > > Hi Qiaobing,
> > > > 
> > > > On Fri, Dec 15, 2006 at 03:16:18PM -0600, Qiaobing Xie wrote:
> > > > > Yoshi/Michael,
> > > > > 
> > > > > A few thoughts on this:
> > > > > 
> > > > > 1. The network (I guess this means the IS server) may want
> > > > to impose
> > > > > different size limit depending on the mobile is in
> > > > unauthenticated or
> > > > > authenticated state. Should there be a way the IS 
> > server can know
> > > > > about this?
> > > > 
> > > > This is a good point.  I believe that the IS server does 
> > not have to
> > > > know the mobile's authentication state.  There are three cases.
> > > > 
> > > > Case 1: IS queries originated by State 1 station. Since State 1 
> > > > station cannot directly communicate with IS server, AP acts as a 
> > > > proxy MIH IS client on behalf of the station.  In this case, the 
> > > > source address of MIH_Get_Information Request message will be the 
> > > > MAC address of the AP.  The AP should set the per-query 
> > MTU needed 
> > > > for State 1 queries.
> > > > 
> > > > Case 2: IS queries originated by State 3 station. State 3 station 
> > > > can
> > > > directly communicate with IS server.  In this case, the 
> > source address
> > > 
> > > > of MIH_Get_Information Request message will be the MAC address of 
> > > > the
> > > > station.  The station may set whatever per-query MTU it wants.
> > > > 
> > > > Case 3: IS queries originated by AP.  AP may want to generate 
> > > > queries
> > > > on behalf of itself for many reasons.  In this case, the source 
> > > > address of MIH_Get_Information Request message will be 
> > the MAC address
> > > 
> > > > of the AP.  The AP can may whatever per-query MTU it wants.
> > > > 
> > > > The IS server cannot distinguish Case 1 and Case 3, but 
> > it does not
> > > > really have to distinguish the two cases if we expect the 
> > AP to set 
> > > > per-query MTU differently in Case 1 and Case 3.
> > > > 
> > > > For all cases, the IS server can impose its own limit 
> > less than that
> > > > is specified by the IS client.
> > > > 
> > > > > 
> > > > > 2. The actual size limit of a query/response exchange will
> > > > be the the
> > > > > lesser of the mobile's self-imposed limit and network imposed 
> > > > > limit.
> > > > 
> > > > Yes.
> > > > 
> > > > > 
> > > > > 3. What should be the consequence if the response is over
> > > > the lesser
> > > > > of the mobile limit and network imposed limit? Probably we
> > > > simply fail
> > > > > the query with some error code.
> > > > 
> > > > Yes, the IS server should return a response with an error 
> > indication
> > > > in this case.
> > > > 
> > > > Regards,
> > > > Yoshihiro Ohba
> > > > 
> > > > 
> > > > > 
> > > > > regards,
> > > > > -Qiaobing
> > > > > 
> > > > > Michael.G.Williams@NOKIA.COM wrote:
> > > > > >Yoshi,
> > > > > >
> > > > > >Sounds good.  Ideally we want a way for the mobile in one
> > > > packet to
> > > > > >query and the network in one response packet give the
> > > > response back,
> > > > > >esp. in unauth state where fast scanning or high mobility
> > > > are issues,
> > > > > >yes? Is piggybacking the details of limit request or
> > > > enforcement onto
> > > > > >that exchange possible?
> > > > > >
> > > > > >Michael
> > > > > >
> > > > > >-----Original Message-----
> > > > > >From: ext Yoshihiro Ohba [mailto:yohba@tari.toshiba.com]
> > > > > >Sent: Friday, December 15, 2006 10:02 AM
> > > > > >To: Williams Michael.G (Nokia-ES/MtView)
> > > > > >Cc: STDS-802-21@listserv.ieee.org
> > > > > >Subject: Re: [802.21] Limit response message length
> > > > > >
> > > > > >Yes, the network can always impose its own limit if the
> > > > maximum size
> > > > > >specified by the mobile is still too big.
> > > > > >
> > > > > >Yoshihiro Ohba
> > > > > >
> > > > > >On Fri, Dec 15, 2006 at 11:16:10AM -0600,
> > > > > >Michael.G.Williams@NOKIA.COM
> > > > > >wrote:
> > > > > >>HI Yoshi,
> > > > > >>
> > > > > >>That approach could work, as long as the network would
> > > > also need to
> > > > > >>be
> > > > > >
> > > > > >>able to impose/enforce the limit if the mobile's request
> > > > is too big,
> > > > > >>right? That was Tgu's concern I think.
> > > > > >>
> > > > > >>Best Regards,
> > > > > >>Michael
> > > > > >>
> > > > > >>-----Original Message-----
> > > > > >>From: ext Yoshihiro Ohba [mailto:yohba@tari.toshiba.com]
> > > > > >>Sent: Thursday, December 14, 2006 8:50 PM
> > > > > >>To: Williams Michael.G (Nokia-ES/MtView)
> > > > > >>Cc: yohba@tari.toshiba.com; STDS-802-21@LISTSERV.IEEE.ORG
> > > > > >>Subject: Re: Limit response message length
> > > > > >>
> > > > > >>Hi Michael,
> > > > > >>
> > > > > >>What I am trying to do is to add a new parameter in
> > > > > >>MIH_Get_Information.request/indication primitives, which
> > > > is used for
> > > > > >>specifying the maximum size of InfoQueryParameter to be
> > > > returned in
> > > > > >>the corresponding confirm/response primitives, and a 
> > new TLV to
> > > > > >>carry the parameter in MIH_Get_Information Request 
> > message.  This 
> > > > > >>allows the
> > > > > >
> > > > > >>querier to specify a different MTU for each query so that
> > > > a smaller
> > > > > >>size can be specified for queries performed in State 1 of 
> > > > > >>802.11.
> > > > > >>
> > > > > >>We could also define error handling for errors relating
> > > > to message
> > > > > >>size, if needed.
> > > > > >>
> > > > > >>Regards,
> > > > > >>Yoshihiro Ohba
> > > > > >>
> > > > > >>On Thu, Dec 14, 2006 at 06:03:56PM -0600,
> > > > > >>Michael.G.Williams@nokia.com
> > > > > >>wrote:
> > > > > >>>Yoshi,
> > > > > >>>
> > > > > >>>Thanks for tracking this. If possible, could we email a
> > > > bit about
> > > > > >>>it
> > > > > >
> > > > > >>>as it was something .11u was concerned about too.
> > > > > >>>
> > > > > >>>This value could be something configurable by the
> > > > network operator
> > > > > >>>or mobile node provisioner. It could vary from operator to
> > > > > >>>operator,
> > > > > >
> > > > > >>>and possibly vary under other circumstances such as
> > > > authorized vs.
> > > > > >>>unauthorized use of the network, or even query to query.
> > > > > >>>
> > > > > >>>So if the solution here can be something that is 
> > discovered, or
> > > > > >>>handled via error cases (i.e. the limit is provided in
> > > > response to
> > > > > >>>an attempt to exceed it) that might provide the
> > > > flexibility and the
> > > > > >>>constraints needed.
> > > > > >>>
> > > > > >>>Best Regards,
> > > > > >>>Michael
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > > > >>>-----Original Message-----
> > > > > >>>From: ext Yoshihiro Ohba [mailto:yohba@tari.toshiba.com]
> > > > > >>>Sent: Thursday, December 14, 2006 12:06 PM
> > > > > >>>To: Williams Michael.G (Nokia-ES/MtView)
> > > > > >>>Cc: STDS-802-21@LISTSERV.IEEE.ORG
> > > > > >>>Subject: Re: [802.21] Conference call tomorrow Dec 14th
> > > > 9AM Eastern
> > > > > >>>Time US
> > > > > >>>
> > > > > >>>In today's telconf, I forgot to mention that I am working on:
> > > > > >>>
> > > > > >>>>		1.1.4.	Limiting Response Message Length: Need a
> > > > > >>>>mechanism to limit the response length of a query.
> > > > > >>>>
> > > > > >>>Regards,
> > > > > >>>Yoshihiro Ohba
> > > > > >>>
> > > > > >>>
> > > > > >
> > > > > 
> > > > 
> > > 
> > 
> 
>