Subject: Re: [ippm] Fwd: New Version Notification for draft-morton-ippm-twamp-rate-02.txt

From: Christofer Flinta <[email-masked]>
Date: Thu, 24 Jan 2013 10:12:01 +0000

Hi Al, IPPM group,

I have some comments on draft-morton-ippm-twamp-rate-02.

As I understand it, the proposed protocol enables sending bursts of test packets back-to-back in the forward or reverse direction. From the collected time stamps in each receiving node the packet delivery rate for each burst can be calculated, and this delivery rate may be used as an estimate of the peak throughput for the path. However, while peak throughput is an important measure, I think a general rate measurement protocol should also enable measuring of Available Path Capacity (APC) as defined in RFC 5136. In case of a network with user traffic present (In-Service testing), peak throughput > APC, which means that the delivery rate of a burst of back-to-back packets cannot directly be used as an estimate of APC. Only if the network path is empty of cross traffic (Out-of-Service testing) peak throughput = APC, which means that delivery rate can be used as an APC estimate.

In order to estimate APC in a general case (both for In-Service testing and Out-of-Service testing) each measurement node must be able to send trains with different rates during a session. APC can then be estimated by comparing the receive rates with the send rates, according to some scheme. I think this requirement is in line with the proposed requirement of a test protocol in draft-ietf-ippm-rate-problem-01: "The test protocol SHALL support test packet ensemble generation (category 3) ...", where  Category 3 is describes as: " One or more packet ensembles in a test stream, using a fixed ensemble size in packets and one or more fixed intra-ensemble packet spacings (including zero spacing)."

To meet this requirement, I propose two small changes to draft-morton-ippm-twamp-rate-02:

1) Measuring APC in forward direction.
The only change needed is to relax the requirement on the sending of packets in 5.1.1 to allow packets to be sent with any packet interval in a burst.

2) Measuring APC in reverse direction.
The Session-Sender needs to inform the Session-Reflector of the desired send rate for each generated burst. The simplest way to do this is to convert the desired send rate to a desired packet interval in NTP format, valid for all packets in the burst, and send that value in the Burst Initiation Packet. The Timestamp field is not used by the reflector and not reflected back in Burst Generation mode and can therefore be reused as a new field, e.g. called Desired Packet Interval. This packet interval should be used by the reflector as a waiting time for each packet in the generated burst, except for the first packet in the burst, which should be sent as quickly as possible.

I believe these changes may strengthen the draft.

Best regards
Christofer Flinta
Ericsson Research

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Al Morton
Sent: den 3 september 2012 15:57
To: [email-masked]
Subject: [ippm] Fwd: New Version Notification for draft-morton-ippm-twamp-rate-02.txt

IPPM,

We've updated this draft to coordinate with the problem statement as it now stands.

Al and Len

>A new version of I-D, draft-morton-ippm-twamp-rate-02.txt
>has been successfully submitted and posted to the IETF repository.
>
>Filename:       draft-morton-ippm-twamp-rate
>Revision:       02
>Title:          TWAMP Burst Rate Measurement Features
>Creation date:  2012-09-03
>WG ID:          Individual Submission
>Number of pages: 19
>URL: 
>http://www.ietf.org/internet-drafts/draft-morton-ippm-twamp-rate-02.txt
>Status:          http://datatracker.ietf.org/doc/draft-morton-ippm-twamp-rate
>Htmlized:        http://tools.ietf.org/html/draft-morton-ippm-twamp-rate-02
>Diff: 
>http://www.ietf.org/rfcdiff?url2=draft-morton-ippm-twamp-rate-02
>
>Abstract:
>    This memo describes two rate-measurement features for the core
>    specification of TWAMP - the Two-Way Active Measurement Protocol: an
>    optional capability where the reflector host responds with a
>    controlled burst of test-session packets (instead of a single
>    packet), and an optional test mode that requires the responder to
>    measure a burst of test packets and communicate the results in
>    truncated packet(s).  Both features add the ability to control packet
>    size in the tested direction, enabling asymmetrical packet size
>    testing.  There is an open question on using TCP transport instead of
>    UDP.
>
>
> 
>
>
>
>The IETF Secretariat

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

---

From: "MORTON JR., ALFRED (AL)" <[email-masked]>
Date: Thu, 24 Jan 2013 18:26:31 -0500

Hi Christofer,

I think it's worth considering the addition of inter-ensemble packet 
spacing. It's clear that many past capacity measurement experiments have
used this technique. But it's probably worth hearing from folks about
their current experiments, too.  For example:

You mentioned that bursts can be used to estimate the peak throughput,
and Available Path Capacity is also needed, and unless there is no user
traffic, peak > available. I think there are cases where burst and 
fixed rate ensembles measure the same quantity, but they have different
methodological constraints (you can't send bursts greater than the 
bottleneck buffer capacity, and while you can send very long ensembles of
fixed rate packets you would be averaging the rate measurement over 
a long time scale, too, and you may end up measuring different values
because of the different time-scales). 

