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

From: Steve Baillargeon <[email-masked]>
Date: Wed, 6 Apr 2011 09:43:13 -0400

Hi
Can I ask the chairs to determine if there is interest to adopt the Value-Added Octets draft as a WG document?

Thank you

-Steve

---

From: Henk Uijterwaal <[email-masked]>
Date: Thu, 07 Apr 2011 10:13:25 +0200

IPPM group,

In Prague, Steve and colleagues presented
draft-baillargeon-ippm-twamp-value-added-octets and asked if this can become a
WG document.  If you support
this idea or disagree with it, please speak up on the list before April 21.

Henk (as WG chair)

-- 
------------------------------------------------------------------------------
Henk Uijterwaal                           Email: henk(at)uijterwaal.nl
RIPE NCC                                  http://www.xs4all.nl/~henku
                                          Phone: +31.6.55861746
------------------------------------------------------------------------------

There appears to have been a collective retreat from reality that day.
                                 (John Glanfield, on an engineering project)

---

From: Henk Uijterwaal <[email-masked]>
Date: Thu, 07 Apr 2011 10:15:11 +0200

> this idea or disagree with it, please speak up on the list before April 21.

And as a participant: I support this document becoming a WG document.

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.

Henk (as a WG participant)

---

From: Barry Constantine <[email-masked]>
Date: Thu, 7 Apr 2011 04:27:41 -0700

I support this draft work, plan to review it as it moves along.

-Barry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Henk Uijterwaal
Sent: Thursday, April 07, 2011 4:13 AM
To: [email-masked]
Subject: [ippm] draft-baillargeon-ippm-twamp-value-added-octets

IPPM group,

Henk (as WG chair)

There appears to have been a collective retreat from reality that day.
                                 (John Glanfield, on an engineering project)
_______________________________________________
ippm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ippm

---

From: Al Morton <[email-masked]>
Date: Thu, 07 Apr 2011 08:32:17 -0400

At 04:15 AM 4/7/2011, Henk Uijterwaal wrote:
>...

...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

---

From: Steve Baillargeon <[email-masked]>
Date: Thu, 7 Apr 2011 10:53:37 -0400

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: [email-masked] [mailto:[email-masked]] On Behalf Of Al Morton
Sent: April-07-11 8:32 AM
To: Henk Uijterwaal; [email-masked]
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.

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

---

From: Al Morton <[email-masked]>
Date: Thu, 07 Apr 2011 14:38:22 -0400

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

---

From: Steve Baillargeon <[email-masked]>
Date: Thu, 7 Apr 2011 15:26:25 -0400

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: [email-masked] [mailto:[email-masked]] On Behalf Of Al Morton
Sent: April-07-11 2:38 PM
To: [email-masked]
Subject: Re: [ippm] draft-baillargeon-ippm-twamp-value-added-octets

>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

---

From: Al Morton <[email-masked]>
Date: Thu, 07 Apr 2011 15:58:26 -0400

Ok, I thought you were referring to other proposals which
were discussed, and the suggestion of combining what makes sense,
but apparently not.

My comment below on the tendency toward placing Control in
the Test Session in this proposal is still worth a look, I think.

Al

At 03:26 PM 4/7/2011, Steve Baillargeon wrote:
>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
>
>Well, this separate proposal was to allow different test packet 
>sizes to be used in the forward and reverse directions, that's right.
>
>Request-TW-Session command, since it would likely be static for the 
>entire session. This is the more usual way to operate TWAMP:
>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
>

---

From: Steve Baillargeon <[email-masked]>
Date: Thu, 7 Apr 2011 17:10:05 -0400

Hi Al
I don't see much values to add the proposed fields in the TWAMP control protocol because they are specifically applicable to the handling of the test packets.

For instance, carrying the Last SeqNo in the Train in the control protocol is not useful since it may/will change on a per test packet basis. Same thing for the Desired Reverse Packet Interval.

