Subject: [ippm] I-D Action: draft-ietf-ippm-rate-problem-07.txt

From: [email-masked]
Date: Tue, 07 Oct 2014 08:28:27 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the IP Performance Metrics Working Group of the IETF.

        Title           : Rate Measurement Test Protocol Problem Statement
        Author          : Al Morton
	Filename        : draft-ietf-ippm-rate-problem-07.txt
	Pages           : 12
	Date            : 2014-10-07

Abstract:
   This memo presents an access rate-measurement problem statement for
   test protocols to measure IP Performance Metrics.  The rate
   measurement scenario has wide-spread attention of Internet access
   subscribers and seemingly all industry players, including regulators.
   Key test protocol aspects require the ability to control packet size
   on the tested path and enable asymmetrical packet size testing in a
   controller-responder architecture.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ippm-rate-problem/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-ippm-rate-problem-07

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-rate-problem-07

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Bill Cerveny <[email-masked]>
Date: Wed, 22 Oct 2014 12:05:51 -0400

draft-ietf-ippm-rate-problem has been updated with changes requested by IPPM participants. As such, I am kicking off a WGLC for draft-ietf-ippm-rate-problem-07 until November 5, 2014. Please provide comments before the WGLC ends.

Thanks,

Bill Cerveny
IPPM WG co-chair

Begin forwarded message:

> From: [email-masked]
> Subject: [ippm] I-D Action: draft-ietf-ippm-rate-problem-07.txt
> Date: October 7, 2014 at 11:28:27 AM EDT
> To: [email-masked]
> Cc: [email-masked]
> 
> 
> _______________________________________________
> ippm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ippm

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 22 Oct 2014 16:50:20 -0700

Dear Authors, et. al,
please find my WG LC comments below:

   - Abstract.

I believe that in our meeting in Toronto the WG agreed that support of
asymmetrical test packet rate is required and support of asymmetrical
packet size is recommended. Thus I propose following text update.

Key test protocol aspects require the ability to control test packet
characteristics on the tested path and enable asymmetrical test flow
rates in controller-responder architecture.

   - Requirements Language

Because this document is on Informational track, normative language of RFC
2119 not usually used. Use of defined RFC 2119 language may be explained by
the following:

   Although this document is not a protocol specification, the use of
this language clarifies the instructions to protocol designers
   producing solutions that satisfy the requirements set out in this document.

   - Section 2. Purpose and Scope

As the WG agrees that the problem is asymmetric rate I propose to add to
the list on p.3 'intra-pair spacing' and 'inter-pair interval' that both
are referenced in Section 4.

   - Section 3. Active Rate Measurement

P.5, second paragraph s/a it may be possible/it may be possible/
Not clear the intended role of asterics, double and single, in the text.
Are these quotations?

   - Section 5. Test Protocol Control & Generation Requirements

As the WG agreed that asymmetric test packet flow may be created by
variating not just packet size but intra-pair spacing and/or inter-pair
interval, requirement #4 is not generic but presents only one possible
solution. I propose change requirement #4 to:
4. Asymmetric packet flows in a two-way measurement architecture

I didn't find the reference to the definition or the definition of
'pseudo-one-way test' in the document and thus I propose the requirement to
avoid the term.

The next to last paragraph suggests:

 Implementations may support control and generation for only symmetric
packet sizes when none of the above conditions hold.

That contradicts earlier explanation that mentions variation of intra-pair
spacing and inter-pair interval as possible method to generate asymmetric
flow of test packets. Thus a protocol that can control spacing and/or
intervals would be suitable to any combination of 1, 3, 4 and 6.

Regards,
Greg

On Wed, Oct 22, 2014 at 9:05 AM, Bill Cerveny <[email-masked]> wrote:

> draft-ietf-ippm-rate-problem has been updated with changes requested by
> IPPM participants. As such, I am kicking off a WGLC
> for draft-ietf-ippm-rate-problem-07 until November 5, 2014. Please provide
> comments before the WGLC ends.
>
> Thanks,
>
> Bill Cerveny
> IPPM WG co-chair
>
> Begin forwarded message:
>
> *From: [email-masked]
> *Subject: **[ippm] I-D Action: draft-ietf-ippm-rate-problem-07.txt*
> *Date: *October 7, 2014 at 11:28:27 AM EDT
> *To: [email-masked]
> *Cc: [email-masked]
>
>

---

From: Andreas Johnsson A <[email-masked]>
Date: Wed, 29 Oct 2014 09:55:38 +0000

Hi,
I reviewed the document and have three main comments that I feel must be considered. Two are related to Section 5 while the third is related to Section 2.

