Subject: Re: [ippm] Possible Draft for: Internet Draft Review Team: IPv6

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 14 Jul 2016 19:26:00 +0000

> On Jul 14, 2016, at 1:36 AM, [email-masked] wrote:
> I don't know if you would consider it, but we could use some IPv6 review for a draft that we have in IPPM.
> 
> It is just the IPv6 related changes you have to look at:
> 
> Draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-2330-ipv6/

Taking a look for myself...

> Abstract
> 
>    This memo updates the IP Performance Metrics (IPPM) Framework RFC
>    2330 with new considerations for measurement methodology and testing.
>    The memo updates the definition of standard-formed packets in RFC
>    2330 to include IPv6 packets.  It also augments distinguishing
>    aspects of packets, referred to as Type-P for test packets in RFC
>    2330.
> 
>    Two points (at least) are worthwhile discussing further: extent of
>    coverage for 6LO and IPv6 Header Compression, and the continued need
>    to define a "minimal standard-formed packet".

You'll understand if I cringe a bit when I read "standard-formed". "Form" is a verb, which makes "standard" (which modifies "formed") an adverb, which means that the proper usage is "standardly-formed". I recognize the need to take 2330 as specifying the word, but the grammar-nazi in me cringes.

> 3.  Packets of Type-P
   ...
>    If the information constituting Type-P at the Source is found to have
>    changed at the Destination (or at a measurement point between the
>    Source and Destination, as in [RFC5644]), then the modified values
>    SHOULD be noted and reported with the results.  Some modifications
>    occur according to the conditions encountered in transit (such as
>    congestion notification) or due to the requirements of segments of
>    the Source to Destination path.  For example, the packet length will
>    change if IP headers are converted to the alternate version/address
>    family, or if optional Extension Headers are added or removed.  Local
>    policies in intermediate nodes based on examination of IPv6 Extension
>    Headers may affect measurement repeatability.  If intermediate nodes
>    follow the recommendations of [RFC7045], repeatability may be
>    improved to some degree.

It may be worth mentioning that TTL/Hop Limit will normally change in transit, and the fact may be relevant to a specific test. For example, NDP packets are transmitted with Hop Limit=255, and a validity test is specified that the Hop Limit should still be 255 when the packet arrives. If the test is testing that, it will be relevant.

>    A Network Address Translator (NAT) on the path can have unpredictable
>    impact on latency measurement (in terms of the amount of additional
>    time added), and possibly other types of measurements.  It is not
>    usually possible to control this impact (as testers may not have any
>    control of the underlying network or middleboxes).  There is a
>    possibility that stateful NAT will lead to unstable performance for a
>    flow with specific Type-P, since state needs to be created for the
>    first packet of a flow, and state may be lost later if the NAT runs
>    out of resources.  However, this scenario does not invalidate the
>    Type-P for testing.  The presence of NAT may mean that the measured
>    performance of Type-P will change between the source and the
>    destination.  This can cause an issue when attempting to correlate
>    measurements conducted on segments of the path that include or
>    exclude the NAT.  Thus, it is a factor to be aware of when conducting
>    measurements.

BTW, the purpose of the test may be to quantify the impact on jitter...

> 4.  Standard-Formed Packets
> 
>    Unless otherwise stated, all metric definitions that concern IP
>    packets include an implicit assumption that the packet is *standard-
>    formed*. A packet is standard-formed if it meets all of the following
>    criteria:

Theorizing on standard(ly)-formed packets:

