Encryption algorithm multiple threads/cores for higher throughput There are situations where a single connection (or file) may require additional throughput available. While network bandwidth and CPU cores are available, they cannot be utilised. (Aside from means that are external to the algorithm as is)
Some examples:

VPN - when encryption is done only on the tunnel connection that internally encapsulates packets of multiple flows.

Typically, it is thought that an encryption algorithm itself is a sequential process, that relies on the previous block or bit(s) in order to accomplish effective cipher strength. This means the algorithms cannot be multi-threaded.
Is this true of all encryption? Does this apply equally to modern common algorithms (block and stream)?
Is there a way to purpose-make an encryption algorithm that works on multiple threads (cores)? Are there any existing algorithms (perhaps not common or academic only) that would work across multiples cores?
Usually, this isn't a problem, because machines may make use of multiple connections (HTTPS), but it means a single connection is limited by the cipher transform speed of a single CPU core. Also, when multiplexing is used (like VPN), this might be a particularly limiting issue.
Typically, it is thought that an encryption algorithm is a sequential process, that relies on the previous block or bit(s) in order to accomplish effective cipher strength. This means the algorithms cannot be multi-threaded.

This is only true for &quot;heavy-handed&quot; operations like CBC-MAC (and its variants), HMAC and CBC. For most of modern cryptography as implemented, parallelizability is both a feature an a necessity for high performance implementations.
Before jumping to the schemes that are relevant to you in this context, let me clarify why parallelism is actually a necessity. You might have heard of the AES-NI. These are instructions that perform one AES round per instruction. However, the instructions don't have a latency of 1 CPU cycle but of 3-7 CPU cycles even though they have a throughput of at least 1 instruction per cycle. Latency in this context means that if instruction B depends on the result of instruction A, B must wait for the full latency of A. So, what you need to do to optimally use your hardware is to have 8 data-independent AES operations be run in parallel which is quite tricky with request-level parallelism. So instead what schemes do, is they use a parallelizable scheme and don't compute one block of AES data at a time, but rather 8 or however many is optimal for the implementation.
But how can this be done, you surely ask yourself:

If you want CPA-secure encryption, CTR-mode transforms a block cipher into a stream cipher by encrypting a counter.
If you want a nonce-based MAC, GMAC can be parallelized - which is commonly exploited to reduce the number of reductions to compute.
If you want a full-blown parallel PRF, PMAC is the way to go, though it is not seen as often in practice due to the prominence of HMAC or single-block AES where needed.
If you want a parallel hash algorithm, you can use tree-hashing.
If you want authenticated encryption, AES-GCM can be parallelized - as it is essentially composed of GMAC and CTR.
If you want nonce-misuse-resistant authenticated encryption, the generic SIV transform and AES-GCM-SIV both require two passes but each pass can be parallelized - at least for the encryption, the decryption is natively parallel.