Deterministic Networking Architecture
Note: This ballot was opened for revision 10 and is now closed.
Deborah Brungard Yes
Ignas Bagdonas No Objection
(Ben Campbell) No Objection
Comment (2019-02-20 for -11)
I support Benjamin's and Alissa's DISCUSS positions. I also agree with the several people who commented that this should be informational. Otherwise, I have some minor comments: §220.127.116.11, - first paragraph: Please expand "GigE" - "In general, users are encouraged to use, instead of, "do this when you get the packet," a combination of:" - Hard to parse. §18.104.22.168: Please expand "PREOF" on first use. I realize readers can probably construct it from the previous few sentences, but it's more reader-friendly not to require them to do so. §3.3.2: "Robust real-time systems require to reduce the number of possible failures." - The sentence does not parse. Are there missing words prior to "to"? §4.1.2: - "Distinguishing the function of two DetNet data plane sub-layers, the DetNet service sub-layer and the DetNet forwarding sub-layer, helps to explore and evaluate various combinations of the data plane solutions available, some are illustrated in Figure 4." Hard to parse. Also, there is a comma splice. - "There are many valid options to create a data plane solution for DetNet traffic by selecting a technology approach for the DetNet service sub-layer and also selecting a technology approach for the DetNet forwarding sub-layer. There are a high number of valid combinations." Does this refer to implementation/deployment options, or protocol design options? If the latter, are the choices still open? §4.1.3: Please define or expand DetNet-UNI. §4.2.1, first paragraph: Does L1 stand for Layer-1, etc? If so, please spell it out.
Alissa Cooper (was Discuss) No Objection
Thanks for addressing my DISCUSS point. Old COMMENT left here: I support Benjamin's DISCUSS. I agree with others that this document should be informational. = Section 3.1 = "There are, of course, simpler methods available (and employed, today) to achieve levels of latency and packet loss that are satisfactory for many applications." I think this paragraph would make more sense if it said "specific levels of latency and packet loss for particular applications." A lot of applications have satisfactory performance without any of the methods/techniques described. "Prioritization and over-provisioning is one such technique." It seems these are two techniques, not one. = Section 22.214.171.124 = s/sensitive/time-sensitive/ I can't parse this sentence: 'In general, users are encouraged to use, instead of, "do this when you get the packet," a combination of: o Sub-microsecond time synchronization among all source and destination end systems, and o Time-of-execution fields in the application packets.' = Section 126.96.36.199 = s/ Either of these functions/ Any of these functions/ "Providing sequencing information to the packets of a DetNet compound flow. This may be done by adding a sequence number or time stamp as part of DetNet, or may be inherent in the packet, e.g., in a higher layer protocol, or associated to other physical properties such as the precise time (and radio channel) of reception of the packet." How do multiple connected DetNet nodes know which fields they are supposed to use as the packet sequence number? = Section 3.3.1 = "the highest-priority non-DetNet packet is also ensured a worst-case latency." --> Did you mean "ensured less than or equal to a worst-case latency"? = Section 4.3.2 = If applications need to be altered to be run over DetNet, or if they need to be DetNet-aware, it would be useful to state that explicitly up front somewhere in this document. This is sort of implied in this section but it's not clear. = Section 6 = "However, the requirement for every (or almost every) node along the path of a DetNet flow to identify DetNet flows may present an additional attack surface for privacy, should the DetNet paradigm be found useful in broader environments." I'm not sure what is meant by "broader environments." Is the implication that flow identification doesn't present a privacy risk within a single administrative domain? I don't think that is always true.
(Spencer Dawkins) No Objection
Benjamin Kaduk (was Discuss) No Objection
Comment (2019-03-25 for -12)
Thank you for addressing my Discuss point! The new security considerations section is well-written and quite well matched to an architecture document.
Suresh Krishnan No Objection
Comment (2019-02-21 for -11)
* Section 188.8.131.52. Given that we also know some of the downsides as well of large buffers, I think a pointer to some background might be warranted here. I would recommend a basic reference to something like Bufferbloat: Dark Buffers in the Internet, Communications of the ACM, January 2012, * Section 184.108.40.206. It is not obvious to me how the POF cannot be the last operation at the receiver. Can you clarify? Also, do intermediate nodes apply the POF? I can see the need for them to do PRF and PEFs but I am not sure applying the POF at intermediate nodes can necessarily help the low latency and low jitter goals. The order in which a DetNet node applies PEF, POF, and PRF to a DetNet flow is implementation specific. * Section 3.2.3. RFC7426 does not contain much specific information about explicit route setup. Is there a particular section you want to point to. If not, I don't think this reference is of much use. RFC8453 is listed twice. * Section 3.3.1. Not sure why this is a requirement but I do wish to note that there are no such worst-case latency guarantees for best effort traffic (aka non-Detnet) in current networks. Can you clarify? o DetNet flows can be shaped or scheduled, in order to ensure that the highest-priority non-DetNet packet is also ensured a worst- case latency. * Section 4.1.1. This text "Peers with Duplicate elimination." seems to be completely out of place under the "Packet sequencing" heading below Figure 2. Copy and paste error? * Section 4.3.2. I found the expression "number of bit times" confusing. I have understood "bit time" to mean the amount of time taken to emit a bit from a network interface. Based on that definition, this expression does not make sense. Is there a better reference/definition of what you mean? * Section 4.5. There might be some other recent IETF defined mechanisms that might be relevant to mention here as well. e.g. RFC8289 (Codel), RFC8033 (PIE) etc. * Section 4.7.2. While IPv6 does offer a mechanism to add/remove a flow id (flow label) not sure what kind of mapping you were thinking for IPv4. If this is not possible, I think a note to that effect might be useful here. * Sections 5 and 6 I also support Alissa and Benjamin's DISCUSSes (on privacy and security) and would like to see them addressed.
Warren Kumari No Objection
Comment (2019-02-20 for -11)
Thank you, this is a very well written, and easy to follow. I do have some minor comments and nits. 1: 220.127.116.11. Jitter Reduction "A core objective of DetNet is to enable the convergence of sensitive non-IP networks onto a common network infrastructure." You *do* say this in the introduction, etc, but this sentence is the clearest description - consider moving it up to the top. 2: 3.2.2. Service Protection "Service protection aims to mitigate or eliminate packet loss due to equipment failures, random media and/or memory faults." This talks about memory faults, but what about (the common case) of memory corruption? AFAICT, the protocol itself doesn't do anything about this - perhaps it should mention this, and say that strong checksums / integrity is the responsibility of the upper layer protocol? "Extraordinary claims require extraordinary evidence"- Carl Sagan. 3: "The DetNet service sub-layer includes the packet replication (PRF), the packet elimination (PEF), and the packet ordering functionality (POF) for use in DetNet edge, relay node, and end system packet processing. Either of these functions can be enabled in a DetNet edge node, relay node or end system." This says "either" about three things. 4: "3.3.2. Fault Mitigation Robust real-time systems require to reduce the number of possible failures." Apologies, I don't have suggested test to fix this, but "require to reduce" reads oddly -- perhaps "require a reduction in"?
Mirja Kühlewind (was Discuss) No Objection
Comment (2019-04-15 for -12)
Thanks for addressing my discuss. One more minor comment: I see the reference to bufferbloat in section 18.104.22.168, however, I guess the reference would actually be even more need in section 3.3.2. I agree with Alexey and Benjamin that this document should be informational. Informational documents can also have IETF consensus, so that cannot be the reason to go for PS. However, this document does not specify a protocol or any requirements that are mandatory to implement for interoperability and therefore should not be PS.
Alexey Melnikov No Objection
Comment (2019-02-19 for -11)
Why is this document is not IETF Consensus Informational?
Alvaro Retana (was Discuss) No Objection
Comment (2019-03-25 for -12)
[Thank you for addressing my DISCUSS.]