Comment 1

In general I think that Section 5 is very confusing. Especially considering that the group agreed on that asymmetric packet size testing should be a RECOMMENDED feature in this draft. I'll give a few examples from this paragraph that creates this confusion.

In the beginning of Section 5 it is stated that

Essentially, the test protocol MUST support the measurement features
   described in the sections above.  This requires:

   1.  Communicating all test variables to the SENDER and RECEIVER

   2.  Results collection in a one-way architecture

   3.  Remote device control for both one-way and two-way architectures

   4.  Asymmetric packet size and/or pseudo-one-way test capability in a
       two-way measurement architecture (along with symmetric packet
       size tests in common use)

Bullet 4 says that a test protocol MUST be able to control asymmetric packet sizes and/or pseudo-one-way test capabilities. Since pseudo-one-way test capabilities are not defined in the document this becomes contradictory to the next paragraph

The ability to control and generate asymmetric rates in a two-way
   architecture is REQUIRED.  Two-way architectures are RECOMMENDED to
   include control and generation capability for both asymmetric and
   symmetric packet sizes, because packet size often matters in the
   scope of this problem and test systems SHOULD be equipped to detect
   directional size dependency through comparative measurements.
where it is stated that two-way architectures are RECOMMENDED to include asymmetric packet size testing features.

So, either the draft must define pseudo-one-way testing or change the MUST to RECOMMENDED.

Comment 2

A set of conditions arguing for asymmetric packet size testing are described in Section 5. I think that it is only the condition describing the MTU - ACK streams that really requires asymmetric packet size testing. The other conditions can be dealt with using "pseudo-one-way testing" (assuming it is defined as creating two TWAMP sessions with two different packet sizes).

Therefor I think that the 2nd to last paragraph

should be removed. Also I think that the draft should state that the conditions can be solved either with asymmetrical packet size testing features or with a pseudo-one-way testing feature (if defined).

Comment 3

I strongly believe that the first paragraph of section 2 should mention RFC 6802 as a test protocol tool. This protocol is the first IETF protocol specifically designed for rate and capacity measurements.

Best regards,
Andreas Johnsson

From: ippm [mailto:[email-masked]] On Behalf Of Bill Cerveny
Sent: den 22 oktober 2014 18:06
To: [email-masked]
Subject: [ippm] WGLC on draft-ietf-ippm-rate-problem-07.txt

Thanks,

Bill Cerveny
IPPM WG co-chair

Begin forwarded message:

From: [email-masked]<mailto:[email-masked]>
Subject: [ippm] I-D Action: draft-ietf-ippm-rate-problem-07.txt
Date: October 7, 2014 at 11:28:27 AM EDT
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>

Abstract:

_______________________________________________
ippm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ippm

---

From: Christofer Flinta <[email-masked]>
Date: Wed, 29 Oct 2014 17:33:24 +0000

Hi,

I have reviewed the draft and I have two comments.

Comment 1.
I think the concept "stream" should be defined.
Its use in the text suggests that it is the same thing as a session, but in Section 4 the following statement is then confusing:

"e.  Variable number of packets-pairs, ensembles, or streams used in a
       test session."
Is the intention to enable several intermixed streams from the Sender to the Receiver within the same session? In that case the session set-up may be very complex, since a control protocol needs to specify all parameters for several streams within a session. IMO a better option is to set up several parallel sessions between the Sender and the Receiver if different profiles are needed. I think this must be sorted out.

Comment 2.
Section 5, bullet 4:
"4.  Asymmetric packet size and/or pseudo-one-way test capability in a
       two-way measurement architecture (along with symmetric packet
       size tests in common use)"
I am not sure this draft should specify the details of the protocol to be used for rate measurements, e.g. the use of packet size. It should rather be a general specification for any type of two-way protocol - in the future not necessarily based on TWAMP. As we know, there are many possibilities for implementing rate measurements in different directions, including sending packets with asymmetric size, sending trigger packets for trains in reverse direction and buffering trains in the Receiver. I don't think we should restrict ourselves to any of these methods in the draft, but let the implementers be able to choose from different alternatives depending on the needs. Therefore I suggest to replace bullet 4 with a general requirement about how the control protocol sets up the rate measurement sessions:

"4. The ability for the control protocol to set up rate measurements in both directions of a session in a two-way measurement architecture. The rate measurements can be set up separately for each direction (measuring forward direction only or reverse direction only during a session) or in parallel (measuring both forward and reverse direction during the same session)."

Best regards,
Christofer Flinta

Thanks,

Bill Cerveny
IPPM WG co-chair

Begin forwarded message:

Abstract: