Subject: [ippm] Review of draft-ietf-ippm-rate-problem-04

From: Barry Constantine <[email-masked]>
Date: Mon, 2 Dec 2013 14:27:21 +0000

Hi IPPM,

As agreed in VC, I reviewed this work and have the following comments.

First off, it is a very good draft and does a good job of explaining the nature of the problem, while providing some context to high level measurement method requirements.

So here are some specific suggestions:

Section 2:

-        Extremely large scale of access services requires low complexity

devices participating at the user end of the path.

** I was not sure how this was a different scenario from an access network perspective, probably needs another sentence or two to explain.

Other use cases for rate measurement involve situations where the packet switching and transport facilities are leased by one operator
from another and the link capacity available cannot be directly determined (e.g., from device interface utilization).  These
scenarios could include mobile backhaul, Ethernet Service access networks, and/or extensions of layer 2 or layer 3 networks.

** This is really important and in these cases, operators are specifying burst sizes in addition to CIR.  I think the rate measurement problem statement should identify  burst testing as part of the problem since this is more and more being added into the SLA (especially between providers, not so much for business services yet)

As noted in [RFC2330] the actual traffic handling may influence the rate measurement results for some forms of access

** Maybe a nit, but would it be better to say "traffic management" verus "traffic handling"?  Also, does this imply more broadly that QoS policy is applied to the user traffic per the examples listed (packet length, IP addresses, etc)?  If so, I would include DSCP in the list of examples since this is widely used and understood.

Opportunistic In-Service testing when there is no user traffic present throughout the test interval is essentially equivalent to Out-of-Service testing.

** Suggest:  Opportunistic In-Service testing when there is no user traffic present throughout (i.e. after normal business hours)

Section 3:
REPORTER:
Use information from test packets and local processes to measure delivered packet rates, and prepare results in the required format.

** Should a sentence or two be added to clarify that the REPORTER  may be a separate test entity or may be embedded into the SENDER for example?

Section 4:
For all categories, the test protocol MUST support:

d.  Choice of UDP transport and variable port numbers, OR, choice of
       TCP transport and variable port numbers for two-way architectures
       only, OR BOTH.

**  This implies TCP "stateless" traffic per Mathis's model-based work, right?

e.  Variable number of packets-pairs, ensembles, or streams used in a test session

** This should include VLAN or MPLS tagging, right?

Thank you,
Barry Constantine

JDSU Network and Service Enablement
Principal Member Technical Staff
301-325-7069

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Thu, 12 Dec 2013 10:50:13 -0500

Hi Barry, thanks for your comments and suggestions.

I have uploaded version 05 which addresses your comments.
(the announcement seems to be delayed, but I assure you that
submission was successful)

In one case, you said:

I'm sure you read later on (section 4) that burst generation is mandatory,
and we can describe the various methods in more detail when we move beyond the
scope, so that's what is done.

regards,
Al

From: ippm [mailto:[email-masked]] On Behalf Of Barry Constantine
Sent: Monday, December 02, 2013 9:27 AM
To: [email-masked]
Subject: [ippm] Review of draft-ietf-ippm-rate-problem-04

Hi IPPM,

Section 2:

Section 3:
REPORTER:

Section 4:

Thank you,
Barry Constantine