[Gen-art] Gen-ART review of

jouni korhonen <jouni.nospam@gmail.com> Fri, 23 September 2016 18:14 UTC

Return-Path: <jouni.nospam@gmail.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id CC36D12B163; Fri, 23 Sep 2016 11:14:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id UPEqzOCjvpml; Fri, 23 Sep 2016 11:14:53 -0700 (PDT)
Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BF4612B0ED; Fri, 23 Sep 2016 11:14:53 -0700 (PDT)
Received: by mail-yw0-x22a.google.com with SMTP id g192so120372139ywh.1; Fri, 23 Sep 2016 11:14:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=FVTXs6HV7wn6oGbVHPyu+hjwrUmCOC+DrGbEQmdFEZ8=; b=a/dVaAFrLlRwAlHUiNYPBmSuClLtTQ1YwhQhvOOM8W+or8MT4xypr+4eObay88xu0k qiCGnV+4KehhSVqgDzD4xKr7u8L2VMXoBJtmfLf/L/IOn4+5f4jFOZlrMdFyjwZyYGn6 Pi2YuPcOmwCwGvc49rq5j1k7GhB1EpokrhOhJvyVmBr+AjrxiH9DmLPlsA8mBbJII7wp Kcthop/VKJhaJnSxccgItNxI31awDGsrJuNvzRvJvFu3uZM/7bhsqXXKAwnlTlfXAX9a 6fKo5w0xZTRvf8btEjmcIH7p2uFEGUkuv8RtKDMI2Il7+J2tnQQnHucx2csk6rgy0eBK YQBw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=FVTXs6HV7wn6oGbVHPyu+hjwrUmCOC+DrGbEQmdFEZ8=; b=VMB5ZUS1VcDcE4D3tivQ4qjlv9Vtk2XlkHpWAEC2iep1y+9XpuUvPrKqvrGjGGst/Z KfDRQWwet4TcerIIg8rd3MCDsHxgf8NZ1hfvjr+bm0v7X4YQKtAMGdlEXXMJnf00y0Sk ORomFWH2ZAmZXxzz0P586SBA8VBNskBsQ/yBNY1V+c6f23B6gMp7FEfjLc+FhhpwNtBw dvWb6i6xvxCXxuCqoiW0Zh7Sm2OZ11dux8Tapy7n2KWJOFPG/LybSaI2oSuYuEveJNhl QNUqZIPOXgl2UVfM8TESg23l75Lj84KOryHIslQMDERIE0hLbgoyJpVCjdSrODl0+UfH 1WTQ==
X-Gm-Message-State: AE9vXwObP1zqV7CR8MmQolbKJocbnHAlBpopGtUusCSsvyDmcPhTJpD1iSFS+8x4DHEs8gHrgKvE8XEkBR3nrg==
X-Received: by with SMTP id y139mr7431016ywd.348.1474654492277; Fri, 23 Sep 2016 11:14:52 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 23 Sep 2016 11:14:51 -0700 (PDT)
From: jouni korhonen <jouni.nospam@gmail.com>
Date: Fri, 23 Sep 2016 11:14:51 -0700
Message-ID: <CAC8SSWtS6f5_YgpOtXP_oprQwFMVDmpsMa+VGJGWYpAk2doc=g@mail.gmail.com>
To: General Area Review Team <gen-art@ietf.org>, draft-ietf-ippm-6man-pdm-option.all@ietf.org
Content-Type: multipart/alternative; boundary=94eb2c07624e2dca86053d30c148
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/s-3IApLS7lu-6dIotI-towNX9PM>
Subject: [Gen-art] Gen-ART review of
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 Sep 2016 18:14:56 -0000

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at


Document: draft-ietf-ippm-6man-pdm-option-05
Reviewer: Jouni Korhonen
Review Date: 9/23/2016
IETF LC End Date: 2016-09-28
IESG Telechat date: (if known)

Summary: The draft needs some work.

Major issues:

I have two technical issues here:

1) There is no mention of what is the time reference plane for internal
time stamping. All other timing and synchronization related documents I am
aware of (at least outside IETF) describe it very clearly where in the
processing/packet handling the time stamp is to be taken. Now the document
gives me no idea as an implementer where that should take place. At least
it makes it hard to calculate the *network* RTT precisely.

2) The PDM option relation to actual "server" time is somewhat confusing
and the 5-tuple does not allow me to detect the real relationship between
the server/application action that caused the generation of the packet and
the PDM within the packet. This is specifically an issue with
transport/application protocols that multiplex/interleave multiple
application streams into one transport. I have no idea of the actual
individual application time since the packets get generated independent of
the processing of a single thread. I would welcome some discussion around
here. Section 1.4 last paragraph is going to this direction but is not
sufficient IMHO.

Minor issues:

