Subject: [ippm] Comment on TWAMP draft-hedayat-two-way-active-measurement-protocol-01.txt

From: "sharee mcnab" <[email-masked]>
Date: Wed, 19 Oct 2005 11:42:16 +1300

Hello,
I recently became aware of the TWAMP draft and we at Allied Telesyn Research are interested in producing an implementation of the TWAMP (initially Light). I have some comments/questions as well as a suggestion for the format of the reflected packet in the two-way measurement.

1.  I assume this is an error - Page 4, Sect 3.2, last paragraph.   "fit inside the payload of a single ATM cell (only in unauthenticated mode and encrypted modes)."
This must be wrong as the encrypted mode packet is defined as 80 octets.

2.  Section 4.7 Fetch-Session.  Fetch-Session does not appear to be extended to fetch the two-way data.  Is this correct? For a distributed architecture looking at the logical model in section 3.2 there seems to be no data path between the Session-Sender and the Fetch-Client. The only way to retrieve data from a two way test seems to be via proprietary communication which appears to inhibit inter-operability.  Of course this isn't an issue in TWAMP Light but does not seem to work in the distributed case.

3.  I'd like to propose an alternative reflected packet format where the reflected packet header remains consistent with the send packet format for the initial 14 octets (unauthenticated) & 32 octets (authenticated and encrypted).  To achieve this, the order of the packet is changed to put the sequence number (reflector) and the reflected send timestamp of the reflected packet are first. The benefit of this is that the hardware doesn't need to differentiate between a reflected packet and the initial send packet if using hardware time-stamping for example - the header looks the same from the hardware perspective.  This means the Reflector Delay field is no longer required as instead an absolute time for when the reflected packet is sent is provided.  This imposes a small increase in size for the unauthenticated packetincreasing to a minimum of 40 octets long while the authenticated/encrypted packet remains at 80 octets.  Note the error estimate for the Received Timestamp is assumed to be the same as the Error Estimate for the Reflected Send Timestamp at the top of the packet.
The proposed packet formats are shown below:

For unauthenticated mode: 

    0                   1                   2                   3 
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |                        Sequence Number (Reflected)            | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |                          Timestamp  (Reflected)               | 
    |                                                               | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |         Error Estimate        |           MBZ                 | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |                        Sender Sequence Number                 | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     
    |                      Sender Timestamp                         | 
    |                                                               | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |      Sender Error Estimate    |           MBZ                 | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |       Received Timestamp (Replace Reflector Delay)            |
    | 										  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |                                                               | 
    .                                                               . 
    .                         Packet Padding                        . 
    .                                                               . 
    |                                                               | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

For authenticated and encrypted mode:

    0                   1                   2                   3 
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |                        Sequence Number  (Reflected)           | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |                        IZP (12 octets)                        | 
    |                                                               | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |                          Timestamp  (Reflected)               | 
    |                                                               | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |         Error Estimate        |                               | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               | 
    |                        IZP (6 octets)                         | 
    |                                                               | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |                        Sender Sequence Number                 |     
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                        IZP (12 octets)                        | 
    |                                                               | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |                      Sender Timestamp                         | 
    |                                                               | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |      Sender Error Estimate    |                               | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               | 
    |                        IZP (6 octets)                         | 
    |                                                               | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |       Received Timestamp (Replace Reflector Delay)            | 
    |											  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |                        IZP (8 octets)                         | 
    |                                                               | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 
    |                                                               | 
    .                                                               . 
    .                         Packet Padding                        . 
    .                                                               . 
    |                                                               | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Regards
Sharee McNab
Allied Telesyn Research
Christchurch, NZ
[email-masked] 
NOTICE: This message contains privileged and confidential
information intended only for the use of the addressee
named above. If you are not the intended recipient of
this message you are hereby notified that you must not
disseminate, copy or take any action in reliance on it.
If you have received this message in error please
notify Allied Telesyn Research Ltd immediately.
Any views expressed in this message are those of the
individual sender, except where the sender has the
authority to issue and specifically states them to
be the views of Allied Telesyn Research.

_______________________________________________
ippm mailing list
[email-masked] 
https://www1.ietf.org/mailman/listinfo/ippm