Introduction to QBSS

QBSS, or Quiche Block Storage Service, is an EI service designed to allow senders to publish a stream of data in the form of blocks. Blocks are designed to be concrete, reasonably sized data units that can be rapidly downloaded and processed. Receivers can then subscribe to a stream and be notified when new blocks are published, and then choose to download them. Intermediates between senders and receivers cache downloaded blocks so that multiple receivers can all download a block quickly. The service uses Quiche streams to transfer information reliably over EI pipes.

Stream Information Controller

QBSS requires an HTTP-based external controller that all nodes must communicate basic stream information with. This controller purely holds stream metadata, and does not push out any information- senders and receivers instead push and pull information from it directly. The controller keeps track of stream subscriptions from receivers, and recievers can ask for an update on all streams they are subscribed to.

The QBSS controller can also take commands directly from applications other than an EI node running QBSS. This can be useful for monitoring stream state on an external platform, which may help in detecting faults on a node that need to be corrected.

Endpoints must be configured with the controller’s HTTP address:

./bin/ctl tree.add_child --tree=config --path='./"services"/"qbss"/"controller_address"/"http://{bss_ip_addr}:{port}/bssctl/"'

The controller can be started via:

./qbss/scripts/run_controller.sh

Node Roles

Every node must be assigned a role (sender, receiver, or intermediate server). These are assigned in the EI config tree:

./bin/ctl tree.add_child --tree=config --path='./"services"/"qbss"/"role"'
./bin/ctl tree.write --tree=config --path='./"services"/"qbss"/"role"' --value=<value>

The values for each role are defined in qbss/headers.h, as the type enum qbss_role_t.

Dom, SN, Pipe (DSP)

Every sender and receiver endpoint must be configured with a “first-hop” intermediate node. This is either automatically chosen, or can be set via services/qbss/dsp_pipe_id in the EI config tree. The first-hop then tells the endpoint what its Dom, SN, and Pipe are as seen by the first-hop. This is called the endpoint’s DSP.

Stream Information

A stream in QBSS is denoted by a UUID. The UUID is given by the sender when the stream is created, or the sender can ask QBSS to generate one. The controller marks the DSP of the sender that created the stream. The sender updates the controller with what block numbers are available on that stream, and receivers can then download that information to choose what block numbers to request.

Block Retrieval and Caching

Every node in QBSS has a block cache. This contains all blocks available on the node. A node downloads a block any time it needs to send it somewhere else- that is, when a request for that block arrives. The size of the block cache on a node is configurable. The cache is non-persistent, even on senders. When a block is added to the cache, or accessed via a request for the block, an LRU cache is updated marking the block as used. When the cache is full and a new block is added, the lowest numbered block of the least recently used stream will be deleted [1].

When a block is requested from a receiver, the QBSS controller will be queried to see what the source DSP of the stream is. The receiver will then request the block from its first hop intermediate along with the source DSP. This process will repeat along the path to the source DSP, at which point the block will be sent back along the path, one hop at a time, with each hop caching the block. Once the receiver has the block, it will be given to the requesting host stack and also cached at the receiver.

Wrapper Proxy and Client

We provide a QBSS wrapper proxy and a client to access the wrapper proxy. The proxy can be run with qbss/proxy/run_proxy.sh and the client can be imported into a Python application. We provide documentation for both these components in the relevant pages for these two modules.

Footnotes

[1]

To prevent unfairness, QBSS tracks the least recently used block of all blocks, and deletes the lowest block of the stream with the least recently used single block.