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

From: Yaakov Stein <[email-masked]>
Date: Sun, 1 Apr 2012 12:31:47 +0000

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: [email-masked] [mailto:[email-masked]] 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
[email-masked]
https://www.ietf.org/mailman/listinfo/ippm

---

From: [email-masked]
Date: Sun, 01 Apr 2012 17:25:17 -0400

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 <[email-masked]>
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 <[email-masked]>, IETF IPPM WG <[email-masked]>

>    Ericsson lab. The prototype has been tested in real 
> network   environments. The conclusion from these 
> tests is that the Value-added
> 2) What is the relationship of this to "draft-morton-ippm-rate-
> problem"and "draft-morton-ippm-twamp-rate" ?

---

From: Henk Uijterwaal <[email-masked]>
Date: Mon, 02 Apr 2012 15:52:31 +0200

Yaakov, others,

> not a document to be submitted to the IESG as a product of the IPPM WG.

I understand the problem.  The reason I asked for this to make
it a WG document is that I think the WG should review this document.  The
document describes a problem plus a prototype implementation of a solution.
I think it is good to have a good description of the prototype, that has
been reviewed by the entire WG for clarity/completeness/etc of the prototype,
even if the problem we ultimately have to solve is different or we may
decide on a completely different approach towards solving the problem.

So, what I hope the first paragraph ("This memo is ... metrics") says is
"somebody in the WG did an experiment, the WG saw that it solved something
close to an existing problem, the write-up of the experiment is clear").
If it doesn't then I've done something wrong :-)

> not an "informational" one.

I think I agree with Steve that "informational" is the best fit, but reading
 http://www.ietf.org/u/ietfchair/info-exp.html suggests that "experimental"
might be a good choice either.  I don't think this matters too much at this
stage of the discussion though.

Henk

                                          http://www.uijterwaal.nl

---

From: Al Morton <[email-masked]>
Date: Mon, 02 Apr 2012 10:09:09 -0400

>Please review the draft and raise any issues by Monday, April 16, 2012,

Hi Henk and Matt,

When I read:
At 05:54 AM 1/24/2012, Henk Uijterwaal wrote:
>The authors of draft-baillargeon-ippm-twamp-value-added-octets-02.txt
>have asked for this document to be published as an informational RFC,
>by the WG, with the goal of documenting the work done by them.

I wasn't happy with the informational-only approach,
but I figured that it was a decent compromise if the authors
published the Ericsson IPR-encumbered work by itself,
and then let the rest of the WG proceed with defining the problem
and deciding on a standards track solution.

No one else objected either, but then:

- The authors published -value-added-octets with a WG document filename
   (which confuses things, it has not represented WG consensus at
    any stage)
- The authors modified the draft to adopt the function
   of asymmetrical packet size test capability and possibly
   other functions identified in the problem statement draft
   (and in my talk at IETF-80 in Prague).
- The authors now claim to have simplified their protocol, after
   discounting the WG's comments on the complexity of their approach
   for about a year.

Adding features which they didn't suggest/invent, and reversing their
position on protocol complexity means that the current draft does not meet
the goal of "documenting work done by them", and instead lands in a
middle-ground of "partly addresses WG comments and the problem statement".
I don't think that's fair or useful.

So, I still have no objection if the WG documents the individual
draft-baillargeon-ippm-twamp-value-added-octets-02.txt (not -03 or other)
with *Historic* status prepared on the way to a WG consensus solution,
IF it means the WG can close the unproductive discussion on this draft.

To me, the authors have circumvented the WG process with their
current text, waving the "this is how the prototype works now" flag.
It takes benefit from contributions under Note Well, and includes
ideas of others contributed to the IETF IPPM WG which are not theirs.
I object to publishing the current text, and I note that a new IPR
disclosure is likely needed for it.

I also appreciate Yaakov's comment attached below, that the
Introduction's disclaimer describes an RFC Editor Stream submission,
which is yet another way that authors publish alternative ideas
outside the IETF Stream and remains a viable option for them.

regards,
Al

...

---

From: Steve Baillargeon <[email-masked]>
Date: Mon, 2 Apr 2012 12:04:14 -0400

Hi
 
>>>The authors published -value-added-octets with a WG document filename(which confuses things, it has not represented WG consensus at   any stage)

My take on it is that it is OK for an Informational RFC: a subset did the work, the entire WG was asked to review the write-up.

>>>The authors modified the draft to adopt the function of asymmetrical packet size test capability and possibly other functions identified in the problem statement draft.

The only field we added in 03 is Desired Reverse Padding Length. We showed a prototype @ IETF-80, people came up with suggestions, we showed that our prototype could be extended.

