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

[Al Morton <[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