Re: [Detnet] Packet Ordering Function (draft-varga-detnet-pof-00.txt)

[Ludovic Thomas <[e-mail]>]

Hi all, I have two thoughts on it:

=======

1/ what are you thoughts in changing:

"""" [Current version]
The next received packet must be forwarded and the POFLastSent
       updated wheno the POF function was reset OR no packet was received
       for a predefined time ("POFTakeAnyTime").
""""

for

""" [Proposed version]
The next received packet must be forwarded and the POFLastSent
       updated wheno the POF function was reset OR no packet_with a seq_num strictly higher (>) than POFLastSent_  was received
       for a predefined time ("POFTakeAnyTime").
"""
?

Consider the following use-case:

Source has been up for a while, at POF point we received and sent thousand packets such that POFLastSent = 1000
Suddenly the source reboots and the reboot is so fast that the time elapsed between:
		- when packet noted 1000 was sent prior to reboot
		- when packet noted 0 is sent after reboot
is less or equal to the inter-packet spacing. (meaning the time elapsed between 1000 and 0 is about the same or even less than between 999 and 1000).
As such, in any coherent design the time elapsed between 1000 and 0 is less than POFTakeAnyTime.

Now assume POF function receives 1000, 0, 3, 1, [a sequence of out-of order packets], 100, 102, 101, 104, 103 ... again with a spacing between 1000 and 0 that is less than POFTakeAnyTime.

* With the current version, after reception of 1000, timer is started, but reset as soon as 0 is received.
At the end of the day each receiving packet resets the timer before it fires, so POFLastSent stays at 1000 and all packets are forwarded without being reordered until the sequence number reaches 1000 again.

* With the proposed version, neither 0 nor 3, 1, etc resets the timer because their sequence number is <= POFLastSent.
After some time (say just BEFORE packet 100) the timer is fired, POFLastSent is set to 100 and starting from there is the output of POF is back in order.

======

2/ also, the draft states

o  If (seq_num <= POFLastSent + 1)

       *  Then the packet is forwarded and "POFLastSent" is updated
          (POFLastSent = seq_num).

I believe we shouldn't update POFLastSent if the seq_num is <= POFLastSent. In the above example, assume the POFTakeAnyTime is fired just AFTER packet 100. Packet 102 is received, is sent and sets POFLastSent=102.
With the current version, 101 is received, is sent (because seq_num <= POFLastSent + 1) and sets POFLastSent=101, from there the system is stuck because 102 will never be received again, and the following packets will be released after the POFMaxDelay expires.
With the proposed version (no update of POFLastSent if the seq_num is <= POFLastSent), then 101 does not set POFLastSent=101 and the system continues normal operation.

======

My two cents,
Ludovic