Subject: [ippm] Comments on OWDP IETF draft

From: "Hamid.Asgari" <[email-masked]>
Date: Thu, 15 Feb 2001 11:08:36 -0000

Hello Stanislav, Benjamin, and Matthew

Please find below some comments on the OWDP IETF draft. I am new to the
list. Please forgive me if these issues have already been raised in the
list.

1- There is the possibility that a server may want to initiate an active
test measurement between a source and destination. I mean, shouldn't be
better that the request also come from the server to instruct a source
client (located at a measurement machine) for creating test sessions and
inform the destination. This is normally done in large private networks
where a centralised server is responsible for initiating and collecting
measurement information for SLA purposes.

2- Is OWDP protocol aimed to be used at best-effort networks or it is also
aimed at QoS-enabled networks where one-way delay measurements play an
important role for traffic engineering purposes?

Traffic forwarded in the QoS-enabled networks might encounter a
differentiation into several CoS. As traffic belonging to each CoS has
certain requirements and exhibit a certain behaviour, there is no longer a
single metric result adequate for all packets belonging to a different CoS.
Therefore, the measurement methodology must be aware of these classes of
services. 

The OWDP test packets are UDP using unspecified ports. I think the protocol
doesn't incorporate the DiffServ Code Points awareness. If the protocol is
aimed at QoS-enabled network, I think the DSCP must be taken into account in
the request session messages. This must enable a source to have multiple
test sessions (each for a CoS) with a single destination. The ability to
mark the test packets with appropriate DSCP, enables the test packet to the
pass through the same queues and follow the same path as the particular QoS
traffic under test. It is obvious that the DSCP can be set in the IP header
but with the current method, the source must be able to map it to the
requested port somehow and the test recipient must be aware of this mapping
in order to be able to distinguish between the test packets coming from a
single source belonging to different code points. 

3- Section 4.2: the packet IP header (source, destination, port , etc.)
needs to be stored as the destination may have multiple test sessions with
one or more sources.

Best regards,
Hamid Asgari 

Thales Research Limited          
Worton Drive,                         
Worton Grange Industrial Est.  
Berkshire  RG2  0SB, UK         
Email: [email-masked] 

*******************************************************************************
This email and any files transmitted with it are intended solely for the use of
the individual or entity to whom they are addressed and may not be divulged to
any third party without the express permission of the originator.  Any views
expressed in this message are those of the individual sender, except where the
sender specifically states them to be the views of Thales Research Ltd.

Following the acquisition of Racal Electronics plc by Thomson-CSF, please note
that our new name is Thales Research Ltd.  For more information regarding the
Thales Group (formerly Thomson-CSF) please see our website www.Thalesgroup.com
*******************************************************************************
_______________________________________________
ippm mailing list
[email-masked]
http://mailhost.advanced.org/mailman/listinfo/ippm

---

From: stanislav shalunov <[email-masked]>
Date: 15 Feb 2001 11:25:48 -0500

Hamid,

"Hamid.Asgari" <[email-masked]> writes:

> 1- There is the possibility that a server may want to initiate an
> active test measurement between a source and destination. [...]

In this case, the server by definition becomes a client (and can
follow the normal test initiation procedure).

> 2- [...] I think the DSCP must be taken into account in the request
> session messages.

We heard the request before and want to include something to that
effect.  As you know, DSCP values per se have only local significance,
and we're still unsure how we should approach this (one could use a
16-bit PHB descriptor, but then you have the problem of mapping those
to DSCP values, and the only reasonable way for an implementor to
solve that problem for now is via a config file; ouch).

Unfortunately, for now there's not a lot of understanding how DSCP
values will actually be used.

We may simply include DSCP, or go for PHB descriptor.

> 3- Section 4.2: the packet IP header (source, destination, port ,
> etc.)  needs to be stored as the destination may have multiple test
> sessions with one or more sources.

I don't quite understand what you mean here; Section 4.2 is 14 lines
and titled "OWDP-Control Commands".

In any case, naturally the server is expected to store the data in
such a way that it can serve a Retrieve-Session command.  What
precisely will be done is up to implementors.

Thanks for the comments.

-- 
Stanislav Shalunov		http://www.internet2.edu/~shalunov/

"Computer Science is no more about computers than astronomy is about
telescopes."					-- E. W. Dijkstra
_______________________________________________
ippm mailing list
[email-masked]
http://mailhost.advanced.org/mailman/listinfo/ippm

---

From: "Henk Uijterwaal (RIPE-NCC)" <[email-masked]>
Date: Thu, 15 Feb 2001 18:07:48 +0100 (CET)

> follow the normal test initiation procedure).

Is this true?

If I understood it correctly, then the standard case in OWDP is that A
sets up a session that sends traffic from A to B, then starts sending
traffic.  However, Hamid wants the opposite: A sets up a session that then
sends traffic from B back to A.

This is certainly a useful feature to have, but it does require that
different processes are started on both ends.

Henk

------------------------------------------------------------------------------
Henk Uijterwaal                    Email: [email-masked]
RIPE Network Coordination Centre     WWW: http://www.ripe.net/home/henk
Singel 258                         Phone: +31.20.5354414
1016 AB Amsterdam                    Fax: +31.20.5354445 
The Netherlands                   Mobile: +31.6.55861746  
------------------------------------------------------------------------------

As long as you don't tell your friends how I played the hand,
then I won't tell my friends how you defended it.                 (Anonymous)

---

From: stanislav shalunov <[email-masked]>
Date: 15 Feb 2001 13:17:20 -0500

"Henk Uijterwaal (RIPE-NCC)" <[email-masked]> writes:

> If I understood it correctly, then the standard case in OWDP is that
> A sets up a session that sends traffic from A to B, then starts
> sending traffic.  However, Hamid wants the opposite: A sets up a
> session that then sends traffic from B back to A.

Now you can open an OWDP-Control session from A to B (A is
Control-Client and B is Server in draft terminology), after which A
can proceed to request OWDT-Test sessions going from an arbitrary
place to another arbitrary place (this may be from B to A).

Is that sufficient?

I (mis?)interpreted Hamid's request as asking to include functionality
to allow B to request OWDP-Test sessions in the same OWDP-Control
session.  This functionality is not present.  B would have to open an
OWDP-Control session back to A if it decides it wants anything from A.

I never let school stand in the way of my education.  -- Mark Twain
_______________________________________________
ippm mailing list
[email-masked]
http://mailhost.advanced.org/mailman/listinfo/ippm