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

From: "Hedayat, Kaynam" <[email-masked]>
Date: Thu, 20 Oct 2005 13:31:34 -0400

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

---

From: Hélder Veiga <[email-masked]>
Date: Mon, 24 Oct 2005 18:39:29 +0100

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:

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,

Regards,
Kaynam 

-----Original Message-----

Hello,

    0                   1                   2                   3 

    |                      Sender Timestamp                         | 
    |                                                               | 

    0                   1                   2                   3 

Regards
Sharee McNab
Allied Telesyn Research
Christchurch, NZ