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

Hi
As indicated in the meeting #80, we think the TWAMP value-added octets draft is designed to accommodate all (or almost all) "capacity test measurements" in the context of TWAMP.

The benefits are:

- can be used for intrusive or non-intrusive capacity tests e.g. the size of the train and/or inter-packet interval will determine if a packet stream is considered intrusive or not for a given network environment in a given direction.
- can also be used for measuring other metrics

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. This would enable the following "new use cases":

- 1) a "non-intrusive" capacity test in the forward direction with an "intrusive" capacity test in the reverse direction via a larger train size. However this use case can also be achieved with the current draft using the configuration of the appropriate train size at the source, a "slow" inter-packet interval in the forward direction and an "intrusive" inter-packet interval in the reverse direction.
- 2) an "intrusive" capacity test in the forward direction with an "intrusive" capacity test in the reverse direction where packets that are lost in the forward direction are "re-generated". 

This can achieved by introducing a new field called "Tran Size" or "Reverse Train Size" with its corresponding flag bit.

The use of such new field will introduce significant changes to the Session-Reflector and the reporting of the metrics. For instance:

- If the reverse train size is smaller than the "forward train size", the Session-Reflector will need to "create" loss in the "reverse direction" and one must be careful to avoid reporting the one-way packet loss in the reverse direction or must account for it. This scenario may also skew the capacity estimates for the forward direction if the train size is to small.
- If the reverse train size is larger than the "forward train size" or if packet loss has occurred in the forward direction, what will be the values of the Receive Timestamp, Sender Sequence Number, Sender Timestamp, Sender Error Estimate? I am assuming they can all be set to zero except the error estimate.

I am open to add/explore such new fields and new behaviors on top of the proposed TWAMP Value-Added Octets Version 1 mode. On the other hand, we should carefully evaluate if it is best to keep the essence of current TWAMP Value-Added Octets Version 1 mode which attempts to minimize changes to the Session-Reflector behaviors versus RFC5357. In my opinion, it will be best to avoid adding more complexity to the current draft.

-Steve

-----Original Message-----
From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of Al Morton
Sent: April-07-11 8:32 AM
To: Henk Uijterwaal; ippm@ietf.org
Subject: Re: [ippm] draft-baillargeon-ippm-twamp-value-added-octets

At 04:15 AM 4/7/2011, Henk Uijterwaal wrote:
>...
>
>There are more ideas in this direction, including work presented by 
>Yaakov in Prague.  I think it'd be good if the next iteration of the 
>draft tried to combine all ideas.

...or at least, the ideas that make sense to be combined.

I thought this was the next step we agreed at the meeting (then ask about adoption once the work was organized into chunks), It can still be worked this way, but on a schedule longer than 2 weeks.

Al

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