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

From: Steve Baillargeon <[email-masked]>
Date: Wed, 6 Mar 2013 18:15:18 +0000

Hi Al
Do you have any problems with your email server (if you can get this message)?
I got the following message: Delivery is delayed to [email-masked] . Subject: RE: [ippm] I-D Action: draft-ietf-ippm-rate-problem-02.txt. This message hasn't been delivered yet. Delivery will continue to be attempted.

See comments below.

-Steve

-----Original Message-----
From: Steve Baillargeon 
Sent: March-06-13 9:08 AM
To: 'MORTON JR., ALFRED (AL)'
Cc: [email-masked]
Subject: RE: [ippm] I-D Action: draft-ietf-ippm-rate-problem-02.txt

Hi Al
I am resending with the correct draft name! I also added one more comment and put them in chronological order.

Here are my comments about draft-morton-ippm-twamp-rate-problem-02.txt.

-  Section 3) You indicate the two-way measurement architecture is favored and I agree. You also indicate that each direction of transmission must be evaluated separately and I agree. However this paragraph does not clarify the meaning of test streams vs test sessions. If you imply that each test stream requires its own test session, then I don't agree this is a good architectural decision since in many access networks following a hub-and-spoke topology, I expect the spoke to be the low complexity device (as you have indicated) and the hub to be the controller where the test sessions are configured, activated/deactivated and where data is probably collected. With In-Service testing including 24/7 monitoring, one challenge is the number of concurrent test sessions supported at the hub/controller. It is often the limiting factor for scaling the measurement system. Therefore it is desirable to include the case where a single test session (e.g. TWAMP) can measure both the forward and reverse rates for a given Type-P packet. If you don't, you could end-up with twice as many test sessions than actually needed. 

- Section 4) You are missing variable intra-packet spacing in the pair, ensemble or train where you are listing the MUST for the test protocol.

- Section 5)  I would like to see a requirement on the test protocol for the two-way architecture where it can measure the rate in a specific transmission direction using a single Type-P test session where the test session has its own test data stream and also measure rates in both forward and reverse transmission directions using a single Type-P test session where the forward direction data stream is also used to measure the reverse direction rate.

-  Section 5) Why is it so important to specify ALL variables to the Receiver in the one-way architecture. As far as I know it is possible today to measure rate in a given direction with the existing OWAMP protocol without any changes to it.

Regards
Steve B

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: February-01-13 5:02 PM
To: [email-masked]
Cc: [email-masked]
Subject: [ippm] I-D Action: draft-ietf-ippm-rate-problem-02.txt

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(s)       : Al Morton
	Filename        : draft-ietf-ippm-rate-problem-02.txt
	Pages           : 11
	Date            : 2013-02-01

Abstract:
   There is a rate measurement scenario which has wide-spread attention
   of Internet access subscribers and seemingly all industry players,
   including regulators.  This memo presents an access rate-measurement
   problem statement for test protocols to measure IP Performance
   Metrics.  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-02

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

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

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