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

  Hi Henk

 1) We have discussed this aspect last year and have agreed Informational is the best fit. The definitional of an Informational RFC (as defined in RFC 4677) is a specification that is created outside the IETF but is referenced by IETF documents or a precursor for work being done by IETF Working Groups.

 2) There is no relationship. This is for information only as a precursor to the problem statement.  We will be happy to work on the problem statement if the WG thinks it is beneficial.

 3) Yes the word congestion is used in a broad context here. In our working prototype, the accuracy of the results depends on having the inter-packet interval running near or “lower” the available capacity.  This is why the statement is there. I suggest debating a different phrasing in the problem statement.

  4) This draft mainly reflects the working prototype demonstrated in Prague in 2011. The prototype should work with any existing TWAMP modes including TWAMP light but it does not define a new TWAMP mode. We assume the work on the standard extension to the TWAMP protocol will be started after the work on the problem statement is completed. Is this correct?

  Regards
  Steve Baillargeon

----- Original Message -----
From: Yaakov Stein <yaakov_s@rad.com>
Date: Sunday, April 1, 2012 9:01 am
Subject: Re: [ippm] WGLC for draft-ietf-ippm-twamp-value-added-octets-01.txt
To: Henk Uijterwaal <henk@uijterwaal.nl>, IETF IPPM WG <ippm@ietf.org>

> 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
> _______________________________________________
> ippm mailing list
> ippm@ietf.org
> https://www.ietf.org/mailman/listinfo/ippm