Head-of-line blocking

Users and Developers
1

I’m considering using parts of libp2p for circulex, but I’m a little concerned about one thing in the documentation:

The “medium” over which a libp2p protocol transpires is a bi-directional binary stream with the following properties:
…

    • Data is read in the same order as it was written

Does this mean that libp2p protocols all suffer from head-of-line blocking, like TCP, even if TCP isn’t the underlying transport?

This isn’t necessarily a dealbreaker for circulex, but circulex is oriented around messages, rather than streams, and some of those messages are more important and urgent than others, so if they’ve been received, it would be a shame to delay processing them until earlier less important messages have also been received.

I like what I’ve seen written about SCTP, including its message-oriented nature, and its avoidance of head-of-line blocking, so it’s currently specified in the unfinished draft circulex specification. Has SCTP (or any of its design features) been considered by the libp2p community?

2

Data is read in the same order as it was written

This applies to the individual stream. If you need to avoid HOL blocking, you can open separate logical streams.

Caveat: even with the above strategy, you can still get HOL blocking if you use TCP as the underlying transport. Use QUIC instead.

1 Like