Subject: Re: [Qirg] Qirg Digest, Vol 12, Issue 16

From: gyananjay rai <[email-masked]>
Date: Fri, 15 Mar 2019 04:07:26 +0530

What paradigm shift takes place in existing  frame works  if we create our
entire quantum infrastructure (Servers,hardwares,repeters,possibly
routers,datacentres ,quantum cloud)
in space on satellite.Only end nodes/user interface  will be located on
ground.

I mean is there possibility of many fold improvements in lesser cost for

1.error correction
2.noise reduction
3.Fidelity
3 rate
4.Bell pair destributiion
6 Memory lifetime
 and possibly a consumer viable quantum computer

Regards
Gyananjay

On Fri, 15 Mar 2019, 03:40 , <[email-masked]> wrote:

> Send Qirg mailing list submissions to
>         [email-masked]
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://www.irtf.org/mailman/listinfo/qirg
> or, via email, send a message with subject or body 'help' to
>         [email-masked]
>
> You can reach the person managing the list at
>         [email-masked]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Qirg digest..."
> Today's Topics:
>
>    1. Re: Qirg Digest, Vol 12, Issue 15 (gyananjay rai)
>    2. Re: connection setup (Rodney Van Meter)
>
>
>
> ---------- Forwarded message ----------
> From: gyananjay rai <[email-masked]>
> To: [email-masked]
> Cc:
> Bcc:
> Date: Fri, 15 Mar 2019 03:14:13 +0530
> Subject: Re: [Qirg] Qirg Digest, Vol 12, Issue 15
> Hi Wojtek,
>
> Being a classical computing guys from chemical engineering background the
> draft give a good insight of quantum network architecture. Infact last 3
> drafts Axel /Rod/your's slowly getting me of nearer to quantum computing
> phenomenon.
>
> Certainly I never had opportunity do actual research realisation,but next
> step I Can think of  is to get quantum constrain frame .
> It comprise quad elements
> 1.Fidelity
> 2.Memory lifetime
> 3.Rate for Bell pair generation.
> 4.Bell pair distribution
>
> Taking certain outcome of classical computing as reference I can think of
> braking the constrain frame with cross desciplinary iterative phenomenon
> (resonance ,vacumn ,space etc list is exhaustive for hit and trial
> ),materials (entire periodic table where you have a trade off for material
> property choice).
>
>
> Once findamental goals and principle are set ,it is natural to break the
> constrain in order to realise the quantum computing.
>
>
> Sincerely
> Gyananjay
>
>
> On Fri, 15 Mar 2019, 00:33 , <[email-masked]> wrote:
>
>> Send Qirg mailing list submissions to
>>         [email-masked]
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>>         https://www.irtf.org/mailman/listinfo/qirg
>> or, via email, send a message with subject or body 'help' to
>>         [email-masked]
>>
>> You can reach the person managing the list at
>>         [email-masked]
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of Qirg digest..."
>> Today's Topics:
>>
>>    1. Re: connection setup (Wojciech Kozlowski)
>>    2. Re: agenda (Gelard Patrick)
>>
>>
>>
>> ---------- Forwarded message ----------
>> From: Wojciech Kozlowski <[email-masked]>
>> To: Rodney Van Meter <[email-masked]>, "[email-masked]" <[email-masked]
>> >
>> Cc:
>> Bcc:
>> Date: Thu, 14 Mar 2019 10:10:51 +0100
>> Subject: Re: [Qirg] connection setup
>> Hi Rod,
>>
>> Very interesting draft. I have some questions/remarks:
>>
>>
>>    1. I think I could benefit from a more specific use-case example. I
>>    am struggling a bit to understand at what stage these connections are made.
>>    Is this something that a network sets up ahead of time, or is this set up
>>    per flow and must be maintained for its duration? I think this would also
>>    shed light on how failures along the path should be handled.
>>
>>    At the moment I'm reading it as if it's set up per end-to-end
>>    connection. What happens if a node fails during various stages of the
>>    process?
>>
>>    2. The new craze in classical networking as far as I can tell is
>>    segment routing. I don't know much about it, but my brief read on (
>>    http://www.segment-routing.net/) suggests that this is a classical
>>    mechanism that can be extended with QCaps. It even supposedly supports
>>    network programming which is exactly what you want to do. Would be worth
>>    investigating further.
>>
>> Thanks,
>>
>> Wojtek
>>
>> On 13/03/2019 01:39, Rodney Van Meter wrote:
>>
>> We uploaded a draft on connection setup in a quantum network.  This
>> represents how our quantum Internet simulator actually does things today,
>> though the implementation isn’t yet truly complete.
>>
>> https://datatracker.ietf.org/doc/draft-van-meter-qirg-quantum-connection-setup/
>>
>> With the chair’s permission(???), would like to add this to the agenda
>> for Prague.
>>
>> —Rod
>>
>> P.S. I don’t think any of the three new drafts that were uploaded have
>> correctly shown up as QIRG-related.  Will see what I can do to fix.
>>
>>
>> _______________________________________________
>> Qirg mailing [email-masked]://www.irtf.org/mailman/listinfo/qirg
>>
>>
>>
>>
>>
>> ---------- Forwarded message ----------
>> From: Gelard Patrick <[email-masked]>
>> To: Wojciech Kozlowski <[email-masked]>, "[email-masked]" <
>> [email-masked]>
>> Cc:
>> Bcc:
>> Date: Thu, 14 Mar 2019 15:38:49 +0000
>> Subject: Re: [Qirg] agenda
>> Hi Wojtek
>>
>> Very interesting draft.
>>
>> I have a little comment..
>>
>> You wrote :
>>
>>         - “The key message here is that a network stack relies on the
>> hardware being able to provide two services: Bell Pair generation across a
>> link, and swap operation. In any network model it is assumed that the
>> physical device is capable of providing both of these services and offers a
>> suitable interface for their usage.”
>>
>> It may also be appropriate to separate these two functions (Bell Pair
>> generation and swap operation ). I am thinking, for example, of the
>> scenario where the generation of Bell pairs would be done by a satellite
>> and the swap by ground nodes ( https://arxiv.org/abs/1410.5384 ).
>>
>>
>> Thanks
>> /Patrick
>> De : Qirg <[email-masked]> De la part de Wojciech Kozlowski
>> Envoyé : samedi 9 mars 2019 12:55
>> À : [email-masked]
>> Objet : Re: [Qirg] agenda
>>
>> Hi all,
>>
>> I would like to add an item to the agenda.
>>
>> I would like to start work as a group on the first work item in the
>> charter:
>>
>> An architectural framework delineating network node roles and
>> definitions, to build a common vocabulary and serve as the first step
>> toward a quantum network architecture.
>>
>> To start this I have just submitted a draft called "Architectural
>> Principles for a Quantum Internet"
>> https://datatracker.ietf.org/doc/draft-irtf-qirg-principles/. The goal
>> of the draft is to start this discussion. It consists of three parts:
>> 1. An introduction to quantum information - my goal was to make this
>> document self-contained so that people with no quantum background can
>> understand it and make a contribution to the discussion. The introduction
>> is brief and will not replace a proper tutorial (such as the one organised
>> by Rodney and Tracy), but it should cover the basic concepts and how they
>> fit together.
>> 2. A brief review and summary of the current state of quantum networks.
>> It introduces concepts such as Bell Pairs and entanglement swapping and how
>> the pieces fit together.
>> 3. I propose a set of goals and principles for the architecture. The
>> goals define what a successful architecture achieves and the principles are
>> guidelines to achieve it. This is the key point of the draft and the one
>> that is up for discussion.
>> I would also like to add that one other goal of this draft is to engage
>> the classical networking people just like the tutorial organised by Rodney
>> and Tracy.
>> This draft is merely my attempt to start a discussion and I would very
>> much like to see many iterations and would be very happy to see as many
>> people contribute as possible and anyone should feel free to contribute.
>> Any feedback now or at the meeting itself is more than welcome!
>> Thanks,
>> Wojtek
>> On 09/03/2019 02:55, Rodney Van Meter wrote:
>> Folks,
>>
>> We have a two-hour tutorial Monday 1610-1810.  Tracy Northup and I are
>> handling that.
>>
>> I’m behind in getting the agenda put together for the upcoming RG
>> meeting. The research group meeting will be 1120-1220 on Tuesday of IETF
>> week.  Agenda items?
>>
>> https://datatracker.ietf.org/meeting/104/agenda.html
>>
>> —Rod
>>
>>
>>
>> _______________________________________________
>> Qirg mailing list
>> mailto:[email-masked]
>> https://www.irtf.org/mailman/listinfo/qirg
>>
>> _______________________________________________
>> Qirg mailing list
>> [email-masked]
>> https://www.irtf.org/mailman/listinfo/qirg
>>
>
>
>
> ---------- Forwarded message ----------
> From: Rodney Van Meter <[email-masked]>
> To: Wojciech Kozlowski <[email-masked]>
> Cc: Rodney Van Meter <[email-masked]>, "[email-masked]" <[email-masked]>
> Bcc:
> Date: Fri, 15 Mar 2019 07:09:55 +0900
> Subject: Re: [Qirg] connection setup
>
> On Mar 14, 2019, at 6:10 PM, Wojciech Kozlowski <[email-masked]>
> wrote:
>
> Hi Rod,
>
> Very interesting draft. I have some questions/remarks:
>
>
>    1. I think I could benefit from a more specific use-case example. I am
>    struggling a bit to understand at what stage these connections are made. Is
>    this something that a network sets up ahead of time, or is this set up per
>    flow and must be maintained for its duration? I think this would also shed
>    light on how failures along the path should be handled.
>
>
> It could definitely use that.  Hopefully in the -01 draft.
>
> We are assuming this is triggered by an application request. One good work
> item for QIRG is to advance our understanding of use cases.  In the
> foreseeable future, connection setup/teardown won’t be as fast as a TCP
> handshake, and connections will likely live for hours or days or longer;
> QKD, for example, is more likely to be in support of gateway-to-gateway
> IPsec than for every TLS session to Gmail or Amazon. But we think this
> mechanism will work across that range of possibilities.
>
>
>    1.
>    At the moment I'm reading it as if it's set up per end-to-end
>    connection. What happens if a node fails during various stages of the
>    process?
>
>
> Yes, it’s E2E setup we’re looking at here.  Although the goal is
> internetworking, in which case the endpoint in a particular notion can be
> the gateway to the wider internet.
>
> At the moment, we have no fault tolerance built into this. Multipathing
> could be built on top of the rule-based repeaters; that’s something we’ve
> talked about but not yet pursued.
>
>
>    1.
>    2. The new craze in classical networking as far as I can tell is
>    segment routing. I don't know much about it, but my brief read on (
>    http://www.segment-routing.net/) suggests that this is a classical
>    mechanism that can be extended with QCaps. It even supposedly supports
>    network programming which is exactly what you want to do. Would be worth
>    investigating further.
>
>
> That’s a great topic of conversation. We haven’t attempted to compare it
> to segment routing. We actually developed the idea in the context of our
> Quantum Recursive Network Architecture (QRNA),
> https://arxiv.org/abs/1105.1238.
>
> Let’s talk about segment routing here and/or in Prague. Anybody on the
> list got an opinion on segment routing?  (I might regret asking this…)
>
> —Rod
>
>
>    1.
>
> Thanks,
>
> Wojtek
>
> On 13/03/2019 01:39, Rodney Van Meter wrote:
>
> We uploaded a draft on connection setup in a quantum network.  This
> represents how our quantum Internet simulator actually does things today,
> though the implementation isn’t yet truly complete.
>
> https://datatracker.ietf.org/doc/draft-van-meter-qirg-quantum-connection-setup/
>
> With the chair’s permission(???), would like to add this to the agenda for
> Prague.
>
> —Rod
>
> P.S. I don’t think any of the three new drafts that were uploaded have
> correctly shown up as QIRG-related.  Will see what I can do to fix.
>
>
> _______________________________________________
> Qirg mailing [email-masked]://www.irtf.org/mailman/listinfo/qirg
>
>
>
> _______________________________________________
> Qirg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/qirg
>