Subject: [ippm] Wrapping up

From: Henk Uijterwaal <[email-masked]>
Date: Mon, 09 Jan 2012 10:32:12 +0100

IPPM,

One of my new year's resolutions was to wrap up the work of this group.  Besides
the 2 drafts that were recently updated, there are these little items left on
our plate:

1. Draft-ietf-ippm-reporting-06.txt:
   There were some comments raised on WGLC.  Authors: please take a look at the
   archives and respond to them.

2. RFC5136 update RFC
   In Quebec, there was a proposal for an update draft from, IIRC, some of the
   Ericsson folks.  Nothing has happened since then, if people still feel that
   this document is needed, speak up.

3. TWAMP.
   a. Packet trains.  There has been some discussion on this with the conclusion
      that we need a document to specify what problem we want to solve .  Nobody
      took any action so-far.
   b. Yakov raised some issues with TWAMP in Prague but there was no follow-up,
      I suggest to table this.
   c. There is a suggestion to rewrite the entire spec, but as there is little
      momentum to work on (a) and (b), I suggest to table this as well.
   d. An Interop event has been mentioned, has there ever been one and did
      anything come out of it that is of interest to the group.

4. Draft-morton-ippm-testplan-rfc2679-01
   This is ongoing work (and meanwhile a WG doc) which we'll keep going.

If you are interested in working on any of these topics in the near future,
speak up now.  If nobody speaks up by January 23, 2012, I'm going to declare
them dead.  The near future is defined here as "the Paris IETF meeting",
that is, if you are interested in any of these topics, you don't have to
do anything by January 23, but I do expect significant progress on a topic
by Paris.

Henk

-- 
------------------------------------------------------------------------------
Henk Uijterwaal                           Email: henk(at)uijterwaal.nl
                                          http://www.uijterwaal.nl
                                          Phone: +31.6.55861746
------------------------------------------------------------------------------

There appears to have been a collective retreat from reality that day.
                                 (John Glanfield, on an engineering project)

---

From: Murtaza Chiba <[email-masked]>
Date: Mon, 9 Jan 2012 11:44:20 -0800

Hello All,
     Happy new year to all. We (the authors) would love to hear comments on
the Cisco SLA Protocol draft. The related IPR statement has been sent to
the list just before the new year. The IPR statement, in brief, is a
defensive non-discriminatory clause.

Draft:
http://www.ietf.org/id/draft-cisco-sla-protocol-00.txt

IPR Statement:
https://datatracker.ietf.org/ipr/1659/

Thanks and Regards,
-murtaza

On Mon, Jan 9, 2012 at 1:32 AM, Henk Uijterwaal <[email-masked]> wrote:

> _______________________________________________
> ippm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ippm
>

---

From: Henk Uijterwaal <[email-masked]>
Date: Tue, 10 Jan 2012 08:20:42 +0100

Murtaza,

>      Happy new year to all. We (the authors) would love to hear comments on the
> Cisco SLA Protocol draft. The related IPR statement has been sent to the list
> just before the new year. The IPR statement, in brief, is a defensive
> non-discriminatory clause. 

Happy new year to you too.  I suggest to follow the same approach for this as
for the other open items.  If people in the IPPM WG are interested in this
topic and have cycles to work on it, speak up in the next 2 weeks, if not, we
should discuss where this draft fits best.  We is defined as you plus fellow
authors, the AD and IPPM chairs.

Henk

> On Mon, Jan 9, 2012 at 1:32 AM, Henk Uijterwaal <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     IPPM,
> 
>     <http://uijterwaal.nl>
>     <tel:%2B31.6.55861746>
>     [email-masked] <mailto:[email-masked]>

---

From: <[email-masked]>
Date: Tue, 10 Jan 2012 08:47:18 +0100

Hi Hank,

I plan to work on this draft.

Regards,

Ruediger

---

From: Al Morton <[email-masked]>
Date: Sun, 15 Jan 2012 21:47:55 -0500

> > https://datatracker.ietf.org/ipr/1659/

Now that the IPR situation is clarified, I reviewed the draft.
I encourage others to read this, it is a low-complexity alternative
to TWAMP with the security features that TWAMP-Light lacks.

My comments are below, I'm willing to work this further.
Al

In a couple of places, I saw configuration specifications
in the protocol spec. These need to formalized if they
are to be included, or removed (or identified more clearly as examples?)
where they don't seem appropriate.

Section 2:
    The Measurement Phase forms the second phase and is comprised of a
    sequence of Request/Response messages.  These messages may be
    exchanged as often as required.  The number and frequency with which
    messages are sent is controlled by configuration on the Sender
    element.
I suggest:
    ... The number and frequency with which
    messages are sent SHOULD be controlled by configuration on the Sender
    element, along with the waiting time for a Control Response.

2.2.  Measurement Phase

    Upon receiving the Control Response message with the Status set to
    Success, the second phase of the protocol, the Measurement Phase, is
    initiated.  In all other cases when the Status is not success no
    measurement traffic is initiated.  In the Measurement Phase the
    Sender sends a stream of measurement messages.  The measurement
    message stream consists of packets/frames that are spaced a
    configured number of milliseconds apart.

