Re: [Qirg] hardware components

Rodney Van Meter <rdv@sfc.wide.ad.jp> Tue, 27 March 2018 03:03 UTC

Return-Path: <rdv@sfc.wide.ad.jp>
X-Original-To: qirg@ietfa.amsl.com
Delivered-To: qirg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C784012D7F2 for <qirg@ietfa.amsl.com>; Mon, 26 Mar 2018 20:03:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 yY-qR6jXwRfX for <qirg@ietfa.amsl.com>; Mon, 26 Mar 2018 20:03:45 -0700 (PDT)
Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6F4312D7EC for <qirg@irtf.org>; Mon, 26 Mar 2018 20:03:44 -0700 (PDT)
Received: from [10.133.2.109] (kmobile2.sfc.keio.ac.jp [133.27.5.48]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id B9E09278371; Tue, 27 Mar 2018 12:03:42 +0900 (JST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Rodney Van Meter <rdv@sfc.wide.ad.jp>
In-Reply-To: <alpine.LRH.2.00.1803262026100.4119@rtp-ads-285.cisco.com>
Date: Tue, 27 Mar 2018 12:03:42 +0900
Cc: Rodney Van Meter <rdv@sfc.wide.ad.jp>, qirg@irtf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <90D0D337-433C-467B-8A93-0EAE371ABFCE@sfc.wide.ad.jp>
References: <7DFAEB8A-3FF6-40CC-9710-8ABA35574F7D@sfc.wide.ad.jp> <alpine.LRH.2.00.1803262013470.4119@rtp-ads-285.cisco.com> <E32C865B-1DD1-4312-8286-04C34605BAF1@sfc.wide.ad.jp> <alpine.LRH.2.00.1803262026100.4119@rtp-ads-285.cisco.com>
To: "rbroberg@cisco.com" <rbroberg@cisco.com>
X-Mailer: Apple Mail (2.2104)
Archived-At: <https://mailarchive.ietf.org/arch/msg/qirg/tXFMnQSCKBbwJj0ODhMkJoVyFBg>
Subject: Re: [Qirg] hardware components
X-BeenThere: qirg@irtf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Quantum Internet \(proposed\) RG" <qirg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/qirg>, <mailto:qirg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/qirg/>
List-Post: <mailto:qirg@irtf.org>
List-Help: <mailto:qirg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/qirg>, <mailto:qirg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Mar 2018 03:03:47 -0000

Let’s try this again — I left off photon sources, which are important!
(Further corrections welcome.)

I'm looking forward to discussing the 1G, 2G, 3G taxonomy here (which
has to do with how errors are handled, and affects timing and
throughput), but there is some basic ground we ought to cover first.

First, the types of hardware components we need (list v2):

* quantum memory: can be a single atom, or a quantum dot, or an
  electron trapped in a lattice defect in a diamond, etc. (There are
  also all-optical repeater proposals that use no stationary memory,
  but I think they are even farther from implementation.)  These
  memories have two roles: pure buffer qubits with no ability to
  couple to photons, or transceiver qubits that can emit, absorb or
  otherwise interact with the photons we want to put into our optical
  channel, creating entanglement between the photon and the memory.
* optical channel: optical fiber or another waveguide, or free space;
  ideally, of course, with low loss and high fidelity.
  (Simon Devitt, Ashley Stephens, Andy Greentree and I also
  investigated distributing entanglement via ship, but that's another
  story.)
* wavelength conversion: most of the phenomena proposed don't generate
  photons at telecom wavelengths, so various techniques are being
  developed to convert the frequency of a single photon.
* interferer: most of the link architectures require the interference
  of optical signals (the good, intentional kind in inteferometers,
  not the noise kind).  This can be a half-silvered mirror or
  specially constructed piece of fiber, for example.
* single-photon detectors: many different kinds in development,
  ranging from cheap to if-you-have-to-ask-you-can't-afford-it to
  there-is-only-one.  I'm no expert on them, perhaps one of the
  experimentalists can chime in here.
* single-photon sources: You can make single photons by attenuating a
  laser pulse, but it's statistical and sometimes gives you a
  two-photon pulse instead of one, which is problematic for many
  uses.  Also, whether you succeed in getting one is probabilistic.
  Some other methods include getting a quantum dot to emit a single
  photon.  (Note the relationship with transceiver memories, above;
  the difference here is that a single-photon source isn't entangled
  with the photon after emission.)
* entangled photon pair sources: Some architectures can use a device
  that emits pairs of entangled photons.  Send one photon to the left
  and one to the right, and at the receivers you can do many
  interesting things.  These photons are not entangled with any
  stationary memory.

With those pieces, plus the protocols & architecture we are ostensibly
investigating here, you can build a repeater network.