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

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