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: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of
> Henk Uijterwaal
> Sent: Thursday, April 07, 2011 4:13 PM
> To: ippm@ietf.org
> 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
> ippm@ietf.org
> https://www.ietf.org/mailman/listinfo/ippm