[Qirg] draft-wang-qirg-quantum-internet-use-cases-04; MVDB02

VAN DEN BOSSCHE Mathias <mathias.van-den-bossche@thalesaleniaspace.com> Tue, 10 March 2020 11:01 UTC

Return-Path: <mathias.van-den-bossche@thalesaleniaspace.com>
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 ECB003A1097 for <qirg@ietfa.amsl.com>; Tue, 10 Mar 2020 04:01:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=thalesaleniaspace.com
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 6bF6MZ2bxOMu for <qirg@ietfa.amsl.com>; Tue, 10 Mar 2020 04:01:08 -0700 (PDT)
Received: from thsbbfxrt01p.thalesgroup.com (thsbbfxrt01p.thalesgroup.com [192.54.144.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC7EE3A1087 for <qirg@irtf.org>; Tue, 10 Mar 2020 04:01:07 -0700 (PDT)
Received: from thsbbfxrt01p.thalesgroup.com (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 48cBwL08RZz45Pr for <qirg@irtf.org>; Tue, 10 Mar 2020 12:01:06 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thalesaleniaspace.com; s=xrt20190201; t=1583838066; bh=Zn0V52jxXwWUoR/1sXlBsdeRkGYOelFVqnRnw8HWpP0=; h=From:To:Subject:Date:Message-ID:MIME-Version:From; b=WRX3HLSdJUXKQr926OAaii58Pv2SbHUHEsfPXJ7XMNmMSDZvMpKcbFsH1cW4CMUjW Y/R0QZjh8/sufxvHHV019n6QTCduC8MWJfnF2ykbNjhAeSElusuC0X7C/apiVaSazE V+CPBeWVcIYx2cAmum+WSfUAiM6mXdG7pn4wbRf2l3SAQYjGgP/cI7epkEMYDoKOm1 kPYzsGjh6hPJv79z0mQAJaLcys9ovO9FsHnFzPeuJ7aOLJer7yU4RThfdngRhAL0m/ DlMQrFA+Se/9ul8bKOyju6Npi3otKeQmwWVMaI+RsmH3LK93JYC+rMYztqlAMwckGQ jKnJyFl8WQ4dA==
From: VAN DEN BOSSCHE Mathias <mathias.van-den-bossche@thalesaleniaspace.com>
To: "qirg@irtf.org" <qirg@irtf.org>
Thread-Topic: draft-wang-qirg-quantum-internet-use-cases-04; MVDB02
Thread-Index: AdX2yvOdvkt763zoTOavDE/W2zIhzw==
Date: Tue, 10 Mar 2020 11:01:04 +0000
Message-ID: <8cb48647b7de4ddd86cb2651b42019c2@thalesaleniaspace.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-pmwin-version: 4.0.3, Antivirus-Engine: 3.77.1, Antivirus-Data: 5.73
Content-Type: multipart/alternative; boundary="_000_8cb48647b7de4ddd86cb2651b42019c2thalesaleniaspacecom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/qirg/OlHcEWQFJBqLg2cdTuYLb5oa6Iw>
Subject: [Qirg] draft-wang-qirg-quantum-internet-use-cases-04; MVDB02
X-BeenThere: qirg@irtf.org
X-Mailman-Version: 2.1.29
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, 10 Mar 2020 11:01:10 -0000

Doc: draft-wang-qirg-quantum-internet-use-cases-04

ID : MVDB 02

Page/section: p 4/ § 4.1

Proposal/Question:

The mention of the OSI layers is somehow confusing for Quantum Information Networks(QIN).
It should probably be avoided.
BTW, this is more for an architecture document than for a use case document.

Explanation:

Actually, the main idea of the OSI model is to abstract the classical network organisation layer by layer, so as to encapsulate the lower layers into the higher layers and allow overall manipulation without caring about the lower level details. The point is, quantum network have a very different way of working from classical network, and we should be careful in concept reuse.
The main point here is that the end-to-end connection within a QIN is a _single physical layer_. This is completely different from classical networksthat keep decoding/encoding the data on different physical layers, and in different format to hand them to the next layer above. The two main differences are
* the QIN does not forward data (that would be quantum information) but only entanglement. The data is sent only when the end-to-end entanglement link is  established.
* the QIN nodes cannot decode/encode all along the way, because of the quantum nature of measurements - this is why we need a single physical layer.
  This also probably why QINs can only be connected my merging, and not at the higher level of the network or transport layers (OSI3/4), as is the case with classical networks.

Overall, this probably means that the network protocol stack is simpler for QINs.  It should be reworked in its own right, probably with low similarity to the OSI model.


Discussion:

TBD

Decision:

TBD

[@@ THALES ALENIA SPACE INTERNAL @@]