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