I suggest that the description of the measurement stream become an example:

The measurement stream typically consists of packets/frames with a
periodic inter-packet distribution [RFC3432] or pseudo-random
distribution.

Also, I suggest to make the following statement clear with words to
this effect:

The Sender need not wait for a Measurement Response packet to arrive
before sending another Measurement Request packet, and in many cases it
will not be possible in order to maintain the desired inter-packet
distribution.

2.1.1.1.  Command Header

    The Command Header fields hold the following meaning:
...
    | --------- | --------- | --------------------------                |
    | Send      | 64        | This field is set to the time the command |
    | Timestamp |           | was sent and is updated for a response.   |
    |           |           | This field MAY be used for secure         |
    |           |           | environment.  SHOULD be updated for a     |
    |           |           | response.  When not being used it MUST be |
    |           |           | set to all 0's.  The format is as given   |
    |           |           | in RFC1305                                |
    +-----------+-----------+-------------------------------------------+

There's some ambiguity in when a packet "was sent" when the timestamp
must be inserted before sending takes place, of course. I suggest

s/was sent/submitted to stack for transmission/

or similar sentiment.

That's what I have so far.

---

From: Al Morton <[email-masked]>
Date: Sun, 15 Jan 2012 22:17:30 -0500

At 04:32 AM 1/9/2012, Henk Uijterwaal wrote:
>     that we need a document to specify what problem we want to solve.  Nobody
>       took any action so-far.

Actually, some progress has been made on this topic.

I prepared a problem statement draft prior to Taipei,
and discussed it with several people at the meeting.
Dave McDysan kindly gave me comments, which I've incorporated
into the 01 version. Others have offered to provide comments,
and an updated draft is now ready.

Al

A New Internet-Draft is available from the on-line Internet-Drafts directories.

         Title           : Rate Measurement Problem Statement
         Author(s)       : Al Morton
         Filename        : draft-morton-ippm-rate-problem-01.txt
         Pages           : 7
         Date            : 2012-01-15

    There is a rate measurement scenario which has wide-spread attention
    of users and seemingly all industry participants, including
    regulators.  This memo presents an access rate-measurement problem
    statement for IP Performance Metrics.  Key aspects require the
    ability to control packet size on the tested path and enable
    asymmetrical packet size testing in a controller-responder
    architecture.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-morton-ippm-rate-problem-01.txt

---

From: Henk Uijterwaal <[email-masked]>
Date: Mon, 16 Jan 2012 09:25:04 +0100

IPPM group,

Two things have happened in this area in the last week:

 a) The authors of draft-baillargeon-ippm-twamp-value-added-octets-02.txt
    have asked for this document to be published as an informational RFC,
    with the goal of documenting the work done by them.

    As a chair, I think this is a reasonable request.  The problem that this
    draft tries to solve is close to what we think the generic problem is and
    the work done for this draft shows that the problem can be solved.  I
    think that it'd be good if this is documented in a permanent way.

 b) draft-morton-ippm-rate-problem-01.txt has been submitted.  I think
    I missed the -00 version of this, but at a first glance, this is a
    step towards a problem statement and a general solution for the
    problem.

    For this document, I'd like to see some review from the group and
    get a feeling if there is sufficient energy left from the group
    to work on this.

If you have opinions on either one of these, please speak up in the next
week.

Henk

---

From: Greg Dowd <[email-masked]>
Date: Mon, 16 Jan 2012 16:10:45 +0000

One nit is that RFC1305 for the timestamp format is obsoleted by RFC5905.

Greg Dowd
gdowd at symmetricom dot com (antispam format)
Symmetricom, Inc.
www.symmetricom.com
"A clever person solves a problem.  A wise person avoids it." Albert Einstein

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Al Morton
Sent: Sunday, January 15, 2012 6:48 PM
To: [email-masked]; [email-masked]; mchiba
Subject: [ippm] Comments on draft-cisco-sla-protocol- [was: Re: Wrapping up]

Section 2:

2.2.  Measurement Phase

2.1.1.1.  Command Header

or similar sentiment.

---

From: Al Morton <[email-masked]>
Date: Mon, 16 Jan 2012 11:20:08 -0500

>One nit is that RFC1305 for the timestamp format is obsoleted by RFC5905.

Good catch, Greg.
Al

---

From: Yaakov Stein <[email-masked]>
Date: Mon, 16 Jan 2012 18:04:28 +0000

Henk

I am still interested in working on the packet trains issue 
(insofar as it related to measuring available bandwidth)
and the TWAMP issues I raised in the past.

I haven't had free cycles to get down to writing anything,
but was planning doing so before the next meeting.

Y(J)S

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Henk Uijterwaal
Sent: Monday, January 09, 2012 11:32
To: IETF IPPM WG
Subject: [ippm] Wrapping up

IPPM,

2. RFC5136 update RFC

3. TWAMP.

Henk

---