I would think that a packet that can be described as "standard" in a context is valid with respect to the standards in question (IPv4, IPv6, perhaps TCP, and whatever else is important) and is similar to the preponderance of packets one would observe in the application IRL. If we're testing 64 (or 128) byte Ethernet packets, all packets will be 64 (or 128) bytes long and have valid Ethernet headers and trailers. If we're testing the ability to transfer a file using MSS-sized segments on a path with a PMTU of 1500 octets, the IPv4 MSS will be 1460, and the IPv6 MSS will be at most 1440 (and might be less). So for the file transfer test, I would expect that all of the packets, with the possible exception of the last, have a valid IPv4/6 and a valid TCP header, and TCP payload to fill out 1500 bytes. We might not literally transfer a file (going through all of the TCP antics), but we might - if the test is "how would TCP transfer the file", I should think we absolutely would. If we don't, I would guess that the IPv4/6 header doesn't materially change, the TCP header would be correct for at least one of the segments sent (even if it is the same TCP header over and over again, it will have two valid port numbers, a valid checksum, the flags would identify a data segment, and the magic numbers would have reasonable values), and the payload would be whatever happened to be in memory when we built the packet.

>    +  It includes a valid IP header: see below for version-specific
>       criteria.
> 
>    +  It is not an IP fragment.
> 
>    +  The Source and Destination addresses correspond to the intended
>       Source and Destination, including Multicast Destination addresses.
> 
>    +  If a transport header is present, it contains a valid checksum and
>       other valid fields.
> 
>    For an IPv4 ( [RFC0791] and updates) packet to be standard-formed,
>    the following additional criteria are required:
> 
>    o  The version field is 4
> 
>    o  The Internet Header Length (IHL) value is >= 5; the checksum is
>       correct.
> 
>    o  Its total length as given in the IPv4 header corresponds to the
>       size of the IPv4 header plus the size of the payload.
> 
>    o  Either the packet possesses sufficient TTL to travel from the
>       Source to the Destination if the TTL is decremented by one at each
>       hop, or it possesses the maximum TTL of 255.
> 
>    o  It does not contain IP options unless explicitly noted.
> 
>    For an IPv6 ([RFC2460] and updates) packet to be standard-formed, the
>    following criteria are required:
> 
>    o  The version field is 6.
> 
>    o  Its total length corresponds to the size of the IPv6 header (40
>       octets) plus the length of the payload (including Extension
>       Headers) as given in the IPv6 header.

I would suggest that you say that "the Payload Length conforms to the IPv6 specification". This text exceeds that value by 40 bytes.

From RFC 2460, page 4:

   Payload Length       16-bit unsigned integer.  Length of the IPv6
                        payload, i.e., the rest of the packet following
                        this IPv6 header, in octets.  (Note that any
                        extension headers [section 4] present are
                        considered part of the payload, i.e., included
                        in the length count.)

>    o  Either the packet possesses sufficient Hop Count to travel from
>       the Source to the Destination if the Hop Count is decremented by
>       one at each hop, or it possesses the maximum Hop Count of 255.
> 
> 
> 
> 
> Morton, et al.           Expires January 5, 2017                [Page 5]
> Internet-Draft              IPPM IPv6 Update                   July 2016
> 
> 
>    o  Either the packet does not contain IP Extension Headers, or it
>       contains the correct number and type of headers as specified in
>       the packet, and the headers appear in the standard-conforming
>       order (Next Header).

