Tariff revocation processing leaves a window for mischief

[jecollins]

Currently, tariff revocation is processed immediately, in the timeslot when the revoke message arrives. This can happen up to 5 timeslots before a tariff publication event, which is what triggers customers to re-evaluate their tariffs. During those 5 timeslots, the customer is stuck with the superseding tariff, which could have extravagant rates, and the customer would have to pay.

There are two possible fixes that come to mind:

1. defer revocation until the next publication event, or
2. have customers re-evaluate tariffs when they see a revocation.

The first would minimize the impact on customer models. The spec seems to be silent on exactly when revocation actually happens.

[jecollins]

Here's the situation:

• Tariff revocation processing happens at the beginning of customer activation in each timeslot, when the customer calls getRevokedSubscriptionList() (see the sequence diagram). This happens in Phase 2 of the per-timeslot sequence, before usePower().
• All other subscription processing is driven by the TariffMarket, which is activated once every six timeslots, in Phase 3.

This means that there is no possible fix for the problem without modifying the customers, because revocation happens before subscription processing, even if revocation is deferred. So there's always at least one timeslot in which the superseding tariff will be used, regardless of how bad it is. If revocation processing were deferred to the time of publication processing in the TariffMarket, then the superseding tariff would take effect in the following timeslot (because the customers have already run in the current timeslot when TariffMarket runs), meaning that the superseding tariff would have maximal time to have its way with the poor customers.

An alternative would be to move the processing of superseding tariffs in the customer to the beginning of subscription processing. This way, the superseding tariff could be dumped before the customer has used any power against it. However, the presence of a revocation might need to override or at least influence the intertia of customers.

[jecollins]

Antonios suggests that we simply remove the superseding-tariff feature for now.

[wketter]

I think this makes sense, since it is a reasonable, easy, and fast solution.

Thanks,

Wolf

From: John Collins [mailto:notifications@github.com]
Sent: zondag 23 september 2012 18:16
To: powertac/powertac-server
Subject: Re: [powertac-server] Tariff revocation processing leaves a window for mischief (#618)

Antonios suggests that we simply remove the superseding-tariff feature for now.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/618#issuecomment-8799895.

[preddy]

I agree.

Prashant

On Sep 23, 2012, at 12:21 PM, wketter notifications@github.com wrote:

I think this makes sense, since it is a reasonable, easy, and fast solution.

Thanks,

Wolf

From: John Collins [mailto:notifications@github.com]
Sent: zondag 23 september 2012 18:16
To: powertac/powertac-server
Subject: Re: [powertac-server] Tariff revocation processing leaves a window for mischief (#618)

Antonios suggests that we simply remove the superseding-tariff feature for now.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/618#issuecomment-8799895.

—
Reply to this email directly or view it on GitHub.

[jecollins]

I commented out the code in TariffSubscriptionRepo that creates a subscription to the superseding tariff, with the result that revoked tariffs always fall back to the default tariff. Strangely enough, I've run two games with this setup, and both got wedged in the server around timeslot 950 (somewhat less than 600 timeslots into the sim). There are no errors or exceptions. The last output in the trace log is in the middle of clearing the wholesale market. In both cases, the default broker had issued wholesale orders with quantities of NaN or Infinity.

This may be a result of a collision between Village (and OfficeComplex) and TariffSubscription in the processing of revoked tariffs. Those customer models are keeping their own map of subscriptions, and they are making incorrect assumptions about which tariff gets the subscription in the case of revocation. It was incorrect before, but more so now.

[chrysopoulos18]

I have made the fixes that I told you about.

The first takes the correct tariff Powertype according to the revoked tariff and not the CONSUMPTION as before.
The second takes as granded that the new tariff in place of the revoked one is going to be the default tariff and changes the subscription hashmaps accordingly.

Please try them out and tell me if they fixed some of the problems.

[jecollins]

On 09/23/2012 02:50 PM, Anthony Chrysopoulos wrote:

I have made the fixes that I told you about.

The first takes the correct tariff Powertype according to the revoked
tariff and not the CONSUMPTION as before.
The second takes as granded that the new tariff in place of the revoked
one is going to be the default tariff and changes the subscription
hashmaps accordingly.

Please try them out and tell me if they fixed some of the problems.

I already commented out your code that tries to figure out which tariff
is the correct one, because TariffSubscription already does that.
Instead, I had TariffSubscription return the replacement tariff. It's a
really bad idea to try to implement this logic in two different places.
However, we are still getting

172093 INFO tariffmarket.TariffMarketService: Revoked tariff 200000388
has 7 active subscripti
ons
172093 WARN tariffmarket.TariffMarketService: Attempt to subscribe to
revoked tariff

I'm trying to figure out where this is coming from...

John

[jecollins]

The collision was resolved by returning the superseding tariff from TariffSubscription, and updating household-customer and officecomplex-customer to use that value rather than trying to compute it on its own. It appears that all the odd behaviors noticed by Antonios have now gone away.

[wketter]

Excellent!

Thanks much everybody for your hard work!

Looking forward to a great competition.

Cheers,

Wolf

From: John Collins [mailto:notifications@github.com]
Sent: maandag 24 september 2012 1:03
To: powertac/powertac-server
Cc: Wolf Ketter
Subject: Re: [powertac-server] Tariff revocation processing leaves a window for mischief (#618)

The collision was resolved by returning the superseding tariff from TariffSubscription, and updating household-customer and officecomplex-customer to use that value rather than trying to compute it on its own. It appears that all the odd behaviors noticed by Antonios have now gone away.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/618#issuecomment-8804027.