Performance Measurement with Asymmetrical Traffic Using Simple Two-Way Active Measurement Protocol (STAMP)
draft-ietf-ippm-asymmetrical-pkts-14

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: The IESG <iesg@ietf.org>, draft-ietf-ippm-asymmetrical-pkts@ietf.org, ippm-chairs@ietf.org, ippm@ietf.org, marcus.ihlar@ericsson.com, mohamed.boucadair@orange.com, rfc-editor@rfc-editor.org
Subject: Protocol Action: 'Performance Measurement with Asymmetrical Traffic Using Simple Two-Way Active Measurement Protocol (STAMP)' to Proposed Standard (draft-ietf-ippm-asymmetrical-pkts-14.txt)

The IESG has approved the following document:
- 'Performance Measurement with Asymmetrical Traffic Using Simple Two-Way
   Active Measurement Protocol (STAMP)'
  (draft-ietf-ippm-asymmetrical-pkts-14.txt) as Proposed Standard

This document is the product of the IP Performance Measurement Working Group.

The IESG contact persons are Mahesh Jethanandani and Mohamed Boucadair.

A URL of this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-ippm-asymmetrical-pkts/

Ballot Text

Technical Summary

   This document defines an optional STAMP extension that allows a
   Session-Reflector to send packets whose length or quantity differs
   from those sent by the Session-Sender.  While standard STAMP
   exchanges packets symmetrically, some measurement scenarios benefit
   from asymmetric response packets to better reflect real application
   conditions.  This extension enables the Session-Reflector to send
   packets of different sizes and/or additional packets not tied one-
   for-one to incoming test packets.  The document also analyzes
   challenges in multicast performance monitoring and specifies STAMP
   procedures to improve measurement efficiency and reduce network
   impact.

Working Group Summary

   There is one implementation indicated in the "Additional Resources"
   section of the datatracker page.

Personnel

   The Document Shepherd for this document is Marcus Ihlar.
   The Responsible Area Director is Mohamed Boucadair.

RFC Editor Note