Re: [Qirg] draft-dahlberg-ll-quantum-01 review comments

[Axel Dahlberg <[e-mail]>]

Hello Bruno!


Your feedback is very useful and highly appreciated! I agree with your main comment that we should be more clear that the draft concerns a vertical service (SDU). Is a "vertical service" a generally excepted notion?

Specific protocol comments
(P1) As already mentioned in comments on the open mike after your QIRG presentation, there is no need to invent a new "Node ID". You can use IPv6 addresses to identify quantum nodes in the quantum network. That will make it easier to re-use (modified) existing protocols in other parts of the quantum networking stack (e.g. existing routing protocols such as OSPF or ISIS to discover the topology of the quantum nodes and links, existing signaling protocols such as RSVP to setup end-to-end "paths", etc.)

I agree with this, at least I cannot see any issues with it.

(P2) That said, in this case the "Remote Node ID" is actually a datalink identifier, not a network identifier (this too was already mentioned at the mike after the presentation). Since all quantum links are point-to-point (there are no multi-point quantum links, right?) you don't really need datalink layer node ids. All you need in the CREATE message is some local identifier for the local interface. The remote node on the datalink is implied by the local interface. This might seem like semantic hair-splitting, but it is an important distinction because a local link identifier is a purely local matter (e.g. an interface name). But when you start introducing datalink layer node IDs (the moral equivalent of Ethernet addresses, or in this case perhaps LAPD DLCIs) you immediately open up a whole can of worms related to addressing (format, allocation, scope of uniqueness, address discovery). None of those complications are needed because all links are point-to-point and there is always only one "remote node" on a datalink. Thus, it is best to simply avoid those complications by not having any addresses at the datalink layer, and just stick with locally significant interface identifiers (names).

There can in fact be cases where there are more than two nodes (I think this is what you call multi-point). For example there can be multiple nodes connected to a single heralding station (automated repeater) to which the nodes can send photons. Note that in this case each node only has a single fiber to the midpoint but can generate entanglement with any of the other nodes that are also connected to the midpoint.

As also mentioned in the talk, we also planned to use IDs for nodes together with the "sequence number" to construct "entanglement IDs". However, in principle the link layer does not need to perform this construction but only provide the "sequence number".

