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

[Christofer Flinta <[e-mail]>]

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