### [Cfrg] network traffic

"D. J. Bernstein" <djb@cr.yp.to> Mon, 23 February 2015 03:21 UTC

Return-Path: <djb-dsn2-1406711340.7506@cr.yp.to>

X-Original-To: cfrg@ietfa.amsl.com

Delivered-To: cfrg@ietfa.amsl.com

Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 378151A013B for <cfrg@ietfa.amsl.com>; Sun, 22 Feb 2015 19:21:14 -0800 (PST)

X-Virus-Scanned: amavisd-new at amsl.com

X-Spam-Flag: NO

X-Spam-Score: 2.896

X-Spam-Level: **

X-Spam-Status: No, score=2.896 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, UNPARSEABLE_RELAY=0.001] autolearn=no

Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NBl2ptGQPYTv for <cfrg@ietfa.amsl.com>; Sun, 22 Feb 2015 19:21:12 -0800 (PST)

Received: from calvin.win.tue.nl (calvin.win.tue.nl [131.155.70.11]) by ietfa.amsl.com (Postfix) with SMTP id 925521A0141 for <cfrg@irtf.org>; Sun, 22 Feb 2015 19:21:11 -0800 (PST)

Received: (qmail 22808 invoked by uid 1017); 23 Feb 2015 03:21:29 -0000

Received: from unknown (unknown) by unknown with QMTP; 23 Feb 2015 03:21:29 -0000

Received: (qmail 23372 invoked by uid 1000); 23 Feb 2015 03:21:02 -0000

Date: Mon, 23 Feb 2015 03:21:02 -0000

Message-ID: <20150223032102.23370.qmail@cr.yp.to>

From: "D. J. Bernstein" <djb@cr.yp.to>

To: cfrg@irtf.org

Mail-Followup-To: cfrg@irtf.org

In-Reply-To: <20150222163717.GA6342@roeckx.be>

MIME-Version: 1.0

Content-Type: text/plain; charset="utf-8"

Content-Disposition: inline

Content-Transfer-Encoding: 8bit

Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/2IUOrUlnP_tqehkkO0qx1GRg-fU>

Subject: [Cfrg] network traffic

X-BeenThere: cfrg@irtf.org

X-Mailman-Version: 2.1.15

Precedence: list

List-Id: Crypto Forum Research Group <cfrg.irtf.org>

List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>

List-Archive: <http://www.irtf.org/mail-archive/web/cfrg/>

List-Post: <mailto:cfrg@irtf.org>

List-Help: <mailto:cfrg-request@irtf.org?subject=help>

List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>

X-List-Received-Date: Mon, 23 Feb 2015 03:21:14 -0000

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] Elliptic Curves - poll on specific curve a… Alexey Melnikov
- Re: [Cfrg] Elliptic Curves - poll on specific cur… Ilari Liusvaara
- Re: [Cfrg] Elliptic Curves - poll on specific cur… Alyssa Rowan
- Re: [Cfrg] Elliptic Curves - poll on specific cur… Aaron Zauner
- Re: [Cfrg] Elliptic Curves - poll on specific cur… Dan Harkins
- Re: [Cfrg] Elliptic Curves - poll on specific cur… Tony Arcieri
- Re: [Cfrg] Elliptic Curves - poll on specific cur… Stephen Farrell
- Re: [Cfrg] Elliptic Curves - poll on specific cur… James Cloos
- Re: [Cfrg] Elliptic Curves - poll on specific cur… Jon Callas
- Re: [Cfrg] Elliptic Curves - poll on specific cur… Mike Hamburg
- Re: [Cfrg] Elliptic Curves - poll on specific cur… Adam Langley
- Re: [Cfrg] Elliptic Curves - poll on specific cur… Jon Callas
- Re: [Cfrg] Elliptic Curves - poll on specific cur… Russ Housley
- Re: [Cfrg] Elliptic Curves - poll on specific cur… Phillip Hallam-Baker
- Re: [Cfrg] Elliptic Curves - poll on specific cur… Watson Ladd
- Re: [Cfrg] Elliptic Curves - poll on specific cur… Tony Arcieri
- Re: [Cfrg] Elliptic Curves - poll on specific cur… Ilari Liusvaara
- Re: [Cfrg] Elliptic Curves - poll on specific cur… Paterson, Kenny
- Re: [Cfrg] Elliptic Curves - poll on specific cur… Phillip Hallam-Baker
- Re: [Cfrg] Elliptic Curves - poll on specific cur… Watson Ladd
- Re: [Cfrg] Elliptic Curves - poll on specific cur… Michael Hamburg
- Re: [Cfrg] Elliptic Curves - poll on specific cur… Blumenthal, Uri - 0558 - MITLL
- Re: [Cfrg] Elliptic Curves - poll on specific cur… Phillip Hallam-Baker
- Re: [Cfrg] Elliptic Curves - poll on specific cur… Michael Hamburg
- Re: [Cfrg] Elliptic Curves - poll on specific cur… Alyssa Rowan
- Re: [Cfrg] Elliptic Curves - poll on specific cur… Tony Arcieri
- Re: [Cfrg] Elliptic Curves - poll on specific cur… Tony Arcieri
- Re: [Cfrg] Elliptic Curves - poll on specific cur… Jon Callas
- Re: [Cfrg] Elliptic Curves - poll on specific cur… Damien Miller
- Re: [Cfrg] Elliptic Curves - poll on specific cur… Damien Miller
- Re: [Cfrg] Elliptic Curves - poll on specific cur… Tony Arcieri
- Re: [Cfrg] Elliptic Curves - poll on specific cur… Watson Ladd
- Re: [Cfrg] Elliptic Curves - poll on specific cur… Phillip Hallam-Baker
- Re: [Cfrg] Elliptic Curves - poll on specific cur… Michael Scott
- Re: [Cfrg] Elliptic Curves - poll on specific cur… Paterson, Kenny
- Re: [Cfrg] Elliptic Curves - poll on specific cur… Paterson, Kenny
- Re: [Cfrg] Elliptic Curves - poll on specific cur… Torsten Schuetze
- Re: [Cfrg] Elliptic Curves - poll on specific cur… Alyssa Rowan
- Re: [Cfrg] Elliptic Curves - poll on specific cur… Aaron Zauner
- Re: [Cfrg] Elliptic Curves - poll on specific cur… Kurt Roeckx
- Re: [Cfrg] Elliptic Curves - poll on specific cur… Ilari Liusvaara
- Re: [Cfrg] Elliptic Curves - poll on specific cur… Andrey Jivsov
- [Cfrg] network traffic D. J. Bernstein
- Re: [Cfrg] network traffic Kurt Roeckx
- Re: [Cfrg] Elliptic Curves - poll on specific cur… Simon Josefsson
- Re: [Cfrg] network traffic RONDEPIERRE Franck
- Re: [Cfrg] network traffic David Jacobson
- Re: [Cfrg] Elliptic Curves - poll on specific cur… Phillip Hallam-Baker
- Re: [Cfrg] Elliptic Curves - poll on specific cur… Damien Miller
- Re: [Cfrg] Elliptic Curves - poll on specific cur… Michael Hamburg
- Re: [Cfrg] Elliptic Curves - poll on specific cur… Michael Hamburg
- Re: [Cfrg] network traffic Kurt Roeckx
- Re: [Cfrg] Elliptic Curves - poll on specific cur… _MiW