[Detnet] updating the flow information model draft

[János Farkas <[e-mail]>]

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