Subject: RE: [ippm] Comment onTWAMPdraft-hedayat-two-way-active-measurement-protocol-01.txt

From: "Hedayat, Kaynam" <[email-masked]>
Date: Mon, 24 Oct 2005 17:07:19 -0400

The interface for fetching data from the Session-Sender is out of the scope of this standard. The standard defines the interfaces necessary to compute two-way metrics within one entity (in this case Session-Sender). You may choose any protocol that is suitable to your architecture for retrieving of the results from the Session-Sender. Note that the use of a non-standard protocol for this interface will not cause interoperability problems for setting up and conducting a TWAMP session.

Regards,
Kaynam  

-----Original Message-----
From: Hélder Veiga [mailto:[email-masked]] 
Sent: Monday, October 24, 2005 1:39 PM
To: Hedayat, Kaynam; 'sharee mcnab'; [email-masked]
Cc: [email-masked]; 'João Silva'; [email-masked]; nogueira; Paulo Salvador; Rui Valadas
Subject: RE: [ippm] Comment onTWAMPdraft-hedayat-two-way-active-measurement-protocol-01.txt

Dear Kaynam,

We are a group of researchers of Institute of Telecommunications of Aveiro University and we are also implementing TWAMP. Regarding point 2 of your previous email:

2. The Fetch-Client's role is to retrieve the one-way measurement result and not the two way measurement. With the Fetch-Client a TWAMP session can also report one-way results.

It's not clear to us how will we fetch the two-way session data from the Session-Sender. In the first example (in section 3.2 Logical Model), where each logical role is played by different hosts, how does one get the session data from the Session-Sender?

We thought of extending Fetch-Client to request the data directly to the Session-Sender, using a process similar to OWAMP's one-way Fetch-Session.

Best Regards,

João Silva
Helder Veiga

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hedayat, Kaynam
Sent: quinta-feira, 20 de Outubro de 2005 18:32
To: sharee mcnab; [email-masked]
Subject: RE: [ippm] Comment
onTWAMPdraft-hedayat-two-way-active-measurement-protocol-01.txt

Sharee,

Thank you for the feedback and comments. Following are my comments:

1. Agreed. I will change the text.

2. The Fetch-Client's role is to retrieve the one-way measurement result and not the two way measurement. With the Fetch-Client a TWAMP session can also report one-way results.

3. I agree with your comments and will propose the changes. The reason for incorporating reflector delay instead of the receive timestamp was saving octets. Howeve, I believe that the benefits suggested by your email outweights saving four octets.

Regards,
Kaynam 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of sharee mcnab
Sent: Tuesday, October 18, 2005 6:42 PM
To: [email-masked]
Subject: [ippm] Comment on
TWAMPdraft-hedayat-two-way-active-measurement-protocol-01.txt

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

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

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