Re: [Detnet] Martin Duke's Discuss on draft-ietf-detnet-pof-08: (with DISCUSS and COMMENT)

[Martin Duke <[e-mail]>]

HI Balazs,

Replies inline.

On Wed, Jan 3, 2024 at 6:57 AM Balázs Varga A <[e-mail]>
wrote:

> Hi Martin,
>
> Thanks for your review. Please find clarifications below:
>
> 1. Sequencing of PRF, PEF, and POF functions.
> <Reply> Implementation of PRF and PEF are not defied in details in IETF. A
> possible implementation
> of an Elimination (PEF) functionality is described in the IEEE
> 802.1CB-2017 standard. PEF has its own
> internal states and various elimination algorithms (e.g., vector recovery,
> match recovery) can be
> used. If PRF and PEF are not designed and configured correctly, then PEF
> may result in duplicate
> packet delivery (e.g., match recovery is used for bulk flows).
> In section 4.1 the intention was to highlight, that POF cannot repair such
> scenarios.
>
> POF is usually the last thing before egress, but not always. It may be
> located within the DetNet
> network if PREOF is designed so.
>

[MD] Fair enough. Perhaps you could make this change:
OLD
Error cases in which the POF is presented duplicate packets can lead to out
of
order delivery of duplicate packets as well as to increased delays.

NEW
Error cases in which the PRF or PEF implementation errors present duplicate
packets to the POF can lead to out of
order delivery of duplicate packets as well as to increased delays.


>
> 2. Requirements for ordering vs loss
> <Reply> These POF algorithms are designed for DetNet networks as part of
> the DetNet service sub-layer
> (PREOF) functionalities. POF never drops any packet. Only the PEF has the
> task to drop duplicates.
> The only task for POF is to correct the order of packets (if it is
> possible with its configuration).
> Just again, if PRF and PEF are not designed and configured correctly, then
> POF may not re-order
> the packets in some scenarios. If POF parameters are not designed and
> configured correctly,
> it may not re-order the packets.


[MD] I'm not going to hold indefinitely on this point, because it's not my
design or use case.  If you and the AD *really* think this is how it should
work, I'll relent.

But ISTM that by forwarding out of order packets you are undermining the
POF function in the service of avoiding packet loss, which is not the POF's
job.

Forwarding a packet below pof_last_sent is by definition out of order. I
would think a POF would focus on guaranteeing order delivery, and rely on
the reliabilty
functions to provide reliability.


> 3. Strange assumptions in the advanced algorithm.
> 3a. Is there an assumption that there is no PRF beyond the POF?
> <Reply> There is no such an assumption. It is design specific and depends
> on the topology, flow
> parameters, etc., how the PREOF functions are located in the network. A
> POF function (and its
> parameters) has to be designed based on the delay budget upto the point of
> the POF function.
> If there are further PRF/PEF stages behind the POF, then You may need a
> further POF function
> after them.
>

[MD] If a POF is not accounting for downstream delay, it would appear that
limiting the timeout isn't actually ensuring that traffic falls within the
delay guarantees.


> 3b. The introduction suggests that out-of-order delivery is a result of
> the PRF
> rather than some sort of link-layer pathology.
> <Reply> The out-of-order delivery is a result of PEF (and not the PRF).
>
> 3b. ... So it's sufficient for the timeout to be the limited by the
> remaining time budget for the longest path.
> <Reply> No. The "remaining time budget for the longest path" shows the
> latest delivery time of
> a packet that can fulfil the bounded latency requirement of the flow. The
> necessary buffering
> time is determined by the latency difference of the paths. You have to be
> prepared for the worst
> case scenario: packet "n" received over the shortest path and packet "n-1"
> received over the
> longest path. Packet "n" has to be buffered until packet "n-1" arrives
> (i.e., for the latency
> difference of the paths). The advanced POF algorithm is used if the
> remaining delay budget of a
> flow at the POF point is smaller than the latency difference of the paths.
> (Therefore, buffering for
> "remaining time budget for the longest path" can not re-order packet "n"
> and "n-1".)


[MD] Yes, thank you for pointing out my analytical error. I withdraw point
(3b).


> 4. Is there some reason that "Consensus Boilerplate" is set to NO on the
> datatracker page? Informational RFCs have IETF consensus!
> <Reply> I think this may be an error on the page.
>

[MD] Ok, this is easy to fix.


>
> I hope these have clarified your concerns.
>
> Thanks & Cheers
> Bala'zs
>
> -----Original Message-----
> From: Martin Duke via Datatracker <[e-mail]>
> Sent: Tuesday, January 2, 2024 10:49 PM
> To: The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail]
> Subject: Martin Duke's Discuss on draft-ietf-detnet-pof-08: (with DISCUSS
> and COMMENT)
>
> Martin Duke has entered the following ballot position for
> draft-ietf-detnet-pof-08: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-detnet-pof/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> There are several elements here that are either poorly phrased or
> misconceived
> in some way.
>
> 1. Sequencing of PRF, PEF, and POF functions.
>
> Section 4.1 says "However, the PREOF functions run independently without
> any
> state exchange required between the PEF and the POF or the PRF and the POF.
> Error cases in which the POF is presented duplicate packets can lead to
> out of
> order delivery of duplicate packets as well as to increased delays."
>
> but then Section 4.6 says "In DetNet scenarios there is always an
> Elimination
> function before the POF (therefore duplicates are not considered by the
> POF)."
>
> I can't reconcile these statements. How can there be a duplicate packet
> error
> case if the PEF is always before the POF?
>
> A statement that the POF is always the last thing before egress would
> clean up
> some logical holes, like in (3a) below.
>
> 2. Requirements for ordering vs loss
>
> What is the purpose of Sec 4.3 directly forwarding packets with (sequence
> number < POF Last Sent + 1)? There's an implicit requirement that
> delivering
> the packet in order is less important that not dropping it, but is a
> strange
> requirement for a *Packet Ordering Function*. If Detnet is to be decomposed
> into three functions, it is very difficult reason about if the POF
> guarantees
> ordering, but sometimes it ignores that if it's trying to avoid losses.
> Just do
> PRF/PEF if you want to avoid losses!
>
> So I would suggest that the POF forward (sequence number == POF Last Sent
> + 1)
> and drop anything earlier.
>
> 3. Strange assumptions in the advanced algorithm.
>
> 3a. Is there an assumption that there is no PRF beyond the POF? If there
> is,
> it's possible that there are different path delays beyond the POF, and
> that has
> to be accounted for in the algorithm. My guess is that you are assuming
> that,
> given Figure 1. In that case it should be stated explicitly (See point #1).
>
> 3b. The introduction suggests that out-of-order delivery is a result of
> the PRF
> rather than some sort of link-layer pathology. If so, I don't see why it's
> necessary for the POF timeout to be path-dependent. That is, the
> shorter-path
> packets will by definition be in-order[1], and the longer path will be
> out-of-order. So it's sufficient for the timeout to be the limited by the
> remaining time budget for the longest path.
>
> [1] Unless there's a loss on that path. But in that case, there is no
> advantage
> to a longer delay, so my proposed algorithm holds.
>
> Maybe I'm getting the underlying assumptions wrong?
>
> 4. Is there some reason that "Consensus Boilerplate" is set to NO on the
> datatracker page? Informational RFCs have IETF consensus!
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Thanks to Kyle Rose for the TSVART review.
>
>
>