RE: [802.21] Limit response message length
Stephen and all,
Speaking on behalf of the air interface community, Stephen's concern is
spot-on.
As the medium for L1&L2, first hop transport, we (802.16, 802.11, others)
are concerned about ensuring that the 802.21 service does not impose too
heavy an overhead burden on the medium. Being able to constrain message size
(and perhaps other messaging characteristics like retry limits, message
fragmentation, etc...) is the only method available to the air link to
ensure that the 802.21 service does not become an overhead burden, and to
minimize the opportunity and impact for malicious abuse.
This concern is magnified during any 802.21 service occurring prior to
authenticating the mobile device to the network.
The air interface community works diligently to constrain overhead for
control and management traffic and we appreciate 802.21's consideration in
aiding us in this endeavor.
Providing reasonable tools so that the air links can restrict consumption of
the medium is both prudent and necessary.
Thanks,
Phillip Barber
Chief Scientist
Broadband Wireless Solutions
Huawei Technologies Co., LTD.
-----Original Message-----
From: stds-802-21@ieee.org [mailto:stds-802-21@ieee.org] On Behalf Of
McCann, Stephen
Sent: Friday, December 22, 2006 5:08 AM
To: STDS-802-21@listserv.ieee.org
Subject: RE: [802.21] Limit response message length
Dear all,
I think a general conclusion to all this, is that something
needs to be defined both at the client and host ends which will
allow size limitation of these messages.
I'm currently concerned that just relying on a query language to
send information from the IS in a priority order (without explicit
field tagging) may not be useful to the specific problem that Angelo
(and IEEE 802.11u) is trying to solve.
Kind regards
Stephen
> -----Original Message-----
> From: stds-802-21@ieee.org [mailto:stds-802-21@ieee.org] On
> Behalf Of Qiaobing Xie
> Sent: 21 December 2006 18:56
> To: Centonza, Angelo
> Cc: STDS-802-21@listserv.ieee.org
> Subject: Re: [802.21] Limit response message length
>
> Hi, Angelo, Yoshi, and others,
>
> This is very good discussion. I think there are several
> separate issues
> raised:
>
> 1) How to determine the size limit? (e.g, MN input + AN input
> + server provisioning => per transaction size limit)
>
> 2) How to enforce the determined size limit? (e.g., server
> enforcement)
>
> 3) Whether to support partial result or simply fail the
> transaction when size limit is exceeded? (e.g., need to fully
> justify the added complexity with the benefits)
>
> 4) If the answer to 3) is yes, then what mechanism or
> mechanisms should be used to determine the partial result
> (e.g., explicit priority indicated in query, implicit
> priority implied by IE types)?
>
> regards,
> -Qiaobing
>
> Centonza, Angelo wrote:
> > Hello Yoshihiro,
> >
> > I agree with what you say: in TLV the prioritisation could
> be done on
> > the basis of the order IEs are requested.
> >
> > However, I think there would be the need to specify within the .21
> > specs how and according to which principles the overall filtering
> > process is performed.
> > Just to mention one case that would need support from the
> > specifications and that is not a mere implementation issue,
> we could
> > consider the case where IEs labelled with high priority are still
> > filtered out from the query response due to the presence in the IS
> > database of several instances of them. In this case it should be
> > specified how and whether the STA can re-request the high
> priority IEs
> > that were filtered out without formulating a new query that
> asks for
> > the whole set of IEs again.
> >
> > Moreover, I am not sure if we can extend the concept of
> prioritising
> > IEs depending on the listing order of IEs in the query
> message to all
> > query languages. There could be cases where the query language
> > formulates the query according to e.g. the hierarchy of IEs
> in the IE
> > tree. In order to generalise the concept of prioritisation
> we would
> > need to make sure that IEs priorities can be clearly
> detected in all possible cases.
> >
> > I think this will be a good topic of discussion for the
> London meeting.
> >
> > Kind Regards,
> >
> > Angelo
> >
> > -----Original Message-----
> > From: Yoshihiro Ohba [mailto:yohba@TARI.TOSHIBA.COM]
> > Sent: 20 December 2006 15:36
> > To: STDS-802-21@listserv.ieee.org
> > Subject: Re: [802.21] Limit response message length
> >
> > Hi Angelo,
> >
> > I think that implicit prioritization is possible without
> defining any
> > additional field, based on order of appearance of IE types in
> > Reporting Template TLV.
> >
> > Yoshihiro Ohba
> >
> >
> > On Wed, Dec 20, 2006 at 02:20:59PM -0000, Centonza, Angelo wrote:
> >> Hello Yoshi,
> >>
> >> I have no doubts that each query language might provide different
> >> types of filtering mechanisms. However, the point we are trying to
> >> address is how to provide the right information in order
> to allow an
> >> effective filtering.
> >>
> >> If for example the STA queries for a series of IEs out of
> which some
> >> are more important than other and if these IEs are not assigned to
> >> the
> >
> >> right priority level the filtering mechanisms implemented in the
> >> query
> >
> >> language will not be able to understand which IE to filter
> out in the
> >> case of a query response larger than the maximum frame
> size allowed
> >> by
> >
> >> the underlying link layer advertisement service (GAS in
> the case of
> >> 802.11). In other words, the idea we have in mind for priority
> >> levels
> >
> >> of each requested IE is a bit similar to the DSCP field
> in DiffServ:
> >> it is a tag of some sort that is given to the IE at the
> time of the
> >> query and that allows the query language or the IS itself
> to filter
> >> out the less important IEs in case of oversized responses.
> >>
> >> Kind Regards,
> >>
> >> Angelo
> >>
> >> -----Original Message-----
> >> From: Yoshihiro Ohba [mailto:yohba@TARI.TOSHIBA.COM]
> >> Sent: 18 December 2006 20:45
> >> To: 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
> >>>>>>>>
> >>>>>>>>
> >>
> >
>