Re: [ippm] draft-baillargeon-ippm-twamp-value-added-octets

Steve Baillargeon <steve.baillargeon@ericsson.com> Thu, 07 April 2011 19:24 UTC

Return-Path: <steve.baillargeon@ericsson.com>
X-Original-To: ippm@core3.amsl.com
Delivered-To: ippm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 661D528C0E5 for <ippm@core3.amsl.com>; Thu, 7 Apr 2011 12:24:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.789
X-Spam-Level:
X-Spam-Status: No, score=-5.789 tagged_above=-999 required=5 tests=[AWL=0.810, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aq9pkTSLZju9 for <ippm@core3.amsl.com>; Thu, 7 Apr 2011 12:24:48 -0700 (PDT)
Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 635F33A690A for <ippm@ietf.org>; Thu, 7 Apr 2011 12:24:48 -0700 (PDT)
Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p37JQVnA028699; Thu, 7 Apr 2011 14:26:32 -0500
Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.141]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Thu, 7 Apr 2011 15:26:25 -0400
From: Steve Baillargeon <steve.baillargeon@ericsson.com>
To: Al Morton <acmorton@att.com>, "ippm@ietf.org" <ippm@ietf.org>
Date: Thu, 07 Apr 2011 15:26:25 -0400
Thread-Topic: [ippm] draft-baillargeon-ippm-twamp-value-added-octets
Thread-Index: Acv1Uu4UeQSuJDqVTO6+3/7a6h+A2AABGD6g
Message-ID: <4383945B8C24AA4FBC33555BB7B829EF0DEC351CB2@EUSAACMS0701.eamcs.ericsson.se>
References: <4383945B8C24AA4FBC33555BB7B829EF0DEC351277@EUSAACMS0701.eamcs.ericsson.se> <4D9D7225.6080506@uijterwaal.nl> <4D9D728F.8040402@uijterwaal.nl> <201104071231.p37CVbar009830@alpd052.aldc.att.com> <4383945B8C24AA4FBC33555BB7B829EF0DEC351A34@EUSAACMS0701.eamcs.ericsson.se> <201104071837.p37Ibhke018202@alpd052.aldc.att.com>
In-Reply-To: <201104071837.p37Ibhke018202@alpd052.aldc.att.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [ippm] draft-baillargeon-ippm-twamp-value-added-octets
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ippm>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Apr 2011 19:24:49 -0000

Hi Al
I was referring to the train size, not the packet size.
All test packets using the value-added octets (forward and reverse test packets) belonging to a specific test session MUST have the same IP packet size. This indicated in the draft as well. 
We are not recommending to change the requirement on the packet size because it will make reporting and capacity measurements very difficult to do. If a different packet size is needed, a new/different test session SHALL be established.

-Steve

-----Original Message-----
From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of Al Morton
Sent: April-07-11 2:38 PM
To: ippm@ietf.org
Subject: Re: [ippm] draft-baillargeon-ippm-twamp-value-added-octets

At 10:53 AM 4/7/2011, Steve Baillargeon wrote:
>...One aspect we discussed briefly is the possibility to add a new 
>field in the TWAMP value-added padding octets that will allow for a 
>different train size in the reverse direction.

Well, this separate proposal was to allow different test packet sizes to be used in the forward and reverse directions, that's right.

But the session request would convey this information in a new Request-TW-Session command, since it would likely be static for the entire session. This is the more usual way to operate TWAMP:
telling the Server/Session-Reflector everything needed in advance of Starting the test session.

It's good that the value-added-octets proposal incorporates the TWAMP-Control protocol in the latest version (01).

So now, I wonder if the *many* new test session packet formats found in the value-added-octets proposal could be simplified by moving some information currently conveyed in the Test session (via flags/fields) to the Control session?  In other words, this proposal asks the Session-Reflector to perform many new operations, and perhaps adoption will be wider if less processing is expected during the test session. Of course, Request-TW-Session variables are static for the life of the test session, if accepted.

regards,
Al

_______________________________________________
ippm mailing list
ippm@ietf.org
https://www.ietf.org/mailman/listinfo/ippm