Re: [ippm] 1st AD review of rfc8889bis

[Giuseppe Fioccola <[e-mail]>]

Hi Martin,
Sure, I will update this draft as well in the coming weeks.

Regards,

Giuseppe

From: Martin Duke <[e-mail]>
Sent: Friday, December 3, 2021 6:38 PM
To: Giuseppe Fioccola <[e-mail]>
Cc: [e-mail]; IETF IPPM WG <[e-mail]>
Subject: Re: 1st AD review of rfc8889bis



On Fri, Dec 3, 2021 at 6:59 AM Giuseppe Fioccola <[e-mail]<mailto:[e-mail]>> wrote:
Hi Martin,
My answers inline as [GF].


I agree that there are many possibilities, but a standard should either provide guidance or (at least) work through the implications of each. It should be more prescriptive; marking nodes and measurement nodes need to have common expectations about the marking rules, although they can deterministically depend on whether or not one can mark fragments (which is obviously deployment-dependent).

I'm happy to be corrected by an expert, but after thinking about it for a few minutes I would propose the following:
(i) marking nodes MUST mark all fragments if there is a codepoint to use (i.e. it is in the IP header or encapsulation), as if they were separate packets.
(ii) routers that fragment packets in a network under test MUST NOT replicate marks (thus signalling that it was fragmented internally), but SHOULD mark the first fragment if they have the capability to do so.
(iii) Measurement points MAY simply ignore unmarked fragments and count marked fragments as full packets. However, if resources allow, Measurement Points SHOULD make note of marked initial fragments and only increment its counter if (a) other fragments are also marked, or (b) it observes all other fragments and they are unmarked.

[GF]: I fully agree with your proposals. The marking node MUST mark all the fragments except in the case of fragmentation within the network domain; in this case it is suggested to mark only the first packet. The condition about the counters also makes sense so it could be possible to keep track of both marked and unmarked fragments. I can include these considerations in the next version.

Alright, please think it through and write up some text if you think it checks out.

- I don't understand the L determination when there are multiple marking nodes (Sec 7). "The source measurement intervals can be of different lengths and with different offsets" Some questions:
(a) What is a "source measurement interval"? Does it have anything to do with L?
(b) So let's say that source nodes start marking at arbitrary times. Isn't the "offset" then directly a function of L? And if so, how can we scale L based on the offset m?
(c) if the idea is that there is a clock time when marking should begin, then why isn't the value of A [clock skew] embedded in d sufficient?

[GF]: For a multipoint-to-multipoint flow, you may have multiple marking nodes, so there is an additional contribution to take into account. Indeed, the marking nodes may apply the markings at different moments and this time offset does not depend from the clock error or from the network delay but it is an intrinsic delay of the router.
Regarding your questions:
a) it is the marking period. I will replace it to be aligned with the terminology of the rest of the document.
b) yes, there is the formula: L - 2m - 2d > 0
c) m is not given by clock skew, indeed A is already included in d.

I wasn't clear enough about (b). Let's say node A has period L1, and node B is trying to set its L but is going to start at an arbitrary time. What is m for node B? It is a uniform distribution over [0, L1]. so L2 has to be >> L1. But the same is true of A! The only way to disambiguate the blocks is for each L to be much bigger than all the other Ls, which is of course impossible.

The only way I can see for this to work is for the marking nodes to agree a clock time to switch blocks, with fixed L, and then you're only constrained by the clock skew and delay as in 8321.

To me this is the central problem 8889 is trying to solve, and it's under-baked. Maybe there's a constraint I'm not seeing?

[GF]: Yes, the only way is that the marking nodes switch blocks with fixed L based on a clock time. In theory the formula in RFC8321 applies also in case of multipoint network. But we wanted to generalize that formula and let me explain the rationale. Since we have more marking nodes in a multipoint environment, there can be an additional mismatch to consider since different nodes are marking the traffic and the batches get mixed in a multipoint flow. For example, a marking node may apply the marking with a delay because it is overloaded while the other marking nodes are not. To take into account this possible additional gap between the sources we introduced “m” even if m can be negligible in most of the cases. Also note that the formula (L - 2m - 2d > 0) is exactly the same of RFC8321 if m=0, indeed in case of a point-to-point flow we only have one marking node and m=0. Maybe more explanation in the draft could help here.


Agreed, let's more precisely define what m is, and clarify that marking nodes are switching colors based on synchronized clock time.