From: Al Morton <[email-masked]>
Date: Mon, 16 Jan 2012 15:42:54 -0500

>    This is ongoing work (and meanwhile a WG doc) which we'll keep going.
As I mentioned during presentation of this work last July,
we were able to expand our test scope while all the equipment was
running and complete some additional tests for RFC 2680.
An early draft of the -rfc2680-00 test plan was available
in Taipei, and we added additional material describing the
categories of testing shortly after that. Although the results
have yet to be added, sub-sections of section 6 indicate the
different areas that were examined.

Al

         Title           : Test Plan and Results for Advancing RFC 
2680 on the Standards Track
         Author(s)       : Len Ciavattone
                           Ruediger Geib
                           Al Morton
                           Matthias Wieser
         Filename        : draft-morton-ippm-testplan-rfc2680-01.txt
         Pages           : 21
         Date            : 2012-01-16

    This memo proposes to advance a performance metric RFC along the
    standards track, specifically RFC 2680 on One-way Loss Metrics.
    Observing that the metric definitions themselves should be the
    primary focus rather than the implementations of metrics, this memo
    describes the test procedures to evaluate specific metric requirement
    clauses to determine if the requirement has been interpreted and
    implemented as intended.  Two completely independent implementations
    have been tested against the key specifications of RFC 2680.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-morton-ippm-testplan-rfc2680-01.txt

---

From: Ionta Tiziano <[email-masked]>
Date: Tue, 17 Jan 2012 09:05:32 +0100

IPPM,
I'm strongly interested in draft-cisco-sla-protocol-00, since I've been hardly working (as Service Provider) on Cisco IPSLA for 6 years, collecting many feedbacks and enhancement proposals about it.
Therefore I believe this draft (to be maintained inside the IPPM WG) would be the right place to gather my work mentioned above and share it with the IPPM WG.
In order to actively participate in the draft-cisco-sla-protocol-00 review I just need some more time to deeply analyze it and to wrap up my last 6 years notes about it.
Tiziano

-----Messaggio originale-----
Da: [email-masked] [mailto:[email-masked]] Per conto di Henk Uijterwaal
Inviato: martedì 10 gennaio 2012 8.21
A: [email-masked]
Oggetto: Re: [ippm] Wrapping up

Murtaza,

Henk

>     do anything by January 23, but I do expect significant progress on a topic

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

---

From: Murtaza Chiba <[email-masked]>
Date: Tue, 17 Jan 2012 08:55:12 -0800

Thanks Al and Greg,
     The suggestions are great. I will make the changes accordingly.

Regards,
-murtaza

---

From: Murtaza Chiba <[email-masked]>
Date: Tue, 17 Jan 2012 08:56:16 -0800

Hello Tiziano,
    We would love to hear from you. Please do send us your comments.

Regards,
-murtaza

On Tue, Jan 17, 2012 at 12:05 AM, Ionta Tiziano <
[email-masked]> wrote:

> IPPM,
> I'm strongly interested in draft-cisco-sla-protocol-00, since I've been
> hardly working (as Service Provider) on Cisco IPSLA for 6 years, collecting
> many feedbacks and enhancement proposals about it.
> Therefore I believe this draft (to be maintained inside the IPPM WG) would
> be the right place to gather my work mentioned above and share it with the
> IPPM WG.
> In order to actively participate in the draft-cisco-sla-protocol-00 review
> I just need some more time to deeply analyze it and to wrap up my last 6
> years notes about it.
> Tiziano
>
>
> Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle
> persone indicate. La diffusione, copia o qualsiasi altra azione derivante
> dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora
> abbiate ricevuto questo documento per errore siete cortesemente pregati di
> darne immediata comunicazione al mittente e di provvedere alla sua
> distruzione, Grazie.
>
> This e-mail and any attachments is confidential and may contain privileged
> information intended for the addressee(s) only. Dissemination, copying,
> printing or use by anybody else is unauthorised. If you are not the
> intended recipient, please delete this message and any attachments and
> advise the sender by return e-mail, Thanks.
>

---

From: Henk Uijterwaal <[email-masked]>
Date: Tue, 24 Jan 2012 12:01:32 +0100

IPPM Group,

>    archives and respond to them.

I have not seen any action so this topic is dead.

>    this document is needed, speak up.

I have not seen any action so this topic is dead.

>       that we need a document to specify what problem we want to solve .  Nobody

Two things happened here:

* A request to publish draft-baillargeon-ippm-twamp-value-added-octets-02.txt

* Draft-morton-ippm-rate-problem-01.txt was published.
  Please comment on this document.

>    b. Yakov raised some issues with TWAMP in Prague but there was no follow-up,

This will remain on the active list for now, as Yakov has indicated that he will
do work on this before Paris.

>       anything come out of it that is of interest to the group.

Apparently not, so no follow up needed.

>    This is ongoing work (and meanwhile a WG doc) which we'll keep going.

5. Other work:

* draft-cisco-sla-protocol-00.txt
* draft-ionta-new-multiparty-metrics-framework-00

If you are interested in either draft, please speak up.

Henk