[Qirg] Re: New I-D: Timing Regimes in Quantum Networks and their Physical Underpinnings

Rod Van Meter <rdv@sfc.wide.ad.jp> Wed, 04 March 2026 04:38 UTC

Return-Path: <rdv@sfc.wide.ad.jp>
X-Original-To: qirg@mail2.ietf.org
Delivered-To: qirg@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 34F56C3E8068 for <qirg@mail2.ietf.org>; Tue, 3 Mar 2026 20:38:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=sfc.wide.ad.jp
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nqebjm78rdBb for <qirg@mail2.ietf.org>; Tue, 3 Mar 2026 20:38:18 -0800 (PST)
Received: from mail2.sfc.wide.ad.jp (mail2.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:149]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 46E4EC3E8054 for <qirg@irtf.org>; Tue, 3 Mar 2026 20:38:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sfc.wide.ad.jp; s=mail2; t=1772599088; bh=qwvE5YX1QXAkMOJe03xy/bXA7LxdansRvJPJBGk4HY8=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=zqz80AO7eHcrn09vxYPyz7mooYd4KKsTaewIBCbsyCLUrAg9rErpT7MDbIHv4yEmY zmzg5YxTnx4dLmhFHxfzYl391Yzy/rZzFd5XGptMYZI6QtX9ZbFc0/AUJdVe3aIlvH Ig9AM88gRVKeZgS/0YugAHIw/v3h2eX2b6H51AqnfNlT9C4r/o12SzgKU8FrC1+E8B nDujNt+tTcC8Rf3QbMVnYvSne8LaDIBiBon2FV5GnrcwgdIUS1pUxjZ900DjroiHjf 2RiKUV1DwIzcdtvjmursMNnsvZ6M/S89QZRADbXQgVXL0OJvdv7/mWW9TeA43OL6GF PmHdPsLFEA8oA==
Received: from [192.168.1.20] (p8632042-ipngnfx01marunouchi.tokyo.ocn.ne.jp [114.156.135.42]) (Authenticated sender: rdv@sfc.wide.ad.jp) by mail2.sfc.wide.ad.jp (Postfix) with ESMTPSA id 7551F802DC; Wed, 4 Mar 2026 13:38:08 +0900 (JST)
Content-Type: multipart/alternative; boundary="------------um0UPdJPWISltQHNFMsITrOA"
Message-ID: <7cb9c636-09c8-4dcd-bc57-473a89506be6@sfc.wide.ad.jp>
Date: Wed, 04 Mar 2026 13:38:07 +0900
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: amar oxmo <amaroxmo@gmail.com>, Michal Hajdušek <michal=40sfc.wide.ad.jp@dmarc.ietf.org>
References: <7002d633-c0fe-4b2c-b778-93c0ec0a07ae@sfc.wide.ad.jp> <2E4F55B6-953A-43DA-B71A-3274D9822128@gmail.com>
Content-Language: en-US
From: Rod Van Meter <rdv@sfc.wide.ad.jp>
In-Reply-To: <2E4F55B6-953A-43DA-B71A-3274D9822128@gmail.com>
Message-ID-Hash: DCIIXKARTXIRYEFL2WTJGOI53RXBICPT
X-Message-ID-Hash: DCIIXKARTXIRYEFL2WTJGOI53RXBICPT
X-MailFrom: rdv@sfc.wide.ad.jp
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-qirg.irtf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: qirg@irtf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [Qirg] Re: New I-D: Timing Regimes in Quantum Networks and their Physical Underpinnings
List-Id: Quantum Internet RG <qirg.irtf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/qirg/uh4TA9wIr4592Jp1QcFUp16BbwY>
List-Archive: <https://mailarchive.ietf.org/arch/browse/qirg>
List-Help: <mailto:qirg-request@irtf.org?subject=help>
List-Owner: <mailto:qirg-owner@irtf.org>
List-Post: <mailto:qirg@irtf.org>
List-Subscribe: <mailto:qirg-join@irtf.org>
List-Unsubscribe: <mailto:qirg-leave@irtf.org>

Thanks for the comments!  Replies inline.

On 2026/03/04 10:58, amar oxmo wrote:
> Hi Michal and Rod,
>
> Thank you for sharing the draft. I have a few comments that may help 
> strengthen its generality and architectural relevance. Since you plan 
> future improvements and other documents, these are just high-level 
> comments.
>
> - Several timing values are drawn from specific experiments or 
> implementations. While these examples are useful, presenting 
> technology-specific values (e.g., mechanical waveplate switching 
> times) may unintentionally suggest architectural constraints.

That's the point -- to show not specific numbers, but *how* the numbers 
in design decisions are to be made. Any specific numbers are for 
illustrative purposes only -- that can probably be emphasized more.


> Related to this. It’d strengthen the document if the presented 
> formulas were explicitly used to extract technology-independent upper 
> and/or lower bounds for timing regimes (this may be your plan already, 
> from the announcement email). This would give us 
> feasibility/acceptability ranges for designs rather than 
> experiment-specific numbers.

Rather than prescribing numbers, this is more about how to define them. 
There are probably very few numbers that would be appropriate to include 
here as anything other than examples. With interesting things happening 
with hollow core fiber, even the speed of light in fiber is not 
something we would consider constant. (And conversely the speed of light 
in vacuum, which is constant, there's really no need for us to write 
down in this document.)

