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

["Benjamin A. Rolfe" <ben@xxxxxxxxxxxxxx>]

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!

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? 

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