How does the PBS data transfer protocol handle LACP bonded NICs?

Sep 1, 2022
450
175
48
41
I am aware that under most circumstances, just bonding a pair of NICs into an LACP bond doesn't increase speed. An LACP bond creates a two-lane highway, where a single NIC is a one-lane highway. Traffic from a single host is almost always stuck in a single lane for ... reasons. (My understanding of the deeper levels of LACP is unfortunately more than a bit vague).

SMB multichannel, OTOH, does use both NICs in parallel, but cannot work with LACP bonded NICs.
NFS has a similar feature to SMB multichannel (Multipathing?) that may or may not work with LACP bonded NICs. I'm not sure, to be honest. I'm just starting to research this and it's a bit confusing.

So, that got me thinking, what does PBS do with an LACP bond? I know it doesn't use SMB or NFS, but a protocol specific to PBS itself.
Does it have any mechanism to create more than one channel when an LACP bonded vmbr is present to boost speeds?

If not, is that something that's on the roadmap, or technically feasible at all?

It's honestly a bit hard to tell how fast the actual network connection is with a PBS backup, as the reported write speed in the moment is so variable based on the content on the VM or LXC, and the average speed when a backup of a VM or LXC is done is way out of line with actual network throughput, since the average includes the GB/s "writes" where nothing is written because the PVE host is using thin provisioning and, say, only 32 GB of a 256 GB virtual disk is actually in use--writing out that empty space appears to be recorded at GB/s speeds, which blows the average.
 
If not, is that something that's on the roadmap, or technically feasible at all?
PBS currently use a single http2 connection per backup. A future plan is to use http3, but I do not
think that can saturate a LACP connection. So, no - there are no plans to optimize for LACP.
 
PBS currently use a single http2 connection per backup. A future plan is to use http3, but I do not
think that can saturate a LACP connection. So, no - there are no plans to optimize for LACP.
Thanks for the info. :)

I'm not familiar with HTTP/3's benefits over HTTP/2, so I did a bit of quick research after seeing your reply and found this:
https://blog.cloudflare.com/http-3-vs-http-2/

One of the main touted advantages of HTTP/3 is increased performance, specifically around fetching multiple objects simultaneously. With HTTP/2, any interruption (packet loss) in the TCP connection blocks all streams (Head of line blocking). Because HTTP/3 is UDP-based, if a packet gets dropped that only interrupts that one stream, not all of them.

In addition, HTTP/3 offers 0-RTT support, which means that subsequent connections can start up much faster by eliminating the TLS acknowledgement from the server when setting up the connection. This means the client can start requesting data much faster than with a full TLS negotiation, meaning the website starts loading earlier.



Improvements in session startup mean that ‘connections’ to servers start much faster, which means the browser starts to see data more quickly. We were curious to see how much of an improvement, so we ran some tests. To measure the improvement resulting from 0-RTT support, we ran some benchmarks measuring time to first byte (TTFB). On average, with HTTP/3 we see the first byte appearing after 176ms. With HTTP/2 we see 201ms, meaning HTTP/3 is already performing 12.4% better!

(That's a really interesting article. I cut out most of what I quoted. It's worth reading. It's also at least 5 years old so there's probably newer, better performance testing available on the actual, current standard.)

@dietmar From what little I've read so far, making the switch to HTTP/3 should make PBS backup sessions quicker due primarily to stability enhancements/reduction in blocking packet loss.

Have y'all noticed a major throughput difference in testing, as well?