[Tsv-art] Tsvart last call review of draft-ietf-6man-ipv6-alt-mark-06

[Yoshifumi Nishida via Datatracker <[e-mail]>]

Reviewer: Yoshifumi Nishida
Review result: On the Right Track

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
[e-mail] if you reply to or forward this review.

Summary: I think this document is on the right track, but it needs to address
                   the following points to be published as a PS document.


1: I think the doc should provide a high-level view of the usage of this
   method. For example, it is not clear to me how measurement nodes interact
   each other, exchange and compare information, etc. If it is provided in 
   other documents, it should be referred.

2: Section 5.1: "By counting the number of packets in each batch and
   comparing the values measured by different network nodes along the path,
   it is possible to measure the packet loss occurred in any single batch
   between any two nodes."

    -> It is not clear to me how two nodes exchanges the measured counts.
       This point should be clarified even if if it's out-of-scope of the
       document.

3: Section 5.1: "In a few words this implies that the length of the batches
   MUST be chosen large enough so that the method is not affected by those
   factors."

    -> It would be better to have recommended length values here.
       At least, it would be better to provide some guidances to decide
       the value.

4: Section 5.1:
   Can we change the length of batch in the middle of data transfer?
   Also, is there any concerns to use different length for each flow?
   I think it would be better to specify on these points.

5: Section 5.2:
   I am wondering if this approach requires time sync between nodes or not.
   This point should be clarified.

6: Section 5.2:
   "Whenever the L bit changes and a new batch starts, a network node
   can store the timestamp of the first packet of the new batch, that
   timestamp can be compared with the timestamp of the first packet of the
   same batch on a second node to compute packet delay."

     -> It is not clear to me how two nodes compare the stored timestamps.
        This point should be clarified.

7: Section 5.2:
   What's the benefits for using the approach described in 1.?
   The use cases for it should be described.

--
Yoshi