Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Salsify: 95th percentile number of states stored? #80
Hi guys! Not sure if I should put this issue in the salsify-results repo, let me know.
I am reviewing your Salsify paper in my Advanced Computer Networking class at UofM. In section 5.2 of the paper, you write:
I would really like to know more about the worst case here. What is, for instance, the 95th percentile number of states stored? This seems relevant for evaluating the memory overhead of Salsify, especially when the network is unreliable and failures may be long and/or frequent. Does the increasing number of states being stored potentially create a memory usage problem?
I tried looking through the
After looking at the source code for
If, however, you guys already have this information available, I would love to hear it. Perhaps my intuition is wrong and the memory overhead of keeping states is negligible. If so, let me know!
P.S. Thank you so much for open-sourcing all of this data and code! This is how research should be done!
Hi Ben -- great question! I unfortunately don't think we have an answer for you without running the code ourselves. And I think that if you were on a system with memory pressure, you could probably arrange to cap the number of states that the sender and receiver have to keep around -- by moving Salsify in the direction of how existing systems do loss recovery in real-time video transmission.
For example, maybe instead of requiring the receiver to keep every state around until the sender gives permission to evict it, the sender would only be allowed to designate a limited number of outgoing states as "retained" states at a time. So if the cap is 4, then if the sender has sent 4 "retained" states to the receiver, it can't send another one until it tells the receiver to discard one of the 4 (whether it was received or not). The receiver would only keep the "retained" states and the most recent state around, and the sender would only be allowed to base its predictions on either the most recent state or one of the "retained" states.
This is sort of similar to what existing schemes do with altref frames, etc.
The truth is that Salsify is not particularly great on networks with random packet loss anyway (as opposed to long stretches of "burst" loss, where Salsify is pretty good -- you've probably seen the video), since for us a state is either received perfectly or not at all. So there's already a lot of room for improvement in how we handle packet loss, again by incorporating existing techniques in FEC and slice repair.