Hi, > On 4 May 2023, at 11:04, Giuseppe Fioccola <giuseppe.fioccola@xxxxxxxxxx> wrote: > > Hi Tim, > Thank you for your feedback, > Please find my replies inline tagged as [GF]. Thanks, your comments and responses look fine. The ECN comment doesn’t require action. One comment on reflection, perhaps emphasise that the draft provides a “toolbox” to capabilities, not all of which need to be implemented at once. Perhaps this can be captured if you show a couple of example scenarios as suggested. Best wishes, Tim > Regards, > > Giuseppe > > -----Original Message----- > From: Tim Chown via Datatracker <noreply@xxxxxxxx> > Sent: Wednesday, May 3, 2023 4:18 PM > To: ops-dir@xxxxxxxx > Cc: draft-ietf-ippm-explicit-flow-measurements.all@xxxxxxxx; ippm@xxxxxxxx; last-call@xxxxxxxx > Subject: Opsdir last call review of draft-ietf-ippm-explicit-flow-measurements-03 > > Reviewer: Tim Chown > Review result: Ready > > Hi, > > I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. > > The document has very minor nits, and is pretty much Ready. > > [GF]: Thank you for the good opinion. > > This draft proposes the use of specific bits for the purposes of marking traffic to support passively estimating round trip time (delay) and loss between two endpoints supporting the mechanisms described in the document. The approach is designed with encrypted transport protocols in mind. > > The document is well-structured. Some of the more detailed descriptions of the use of the bits, particularly the later sections on the R and Q bits were a little hard to follow, but overall the quality is good. Some of the use of language hints at author(s) for whom English is not their first language, some minor improvement would be desirable before submission towards publication, to save effort for the RFC Editor. > > Overall the proposed use of the bits seems reasonable, and potentially useful. > It is not clear what implementations are available or tested as yet, there is only one mention of a part implementation by Christian Huitema. The draft talks of what a QUIC implementation would need to do, implying there is as yet not one available. However, given the document’s Informational status this is less of a concern. > > The summary of approaches at the end is very useful. > > Some use case discussion might be useful, especially for an informational document. Maybe include a couple of extremes, one a intra-DC, one for large scale data transfers over 100G+ paths from Europe to the US; these might require quite different “tuning” of the techniques and bits (considering train sizes, counters, etc)? > > [GF]: This is a useful suggestion. Agree, we could mention some possible application scenarios. > > General comments: > > “Explicit Host-to-Network Flow Measurement Techniques” is perhaps not the best name, or most indicative of the approach. Is it explicit? Is it host to network or client to server? > > [GF]: They are referred to as Explicit since these techniques are especially valuable when applied to protocols that encrypt transport headers as they enable measurements by passive on-path network devices. Also, we called them Host-to-Network since Client and Server are collaborative and expose performance information to the network probes. > > Perhaps emphasise more in the abstract and introduction (and even the title) that the approach is passive. And maybe that the methods don’t necessarily, or even generally, cover all packets in a flow. > > [GF]: Ok, we will highlight that the approach is passive. > > The AltMark drafts are now published - RFC 9341, 9342, 9343. > > [GF]: Sure, we will update all the references. > > Specific comments: > > The draft suggests which bits could be used for TCP and QUIC implementations, in particular using reserved bits at the end of Section 1, but is not a Standards Track document, so cannot specifically reserve bits. > > [GF]: We can rephrase this part in order to emphasize that it is for experimentation. In this regard, I think we can also omit all the figures of section 6. > > Section 2.2 - maybe some scenarios would prefer application measurement; maybe the draft should state the approach is designed for network delays, not full end-to-end delays. > > [GF]: Agree, we may add this point. > > In 2.2.3 I suppose the 100ms needs to be a value big enough that it is worse than the likely worst case. This would be different for the scenarios I mentioned above. > > [GF]: Yes, we can mention that its value can change depending on the scenarios. > > In 2.2.4.1 “endpoints” aren’t defined. Are they nodes, or unique port/IP tuples? Given the title says “flow”, presumably the latter. > > [GF]: Sure, we can add the definition of endpoints as you noted. > > In 2.2.5 is it worth mentioning cases where an observer might not see both flows? Use of ECMP, or other asymmetric routing in particular. The client should still see everything g, but an observer’s mileage may vary. > > [GF]: In this case the observer can measure only a subset of the performance information. > > In 3.1.1 and the end of 3.1.2 these trains could be quite large, thinking of how many packets are in flight on a 30Gbps data transfer flow over a 100ms path. The example at the end of 3.1.3 is of 5 packets. > > [GF]: Yes, we can highlight that it is just an example. > > WRT 3.5, I started musing over ECN as another “measurement” bit somewhere in Section 2, nice to see it discussed here. > > [GF]: Ok we will add it. > > Tim > > > -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