I went around and around in my head on the statement above that the packet "is not fragmented". In IPv4, that is potentially important. On the other hand, there are applications (I'm told) that send long strings of fragments - an entire video frame, or more, might be a single fragmented IP datagram. In IPv6, if there are no extension headers, the "fragmentation" extension header is not present, and the packet is not fragmented.

Should the statement about "it is not fragmented" be an IPv4 consideration?

>    o  All parameters used in the header and Extension Headers are found
>       in the IANA Registry of Internet Protocol Version 6 (IPv6)
>       Parameters, partly specified in [RFC7045].

>    Compressed IPv6 headers must be compliant with [RFC4494], as updated
>    by [RFC6282], in order to be declared "standard-formed".

Should the discussion of compressed IPv6 headers be in a separate section? I tend to think it is a slightly different topic - a standard-format message is one thing, and a compressed standard-format message is a derivative of a standard-format message.

>    The topic of IPv6 Extension Headers brings current controversies into
>    focus as noted by [RFC6564] and [RFC7045].

This very much dates the draft. I understand it in an internet draft - "we're talking about this, and we're also talking about that somewhere else, and they relate". In an RFC ten years from now it may seem anachronistic.

> The following additional
>    considerations apply when IPv6 Extension Headers are present:
> 
>    o  Extension Header inspection: Some intermediate nodes may inspect
>       Extension Headers or the entire IPv6 packet while in transit.  In
>       exceptional cases, they may drop the packet or route via a sub-
>       optimal path, and measurements may be unreliable or unrepeatable.
>       The packet (if it arrives) may be standard-formed, with a
>       corresponding Type-P.
> 
>    o  Extension Header modification: In Hop-by-Hop headers, some TLV
>       encoded options may be permitted to change at intermediate nodes
>       while in transit.  The resulting packet may be standard-formed,
>       with a corresponding Type-P.
> 
>    o  Extension Header insertion or deletion: It is possible that
>       Extension Headers could be added to, or removed from the header
>       chain.  The resulting packet may be standard-formed, with a
>       corresponding Type-P.

You'll get comments on that from 6man. It's a true statement, but not a blessed one.

>    o  A change in packet length (from the corresponding packet observed
>       at the Source) or header modification is a significant factor in
>       Internet measurement, and requires a new Type-P to be reported.
> 
>    We further require that if a packet is described as having a "length
>    of B octets", then 0 <= B <= 65535; and if B is the payload length in
>    octets, then B <= (65535-IP header size in octets, including any
>    Extension Headers).  The jumbograms defined in [RFC2675] are not
>    covered by this length analysis.  In practice, the path MTU will
>    restrict the length of standard-formed packets that can successfully
>    traverse the path.
> 
>    So, for example, one might imagine defining an IP connectivity metric
>    as "IP-type-P-connectivity for standard-formed packets with the IP
>    Diffserv field set to 0", or, more succinctly, "IP-type-
> 
> 
> 
> Morton, et al.           Expires January 5, 2017                [Page 6]
> Internet-Draft              IPPM IPv6 Update                   July 2016
> 
> 
>    P-connectivity with the IP Diffserv Field set to 0", since standard-
>    formed is already implied by convention.  Changing the contents of a
>    field, such as the Diffserv Code Point, ECN bits, or Flow Label may
>    have a profound affect on packet handling during transit, but does
>    not affect a packet's status as standard-formed.
> 
>    A particular type of standard-formed packet often useful to consider
>    is the "minimal IP packet from A to B" - this is an IP packet with
>    the following properties:
> 
>    +  It is standard-formed.
> 
>    +  Its data payload is 0 octets.
> 
>    +  It contains no options or Extension Headers.
> 
>    (Note that we do not define its protocol field, as different values
>    may lead to different treatment by the network.)
> 
>    When defining IP metrics we keep in mind that no packet smaller or
>    simpler than this can be transmitted over a correctly operating IP
>    network.

> 5.  Conclusions
> 
>    This memo adds the key considerations for utilizing IPv6 in two
>    critical conventions of the IPPM Framework.  It is RECOMMENDED to
>    adopt these new considerations in measurements involving IPv6.

I'm not sure the second sentence is needed. The fact of the existence of an Internet Draft means that the authors recommend its adoption; otherwise, they wouldn't post it. As an RFC, "so what?".

For that matter, I don't think this section adds much.

---

From: <[email-masked]>
Date: Sat, 16 Jul 2016 09:11:38 +0000 (UTC)

Fred,
Thanks so much for your comments.   I think everyone is travelling.   The document authors will meet to discuss your comments and be back to you. Thanks,
Nalini ElkinsInside Products, Inc.www.insidethestack.com(831) 659-8360

      From: Fred Baker (fred) <[email-masked]>
 To: Nalini Elkins <[email-masked]> 
Cc: Edwin Cordeiro <[email-masked]>; Douglas Onyango <[email-masked]>; Ricardo Pelaez Negro <[email-masked]>; Honest Ornella GANKPA <[email-masked]>; "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>
 Sent: Thursday, July 14, 2016 9:26 PM
 Subject: Re: Possible Draft for: Internet Draft Review Team: IPv6

  ...