>>>The authors now claim to have simplified their protocol, after discounting the WG's comments on the complexity of their approach for about a year.

The only field we removed in 03 is the Sender Discriminator since it is not specifically related to capacity measurements. Sender Discriminator looked like a good idea at the time @ IETF80 but then wasn't used during our demo and is now dropped.

Regards
Steve B

---

From: <[email-masked]>
Date: Tue, 3 Apr 2012 09:50:20 +0200

Chairs,

could you clarify your idea of the process making value-added-octets an informational?
I understand Al's position. I myself am not clear whether Al's view is following
the process rules (and I don't know what exactly the process is). Please let me hear your
version.

Al wrote

As there is an IPR issue and the WG compromise seems to have been to publish value-added-octets
with functionality as demonstrated during IETF 80, I favour sticking to that.

I agree with Al and Yaakov that it is not appropriate incorporate features discussed
under note well into an IPR protected solution. I don't think it is apropriate to continue to
change technical features described in this publication before it's IETF stamped as informational .
It is not relevant whether these changes are small. Apart from that the authors refuse to refer to
other IETF work while they seem to integrate functionality resulting from this work into their
prototype. If that's true (and it again doesn't matter whether changes are big or small), it's
not agreeable.

Regards,

Ruediger

---

From: Henk Uijterwaal <[email-masked]>
Date: Tue, 03 Apr 2012 11:21:28 +0200

Ruediger,

> could you clarify your idea of the process making value-added-octets an informational?

As I said before, I think it is good to have a document describing the prototype
developped by the authors, that has been reviewed by the entire WG for clarity
and completeness.  We do not agree on the problem that there is to be solved, we
don't agree either if this is the best solution, but I believe we agree that the
prototype solves something close to the actual problem.  That suggests, at least
to me, to make it an informational document that can be properly referenced in
the future.  Note that I have specifically never asked for consensus about the
problem statement or the solution chosen, just if the description is clear.

> prototype. If that's true (and it again doesn't matter whether changes are big or small), it's

I'm not sure if I understand this.  There is the prototype (with IPR), there are
suggestions made by others (under the note-well). The latter have been
incorporated into the prototype, but, as far as I understand, that doesn't
put them under the IPR.  In other words, we can still use those suggestions
in another solution when we come to that.  Or am I missing something here?

Henk

---

From: <[email-masked]>
Date: Tue, 3 Apr 2012 12:09:08 +0200

Henk,

thanks, that's what you've said so far. My question is:

- Al says, agreement was to make ID -value-added-octets-02 an
  informational, and Al's interpretation is "as was written".
- now it is a WG draft and it continues to change.

Is that appropriate from your point of view? Reading your reply, I don't
understand whether you've clearly answered this. I don't see a need for
a fast reply, if you need time to think about it. My impression is, that
leaving that open may block the standardisation progress on the technical
issues behind that.

The issue I see is, if we continue to work on the problem and possible
solutions, the draft-documentation and functionality of the prototype
may continue to be adapted as well. The question then is, what's the
purpose of a second standards track document, if the very same solutions
may be found in the informational? I think, that's not what the WG
has agreed to do.

Of course the prototype may be enhanced by features, standard or proprietary,
after -value-added-octets has been published as informational.

Regards,

Ruediger

-----Original Message-----
From: Henk Uijterwaal [mailto:[email-masked]]
Sent: Tuesday, April 03, 2012 11:21 AM
To: Geib, Rüdiger
Cc: [email-masked]; [email-masked]
Subject: Re: [ippm] WGLC for draft-ietf-ippm-twamp-value-added-octets-01.txt

Ruediger,

Henk

---

From: Steve Baillargeon <[email-masked]>
Date: Tue, 3 Apr 2012 06:22:00 -0400

Hi
Henk is correct.
The only new field, Desire Reverse Padding Length is not covered by the IPR.
We were inspired from the field "Padding Length" that is already defined in the OWAMP spec dated Sept 2006.
We are open to remove it.

-Steve

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: April-03-12 6:09 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [ippm] WGLC for draft-ietf-ippm-twamp-value-added-octets-01.txt

Henk,

Is that appropriate from your point of view? Reading your reply, I don't understand whether you've clearly answered this. I don't see a need for a fast reply, if you need time to think about it. My impression is, that leaving that open may block the standardisation progress on the technical issues behind that.

The issue I see is, if we continue to work on the problem and possible solutions, the draft-documentation and functionality of the prototype may continue to be adapted as well. The question then is, what's the purpose of a second standards track document, if the very same solutions may be found in the informational? I think, that's not what the WG has agreed to do.

