Re: [Detnet] updating the flow information model draft

[Rodney Cummings <[e-mail]>]

Hi Janos,

I don't necessarily agree with the proposals to add in-order delivery and/or probability-of-packet-loss to the DetNet information model(s).

We need to keep the user in mind. The user-side of the information model must provide parameters that:
1. Are known by a user without any knowledge of the network details.
2. Can be practically provided by the network independent of the application/user data protocol.

Item 2 means that we cannot assume a specific protocol on top of IP and/or layer-2 packets. Maybe it is UDP. Maybe it is TCP. Maybe it is layer-2 (e.g. IEEE Std 1722). We all know that TCP has a lower probability-of-packet-loss than UDP, but that is not relevant to the DetNet information model.

In that context, if the information model provides a probability-of-packet-loss parameter, how do we propose that the user will compute that number? I would argue that the user does not have sufficient knowledge to do this. What's more... how would the network compute the number that is delivered by the network? For example, if Ethernet cabling is installed in a noisy environment, probability-of-packet-loss is probably higher, but I don't see how a central controller would be aware of it.

To be practical, we need to provide parameters that are associated with things the user actually knows. For example, the user knows whether he/she can deployed IEEE Std 802.1CB technology in switches/routers, and the user know how many redundant paths have been deployed. Therefore, if we have a flow parameter like number-of-redundant-paths, that is something that the user can understand, and it is something that the network can check for and configure.

As for in-order delivery, I haven't seen a proposal for how that would be delivered by the network. If/until we have such a proposal, adding it now would do nothing but provide a false promise. I would argue that we should wait until a standard for in-order delivery exists, and then provide this parameter.

Rodney

> -----Original Message-----
> From: detnet <[e-mail]> On Behalf Of qiangli (D)
> Sent: Thursday, July 12, 2018 1:40 AM
> To: János Farkas <[e-mail]>; DetNet WG <[e-mail]>
> Subject: Re: [Detnet] updating the flow information model draft
> 
> Hi Janos,
> 
> I agree with you that the information model draft needs to add some "in
> order delivery" related content. And I personally prefer your first
> suggestion, using the number of misordered packets to express the
> misodering.
> 
> Besides, I have two other questions:
> 
> --what is the relationship between "section 5.2 service parameters" and
> "section 10.3 user to network requirements", aren't they both on the
> interface between user and network? One interface two usages, depend on
> which direction you look at it. From network to user is service, in the
> opposite direction is requirement, but either way, they will have the same
> parameters.
> 
> -- Do we need to expand information model draft for jitter? I couldn't
> find the description of jitter in the current version. However according
> to the PS draft, jitter is one of the important features of detnet flow,
> see below:
> 
> "....along the multi-hop path with such characteristics as low latency and
> ultra-low jitter, reordering and/or replication and elimination of
> packets.....",
> as well as "Need absolute guarantees of minimum and maximum latency end-
> to-end across the network; sometimes a tight jitter is required as well;"
> 
> 
> Best regards,
> 
> Cristina QIANG
> 
> -----Original Message-----
> From: detnet [mailto:[e-mail]] On Behalf Of János Farkas
> Sent: Thursday, July 05, 2018 2:12 AM
> To: DetNet WG <[e-mail]>
> Subject: [Detnet] updating the flow information model draft
> 
> Dear all,
> 
> I think the flow information model draft needs some updates to bring it
> in-line with the recent developments in the WG. I’d like to have WG
> discussion on the list and at IETF 102 before making any updates.
> 
> 1, Current version of draft-ietf-detnet-flow-information-model-01
> 
> Section 5.2 Service Parameters includes in order delivery, which is a
> binary value in draft-ietf-detnet-flow-information-model-01 depending on
> whether or not in order delivery is required for the given service. This
> requires refinements based on the developments we had in draft-ietf-
> detnet-architecture-06.
> 
> The refinement would involve introducing a numerical service parameter,
> which could be called “MisorderingTolerance” or alike to replace the
> current binary parameter.
> 
> 
> 2, Recent updates of draft-ietf-detnet-architecture-06
> 
> draft-ietf-detnet-architecture-06 provides a finer grade DetNet QoS
> parameter by introducing :
> 
> Section 3.1:
> “o An upper bound on out-of-order packet delivery. It is worth noting that
> some DetNet applications are unable to tolerate any out-of-order
> delivery.”
> 
> Section 3.2.2.1. In-Order Delivery:
> “Out-of-order packet delivery can be a side effect of service protection.
> Packets delivered out-of-order impact the amount of buffering needed at
> the destination to properly process the received data. Such packets also
> influence the jitter of a flow. The DetNet service includes maximum
> allowed misordering as a constraint. Zero misordering would be a valid
> service constraint to reflect that the end system(s) of the flow cannot
> tolerate any out-of-order delivery.
> Service protection may provide a mechanism to support in-order delivery.”
> 
> The architecture document does not provide further details on purpose.
> It is the job of the flow information model draft to go into the details.
> 
> 
> 3, “MisorderingTolerance” related thoughts
> 
> The DetNet QoS requirements are correlated to each other. For instance, a
> packet received with a too big delay or jitter is practically a lost
> packet for the application. As for misordering, it is related, e.g., to
> jitter as explained in the architecture document. (Well, misordering above
> the tolerable limit can be considered loss.) The correlations can be taken
> into account when defining the QoS requirements for a DetNet service, and
> also when providing the given DetNet service by the DetNet network.
> 
> Actually, misordering and jitter can be decreased with a similar tool,
> e.g., a playout buffer. It is a bit more complex for reordering and
> requires sequencing information carried in the packets.
> 
> I see two approaches to express maximum allowed misordering:
> a) number of misordered packets
> b) time
> 
> Both of them have their pros and cons.
> 
> I propose to follow a) for multiple reasons.
> 
> Maximum allowed/tolerable misordering could be defined along:
> “maximum number of misordered packets, e.g., a delta of sequence numbers
> between the highest sequence number that was just received and the lowest
> sequence that is acceptable”
> (credit goes to Pascal for initial wording!)
> 
> This is a relatively simple definition and also simple to measure, detect,
> and verify. Furthermore, timing requirement is already defined as part of
> the jitter requirement, no need to duplicate. In addition, timing may not
> be as important as the order of packets for some applications.
> 
> What do you think?
> 
> Regards,
> Janos
> 
> _______________________________________________
> detnet mailing list
> [e-mail]
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_detnet&d=DwIGaQ&c=I_0YwoKy7z5LMTVdyO6YCi
> E2uzI1jjZZuIPelcSjixA&r=WA71sf2o7Dw7CbYhFt24DPjt3lJuupswWYdnboKbZ8k&m=LfnP
> f6Uf2mcshZCd4Hhh86TbHNNdk94xnvtrMY80gXk&s=tsOfM8UGcBXWlUPiGg7XegkpgP5foZGt
> ulwtpGszb_g&e=
> _______________________________________________
> detnet mailing list
> [e-mail]
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_detnet&d=DwIGaQ&c=I_0YwoKy7z5LMTVdyO6YCi
> E2uzI1jjZZuIPelcSjixA&r=WA71sf2o7Dw7CbYhFt24DPjt3lJuupswWYdnboKbZ8k&m=LfnP
> f6Uf2mcshZCd4Hhh86TbHNNdk94xnvtrMY80gXk&s=tsOfM8UGcBXWlUPiGg7XegkpgP5foZGt
> ulwtpGszb_g&e=