>
> - The timing analysis currently focuses on HOM-based entanglement 
> generation and photonic Bell-state analyzers. It would enhance the 
> document’s generality to either (1) extend the timing taxonomy to 
> include photon-matter interface mechanisms (e.g., absorption-based 
> entanglement, atom-photon gates/projectors) and transduction, or (2) 
> explicitly scope the document to interference-based architectures.

Yes, since we are working with interference-based schemes it was easiest 
for us to start there, but those others should be included, as well.


>
> - The draft classifies routing as a background task, which seems 
> right. It would also help to explicitly classify forwarding and local 
> decision logic (e.g., local table/state lookup to decide which 
> entanglement to swap / which request to serve) as distinct from 
> routing; for at least one reason: unlike routing (in its most basic 
> model), forwarding decisions/operations affect qubit decoherence. This 
> likely belongs under Sec. 8 "Urgent but not synchronization-critical 
> tasks", potentially as a subcategory.

As with Diego's I-D, I don't like the term "forwarding", since what we 
are doing is really building distributed entangled states.

Much of what you're talking about, though, is design *decisions*. This 
I-D should not contain any decisions, it's more about how to write down 
and reason about the physics, bridging to engineering. There should be 
essentially nothing in this one where one group could decide one way and 
another group decides another.

>
> - I suggest considering the NIST Single-Photon Source and Detector 
> Dictionary 
> [https://nvlpubs.nist.gov/nistpubs/ir/2025/NIST.IR.8486r1.pdf] Beside 
> terminology, it provides a useful taxonomy of photon sources, 
> detectors, and associated processes (e.g., probabilistic vs. 
> deterministic single-photon sources, continuous-wave sources, etc.), 
> many of which relate directly to mechanisms discussed in the draft. I 
> think you may already be aware of it, and it could help anchor some of 
> the concepts and classifications used in the document.

We love that document, and if it's not cited yet that's an oversight on 
our part that will be corrected!

>
>
> I hope these comments are helpful. Happy to contribute if needed.

Indeed they are helpful. Thanks for the quick and useful feedback.

You should be able to create issues and even pull requests at
https://github.com/moonshot-nagayama-pj/draft-hajdusek-qirg-timing-physics

No automatic guarantee we'll agree with or accept every suggested edit, 
but we will definitely consider them all, and happy to have them! And 
while this mailing list is a visible way to discuss and share, 
Issues/PRs on GitHub are a great way to make sure specific suggestions 
don't get lost.

Shota Nagayama has already promised us some stuff, too.

We expect that this document will grow substantially in the text, as 
well as once we have the figures included.

--Rod

>
>
> Best,
> Amar
>
>
>
>> On Mar 2, 2026, at 9:29 PM, Michal Hajdušek 
>> <michal=40sfc.wide.ad.jp@dmarc.ietf.org> wrote:
>>
>> Dear QIRG members,
>>
>> It is with great pleasure that we would like to introduce our new 
>> Internet Draft called "Timing Regimes in Quantum Networks and their 
>> Physical Underpinnings". The I-D can be found here:
>> https://datatracker.ietf.org/doc/draft-hajdusek-qirg-timing-physics/ 
>> <https://datatracker.ietf.org/doc/draft-hajdusek-qirg-timing-physics/>
>>
>> This is not a typical I-D, both in terms of content and format so we 
>> would like to make a few disclaimers that will hopefully clarify any 
>> potential confusion.
>>
>> Goal:
>> This draft is intended to be a first in a sequence of drafts. Its 
>> purpose is to discuss relevant physical phenomena related to timing 
>> regimes in quantum networks. Therefore, there are quite a number of 
>> equations but there are no engineering decisions. Those will be 
>> presented in upcoming drafts that we are working on. The purpose of 
>> this draft is to serve as a bridge between the more abstract 
>> discussion of RFC9340 and concrete design choices of these planned 
>> drafts.
>>
>> Format:
>> Given that we have used more than a typical number of equations, the 
>> plain txt and pdf versions may be difficult to read in some places. 
>> We are working on making the mathematical expressions more 
>> reader-friendly. The HTML version is in our opinion the most readable 
>> at the moment.
>>
>> Future:
>> Current draft at
>> https://github.com/moonshot-nagayama-pj/draft-hajdusek-qirg-timing-physics 
>> <https://github.com/moonshot-nagayama-pj/draft-hajdusek-qirg-timing-physics>
>> does not contain any figures. However, a figure is worth a thousand 
>> equations, or something like that. Our plan is to include figures in 
>> the next version. If you would like to see the planned figures, you 
>> can visit an older version that the current draft builds on:
>> https://github.com/moonshot-nagayama-pj/public-documents/tree/main/timing-regimes 
>> <https://github.com/moonshot-nagayama-pj/public-documents/tree/main/timing-regimes>
>> We also intend to expand the discussion on how to read the equations 
>> and how to turn them into physical-layer specifications, protocol 
>> messages, timing constraints and code.
>>
>> What we would like:
>> Your frank opinions. This draft is an ambitious undertaking, and we 
>> are certain there are topics that are either underdeveloped, 
>> misleading or outright missing. We would also like your help in 
>> making the text accessible to IETF/IRTF audience. We are also happy 
>> to expand the author list if people make contributions to the draft.
>>
>> We look forward to hearing your opinions, either via the mailing list 
>> or in Shenzhen.
>>
>> Best regards,
>> Michal and Rod
>>
>>
>> _______________________________________________
>> Qirg mailing list -- qirg@irtf.org
>> To unsubscribe send an email to qirg-leave@irtf.org
>