[RFC] Platform Independent Communication Protocol

[OwenCochell]

Dear QICK maintainers,

This is Owen Cochell, I’m a PhD student at the University of Illinois and currently working at the National Center for Supercomputing Applications (NCSA) on developing and refining quantum systems, with a focus on enabling OS-level support for qubit controllers like QICK.

I find that QICK uses Pyro and optionally RPyC for its communication protocol between the board and the client, and pickle for its serialization method. These choices make it difficult for QICK to integrate with non Python environments.

I hope to develop a custom network protocol for board communication that is platform independent. The goal is to allow any stack (be it the default QICK Python implementation, a C driver in an OS, etc.) to communicate with other QICK components. I will include a detailed protocol specification, a generic library for parsing and serializing protocol data, unit tests for all components, and integration of this protocol into the QICK project.

I wanted to gauge interest and get initial feedback before I proceed.

Please let me know if it’s something interesting and/or similar efforts have been attempted or are ongoing.

I eagerly await any feedback!

Thanks,

Owen

[meeg]

OK, makes sense. The median QICK user writes experiment code in Python, and for them I feel that the current architecture is a good one; it's also convenient for development that Pyro gives you the same interface whether you're running your code locally (without Pyro) or remotely (through Pyro). On the other hand I do understand the NCSA perspective here (I was at the UIQC conference last month and John Towns gave a talk). So while I think the short-term benefits are not large, I have no problem with your building this and maybe it will be important in the long term. We have no current plans in this direction that would conflict with yours.

If you have a plan in mind that is strictly adding stuff to QICK, without changes to the existing structure of things, go for it - you're promising to deliver this code with good documentation and tests, so it costs us nothing to keep it integrated even if we don't use it. If you have a plan that requires changes "under the hood" but that keeps the user-facing interfaces the same, that's probably fine but let me know what you want to change. Otherwise - tell me more.

The Qibosoq wrapper around QICK (https://arxiv.org/abs/2310.05851) includes their own network protocol - it's not obvious to me what problem they were solving, I think it is not that close to what you're proposing, but maybe it's interesting.

[OwenCochell]

Hello,

Thanks for the response! This would be a purely under the hood change, and should be an optional feature (users can still use the existing stack if they so choose). The user facing interfaces will be exactly the same, and the way users write and execute programs will not be affected by this change. I think this can be implemented by creating an alternative QickSoc class that interacts with the backend via the binary protocol, instead of using the proxied version via pyro that currently exists. That's the plan as of now, the idea is to make this functionality a separate component that can be easily used (or not used) instead of pyro.

The main reason for doing this is to improve flexibility on the backend if using pyro is not an option. In addition to this, there are some nice side effects that fall out of this design that can be explored now or in the future:

• Explicit set of operations that are supported by the backend - no need to proxy the entire QickSoc class, operations the backend provide are more clear
• No python dependence on client side - In theory clients in new languages other than python can be developed
• Possibly lower bandwidth - pyro may add extra overhead to the protocol that requires more data to be sent
• Batching of many operations - I am planning to include support for defining multiple operations in a single message, which could be beneficial as the current setup is very 'chatty' with many small operations
• No pickling - Removes another python dependency and removes possible arbitrary code execution from untrusted clients

Some of these side effects might not be wanted now or in the future, but the protocol will give us the freedom to consider these if they become important. Over the next few weeks i'll be coming up with a spec, implementation, and tests. We can discuss some of the details more as development continues, and I am sure there are some hurdles ahead I am not seeing as of now.

Thanks!