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

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 <acmorton@att.com>
Date: Thursday, April 7, 2011 8:15 pm
Subject: Re: [ippm] draft-baillargeon-ippm-twamp-value-added-octets
To: "ippm@ietf.org" <ippm@ietf.org>

> 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:acmorton@att.com]
> >Sent: April-07-11 3:58 PM
> >To: Steve Baillargeon; ippm@ietf.org
> >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: 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
> > >_______________________________________________
> > >ippm mailing list
> > >ippm@ietf.org
> > >https://www.ietf.org/mailman/listinfo/ippm
> 
> _______________________________________________
> ippm mailing list
> ippm@ietf.org
> https://www.ietf.org/mailman/listinfo/ippm