-
Notifications
You must be signed in to change notification settings - Fork 8
FAQ
Well, it sort of is supported. If you go through the effort of installing matplotlib so that it can work with both windows and pypy you'll be all set. For whatever reason, this just never seemed to work in the CI/CD pipeline, so it's since been removed. I believe this is because matplotlib does not add their wheels for pypy3.10 to pypi (at least, that was the case as of this writing).
Q: Why use weak references for the AS relationships instead of using dunder del to simply remove the references upon deletion?
dunder del can't be relied upon to be called when garbage collecting in all python interpreters. This may work in Python, but for PyPy, there is no guarantee that objects will be garbage collected the same way or that dunder del will be called at all. At least, that's my interpretation of what the Fluent Python book says.
Q: Why not, as an optimization, just include the results of the policies in the Announcement like you do with the ROA information?
A: There are various places we could do this. If the attacker controls the seeding of announcements, they could in theory just set a boolean value on an announcement, like for pathend. This would certainly be much faster than using an algorithm to determine announcement validity.
However, the problem is that then the user must essentially run the algorithm in their head when they are creating the announcements for the hijack, which is not great. Additionally, then we must modify all of our existing hijacks to include this new information that otherwise would not be included anywhere (if the policy did the algorithm internally).
With ROAs, this is a bit of an exception, because we are not actually adding whether or not an announcement is valid or invalid by ROA - we are putting the same information that would need to be included for a ROA just on the Announcement class instead, so there's no additional burden to the user. The actual validity of the ROA is calculated using an algorithm internal to the announcement class.
That being said - if you'd like to do this for your specific simulation, go for it! That's the approach some papers have taken, such as BGP-iSec (see sections and use cases). It's an easy way to get results quickly, we just can't support it in BGPy since then it would need to work in all cases, rather than for a specific simulation in a paper.
A: I actually attempted this. Unfortunately, it does not play well with pypy, and was 3x slower. There's open issues about it on the PyO3 threads where the maintainer says that PyPy is more optimized and is the gold standard in that regard. I also tried just doing Rust with no python, but due to all the cyclical, circular, mutable, references, Rust's type system enforced a lot of safety checks that made the code slower than pypy once again. Since these things are inherently circular and unsafe, we decided to use C++ which has all the performance benefits, and is frankly to me at least much easier for development. Also more members of our team know C++ than Rust, same with the rest of the world.
A: This is because we would be outputting a ton of data into CSVs (30+ gigabytes for the ROV++ configuration for example) and this would be way too slow for Python. Instead, we average the trials as we go, keeping it in RAM, and only writing the aggregate data onto disk at the end.
A: We ended up moving the caida collector into this repo for a few reasons. There is less dependency madness. If you are installing for development, pypy will overwrite your local install of the caida collector witht he caida collector within git. This will allow for much better typing Previously this was separate because it was used in many other places, however, now it is only used within this simulator This is really coupled with the simulator now, since the base of the caida collector serves as the base for the simulator itself We will be able to dynamically make the subgraphs part of the caida collector, with an enum that someone can inherit and use, veasy easily if it's part of the simulator. We still really need to do a better job of integrating this into BGPy but it's fine for now.
A: slots was initially used for a speedup, however this caused problems with extendability because we are swapping out the class attribute for ASes that may have routing policies that require the use of new instance attributes. This is specifically noted as a use case against slots in the documentation. Also, when we ran the testing with pypy to determine the time difference, it was less than 1 second with everything having slots or nothing have slots for 100 trials. In other words, the difference was negligable, so for easier development, slots were removed from everything other than the announcements. Additionally, a lot of the benefit of these is likely negated by using the YamlAble base class, which, afaik, doesn't use slots.
A: pytest-cov brings the testing time up to 10 minutes (when normally it is less than 30 seconds). This does not play well with pypy, and also does not work with multiprocessing after their 4.0.0 release, so thus it is no longer a default. Developers can add it as they wish, just be aware it is quite slow.