Subject: [tram] Benoit Claise's No Objection on draft-ietf-tram-stun-path-data-03: (with COMMENT)

From: "Benoit Claise" <[email-masked]>
Date: Wed, 20 Apr 2016 01:57:10 -0700

Benoit Claise has entered the following ballot position for
draft-ietf-tram-stun-path-data-03: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tram-stun-path-data/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 21 Apr 2016 09:43:15 -0500

Hi, Varun,

> https://datatracker.ietf.org/doc/draft-ietf-tram-stun-path-data/

Benoit and I have chatted further about this, and he noted that your
affiliation is

   Varun Singh
   Nemu Dialogue System Oy

in the Authors' Addresses section. At a minimum, the front page affiliation
should match what's in the Author's Addresses section.

Could you make sure that change happens?

Thanks,

Spencer

---

From: Varun Singh <[email-masked]>
Date: Thu, 21 Apr 2016 18:37:00 +0300

This is easy to fix, will send an updated author block to the editor.

On Thu, Apr 21, 2016 at 5:43 PM, Spencer Dawkins at IETF <
[email-masked]> wrote:

> in the Authors' Addresses section. At a minimum, the front page
> affiliation should match what's in the Author's Addresses section.
>

-- 
Founder, CEO, callstats.io
http://www.callstats.io
Analytics and Optimizations for WebRTC.

We are hiring: www.callstats.io/jobs/

---

From: Benoit Claise <[email-masked]>
Date: Thu, 21 Apr 2016 17:45:39 +0200

Varun,

 From http://www.callstats.io/about/

    callstats.io is a product of /Nemu Dialogue Systems Oy/, a startup
    based out of Helsinki, Finland

I believe you should use your company name and not a product name.

Regards, Benoit

> On Thu, Apr 21, 2016 at 5:43 PM, Spencer Dawkins at IETF 
> <[email-masked] <mailto:[email-masked]>> 
> wrote:
>
>     Hi, Varun,
>
>     On Wed, Apr 20, 2016 at 3:57 AM, Benoit Claise <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>         Please refer to
>         https://www.ietf.org/iesg/statement/discuss-criteria.html
>         callstats.io <http://callstats.io> on the first page).
>
>
>     Benoit and I have chatted further about this, and he noted that
>     your affiliation is
>
>        Varun Singh
>        Nemu Dialogue System Oy
>
> Founder, CEO, callstats.io <http://callstats.io>
> http://www.callstats.io
> We are hiring: www.callstats.io/jobs/ <http://www.callstats.io/jobs/>