Of course the prototype may be enhanced by features, standard or proprietary, after -value-added-octets has been published as informational.

Regards,

Ruediger

-----Original Message-----
From: Henk Uijterwaal [mailto:[email-masked]]
Sent: Tuesday, April 03, 2012 11:21 AM
To: Geib, Rüdiger
Cc: [email-masked]; [email-masked]
Subject: Re: [ippm] WGLC for draft-ietf-ippm-twamp-value-added-octets-01.txt

Ruediger,

> could you clarify your idea of the process making value-added-octets an informational?

As I said before, I think it is good to have a document describing the prototype developped by the authors, that has been reviewed by the entire WG for clarity and completeness.  We do not agree on the problem that there is to be solved, we don't agree either if this is the best solution, but I believe we agree that the prototype solves something close to the actual problem.  That suggests, at least to me, to make it an informational document that can be properly referenced in the future.  Note that I have specifically never asked for consensus about the problem statement or the solution chosen, just if the description is clear.

> I agree with Al and Yaakov that it is not appropriate incorporate 
> features discussed under note well into an IPR protected solution. I 
> don't think it is apropriate to continue to change technical features described in this publication before it's IETF stamped as informational .
> It is not relevant whether these changes are small. Apart from that 
> the authors refuse to refer to other IETF work while they seem to 
> integrate functionality resulting from this work into their prototype. 
> If that's true (and it again doesn't matter whether changes are big or small), it's not agreeable.

I'm not sure if I understand this.  There is the prototype (with IPR), there are suggestions made by others (under the note-well). The latter have been incorporated into the prototype, but, as far as I understand, that doesn't put them under the IPR.  In other words, we can still use those suggestions in another solution when we come to that.  Or am I missing something here?

Henk

There appears to have been a collective retreat from reality that day.
                                 (John Glanfield, on an engineering project) _______________________________________________
ippm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ippm

---

From: Wesley Eddy <[email-masked]>
Date: Tue, 03 Apr 2012 11:02:44 -0400

> My take on it is that it is OK for an Informational RFC: a subset did the work, the entire WG was asked to review the write-up.

In similar cases, the document title (not to be confused with
the filename) has clearly specified whose work it reflects.
For instance, the document title is currently:
"TWAMP Value-Added Octets"
it could be something like:
"Ericsson's TWAMP Value-Added Octets"

I think that would be more clear for the record, rather than
messing with the filename, which disappears from view once it's
published as an RFC.

> The only field we removed in 03 is the Sender Discriminator since it is not specifically related to capacity measurements. Sender Discriminator looked like a good idea at the time @ IETF80 but then…

To address the comments about confusion as to which parts
reflect the pre-WG activity, and which parts have been
incorporated after IPPM WG feedback, it might make sense
to just have a small bit of text in section 1 to say that
it started as an Ericsson project, but currently incorporates
some feedback from the IPPM working group.  This would, I
think, enhance the paragraph currently right before Section 1.1.

You might list the things that reflect that feedback (e.g. the
desired reverse padding length and removal of sender
discriminator) an an appendix or something, if you want to be
ultra-clear.

-- 
Wes Eddy
MTI Systems

---

From: Al Morton <[email-masked]>
Date: Tue, 03 Apr 2012 11:37:26 -0400

I agree that the title change helps to clarify the situation,
but I also accept Steve's offer to remove the non-Ericsson
idea from the text, specifically the "Padding Length" feature.
(The single sentence or Appendix within the document would contradict
the title, and again cause confusion.)

regards,
Al

At 11:02 AM 4/3/2012, Wesley Eddy wrote:
> >>>> The authors published -value-added-octets with a WG document 
> filename(which confuses things, it has not represented WG consensus 
> at   any stage)
> >
> > My take on it is that it is OK for an Informational RFC: a subset 
> did the work, the entire WG was asked to review the write-up.
> >
>
>
> >>>> The authors modified the draft to adopt the function of 
> asymmetrical packet size test capability and possibly other 
> functions identified in the problem statement draft.
> >
> > The only field we added in 03 is Desired Reverse Padding Length. 
> We showed a prototype @ IETF-80, people came up with suggestions, 
> we showed that our prototype could be extended.
> >
> >>>> The authors now claim to have simplified their protocol, after 
> > The only field we removed in 03 is the Sender Discriminator since 
> it is not specifically related to capacity measurements. Sender 
> Discriminator looked like a good idea at the time @ IETF80 but then 
> wasn't used during our demo and is now dropped.
>
>