Most of the Internet access rate studies conducted in the last few years
have been designed to avoid times when the customers who host the measurement
device are not sending competing traffic. Thus the emphasis is to assess
the apparent peak rate (for a typical subscriber's segment of the path), further 
limited by any other bottlenecks with traffic from other subscribers,
sort of an available capacity for the rest of the path. Strictly speaking,
the rate being measured doesn't have a parallel in RFC 5136 (for this and 
other reasons), and that may mean we have more RFCs to write.

It's probably worth examining the requirements to "correctly" generate
fixed rate packet ensembles, when the hardware doing the generation and/or
measurement was designed for low-cost-large-scale deployment for a purpose
other than measurement. Most of us are thinking "LMAP" these days.

In any case, the current TWAMP draft is compliant with the rate-problem draft
requirement as stated, because "one or more" spacings includes zero spacing.

I hope other knowledgeable folks will chime in, too.

Al

> From: Christofer Flinta [mailto:[email-masked]]
> Sent: Thursday, January 24, 2013 5:12 AM
> To: MORTON JR., ALFRED (AL); [email-masked]
> Subject: RE: [ippm] Fwd: New Version Notification for draft-morton-ippm-
> twamp-rate-02.txt
> 
> Hi Al, IPPM group,
> 
> As I understand it, the proposed protocol enables sending bursts of test
> packets back-to-back in the forward or reverse direction. From the
> collected time stamps in each receiving node the packet delivery rate for
> each burst can be calculated, and this delivery rate may be used as an
> estimate of the peak throughput for the path. However, while peak
> throughput is an important measure, I think a general rate measurement
> protocol should also enable measuring of Available Path Capacity (APC) as
> defined in RFC 5136. In case of a network with user traffic present (In-
> Service testing), peak throughput > APC, which means that the delivery
> rate of a burst of back-to-back packets cannot directly be used as an
> estimate of APC. Only if the network path is empty of cross traffic (Out-
> of-Service testing) peak throughput = APC, which means that delivery rate
> can be used as an APC estimate.
> 
> In order to estimate APC in a general case (both for In-Service testing
> and Out-of-Service testing) each measurement node must be able to send
> trains with different rates during a session. APC can then be estimated by
> comparing the receive rates with the send rates, according to some scheme.
> I think this requirement is in line with the proposed requirement of a
> test protocol in draft-ietf-ippm-rate-problem-01: "The test protocol SHALL
> support test packet ensemble generation (category 3) ...", where  Category
> 3 is describes as: " One or more packet ensembles in a test stream, using
> a fixed ensemble size in packets and one or more fixed intra-ensemble
> packet spacings (including zero spacing)."
> 
> The only change needed is to relax the requirement on the sending of
> packets in 5.1.1 to allow packets to be sent with any packet interval in a
> burst.
> 
> The Session-Sender needs to inform the Session-Reflector of the desired
> send rate for each generated burst. The simplest way to do this is to
> convert the desired send rate to a desired packet interval in NTP format,
> valid for all packets in the burst, and send that value in the Burst
> Initiation Packet. The Timestamp field is not used by the reflector and
> not reflected back in Burst Generation mode and can therefore be reused as
> a new field, e.g. called Desired Packet Interval. This packet interval
> should be used by the reflector as a waiting time for each packet in the
> generated burst, except for the first packet in the burst, which should be
> sent as quickly as possible.
>

---

From: sab <[email-masked]>
Date: Sun, 27 Jan 2013 10:32:44 -0800 (PST)

Hi Al
I agree with the changes proposed by Christofer. They will improve the
protocol and its usability.

Measuring the available path capacity may not be important to end users but
it is definitively an important metric for the operators especially when it
is measured 24/7. 

As I indicated in the Quebec meeting, the protocol should be flexible enough
to accomodate any spacing between test packets in a burst in both forward
and reverse directions. We should not worry about cost here. It is up to the
implementer to decide the appropriate spacing and the balance between
benefits and costs.

I don't think we need to worry about LMAP as well. LMAP has it is own set of
objectives.  As far as I know, we started the rate discussion much before
LMAP and the TWAMP protocol should not ignore this use case.

Regards
Steve Baillargeon

--
View this message in context: http://ietf.10.n7.nabble.com/Fwd-New-Version-Notification-for-draft-morton-ippm-twamp-rate-02-txt-tp250601p354625.html
Sent from the IETF - ippm mailing list archive at Nabble.com.

---

From: Ionta Tiziano <[email-masked]>
Date: Wed, 30 Jan 2013 15:17:48 +0100

Hi all,
I would like to know if there any compatibility between Cisco IPSLA and Juniper RPM. Can they interact somehow?
Thanks.
Tiziano Ionta

-----Messaggio originale-----
Da: [email-masked] [mailto:[email-masked]] Per conto di sab
Inviato: domenica 27 gennaio 2013 19.33
A: [email-masked]
Oggetto: Re: [ippm] Fwd: New Version Notification for draft-morton-ippm-twamp-rate-02.txt

Hi Al

Regards
Steve Baillargeon

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.