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

Hi Xiangsong

I will try to clarify the motivation behind our draft.

If you look att the Introduction part of the RFC 5357 you can see that the intention of the TWAMP protocol was to extend the OWAMP measurements with two-way metrics and at the same time offer TWAMP as an alternative to setting up two separate OWAMP measurements.

It is thus possible to measure delay in both directions either by setting up two separate OWAMP sessions or by setting up one single TWAMP session. However, for capacity measurements in both directions there is currently no other choice than setting up two separate OWAMP sessions. With the current TWAMP protocol it's possible to perform capacity measurements in the forward direction but not in the reverse direction. 

>From our knowledge it appears that the advantages of TWAMP over OWAMP will drive the market towards TWAMP. Therefore we want to extend the TWAMP mechanism with the possibility of also measuring capacity in both directions. Ideally, it should be possible to use TWAMP for any kind of metric in both directions.

Regards
Christofer

-----Original Message-----
From: Xiangsong Cui [mailto:Xiangsong.Cui@huawei.com] 
Sent: den 10 maj 2011 03:47
To: Andreas Johnsson A; Christofer Flinta; 'Henk Uijterwaal'; ippm@ietf.org
Subject: RE: [ippm] draft-baillargeon-ippm-twamp-value-added-octets

Hi Andreas,

Please see my comments below.

> -----Original Message-----
> From: Andreas Johnsson A [mailto:andreas.a.johnsson@ericsson.com]
> Sent: Friday, May 06, 2011 10:54 PM
> To: 'Xiangsong Cui'; Christofer Flinta; 'Henk Uijterwaal'; 
> ippm@ietf.org
> Subject: RE: [ippm] draft-baillargeon-ippm-twamp-value-added-octets
> 
> Hi Xiangsong,
> We are drifting away from the topic here. What we want to do is to 
> include functionality in the TWAMP spec for measuring available 
> capacity in both
the
> forward and reverse direction. This interest was also raised by for
example Al
> and Yaakov (maybe throughput was the main idea here?). 

I think this is not the problem we are talking about, I'm OK with this interest (i.e., measuring available capacity in both the forward and reverse direction), my concern is I don't think the approach of TWAMP extension to one-way metric is OK.

The problems with
> loss measurements are outside the scope of this discussion, but do 
> belong
to
> draft-ietf-ippm-rt-loss-00 by Al.

Yes, I agree with you, and I believe you can find that it's not me bringing "packet loss" into this discussion.

> 
> There seem to be a little bit of confusion when it comes to TWAMP. As 
> you know, TWAMP time stamps packets when a packet is sent at the 
> session sender, when it is received at the reflector, when it is sent 
> by the
reflector and
> when it is again received by the session sender. From this it is very 
> easy
to
> deduct forward and reverse delay, and with our proposal also forward 
> and reverse available capacity. Sure, OWAMP can be used to do these 
> measurements, but the intention with TWAMP is to perform both 
> measurements in both directions (and round trip) with only one 
> trigger. I
think
> this is a strong argument for trying to put new functionality into 
> TWAMP
and
> not only focus on OWAMP.

I'm not sure what the "trigger" means here, but I'm sure that the both entities (source node and destination node) in this approach need to be modified. But if we can do this by existing protocols, why we need the protocol modification?

> 
> I hope this resolves any issues you have with the intention with our
draft,
> although maybe the draft needs to be enhanced or split into several.
> Suggestions are welcome.

I would like to suggest applying TWAMP to two-way metrics and ONLY to two-way metrics, at the same time, applying OWAMP to one-way metrics.

As to this specific requirement of measuring available capacity in both the forward and reverse direction, since RFC5357 tells us:

   " OWAMP can be used bi-directionally to
   measure one-way metrics in both directions between two network
   elements. "

And RFC4656 tells us:

   "Several roles are logically separated to allow for broad flexibility in use." and,
   "Different logical roles can be played by the same host. "

I think this is ONLY a protocol deployment business, it not worth a protocol change or extension.

And based on your concern of "Controlling the measurement at one point", my proposal is:

+--------------------------------+
+------------------------------+
|           Node A               |                       |           Node B
|
|  +---------------------------+ |                       |
+--------------------------+ |
|  | Forward-Control-Client    |<--Forward-OWAMP-Control-->| Forward-Server
| |
|  | Forward-Fetch-Client      |                           |
| |
|  | Forward-Session-Sender    |---Forward-OWAMP-Test----->|
Forward-Session-Receiver | |
|  +---------------------------+ |                       |
+--------------------------+ |
|                                |                       |
| 
|  +---------------------------+ |                       |
+--------------------------+ |
|  | Reverse-Control-Client    |<--Reverse-OWAMP-Control-->| Reverse-Server
| |
|  | Reverse-Fetch-Client      |                           |
| |
|  | Reverse-Session-Receiver  |<--Reverse-OWAMP-Test------|
Reverse-Session-Receiver | |
|  +---------------------------+ |                       |
+--------------------------+ |
|                                |                       |
|  
+--------------------------------+
+------------------------------+ 

Node A now is fully the controller of the measurement, can this achieve the capacity measurement in both the forward and reverse direction?

Best regards,
Xiangsong

> 
> Best regards
> Andreas Johnsson
> 
> -----Original Message-----
> From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf 
> Of Xiangsong Cui
> Sent: Wednesday, May 04, 2011 4:09 AM
> To: Christofer Flinta; 'Henk Uijterwaal'; ippm@ietf.org
> Subject: Re: [ippm] draft-baillargeon-ippm-twamp-value-added-octets
> 
> 
> > This draft is trying to provide a means for measuring the capacity 
> > in both
> the
> > forward and reverse directions as two separate measurements. This is
> similar
> > to the current capabilities of TWAMP, where e.g. delay and packet 
> > loss can
> be
> > measured separately in both directions.
> 
> If you are referring to one-way metric, e.g. one-way packet loss, how 
> can
you
> get the one-way metric by the two-way test?
> That said, how can the session-sender get to know whether the packet 
> is
lost
> before or after the session-reflector?
> 
> Regards,
> Xiangsong
> 
> 
> _______________________________________________
> ippm mailing list
> ippm@ietf.org
> https://www.ietf.org/mailman/listinfo/ippm