Carrying the Sender Discriminator field in the TWAMP control protocol is a possibility via a new definition of the Type-P descriptor for instance (e.g. first two bits is 02 followed by SD). 	It will bring some benefits to the solution but will not necessarily reduce complexity on the Session-Reflector. With or without the SD, the Session-Reflector (in most cases) needs to continue inspecting various fields on a per test packet basis in order to match the packets to the correct session.

The flags are proposed in the test session in order to avoid creating/allocating a large number of TWAMP modes with a large number of corresponding "fixed" test packet formats. Our proposal is to use a single mode that has a single "variable" test packet format that is easy to parse through. On the contrary, it helps reduce complexity for products supporting TWAMP. The other option to completely remove the flags but this will remove the flexibility to use the format for other purposes and re-open the case for creating a larger number of modes and packet formats in the future.

-Steve  

-----Original Message-----
From: Al Morton [mailto:[email-masked]] 
Sent: April-07-11 3:58 PM
To: Steve Baillargeon; [email-masked]
Subject: Re: [ippm] draft-baillargeon-ippm-twamp-value-added-octets

Ok, I thought you were referring to other proposals which were discussed, and the suggestion of combining what makes sense, but apparently not.

My comment below on the tendency toward placing Control in the Test Session in this proposal is still worth a look, I think.

Al

At 03:26 PM 4/7/2011, Steve Baillargeon wrote:
>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.
>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
>
>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
>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
>

---

From: Al Morton <[email-masked]>
Date: Thu, 07 Apr 2011 20:15:42 -0400

Steve,

It seems that we're not on the same page here,
so I won't pick-apart what you said...

 From my POV, the Session-Reflector needs to be the most efficient process
in the system. So, I don't understand sparing the non-real-time
Control process from complexity, while adding much more complexity
(including the ability to revise the task on a dynamic basis)
to the real-time process of Reflector. I'm not sure you need a lot of
Mode code points to move functions to Control, either, because it seems
that a new Request-TW-Session command could convey most of the info in new
fields for static test sessions (instead of last sequence number in a train,
use constant train length in packets, and similar substitutions).

It's an opinion on an option, FWIW.
Al

At 05:10 PM 4/7/2011, Steve Baillargeon wrote:
>Hi Al
>I don't see much values to add the proposed fields in the TWAMP 
>control protocol because they are specifically applicable to the 
>handling of the test packets.
>
>For instance, carrying the Last SeqNo in the Train in the control 
>protocol is not useful since it may/will change on a per test packet 
>basis. Same thing for the Desired Reverse Packet Interval.
>
>Carrying the Sender Discriminator field in the TWAMP control 
>protocol is a possibility via a new definition of the Type-P 
>descriptor for instance (e.g. first two bits is 02 followed by 
>SD).   It will bring some benefits to the solution but will not 
>necessarily reduce complexity on the Session-Reflector. With or 
>without the SD, the Session-Reflector (in most cases) needs to 
>continue inspecting various fields on a per test packet basis in 
>order to match the packets to the correct session.
>
>The flags are proposed in the test session in order to avoid 
>creating/allocating a large number of TWAMP modes with a large 
>number of corresponding "fixed" test packet formats. Our proposal is 
>to use a single mode that has a single "variable" test packet format 
>that is easy to parse through. On the contrary, it helps reduce 
>complexity for products supporting TWAMP. The other option to 
>completely remove the flags but this will remove the flexibility to 
>use the format for other purposes and re-open the case for creating 
>a larger number of modes and packet formats in the future.
>
>
>-Steve
>
>Ok, I thought you were referring to other proposals which were 
>discussed, and the suggestion of combining what makes sense, but 
>apparently not.
>
>My comment below on the tendency toward placing Control in the Test 
>Session in this proposal is still worth a look, I think.
>
>Al
>

---

From: Henk Uijterwaal <[email-masked]>
Date: Thu, 28 Apr 2011 13:45:53 +0200

IPPM Group,

> this idea or disagree with it, please speak up on the list before April 21.

