CCM ciphersuite causes a lot of CPU load #199
Comments
|
Yep, that seems plausible. This is pion-to-pion traffic so the ciphersuite used should be the highest priority one listed there. |
|
It could also be that this list of all cipher is being used instead. |
Before encodeCipherSuites would improperly encode backwards, putting our least preferred suite first. Fix this function so it properly encodes and update TestHandshakeMessageClientHello so it has multiple CipherSuites to make sure this doesn't regress. Relates to #199
Before encodeCipherSuites would improperly encode backwards, putting our least preferred suite first. Fix this function so it properly encodes and update TestHandshakeMessageClientHello so it has multiple CipherSuites to make sure this doesn't regress. Relates to #199
|
@cohosh Fixed! Mind reviewing that PR, I will merge + tag across. |
Match OpenSSL (and Chromium's) ordering of CipherSuites. Go also has a hardware accelerated implementation, so this should be a better experience in almost all cases. Relates to #199
|
|
|
@daenney @at-wat @igolaizola @cohosh I also have moved GCM above CBC. I wanted to add everyone, this feels like something we should have consensus on. My motivation is
I have attached a screenshot above showing Chromium Nightly's current values. |
|
Nice, thanks @Sean-Der ! I'll take a look at this and get back to you later tonight. |
Match OpenSSL (and Chromium's) ordering of CipherSuites. Go also has a hardware accelerated implementation, so this should be a better experience in almost all cases. Relates to #199
Before encodeCipherSuites would improperly encode backwards, putting our least preferred suite first. Fix this function so it properly encodes and update TestHandshakeMessageClientHello so it has multiple CipherSuites to make sure this doesn't regress. Relates to #199
Match OpenSSL (and Chromium's) ordering of CipherSuites. Go also has a hardware accelerated implementation, so this should be a better experience in almost all cases. Relates to #199
|
CCM should really not have been advertised or picked by default at all. That was only added in DTLS in order to support some IoT use-cases, b/c among other things the CoAP RFC requires it. @Sean-Der I'd vote we add a second change, dropping any CCM suite from the defaults. Using CCM should be an explicit opt-in. |
|
W.r.t optimising CCM, that's not really been undertaken yet b/c it would probably mean having to drop down to assembly. That's a maintenance burden and potential massive source of security issues I don't want to incur just yet. |
|
Thanks for taking care of this, the changes solve the issue we were having at our end :) |
If users want CCM they need to explicitly request it. Resolves #199
If users want CCM they need to explicitly request it. Resolves #199
Your environment.
What did you do?
We've been running Snowflake with the pion/webrtc library for a while now. We noticed that our Snowflake proxies were using a lot more CPU than expected in sending and receiving WebRTC messages.
More info on snowflake: https://snowflake.torproject.org
What did you expect?
We expected the CPU usage to be around 10-20% for proxying a single client's traffic.
What happened?
Our CPU usage for a single client was over 60%.
After some investigations, we tracked a lot of CPU heavy operations coming from the CCM ciphersuite. Changing the ciphersuite to GCM resulted in the more expected usage of 10-20%.
See our ticket here: https://trac.torproject.org/projects/tor/ticket/33211#comment:14
I'd suggest
allowing a way for application develoeprs to change the ciphersuite (as filed here: pion/webrtc#1043)
taking a look at the CCM implementation to see if there are some optimizations available there, and
using a different default ciphersuite and update the priority listing of available ciphersuites. GCM is supposed to be slightly more efficient, and is much more commonly seen in practice.
The text was updated successfully, but these errors were encountered: