Re: [RTG-DIR] Review of draft-ietf-detnet-pof-04 for the RTGDIR

[Daniam Henriques <[e-mail]>]

Hi Henning

Thanks for this, are you able to add this review in Datatracker?

Thanks,
Daniam


Internal All Employees

________________________________
From: Henning Rogge <[e-mail]>
Sent: 23 October 2023 10:03
To: [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>; Daniam Henriques <[e-mail]>
Subject: Review of draft-ietf-detnet-pof-04 for the RTGDIR

CAUTION: This email has originated from a free email service commonly used for personal email services, please be guided accordingly especially if this email is asking to click links or share information.


Hi,

Denim Henriques of the RTGDIR secretaries asked me to review the
latest draft-ietf-detnet-pof draft last Thursday. Unfortunately it
seems I already got asked to review an earlier revision of the draft,
but the request got lost (most likely on my side).

I read through draft-ietf-detnet-pof-04 and parts of RFC8655 and I
think the concept of a POF function is pretty straight forward.

When reading through "4.3 The Basic POF Algorithm" I see a couple of
issues that could use clarification (or a fix).

First, I would suggest eliminating the duplicate text what happens
when a packet is forwarded. The fifth bullet point on page 6 already
states what has to be done, so you can remove the POFLastSent update
in the "Then" block of the third bullet point.

Second, I would like to hear a clarification on why POFLastSent is
always set to seq_num when a package is transmitted and not only if
seqnum is larger than POFLastSent. When a package with sequence number
X is forwarded for any reason, everything with a smaller sequence
number than X should be instantly forwarded (order is already being
disrupted anyways).

As an example, if seq_num 10 already has been forwarded and now
seq_num 5 is being forwarded, I would still expect seq_num 7 to 9
going through the POF, which doesn't happen if POFLastSent is reset to
5. If this is correct, I would suggest something like "POFLastSent =
max(POFLastSent, seq_num)" in the algorithm.

Third, the Note on page 6 hints (correctly) that comparison (and
maximum detection) can be done but is a bit tricky in circular
sequence number space. I could not find an example how to handle this
in RFC 8655, so maybe putting an example of how to do it sequence
number overflow in an appendix could improve this document.

Lastly, for the "Advanced POF Algorithm" the path dependent delays
might result in multiple packets triggering the "maximum delay
reached" at exactly the same time. It might be worth writing down that
the transmission order of these packets then should be preserver,
should be done in seq_num order or that it doesn't matter.

Nitpick:
in the description of the POFMaxDelay_i in "5. Control and Management
Plane Parameters for POF" it might be a good idea to mention that this
represents multiple parameters, e.g.

"POFMaxDelay_i" for each possible path i


Henning Rogge
This email disclaimer applies to the original email, all attachments and any subsequent emails sent by Liquid Telecom. This email contains valuable business information that is privileged, confidential and/or otherwise protected from disclosure, intended only for the named person or entity to which it is addressed. If you are not the intended recipient of this email and you received this e-mail in error, any review, use, dissemination, distribution, printing or copying of this e-mail is strictly prohibited and may be unlawful and/or an infringement of copyright. Please notify us immediately of the error and permanently delete the email from your system, retaining no copies in any media. No employee or agent is authorized to conclude any binding agreement on behalf of Liquid Telecom with another party or give any warranty by email without the express written confirmation by an authorized representative or a director of Liquid Telecom. Nothing in this email shall be construed as a legally binding agreement or warranty or an offer to contract. Liquid Telecom will not be responsible for any damages suffered by the recipient as a result of the recipient not taking cognizance of this principle. Liquid Telecom accepts no liability of whatever nature for any loss, liability, damage or expense resulting directly or indirectly from the access of any files which are attached to this message. Any email addressed to Liquid Telecom shall only be deemed to have been received once receipt is confirmed by Liquid Telecom orally or in writing. An automated acknowledgment of receipt will not suffice as proof of receipt by the Liquid Telecom. This email disclaimer shall be governed by the laws of South Africa.