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

[Steve Baillargeon <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] 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,

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

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: [phone]
------------------------------------------------------------------------------

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

--- Begin Message ---

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 <[e-mail]>
Date: Thursday, April 7, 2011 8:15 pm
Subject: Re: [ippm] draft-baillargeon-ippm-twamp-value-added-octets
To: "[e-mail]" <[e-mail]>

> 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
> >
> >-----Original Message-----
> >From: Al Morton [mailto:[e-mail]]
> >Sent: April-07-11 3:58 PM
> >To: Steve Baillargeon; [e-mail]
> >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:
> > >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: [e-mail] [mailto:[e-mail]] On
> Behalf Of
> > >Al Morton
> > >Sent: April-07-11 2:38 PM
> > >To: [e-mail]
> > >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
> > >[e-mail]
> > >https://www.ietf.org/mailman/listinfo/ippm
> > >_______________________________________________
> > >ippm mailing list
> > >[e-mail]
> > >https://www.ietf.org/mailman/listinfo/ippm
>
> _______________________________________________
> ippm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ippm

--- End Message ---