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

[Svante Ekelin <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf Of Christofer Flinta
Sent: den 3 maj 2011 12:15
To: Xiangsong Cui; 'Henk Uijterwaal'; [e-mail]
Subject: Re: [ippm] draft-baillargeon-ippm-twamp-value-added-octets

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: [e-mail] [mailto:[e-mail]] On Behalf Of Xiangsong Cui
Sent: den 3 maj 2011 05:43
To: 'Henk Uijterwaal'; [e-mail]
Subject: Re: [ippm] draft-baillargeon-ippm-twamp-value-added-octets

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: [e-mail] [mailto:[e-mail]] On Behalf 
> Of Henk Uijterwaal
> Sent: Thursday, April 07, 2011 4:13 PM
> To: [e-mail]
> 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: [phone]
>
----------------------------------------------------------------------------
--
> 
> There appears to have been a collective retreat from reality that day.
>                                  (John Glanfield, on an engineering
> project)
> _______________________________________________
> ippm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ippm

_______________________________________________
ippm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ippm
_______________________________________________
ippm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ippm