Measurement of Round-Trip Time and Fractional Loss Using Session Traversal Utilities for NAT (STUN)
draft-ietf-tram-stun-path-data-05

= General =

I find the name the name PATH-CHARACTERISTIC a bit general for this, since it specifies a single specific characteristic while one could imagine other characteristics one might want to specify in the future. Would suggest naming this something more specific.

= Section 1 =

I think it will be important for future ICE specs to document expected usage of this feature, and those won't necessarily be limited to continuous nomination. I don't think there is anything to be done in this draft, but just noting here that close coordination between TRAM and ICE will be necessary to make sure this happens going forward.

= Section 3.3 =

Section 3.1 defines ReTransCnt as "Number of times request is re-transmitted with the same transaction ID to the server," but then the examples in 3.3 all show the client populating this field with 1 in its first request. If the number is supposed to be about *re-transmits* (not transmits, but re-transmits), I would have expected it to be 0 in the first request, then 1 upon an actual re-transmit. Why do these start at 1? It may be that simply re-wording the use of "re-transmits" in 3.1 would fix this.

Also, in the first two examples, why do the ReTransCnt values keep incrementing after a successful response? For example, in the normal case, why does the client re-transmit its request with ReTransCnt equal to 2 when it received a successful response?

I don't think this is appropriate to include a URL as affiliation (see callstats.io on the first page).

Below is Lionel Morand's OPS DIR review:

I think the draft is ready for publication as it is, even if some clarifications would help the reader for a correct use of the proposed solution. The comments listed below should not block the publication process but it would be nice if authors could address them if a new version of the draft is required.

Main comments:

- The whole solution is introduced as an improvement of the ICE prioritization formula. With the PATH-CHARACTERISTIC attribute, it is understood that there are additional criteria for selecting the most suitable candidate. But finally, it is not clearly said how the loss and RTT info modify/impact/improve the formula recommended in the RFC 5245. If it is left outside the document, please indicate it in the text.

- Moreover, the case with stateful agent handling the RespTransCnt field is pretty clear. But I think that more information should be given to the reader about the difference for the client to be able to rely or not on the RespTransCnt field.

Other comments:

- In section 1. Introduction:

   The ICE [RFC5245] mechanism uses a prioritization formula to order
   the candidate pairs and perform connectivity checks, in which the
   most preferred address pairs are tested first and when a sufficiently
   good pair is discovered, that pair is used for communications and
   further connectivity tests are stopped.

It is maybe too obvious and not essential for people involved in this work but could help the reader to know that ICE is a technique for NAT traversal and not a general purpose solution.

- In section 3.  Path characteristics determination mechanism

   This document defines a new comprehension-optional STUN attribute
   PATH-CHARACTERISTIC.  PATH-CHARACTERISTIC will have a STUN Type TBD-
   CA.  This type is in the comprehension-optional range, which means
   that STUN agents can safely ignore the attribute if they do not
   understand it.

It is said in another section but could be good to clarify that "safely ignore" means that when the new attribute is not supported by the server, the client naturally fallbacks to existing STUN/ICE procedures.

Instead of having a format for the request (section 3.1) and the response (section 3.2) that are the same, it would be clearer to have a section describing the format of the attribute (section 3.1)  and addition clarifying the use in the request (section 3.2) and the response (section 3.3).

- In section 3.1. The PATH-CHARACTERISTIC attribute in request

   The PATH-CHARACTERISTIC attribute in a STUN request takes a 4-byte
   Value.

I don't know what is the current IETF policy but I would prefer "32-bit value" instead of "4-byte value".

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Reserved, should be 0  |  ReTransCnt   |  RespTransCnt |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            Figure 1: PATH-CHARACTERISTIC attribute in request

Why are the two first octects marked as "reserved"? I'm assuming that these bits are present for alignment with a fixed size of STUN attributes but it should be clarified.
And if they are "should" should be replaced by "must". I think it would be easier to left "reserved" in the figure and describe its contents in the description given below the figure.

- In section 3.2. .  The PATH-CHARACTERISTIC attribute in response

   When a server receives a STUN request that includes a PATH-
   CHARACTERISTIC attribute, it processes the request as per the STUN
   protocol [RFC5389] plus the specific rules mentioned here.

It is maybe obvious or already described in RFC 5389, but I assume that the server must include the new attribute in the response if not received in the request.

   o  If the server is stateless or does not want to remember the
      transaction ID then it would populate value 0 for the RespTransCnt
      field in PATH-CHARACTERISTIC attribute sent in the response.  If
      the server is stateful then it populates RespTransCnt with the
      number of responses it has sent for the STUN request.

Is there any recommendation between "stateless vs stateful" for an optimal support of this new attribute? If it is, we could find something like "SHOULD be stateful but MAYBE stateless"...

- In section 3.3.  Example Operation

It should be clarified that the server is stateful in this example. Otherwise, the RespTransCnt field in PATH-CHARACTERISTIC attribute in the response is of no use. Could be "stateful server" instead of "server" in the description of the example.

Moreover, as commented earlier, The case with stateful agent handling the RespTransCnt field is pretty clear. But I think that more information should be given to the reader about the difference for the client to be able to rely or not on the RespTransCnt field.

- In section 4. Use cases

   o  When an endpoint has multiple interfaces (for example 3G, 4G,
      WiFi, VPN, etc.), an ICE agent can choose the interfaces for
      application data according to the path characteristics.  After
      STUN responses to STUN checks are received, the ICE agent using
      regular nomination can sort the ICE candidate pairs according to
      the path characteristics (loss and RTT) discovered using STUN.
      The controlling agent can then assign the highest priority to
      candidate pair which best fulfills the desired path
      characteristics.  However, it should be noted that the path
      capacity or throughput is not determined by these STUN checks.  If
      an endpoint needs to pick paths based on capacity, it would have
      to send application data on those paths.

This text illustrates the main comment given above. It is said:

      the ICE agent using
      regular nomination can sort the ICE candidate pairs according to
      the path characteristics (loss and RTT) discovered using STUN.

But there is no clue on how the agent will do.

The draft looks good, I would just add in the security section that the information could be observed passively if not encrypted (especially since that is an option) and used for reconnaissance and later attacks.

I like, but am a little surprised by, the MUST NOT at the
end of section 6. Thanks though!

Thanks for addressing the issues from my DISCUSS and COMMENT.