Re: [802.19] Avoiding continuous requests in the IEEE 802.19.1 coexistence system

[mika.kasslin@xxxxxxxxx]

 

Hi,

 

Thanks for sharing your thoughts and the proposal. This helps us going forward with many issues, I believe.

I have some comments and responses below in-line.

 

Best Regards,

Mika

 

From: ext Benjamin A. Rolfe [mailto:ben@xxxxxxxxxxxxxx]
Sent: 04 July, 2012 21:51
To: STDS-802-19@xxxxxxxxxxxxxxxxx
Subject: Re: [802.19] Avoiding continuous requests in the IEEE 802.19.1 coexistence system

 

Seems like a reasonable concern: if the operation that is intended to enhance coexistence monopolizes the medium for a good percentage of the time, that seems counter to the objective!

Mika: Right, but we are not developing protocol which would be run over the air interface which the protocol aims to support from coexistence perspective. So, whatever we develop will not, at least in default cases, monopolize the wireless medium but we are talking about protocol run in backbone. Even then we should address the issue so that clearly unnecessary and continuously transmitted protocol messages are forbidden.

 

It is important to assure that when writing the standard we don't specify requirements that will inadvertently result in message floods or other overloads, for example if there was a required behavior that specified a maximum response time between transmissions, this could result in effectively mandating a flood of transmissions in some circumstances.

So it is always good to not require devices behave badly, and reasonable to try and define what is reasonably good behavior.  Specifying such good behavior of course doesn't assure that devices will not behave badly.  A malicious actor will ignore any constraints defined in the standard and do what it can to disrupt the network operation - dealing with such is a topic unto itself, and I don't intend to uncap that container of wriggling non-arthropod invertebrates (I assume we accept that we can't do cooperative coexistence without cooperation). 

We should consider unintended consequences of stated requirements.

To Mika's purpose, we might include something like "a device shall not initiate a new request within 30 seconds of a prior request; retransmissions of a request are not defined as initiation of a new request"  seems a good start.

This requires that a device to preserves "request state" between power cycles, or that it makes no requests within 30 seconds of reset. Is that a reasonable, intentional constraint?  Have we somewhere else a requirement that the a request be issued sooner in some circumstances?  How does a device decide that the request failed? 

Mika: I like this proposal. In our case “a device” will be “an entity” but that’s just an editorial. Otherwise this captures extremely well at least my intentions. Thanks!

I’m not sure whether we could require an entity to preserve the state to ensure that the requirement is met even when the entity is somehow “reset”. Alternatively we could make it clear that at “reset” or “power up” there is no prior request and one can issue a request at any time.

On the second question about failed requests we don’t have yet exact rules but I believe a request needs to be considered failed once the transport layer indicates that the request to send a request message failed. Our draft has a SAP for the transport layer and there we support for related indications. I believe we just need to make it more clear what happens when the transport layer indicates that one failed with a message transmission.

 

Would it achieve the same goal to say that the initiator of the request shall not declare the request a failure, and thus initiate a new request, until 30 seconds has elapsed?  This is a more positive specification: "If the corresponding coex report has not been receiced before aCoexReportRequestTimeout has elapsed, then the request will be re-initiated according to...." and whatever conditions/parameters you have to control the  number of times the report is requested.  Retransmissions at the MAC layer are thus not constrained by this requirement.

 

Mika: I agree that this is a more positive way to say the same and positive attitude is always good also in the specification. With this approach we would address also the question on how to behave in case of failed transmission. Thanks for this proposal as well!

  
A very interesting topic!
Hope this helps the discussion.

-Ben

 

Dear all,

 

In reference to the TG1 call earlier today and discussion on really frequent requests from an entity to another (CE-to-CM, CM-to-CDIS, etc.) I would like to propose the specification to set strict limits for information requests and how often one can issue them. The reason for the proposal is to avoid standard compliant entity implementations which overload the system with really frequent requests.

 

Let’s consider the procedure to obtain a coexistence report as specified in section 5.2.4.2 of the DF2.08. That’s the procedure with which a CE requests the latest coexistence report from the CM to which the CE is registered. The report is intended for WSO but from the coexistence system perspective we should concentrate on the interface between a CE and a CM. My proposal is to have the specification to state that a CE may invoke the procedure to obtain a coexistence report only once at least 30 seconds has elapsed from the previous start of the procedure.

In practice this intends to say that a CE may issue a CoexistenceReport_Request message only when at least 30 seconds has elapsed from the previous CoexistenceReport_Request message. This latter wording may have some problems because of possible retransmissions of the CoexistenceReport_Request message. We should at least be very clear that retransmissions are not counted.

Further, I’m not sure whether the limit should be 30 seconds or something else. The value should be, however, such that one can’t overload the system by issuing frequent requests just to check whether the coexistence report has been changed.

 

What do you think on the proposal? Do you see any challenges in it? What could be a reasonable value to determine how often requests can be issued?

 

Best Regards,

Mika