When you setup an ECMP and/or LAG the packets can (usually) be loadbalanced either by flow (aka per-flow, such as the combo of srcip+dstip+srcport+dstport so a specific tcp-session will only use a single path) or per packet (aka per-packet, where packet1 goes path1, packet2 goes path2, packet3 goes path1 and so on).
Traditionally using the per-flow loadbalancing is considered more "safe" because packet order within a flow is maintained however more and more equipment today supports per-packet (and even start to default to that) which will better utilize available links.
Imagine you got 10G hosts but only 1G links in between. With per-flow the max speed for a single filetransfer will become 1G but with per-packet, if you have lets say 8 links, the max speed is now 8G for a single filetransfer.
Another situation is if you are unlucky and two flows are selected to use the same physical path so instead of host11 got 1G to host21 and host12 got 1G to host22 they both got 0.5G.
Anyhow the worry of using per-packet is the possibility of out-of-order packets but how is this a problem (if ever) in reallife if you use up2date linux and/or windows clients/servers?
I can imagine there might exist some usecases like VoIP who needs to have the packets within the decoding window (like 10-30ms) where any late packets are just discarded, but other than that?
Anyone experienced any problems in reality when using per-packet loadbalancing over ECMP/LAG links and if so any fixes to mitigate this (I would assume increase some buffer in the tcpstack settings on the linux/windows boxes)?
No comments:
Post a Comment