SD-WAN Added Latency question

[RICHARD MESSINGER]

customer is asking what the expected latency that will be added by the encryption of traffic through the device?

They are concerned with what either a Viptela or Meraki SD-WAN design would add to the overall latency for traffic.  They are primarily sending and receiving engineering drawings so I imagine that files will be expanded in the encryption process.

Any rule of thumb would be appreciated.

[Joseph W. Doherty · Accepted solution]

Good question. Much would depend on devices doing actual encrypt/decrypt.

Can say, have used many non SD-WAN encrypted tunnels across Internet for "typical" apps, including (well working) VoIP and VidConf, and (hardware supported) encryption latency never was on my radar.

Regarding encryption expansion, again for non SD-WAN, data was 1:1 but often close to an extra 100 bytes per packet for overhead.  Big files like engineering drawing least impacted by additional overhead.  Small packets, e.g. telnet or TCP ACKs, most impacted.

[RICHARD MESSINGER]

Thank you.  Just making sure that it is the old engineering answer.  It all depends....

[Joseph W. Doherty]

---

@RICHARD MESSINGER wrote:

Thank you.  Just making sure that it is the old engineering answer.  It all depends....

---

Indeed, and often very true, too.

BTW, when working with encrypted tunnels, one major issue to avoid was IP fragmentation due to the additional overhead.  I don't know what SD-WAN does about that.

Again, additional latency, due to actual encryption/decryption (hardware supported), was not on my radar.  Big issues, running across the WAN was end-to-end distance based latency, and issues due to congestion.

For something like engineering (CADD?) drawings, they, I recall, may compress well, but that's not usually an implicit feature of encryption, although, also again, regardless of data content, encryption doesn't care, data converted 1 for 1.  Pre-compressed engineering drawings should take less time to convey, end-to-end.  (BTW, encrypted data generally doesn't compress well, if at all, or may even expand!)

Biggest potential downside if transmitting a lot of engineering drawings, they may clog the pipe for all other traffic, unless there's active QoS.