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

From: Xiangsong Cui <[email-masked]>
Date: Tue, 03 May 2011 11:43:14 +0800

Hi Henk,

Sorry for the late comments.

I take a quick look on this draft and have some comments.

First, this draft seems like about capacity, e.g. path capacity,
   This memo describes the optional extensions to the standard TWAMP
   test protocol for identifying test sessions and packet trains, and
   for measuring capacity metrics like the available path capacity,
   tight section capacity and UDP throughput in the forward and reverse
   path directions. (copied from abstract)

But, we all know that path is a unidirectional concept, so I don't
understand, why we need the two-way test to measure the "path capacity"? Why
not the one-way test? For example, in the ADSL/3G/4G/etc. network, the
upstream path and downstream path provide different "capacity", how can the
two-way test be applied? And what is the expected "path capacity" metric
result in this approach?

Second, the motivation of this draft, the first challenge is "The different
trains within a session cannot be differentiated" (copied from minutes), and
the draft reads 
   "The controller (or the Session-Sender) requires a method for
   demultiplexing the received test packets to the correct test session
   especially when it manages multiple active test sessions. "

where is the requirement from? Why the controller cannot set up multiple
control sessions to manage the multiple test sessions separately?

Third, section 3 reads,

   The packet interval between consecutive packets for each train sent
   by the Session-Sender and reflected by the Session-Reflector MUST be
   calculated and determined by the controller or an application or
   entity communicating with the controller. [...]

   The transmission time tt to send one packet (i.e. determined by the
   interface speed and the IP packet size) is also shown in the picture.
   Observe that the packet interval MUST be larger than or equal to tt.

Why we need the two "MUST"? Section 3.6 of RFC5357 tells us:

   The send schedule for test packets defined in Section 3.6 of OWAMP
   [RFC4656] is not used in TWAMP.  The Control-Client and Session-
   Sender MAY autonomously decide the send schedule.  The Session-
   Reflector SHOULD return each test packet to the Session-Sender as
   quickly as possible.

As a conclusion, I DISAGREE with it BEFORE I was told the answers.

Best regards,
Xiangsong

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Henk Uijterwaal
> Sent: Thursday, April 07, 2011 4:13 PM
> To: [email-masked]
> Subject: [ippm] draft-baillargeon-ippm-twamp-value-added-octets
> 
> IPPM group,
> 
> In Prague, Steve and colleagues presented
> draft-baillargeon-ippm-twamp-value-added-octets and asked if this can
become
> a
> WG document.  If you support
> this idea or disagree with it, please speak up on the list before April
21.
> Henk (as WG chair)
> --
----------------------------------------------------------------------------
--
> Henk Uijterwaal                           Email: henk(at)uijterwaal.nl
> RIPE NCC
> http://www.xs4all.nl/~henku
>                                           Phone: +31.6.55861746
>
----------------------------------------------------------------------------
--
> 
> There appears to have been a collective retreat from reality that day.
>                                  (John Glanfield, on an engineering
> project)
> _______________________________________________
> ippm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ippm

---

From: Christofer Flinta <[email-masked]>
Date: Tue, 3 May 2011 12:14:31 +0200

Hi Xiangsong,

Thanks for your input. I will try to answer the questions in your first comment.

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. Our expected output would thus be: Forward Capacity and Reverse Capacity.

TWAMP in its currently form cannot provide capacity estimates separatly in both directions. Today we may send trains of packets in the forward direction and have those packets reflected back to the sender by the reflector. The send rate of each train in the forward direction can be controlled by the sender, which is needed for all capacity measuring methods. However, the send rate of the reflected trains in the reverse direction cannot be controlled, since each packet is reflected back as soon as it arrives at the reflector. Capacity estimates can therefore only be provided in the forward direction in a current TWAMP system.

The aim of this draft is to extend TWAMP with a mechanism that lets the reflector store the packets of a train and then send each train back at a specific rate. This way the send rate can be controlled in both directions.

