Hi Giuseppe, This all looks good, thanks! For the protocol specific mechanisms Section 2.2.3, I'm not sure it necessarily makes sense for an implementation to use a protocol specific value. It might make sense for the draft to suggest a value, but note that there might be an option to use an existing protocol-specific value and designers should consider if such a thing is appropriate. I imagine that some protocols could use information that's only available to the endpoint, and can't be easily estimated by the network, in choosing their protocol specific value; others might use readily available data. Colin On 22 May 2023, at 15:03, Giuseppe Fioccola wrote: > Dear Colin, > Thank you for your review. > Please find my replies inline tagged as [GF]. > > Regards, > > Giuseppe > > -----Original Message----- > From: Colin Perkins via Datatracker <noreply@xxxxxxxx> > Sent: Saturday, May 20, 2023 3:08 PM > To: tsv-art@xxxxxxxx > Cc: draft-ietf-ippm-explicit-flow-measurements.all@xxxxxxxx; ippm@xxxxxxxx; last-call@xxxxxxxx > Subject: Tsvart telechat review of draft-ietf-ippm-explicit-flow-measurements-03 > > Reviewer: Colin Perkins > Review result: Almost Ready > > This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. > > When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC tsv-art@xxxxxxxx if you reply to or forward this review. > > Thank you for a well-written, well-organised, and clearly motivated draft. This is a well-specified mechanism that looks appropriate to the intended task. I have only a few transport-related comments. > > [GF]: Thanks a lot. > > §2.2.3: The mechanism to calculate T_max_c is fine, and I’m not suggesting a change, but I note that protocols such as TCP compute a retransmission timeout value that is similarly some multiple of the RTT, with a comparable magnitude. > It might be helpful for the draft to discuss why such an existing protocol-specific value (e.g., Trto in TCP) was not adopted for T_max. > > [GF]: We can surely mention that an implementation can use an existing protocol-specific value. Note that the draft does not suggest an existing protocol-specific value since it aims to be transport agnostic. It will be up to a possible specific proposed standard document to specify it. > > The delay bit mechanism presumably fails if the delay suddenly increases to more than T_max. Such temporary delay spikes can certainly occur in practise (e.g., I’ve seen them on poor-quality WiFi links). The draft would benefit from a discussion of the limitations of the mechanism in detecting edge cases such as this. > > [GF]: Yes, we can add further details and highlight this point as well. > > §3.5: The use of an unreported ECN-Echo counter looks appropriate for CE marks generated in response to ECT(0)-marked traffic following RFC 3168 that generate CE marks at a rate comparable to that of packet loss. However, flows using L4S marking with ECT(1), as described in RFC 9331, generate CE marks at a much higher rate. Would it make sense for the ECN-Echo Event Bit to either distinguish the two types of CE marking in reports, based on the ECT value of other packets in the flow, or to be restricted to CE marks generated in response to ECT(0)-marked packets? Does the ECN-Echo counter produce usable results for L4S flows? > > [GF]: This is a very interesting point. It would be a possible extension to consider. I suggest to add a reference to RFC 9331 and mention the possibility to handle the two types of CE marking in a possible implementation. > > Section 6 suggests ways in which additional signals, as described in this draft, can be included in QUIC or TCP. While I agree that the approaches suggested could be plausible ways of carrying such additional signals, their inclusion here could be misinterpreted as specifying an approach rather than giving examples of possible approaches. It might be more appropriate to either remove this section, and leave the discussion of how to incorporate these signals into the protocols to the QUIC and TCPM working groups, or to limit the discussion of those protocols to noting that there are sufficient unused bits in their headers to allow these additional signals to be carried. > > [GF]: Yes, we already agreed to revise section 6. In this regard, we will remove all the figures in section 6 and we will only mention in general that some experiments have been done with QUIC and TCP, but without specifying other information. > > In the entire draft, there’s an assumption that the paths taken by flows are stable, or at least traverse the same measurement point, for the duration of the measurements. It may be helpful to note this. > > [GF]: Ok, we will add a note on that. > > Regards > Colin -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
