[ippm] Discussion of unusual policy in draft-ietf-ippm-capacity-metric-method-01

["MORTON, ALFRED C (AL)" <[e-mail]>]

Hi IPPM,

In https://tools.ietf.org/html/draft-ietf-ippm-capacity-metric-method-01,
the authors proposed straightforward methods that measure at the IP-layer 
and depend on the presence of the simple UDP transport layer to make the
measurements possible. 

OTOH, we also understand the points at the end of Section 8.3, 
Measurement Considerations, quoted below:

   In general, results depend on the sending stream characteristics; the
   measurement community has known this for a long time, and needs to
   keep it front of mind.  Although the default is a single flow (F=1)
   for testing, use of multiple flows may be advantageous for the
   following reasons:

   1.  the test hosts may be able to create higher load than with a
       single flow, or parallel test hosts may be used to generate 1
       flow each.

   2.  there may be link aggregation present (flow-based load balancing)
       and multiple flows are needed to occupy each member of the
       aggregate.

   Each flow would be controlled using its own implementation of the
   Load Adjustment (Search) Algorithm.

   As testing continues, implementers should expect some evolution in
   the methods.

So, what if the Internet access policy is somewhat unusual/complex depending
on the stream (Type-P)?

We might see IP-layer Capacity limits for individual users in the
same household, or we might see limits based on the packet markings, packet
transport layer, or higher layer protocols imposed on packets from all users.
We could see policies and queues dedicated to elastic traffic and low-latency 
traffic, and the total IP-Layer Capacity includes some of both traffic types.	

How would we treat such Internet access service specifications/policies when
the goal is to measure the Maximum IP-Layer Capacity?

We could scan for such dependencies and report them, or consult the Service 
agreement for policies that might indicate multiple flows are needed. The 
authors have not encountered much of this; only one policy instance in practice.

It seems prudent to add a third item to the list at the end of Section 8.3 
to add reason where multiple flows may be needed, something like:

  3. access policies may limit the IP-Layer Capacity depending on the Type-P
     of packets, possibly reserving capacity for various stream types.

Do others have opinions on how prevalent these unusual policies are, or will be, 
and ideas on how to handle this point in the WG draft?

Thanks for reading/thinking about it,
Al