Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PettingZooParallelWrapper generates invalid actions #4

Open
hkscy opened this issue Jun 11, 2023 · 0 comments · May be fixed by #5
Open

PettingZooParallelWrapper generates invalid actions #4

hkscy opened this issue Jun 11, 2023 · 0 comments · May be fixed by #5

Comments

@hkscy
Copy link

hkscy commented Jun 11, 2023

The PettingZooParallelWrapper class generates invalid actions.

The method int_to_cyborg_action returns a dictionary that maps the number selected by the agent to a specific CybORG action. However, the dictionary is only constructed during initialisation and reset of the environment. The consequence is that the actions returned by the dictionary have invalid parameters (e.g., keys 'blocked' and 'dropped' which are picked up transparently when the actions are created) at run-time throughout each episode. It is specifically the RetakeControl action where this issue seems to manifest.

This issue was very hard to pin down and I still don't entirely understand why the parameters are invalid, however I compared actions with and without the wrapper class and found inequality as demonstrated below:

{'name': 'RetakeControl', 'priority': 15, 'agent': 'blue_agent_0', 'session': 0, 
'dropped': False, 'blocked': False, 'bandwidth_usage': 10, 'ip_address': IPv4Address('10.0.77.38'), 'detection_rate': 0.15, 'success_rate': 0.75}
>>>
{'name': 'RetakeControl', 'priority': 15, 'agent': 'blue_agent_0', 'session': 0, 
'dropped': False, 'blocked': 'drone_6', 'bandwidth_usage': 10, 'ip_address': IPv4Address('10.0.77.38'), 'detection_rate': 0.15, 'success_rate': 0.75}

I modified the int_to_cyborg_action to return the action directly rather than a potentially outdated dictionary and this seems to have fixed the issue as verifiable by WrappedCanary and Canary now achieving the same results in the evaluation. Please note that WrappedCanary implements more-or-less the same algorithm as Canary so the substantial score discrepancy is caused by the issue in the wrapper.

The fixed class can be found here and I will also create a pull request shortly.

Cheers

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
1 participant