(P3) You should define the transport mechanism for the proposed protocol. If you need messages to be reliable and ordered, TCP or TLS is the obvious choice. If not, UDP will do. I strongly recommend the former. We have to define what happens when the TCP connection is lost (flush? graceful restart? etc.) We have to think about all the usual session establishment issues (authentication, versioning, capability negotiation, etc. etc.


You mean the protocol in the paper? I.e. the horizontal protocol. For the communication between the nodes and the midpoint within the link layer protocol our current plan idea was to use Ethernet rather than TCP or UDP. However, this is a good point for discussion, if this is actually a good way to go or if using UDP could prevent us from implementing certain things that have already been done before.


(P4) For future extensibility, I strongly recommend using Type-Length-Value (TLV) messages. You might want to consider defining the protocol using a formal data modeling language such as Thrift, instead of drawing the traditional ASCII diagrams. For example, see the definition of the RIFT protocol (https://datatracker.ietf.org/doc/draft-ietf-rift-rift/)

This sounds like a good idea. I will look into Thrift.

(P5) The purpose of the "Purpose ID" (no pun intended) is not very clear. The main use seems to be identifying a network layer path. It would probably be better to keep a clean separation of layers, to keep any knowledge of path ID out of the datalink layer, and to introduce a separate path ID concept in the network layer.

Apart from specifying a path, the purpose ID can also identify applications where the entanglement belongs to. This enables a mechanism for rejection of entanglement requests made by remote peers.

(P6) In general you are very stingy with the number of bits in identifiers. Only 16 bits for number of pairs? Only 16 bits for create ID? Only 4 bits for logical qubit id? There is no harm in being more future proof by allocating (much) bigger identifiers, even if the prospects of the hardware supporting much larger numbers are very distant. How much trouble would we have saved ourselves if IPv4 addresses were much bigger than 32 bits right from the get-go?

Yes, it might be a good idea to extend these so also satisfy future needs.

(P7) The current mechanism for allocating Create IDs on the server side (datalink service provider side) does not allow for pipelining of requests, unless we assume all requests are serviced in order. For example, consider a network layer client that sends two CREATE requests without waiting for any ACK. When it eventually receives an ACK, it won't know whether it was the ACK for the first or the second request. Thus, we need (or also need) client-allocated IDs for the purpose of correlating messages. If the ID is allocated by the client, it will only be unique within the scope of the client (note that a multiple clients may be co-located on the same physical node.)

We assumed that the return of the ACK is very fast. However if this would be a bottleneck one could also tag the messages with some communication ID/sequence number such that the higher layer can relate the ACK with the CREATE.

(P8) Looking at the Directionality flag, it appears that there are some scenarios would a local node ever receive a datalink service response to a datalink service request that was initiated by the remote node? Similarly, it appears that there scenarios where the network layer "spontaneously" sends a message to the higher layer to inform it that something happened (e.g. ERR_EXPIRE to report that decoherence occurred). I would recommend using something more formal along the following lines:

This is correct, both nodes will receive the OK, even the node which did not send the CREATE. This is needed such higher layers at both nodes have a way of relating the generated entanglement to a qubit ID.

 * Entangled-Pairs-Create-Request (request-id)
 * Entangled-Pairs-Create-Confirm (request-id, pair-id) => success or error code, possibly multiple responses if more than 1 pair requested
 * Entangled-Pairs-Create-Indication (link-id, pair-id) => report that a pair was created here as a result of a request by the remote id. Maybe this should be an -Indication and -Response if you want the network layer to have the opportunity to accept or refuse the pair.
 * Entangled-Pairs-Change-Indication (create-id, pair-id) => spontaneously report something happened (e.g. decoherence) Or maybe, this could be a -Destroy-Indication.

What is the difference between Confirm and Indication here? Is Confirm for the node that sent the CREATE and Indication for the other node?

(P9) I would recommend having a consistent header for all messages in both directions (as opposed to the current approach of only having a header for datalink to network layer messages).

I’m not sure I understand what is inconsistent. There are headers for both CREATE (higher -> link) and OK, ACK, ERR (link -> higher).

(P10) Reading the text for Sequence Number, it seems that a single CREATE (CREATE-Request) message can result in multiple ACK (CREATE-Confirm) messages, if the CREATE had Number > 1. Is that correct? Would each generated pair have its own sequence number?

Yes, each generated pair will have it’s own OK and it’s own sequence number such that all generated pairs can have a unique entanglement ID in the end.

(P11) You probably also need a message to CANCEL a pending request (and maybe also messages to QUERY and MODIFY pending requests): Entangled-Pairs-Cancel-Request, etc.

We had this up for discussion at some point. It’s not completely clear to me if it’s needed. We have the “max time” but of course the higher layer can learn something in the mean time such that the generation is no longer needed.

Nitpicks
(N1) Section 1: "and send the measurement outcome (2 bits) over a classical channel to A or C". Should this be "... to A and C"?

No, this should be ‘or’. The measurement outcome only needs to be sent to one of them, which can perform a local correction depending on the result.

(N2) "Max Time" is defined as a float. Floats are generally not used in protocols. It might be more expedient to define it as an integer in usec or msec.
(N3) For unused bits, say "set to 0 on transmit, ignore on receive".
(N4) Create ID -> Entangled Pairs Generation Request ID.  (Note the s for plural pairs)

I agree.

(N5) Sequence number -> Entangle Pair ID.  (Note the absence of s, singular?)

We didn’t want to call this the entangle pair ID, since we call (Node_ID_A, Node_ID_B, SEQ_NUM) the entanglement ID. We could maybe call it “generation sequence number” or “generation ID” or similar.

Again, thanks a lot for your feedback. I will try to incorporate your comments in the coming time.

/Axel Dahlberg