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

[Steve Baillargeon <[e-mail]>]

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