Re: [Cfrg] network traffic

[David Jacobson <[e-mail]>]

Where computational efficiency does matter is code verification in 
embedded systems.  For automotive systems, they often want boot times on 
the order of half a second or less.  The code is running on a low-end 
ARM processor and has to validate the certificate chain and the 
executable image.  In some mobile systems, entire subsystems (say WiFi) 
are shut down when not being used, to save power.  They are powered back 
on, and have to boot and verify the code signature in a new 
milliseconds. Alas, in these systems there is no secure non-volatile 
memory available and thus the shortcut of just checking the hash of the 
image against the correct value won't work.

Now admittedly the CFRG serves the IETF, and thus is focused on network 
issues, not embedded systems. So my remarks are perhaps out of scope.  
But standards developed for networking are widely used for other things.

     --David Jacobson

On 2/23/15 3:12 AM, RONDEPIERRE Franck wrote:
> I suggest another view for this study with same figures.
>
> Let's say we are working at 128 bit of security, with uncompressed 64-byte points. Let's assume the key agreement requires 300k CPU cycles.
> Hence each 3GHz CPU can process 10k key agreements per second whereas the network can absorb 195k key agreements per second.
> Besides, most websites do not have more than 10k connections per second, with the exception of google which processes roughly 65k researches per second in 2014 (less than in 2013).
> In this context, which part benefits most from improvement? I'd rather say that saving computations would help to increase the capacity of websites.
> How this still means nothing as long as we don't identify the bottleneck by taking into account the global network capacity, the cost to install wires, the cost of servers (internet providers or web sites)...
>
> I personally doubt it has importance at our level, since big companies will adapt (or not) depending on their policy to fit customers needs and they would make us pay for it (with more commercials or money). I also reckon that cryptography has currently no impact on the internet bandwidth.
>
> On the internet user side, I think we can agree that saving time is pointless since the whole cost of the key agreement (0.1 ms) is nothing compare to human times.
>
> My current personal point of view is that internet industry doesn't really need performance improvements, but I'm ready to listen other argumentations.
>
> Regards,
>
> Franck Rondepierre
>
> -----Message d'origine-----
> De : Cfrg [mailto:[e-mail]] De la part de D. J. Bernstein
> Envoyé : lundi 23 février 2015 04:21
> À : [e-mail]
> Objet : [Cfrg] network traffic
>
> Kurt Roeckx writes:
>> Depending on who you ask you might get a different answer, but I doubt
>> many people here care about bandwidth.
> I care very much about network traffic---although it has to be quantified and put into context, just like CPU time.
>
> As a concrete example, suppose your server resources are ten quad-core 3GHz CPUs and a 100Mbps network connection. Each microsecond the CPUs will perform a total of 120000 cycles of computation while the network connection will transmit 100 bits, i.e., 12.5 bytes.
>
> Case study 1: Suppose you save 20000 cycles of computation by replacing a compressed 32-byte point with an uncompressed 64-byte point. You're
>
>     * saving 0.17 microseconds of computation but
>     * costing 2.56 microseconds of network capacity.
>
> Is this a worthwhile tradeoff? The factor 15 imbalance suggests an answer of "no" (unless your ten servers cost fifteen times more than your network connection, which I doubt). This isn't a guarantee---maybe at this instant your CPUs are fully loaded while your network isn't--- but my experience is that if you need to reduce CPU time then there will be many better ways to reduce CPU time in other parts of the system with less cost to the network.
>
> For me security and simplicity are ample reasons to require compression, but this example still illustrates how to think about the performance impact.
>
> Case study 2: Suppose you save 200000 cycles of computation by switching from 65-byte numsp512t1 points to 66-byte E-521 points. You're
>
>     * saving 1.67 microseconds of computation but
>     * costing 0.08 microseconds of network capacity.
>
> Is this a worthwhile tradeoff? The factor 20 imbalance the other way suggests an answer of "yes" (unless your network connection costs twenty times more than your ten servers, which I doubt). This again isn't a guarantee---maybe at this instant your network is fully loaded while your CPUs aren't---but my experience is that there will be many better ways to reduce network traffic in other parts of the system with less cost to the CPUs.
>
> I should note that a single numsp512t1 coordinate uses only 64 bytes, but sending a compressed second coordinate spills over into another byte. Of course, a single-coordinate ladder skips this compressed bit; there are various cheap tricks to squeeze more bits out of keys; and one can always squeeze out another bit by doubling the key-generation time.
> Any method of saving 1 bit will squeeze numsp512t1 into 64 bytes; any method of saving 4 bits will squeeze E-521 into 65 bytes; any method of saving 9 bits will squeeze numsp512t1 into 63 bytes; etc.
>
> ---Dan
>
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> http://www.irtf.org/mailman/listinfo/cfrg
>
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> http://www.irtf.org/mailman/listinfo/cfrg
>