Re: [ippm] WGLC for draft-ietf-ippm-twamp-value-added-octets-01.txt

Henk,

I object to progressing the draft in question at the present time,
for at least 4 reasons.

1) The new version clearly states :
   This memo is the product of a working prototype. It does not
   represent a consensus of the IETF community. The IETF community is
   currently working on the problem statement and has not reached
   consensus on the preferred method for measuring capacity metrics.
   ...
   This memo describes the protocol used in the current working
   prototype implementation of the Value-added octets feature in the
   Ericsson lab. The prototype has been tested in real network
   environments. The conclusion from these tests is that the Value-added
   octets feature is able to enable estimation of metrics such as
   available path capacity in both the forward and reverse direction of
   the network path.

This is the definition of an individual submission track document,
not a document to be submitted to the IESG as a product of the IPPM WG.
Furthermore, the document seems to be a candidate for an "experimental" RFC, 
not an "informational" one.

2) What is the relationship of this to "draft-morton-ippm-rate-problem"
and "draft-morton-ippm-twamp-rate" ?
I believe that the former is a problem statement for the same problem,
and the latter a somewhat different solution.

My understanding of the problem is to find a way of measuring 
"available bandwidth" / "delivery rate" / "path capacity" using TWAMP packet bursts.

I would really like to agree on the problem statement first,
and only afterwards decide on which of the two solutions we prefer.
Perhaps we could convince the authors of the two documents to merge them 
into a single proposal backed by the WG.

3) I disagree with the statement :
   The second measurement principle is referred to as self-induced
   congestion. According to this principle, in order to measure APC, TSC
   and UDP delivery rate, some trains MUST cause momentary congestion on
   the network path. In essence this means that some trains MUST be sent
   at a higher rate than what is available on the network path.

The idea of many burst proposals is to challenge the weakest-link buffer
and to observe the subsequent increase in inter-packet delay BEFORE causing congestion
(unless the word "congestion" here is being used in a some extended sense,
in which case this should be specified).

4) There are a few specific technical things I don't like about the draft in question.
For example, I don't like the use of flags + values when a value definition would suffice.
I don't like the complex mechanism of defining a "Desired Reverse Packet Interval",
and "Desired Reverse Padding Length" .
It is also not clear to me which features work for "TWAMP light"
or if all of this requires the control protocol.

However, these are minor issues as compared with the previous ones.

Y(J)S

-----Original Message-----
From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of Henk Uijterwaal
Sent: Thursday, March 29, 2012 12:29
To: IETF IPPM WG
Subject: [ippm] WGLC for draft-ietf-ippm-twamp-value-added-octets-01.txt

IPPM Group,

This starts a WGLC for the draft:

  TWAMP Value-Added Octets
  draft-ietf-ippm-twamp-value-added-octets-01.txt

Please review the draft and raise any issues by Monday, April 16, 2012,
8:00 UTC.

Matt & Henk

-- 
------------------------------------------------------------------------------
Henk Uijterwaal                           Email: henk(at)uijterwaal.nl
                                          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