I hope this gave some clarification.
Christofer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Xiangsong Cui
Sent: den 3 maj 2011 05:43
To: 'Henk Uijterwaal'; [email-masked]
Subject: Re: [ippm] draft-baillargeon-ippm-twamp-value-added-octets

Hi Henk,

But, we all know that path is a unidirectional concept, so I don't understand, why we need the two-way test to measure the "path capacity"? Why not the one-way test? For example, in the ADSL/3G/4G/etc. network, the upstream path and downstream path provide different "capacity", how can the two-way test be applied? And what is the expected "path capacity" metric result in this approach?

Second, the motivation of this draft, the first challenge is "The different trains within a session cannot be differentiated" (copied from minutes), and the draft reads 
   "The controller (or the Session-Sender) requires a method for
   demultiplexing the received test packets to the correct test session
   especially when it manages multiple active test sessions. "

where is the requirement from? Why the controller cannot set up multiple control sessions to manage the multiple test sessions separately?

Third, section 3 reads,

Best regards,
Xiangsong

> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Henk Uijterwaal
become
21.

---

From: Svante Ekelin <[email-masked]>
Date: Tue, 3 May 2011 16:21:13 +0200

Hi Xiangsong,

Christofer already answered your first comment, and I will try to answer the questions in the other two comments you made.

As noted below by Christofer, an aim of this draft is extending TWAMP to provide a mechanism which will allow capacity measurement in both the forward and reverse path, by transmitting test packets as a train at a specified rate in the forward path, and then reflected as a train with another specified rate in the reverse path.

So, with regard to your second comment, as the controller (or the Session-Sender) may be engaged in multiple concurrent measurement sessions, it needs to be able to identify to which session a reflected test packet belongs, i.e. demultiplexing.

As for the third comment, the first MUST is due to the fact that the controller needs to be able to specify the rate of the train in the reverse path. As you quote from RFC5357, the send schedule for test packets is not used in the baseline TWAMP. The same is true for the new proposed TWAMP mode. The MAY statement in RFC5357 regarding the autonomous decision on the send schedule at the source is not in conflict with the MUST statement in the draft. For instance, the actual inter-packet interval may be autonomously decided by the Control-Client and Session-Sender, or it may be done by another node or application, but the decision MUST be known at the source since the destination (e.g Session-Reflector) is only reflecting the test packets at the specified rate.

The second MUST is simply a statement of the size relation between the packet interval and the transmission time tt, as is illustrated in the picture on page 5 of the draft.

Hope this helps,
-- Svante

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Christofer Flinta
Sent: den 3 maj 2011 12:15
To: Xiangsong Cui; 'Henk Uijterwaal'; [email-masked]
Subject: Re: [ippm] draft-baillargeon-ippm-twamp-value-added-octets

Hi Xiangsong,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Xiangsong Cui
Sent: den 3 maj 2011 05:43
To: 'Henk Uijterwaal'; [email-masked]
Subject: Re: [ippm] draft-baillargeon-ippm-twamp-value-added-octets

Hi Henk,

Third, section 3 reads,

Best regards,
Xiangsong

become
21.

---

From: Xiangsong Cui <[email-masked]>
Date: Wed, 04 May 2011 09:28:52 +0800

Hi Christofer,

Thanks for your reply, please see my comments inline.

> From: Christofer Flinta [mailto:[email-masked]]
> Sent: Tuesday, May 03, 2011 6:15 PM
> Subject: RE: [ippm] draft-baillargeon-ippm-twamp-value-added-octets
> 
> Hi Xiangsong,
> 
> 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. 

No, I don't think they are similar, because, round-trip delay, which is a
metric defined in RFC2681, is a "metric", however, we have no any definition
on "round-trip path capacity" metric, right?
What is more important, the round-trip delay metric is meaningful, for
example, in TCP, the TCP sender depends on the ACK clock to increase its
window, which is very relevant to the RTT metric. But what is the meaning of
round-trip path capacity metric?

Our expected output would thus be:
> Forward Capacity and Reverse Capacity.

