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

[Axel Dahlberg <[e-mail]>]

Hello Bruno!


Thanks a lot for your feedback! I will respond to the content next week.


/Axel Dahlberg

________________________________
From: Qirg <[e-mail]> on behalf of Bruno Rijsman <[e-mail]>
Sent: 29 March 2019 15:37:08
To: [e-mail]
Subject: [Qirg] draft-dahlberg-ll-quantum-01 review comments

Dear authors of draft-dahlberg-ll-quantum-01,
I reviewed your draft-dahlberg-ll-quantum-01 (https://tools.ietf.org/html/draft-dahlberg-ll-quantum-01).
I also attended your presentation of the draft in the QIRG research group meeting at the IETF-104, and I am in the process of reading your (truly excellent) recently published paper "A Link Layer Protocol for Quantum Networks" (https://arxiv.org/pdf/1903.09778.pdf).
Here are some comments on your draft from the perspective of a traditional network protocol designer:
Main comment
(M1) As was evident from the questions after the presentation of the draft at the QIRG research group meeting at the IETF-104 in Prague, classical network engineers are somewhat confused by this draft. See, for example, this question and answer recorded on YouTube: https://youtu.be/usU9j8lU2zk?t=1999. The confusion is mainly caused by that fact that the draft is in fact a datalink service definition and not a datalink protocol definition. It defines the service that the quantum datalink entity offers to the quantum network entity on the same (logical) node. The draft is quite clear about this, and uses the correct "service" terminology in the appropriate places. It defines the service using formal messages, which is somewhat unusual but not unprecedented (c.f. OpenFlow, ForCES, NETLINK, etc.) However, when an IETF engineer sees a message ASCII diagram such as Figure 1 in your draft, most IETF engineers will "instinctively" assume that it is a Protocol Data Unit (PDU). It is not; the diagram shows a Service Data Unit (SDU), or if you insist, a PDU for a service-access protocol. This is the root of the confusion. Although the draft is (as I mentioned) already using the correct service terminology, you might want to be even more explicit about the fact that you are defining a vertical service (SDUs) and not a horizontal protocol (PDUs). For those of you (maybe quantum physicists) who want more detail on the difference between a service and a protocol and the history behind it, I provided more details at http://bit.ly/osi-service-vs-protocol.
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.)
(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).
(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.
(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/)
(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.
(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?
(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.)
(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:
 * 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.
(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).
(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?
(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.
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"?
(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)
(N5) Sequence number -> Entangle Pair ID.  (Note the absence of s, singular?)