Apologies for the delay.

I'm trying to figure out where to go with this proposal.  If I look
at the comments, then there seems to be agreement that we can enhance
TWAMP for packet train based measurements.  We are, however, not in
agreement on how to do this.  In the draft mentioned above, some
of the work is done during the test session phase whereas people
prepare that the entire setup is done during the setup phase.

I suggest that we should first discuss the general direction of this
idea on the list and only then get into details, where draft-baillargeon-...
is one of the solutions.

Would this work for everybody?  If so, please start fighting over this ;-)

Henk

-- 
------------------------------------------------------------------------------
Henk Uijterwaal                           Email: henk(at)uijterwaal.nl
RIPE NCC                                  http://www.uijterwaal.nl
                                          Phone: +31.6.55861746
------------------------------------------------------------------------------

---

From: Steve Baillargeon <[email-masked]>
Date: Thu, 28 Apr 2011 08:52:42 -0400

Hi
The draft proposes to enhance the TWAMP control protocol with a new mode and add the less possible set of new fields to the TWAMP test packets. The objective is to allow a single test session of a given type-P to measure capacity metrics over time on a given path using any capacity estimation methods. Can someone tell me if there is anything wrong with such goal?

Based on the last discussion, I believe we have a general agreement on the draft. At least, I noticed that more people supporting it than opposing it. I did not see any counter arguments from Al and I did not hear any concerns from anyone else. 
See enclosed email explaining the logic behind improving the test protocol.

-Steve

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Henk Uijterwaal
Sent: April-28-11 7:46 AM
To: IETF IPPM WG
Subject: Re: [ippm] draft-baillargeon-ippm-twamp-value-added-octets

IPPM Group,

> draft-baillargeon-ippm-twamp-value-added-octets and asked if this can 
> become a WG document.  If you support this idea or disagree with it, 
> please speak up on the list before April 21.

Apologies for the delay.

I'm trying to figure out where to go with this proposal.  If I look at the comments, then there seems to be agreement that we can enhance TWAMP for packet train based measurements.  We are, however, not in agreement on how to do this.  In the draft mentioned above, some of the work is done during the test session phase whereas people prepare that the entire setup is done during the setup phase.

I suggest that we should first discuss the general direction of this idea on the list and only then get into details, where draft-baillargeon-...
is one of the solutions.

Henk

There appears to have been a collective retreat from reality that day.
                                 (John Glanfield, on an engineering project) _______________________________________________
ippm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ippm

Subject: Re: [ippm] draft-baillargeon-ippm-twamp-value-added-octets
From: "[email-masked]" <[email-masked]>
To: Al Morton <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Date: Fri, 8 Apr 2011 00:14:21 -0400
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>

Hi Al
I think we are going in circles.

Yes the Session-Reflector needs to be the an efficient process and the proposed draft does not change that.

Current Session-Reflectors already parse through test packet fields today. We just continue to extend this mechanism to a section of the TWAMP padding octets.
The actual implementation is actually very simple to implement.

It is much easier to identify and process the packets belonging to a "train" if the "train information" is carried within the test packet.
It also enables other capabilities like variable train size and TWAMP light which are important cases to consider.

The inter-packet interval will always vary. Why would you remove it from Test? Without it, different train rates within the same test session cannot be tested.

The SD is a lightweight flag to improve the demultiplexing of the test packets to the correct test session. Why would you remove it from Test?

-Steve

----- Original Message -----
From: Al Morton <[email-masked]>
Date: Thursday, April 7, 2011 8:15 pm
Subject: Re: [ippm] draft-baillargeon-ippm-twamp-value-added-octets
To: "[email-masked]" <[email-masked]>

> difficult> >to do. If a different packet size is needed, a
> new/different test
> > >From: [email-masked] [mailto:[email-masked]] On
> Behalf Of
> > >Al Morton
> > >telling the Server/Session-Reflector everything needed in
> advance of
> > >Starting the test session.
> > >