Yes, I do know your expectation, you are expecting Forward Capacity /and/
Reverse Capacity, you are not needing the capacity of "Forward Capacity
/plus/ Reverse Capacity". Why you not utilize the one-way test on forward
path and reverse path? Why you have to couple the two independent metrics
together, and use the two-way test to cover the two one-way metrics?

> 
> TWAMP in its currently form cannot provide capacity estimates separatly in
> both directions. 

Yes, I think you are right on this sentence. But I think you are using the
wrong tool here, the same question, why you like to use TWAMP for metrics
"separately in both directions", why not OWAMP "separately in both
directions"?

Today we may send trains of packets in the forward direction
> and have those packets reflected back to the sender by the reflector. The
send
> rate of each train in the forward direction can be controlled by the
sender,
> which is needed for all capacity measuring methods. However, the send rate
of
> the reflected trains in the reverse direction cannot be controlled, since
each
> packet is reflected back as soon as it arrives at the reflector. 

Yes, and I guess this is the intention of RFC5357's co-authors (or IPPM WG),
there is no MUST or SHOULD, and RFC5357 reads "In the case of TWAMP Light,
the Session-Reflector does not necessarily have knowledge of the session
state" (Note this statement is from informative appendix).

Capacity
> estimates can therefore only be provided in the forward direction in a
current
> TWAMP system.

I think this is just because we only have one-way capacity (if you are
talking about capacity metric defined in RFC5136).

> 
> The aim of this draft is to extend TWAMP with a mechanism that lets the
> reflector store the packets of a train and then send each train back at a
specific
> rate.

It seems you are changing the session-reflector to "session-receiver plus
session-sender", right?

 This way the send rate can be controlled in both directions.

But the paths in the two directions are different and independent. And TWAMP
is not equal to "local OWAMP plus remote OWAMP", I think.

Best regards,
Xiangsong

> Xiangsong Cui
understand,
> why we need the two-way test to measure the "path capacity"? Why not the
> one-way test? For example, in the ADSL/3G/4G/etc. network, the upstream
> path and downstream path provide different "capacity", how can the two-way
> test be applied? And what is the expected "path capacity" metric result in
this
> approach?
> 
> 
> Second, the motivation of this draft, the first challenge is "The
different trains
> within a session cannot be differentiated" (copied from minutes), and the
draft
> reads

---

From: Xiangsong Cui <[email-masked]>
Date: Wed, 04 May 2011 09:33:01 +0800

Hi Svante,

Thanks for your reply, too.

I would like to discuss these issues one by one, imho if the rationale is
incorrect we needn't to waste time on the details.

Best regards,
Xiangsong

> From: Svante Ekelin [mailto:[email-masked]]
> Sent: Tuesday, May 03, 2011 10:21 PM
> To: Christofer Flinta; Xiangsong Cui; 'Henk Uijterwaal'; [email-masked]
> Christofer already answered your first comment, and I will try to answer
the
> questions in the other two comments you made.
> 
> As noted below by Christofer, an aim of this draft is extending TWAMP to
> provide a mechanism which will allow capacity measurement in both the
> forward and reverse path, by transmitting test packets as a train at a
specified
> rate in the forward path, and then reflected as a train with another
specified
> rate in the reverse path.
> 
> So, with regard to your second comment, as the controller (or the
> Session-Sender) may be engaged in multiple concurrent measurement
sessions,
> it needs to be able to identify to which session a reflected test packet
belongs,
> i.e. demultiplexing.
> 
> As for the third comment, the first MUST is due to the fact that the
controller
> needs to be able to specify the rate of the train in the reverse path. As
you
> quote from RFC5357, the send schedule for test packets is not used in the
> baseline TWAMP. The same is true for the new proposed TWAMP mode. The
> MAY statement in RFC5357 regarding the autonomous decision on the send
> schedule at the source is not in conflict with the MUST statement in the
draft.
> For instance, the actual inter-packet interval may be autonomously decided
by
> the Control-Client and Session-Sender, or it may be done by another node
or
> application, but the decision MUST be known at the source since the
> destination (e.g Session-Reflector) is only reflecting the test packets at
the
> specified rate.
> 
> The second MUST is simply a statement of the size relation between the
packet
> interval and the transmission time tt, as is illustrated in the picture on
page 5
> of the draft.
> Christofer Flinta
the
similar
be
> measured separately in both directions. Our expected output would thus be:
> both directions. Today we may send trains of packets in the forward
direction
send
sender,
of
each
> packet is reflected back as soon as it arrives at the reflector. Capacity
current
specific
> rate. This way the send rate can be controlled in both directions.
> 
> 
understand,
this
different trains
draft