1) This is a larger editorial issue. The document is far too long with a
lot of repetition considering it describes only one IPv6 destination
option. It is a writing style issue and I am fully aware of that. I have
proposals how to cut text in the editorial comments section.

2) Section 1.2 3rd paragraph talks about IoT and that speed matters there.
I find this too generalized statement. There are many other things that
matter in this application domain and speed might not be that important as
being able to send/receive that one to two bytes of data in a given time
window. I suggest removing this paragraph.

Nits/editorial comments:

1) Section 1.4 numbered list: add missing full stops.

2) Section 3.2: remove
  "The 5-tuple consists of
   the source and destination IP addresses, the source and destination
   ports, and the upper layer protocol (ex. TCP, ICMP, etc)."
since this is unnecessary repetition.

3) Section 3.2: remove
  "Operating systems MUST NOT implement a single
   counter for all connections."
Seems again like unnecessary repetition to previous sentence.

4) Section 3.2 again unnecessary repetition of IPv6 basics that can be read
from RFC2460. Suggest strongly to remove:
  "This indicates the
   following processing requirements:

   00 - skip over this option and continue processing the header.

   RFC2460 [RFC2460] defines other values for the Option Type field.
   These MUST NOT be used in the PDM."


   possible values are as follows:

   0 - Option Data does not change en-route

   1 - Option Data may change en-route

   The three high-order bits described above are to be treated as part
   of the Option Type, not independent of the Option Type.  That is, a
   particular option is identified by a full 8-bit Option Type, not just
   the low-order 5 bits of an Option Type."

5) Section 3.3 same as in comment 4). Suggest strongly removing:
  "This follows the order defined in RFC2460 [RFC2460]
                 IPv6 header

                 Hop-by-Hop Options header

                 Destination Options header  <--------

                 Routing header

                 Fragment header

                 Authentication header

                 Encapsulating Security Payload header

                 Destination Options header <------------

                 upper-layer header"

6) Suggest removing entire Section 3.4 and moving the following text to
Section 3.3:
  "PDM MUST be placed before the ESP header in
   order to work.  If placed before the ESP header, the PDM header will
   flow in the clear over the network thus allowing gathering of
   performance and diagnostic data without sacrificing security."

7) Section 3.6 suggest removing the following text. I see no value it would
add to what has already been said:
  "As with all other destination options extension headers, the PDM is
   for destination nodes only. As specified above, intermediate devices
   MUST neither set nor modify this field."

8) Section 3.6 suggest removing the following 5-tuple text as it has
already been described earlier in Section 2:
  "The 5-tuple is:

   SADDR : IP address of the sender SPORT : Port for sender DADDR : IP
   address of the destination DPORT : Port for destination PROTC :
   Protocol for upper layer (ex. TCP, UDP, ICMP)"

9) Sections 4.2 and 4.3 suggest removing them entirely. I see what value
these sections add. I acknowledge they are good to know information of
timer hardware implementation difference but do not really add value on the
on-wire encoding of the PDM option.

10) Section 4.4 suggest removing the entire section. Time Base was already
described in detail enough in Section 3.2.

11) Section 4.5 time base for picoseconds is 11 not 00.

12) Section 4.5 suggest removing the following text, since it does not add
any more clarity to what has already been said in my opinion. This is
because all the examples follow nice nybble increment in scaling:
  "Sample binary values (high order 16 bits taken)

   1 psec            1                                              0001
   1 nsec          3E8                                    0011 1110 1000
   1 usec        F4240                          1111 0100 0010 0100 0000
   1 msec     3B9ACA00           0011 1011 1001 1010 1100 1010 0000 0000
   1 sec    E8D4A51000 1110 1000 1101 0100 1010 0101 0001 0000 0000 0000"

12) Section 4.6 I do not understand why this section is here. I strongly
suggest removing it. Sections 4.5 and 3.2 already describe how I would
encode the delta time using scaling as a separate fields not embedded
(option fields ScaleDTLR and ScaleDTLS). Did I misunderstand something here?

13) Section 5 suggest removing the following text because of it repeating
what has already been said earlier:
  "Each packet, in addition to the PDM contains information on the
   sender and receiver. As discussed before, a 5-tuple consists of:

      SADDR : IP address of the sender
      SPORT : Port for sender
      DADDR : IP address of the destination
      DPORT : Port for destination
      PROTC : Protocol for upper layer (ex. TCP, UDP, ICMP)

   It should be understood that the packet identification information is
   in each packet. We will not repeat that in each of the following

14) Section 5.3 suggest merging the following text into one example and do
necessary rewording. There is no need to do the same calculation twice on
almost adjacent lines:

  "Sending time : packet 2 - receive time : packet 1

   We will call the result of this calculation: Delta Time Last Received

   That is:

   Delta Time Last Received = (Sending time: packet 2 - receive time:
   packet 1)"

15) Expand RTT and PSN on their first use.

Phew.. after all this I found the document good reading and most likely a
useful tool to be used.