---

From: Xiangsong Cui <[email-masked]>
Date: Wed, 04 May 2011 10:08:38 +0800

the
similar
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

---

From: Andreas Johnsson A <[email-masked]>
Date: Fri, 6 May 2011 16:54:05 +0200

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?). The problems with loss measurements are outside the scope of this discussion, but do belong to draft-ietf-ippm-rt-loss-00 by Al.

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 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.

Best regards
Andreas Johnsson 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Xiangsong Cui
Sent: Wednesday, May 04, 2011 4:09 AM
To: Christofer Flinta; 'Henk Uijterwaal'; [email-masked]
Subject: Re: [ippm] draft-baillargeon-ippm-twamp-value-added-octets

the
similar
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

---

From: Xiangsong Cui <[email-masked]>
Date: Tue, 10 May 2011 09:47:27 +0800

Hi Andreas,

Please see my comments below.

> From: Andreas Johnsson A [mailto:[email-masked]]
> Sent: Friday, May 06, 2011 10:54 PM
> To: 'Xiangsong Cui'; Christofer Flinta; 'Henk Uijterwaal'; [email-masked]
> 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

you
> get the one-way metric by the two-way test?

---

From: Xiangsong Cui <[email-masked]>
Date: Tue, 10 May 2011 09:55:37 +0800

Sorry, there is a typo in my previous mail,

My proposal should be:

Reverse-Session-Sender   | |
  
Regards,
Xiangsong

the
example Al
> and Yaakov (maybe throughput was the main idea here?). The problems with
to
reflector and
to
think
and
draft,
you

---

From: Henk Uijterwaal <[email-masked]>
Date: Tue, 10 May 2011 10:39:29 +0200

(Catching up on this)

On 28/04/2011 14:52, Steve Baillargeon wrote:

> Hi The draft proposes to enhance the TWAMP control protocol with a new mode
> and add the less possible set of new fields to the TWAMP test packets. The
> objective is to allow a single test session of a given type-P to measure
> capacity metrics over time on a given path using any capacity estimation
> methods. Can someone tell me if there is anything wrong with such goal?

No, not at all and I did not want to imply this.

Henk

-- 
------------------------------------------------------------------------------
Henk Uijterwaal                           Email: henk(at)uijterwaal.nl
                                          http://www.uijterwaal.nl
                                          Phone: +31.6.55861746
------------------------------------------------------------------------------

There appears to have been a collective retreat from reality that day.
                                 (John Glanfield, on an engineering project)

---

From: Christofer Flinta <[email-masked]>
Date: Tue, 10 May 2011 15:15:10 +0200

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:[email-masked]] 
Sent: den 10 maj 2011 03:47
To: Andreas Johnsson A; Christofer Flinta; 'Henk Uijterwaal'; [email-masked]
Subject: RE: [ippm] draft-baillargeon-ippm-twamp-value-added-octets

Hi Andreas,

> 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
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
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
to
> deduct forward and reverse delay, and with our proposal also forward 
> and reverse available capacity. Sure, OWAMP can be used to do these 
think
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?

draft,
> although maybe the draft needs to be enhanced or split into several.

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:

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 now is fully the controller of the measurement, can this achieve the capacity measurement in both the forward and reverse direction?

Best regards,
Xiangsong

> Of Xiangsong Cui
you
> That said, how can the session-sender get to know whether the packet 
> is
lost