Subject: Re: [ippm] I: I-D Action: draft-ietf-ippm-alt-mark-01.txt

From: Qin Wu <[email-masked]>
Date: Tue, 27 Sep 2016 07:34:46 +0000

Hi, Giuseppe:
I have taken a pass on this document and have the following comments and suggestions:
Minor issues:
1. Introduction, paragraph 4 said:
"
  It doesn't
   require any protocol extension or interaction with existing
   protocols, thus avoiding any interoperability issue.  Even if the
   method doesn't raise any specific need for standardization, it could
   be further improved by means of some extension to existing protocols,
   but this aspect is left for further study and it is out of the scope
   of this document.
"
Do we really need this paragraph, it confuses me a lot. in the first sentence, it said  protocol extension is not needed, in the second sentence, it said extension to existing protocol can be used to improve this method, these two sentences are not consistent, in addition, it said this method doesn't need to be standardized in some case, I am wondering if it doesn't need to be standardized, why produce this document?
Suggest to remove these two sentences.

2.Introduction, paragraph 5 said:
"
   The method described in this document, also called PNPM (Packet
   Network Performance Monitoring), has been invented and engineered in
   Telecom Italia and it's currently being used in Telecom Italia's
   network.
"
I can see this method has been implemented in TI network, but it doesn't need to be emphasized in the introduction and abstract, It make people to feel this spec is TI specific standard, :-),which is not true.
I would suggest to remove this statement from spec or move them to implementation report section.

3.Introduction, paragraph 5 said:
"
The previous IETF drafts about this technique were:
   [I-D.cociglio-mboned-multicast-pm] and [I-D.tempia-opsawg-p3m].
   There are some references to this methodology in other IETF works
   (e.g.  [I-D.ietf-mpls-flow-ident], [I-D.bryant-mpls-sfl-framework]
   [I-D.bryant-mpls-rfc6374-sfl], [I-D.ietf-bier-mpls-encapsulation],
   [I-D.mirsky-bier-pmmm-oam]
   [I-D.chen-ippm-coloring-based-ipfpm-framework]).
"
It doesn't need to emphasize the history of this document, I would suggest to create acknowledgement section, move text there.

4. Section 3.1
What is clock error?
How this is related to wait L/2 time units after color switching based on fixed timer?
In this document, it introduce two color switching method, one is based on fixed number of packet, the other is based on fixed timer, I am wondering whether clock error is only applied to color switching based on fixed timer, or applied to both?

5.Section 3.2.3, paragraph 1
Why the second marking is needed? Why we can not calculate minimum and maximum delay based on single marking methodology?

6. Section 3.2.3, paragraph 2 said:
"
Basically, the idea is to use the first marking to create the
   alternate flow and, within this colored flow, a second marking  to
   select the packets for measuring delay/jitter .
"
Is second marking and first marking applied to the same colored flow? Can you give an example to explain what double marking looks like?
Why measure jitter is needed in the one way delay measurement?

7. Section 3.3
Can you detail on how delay variation is calculated in this case?

8.Section 4.1, paragraph 1
Not sure packet loss measurement requires synchronization between two network devices?

9.Section 4.1, paragraph 3 said:
"
The synchronization requirement can be satisfied even with a
   relatively inaccurate synchronization method.
"
Give you give an example of inaccurate sync method? This sentence needs to be expanded to add more details.

10. Section 4.2
Why Data correlation is required in this method? It will be great to see some justification text at the beginning of this section before touching data correlation details.

11.Section 5
Not sure implementation and deployment is part of this spec, either move them to appendix or removed it from this spec.

12. Section 6 paragraph 1 said:
"
The method has been explicitly designed for passive measurements but
   it can also be used with active measurements .
"
This section seems not discuss how method is used in the active measurement? Why active measurement should use this method?

13. Section 6 paragraph 1 said:
"
In order to have both
   end to end measurements and intermediate measurements (hybrid
   measurements ) two end points can exchanges artificial traffic flows
   and apply alternate marking over these flows.  In the intermediate
   points artificial traffic is managed in the same way as real traffic
   and measured as specified before.
"
Is hybrid measurement about combination of passive measurement and active measurement or combination of end to end measurement and intermediate measurement?

Editorial issues and Nits
1. Section 1, 3rd paragraph:
OLD TEXT:
"
A lot of work related to OAM, that includes also performance
   monitoring techniques, has been done by Standards Developing
   Organizations:
"
NEW TEXT:
"
A lot of work related to OAM, that includes also performance
   monitoring techniques, has been done by Standards Developing
   Organizations(SDOs):
"
2.Section 1, 3rd paragraph
OLD TEXT:
"
The IPPM WG has defined standard metrics to
   measure network performance; however, the methods developed in the WG
   mainly refer to refer to active measurement techniques.
"
NEW TEXT:
"
The IPPM WG has defined standard metrics to
   measure network performance; however, the methods developed in this WG
   mainly refer to focus on active measurement techniques.
"
3.Section 4.2 and 4.3 2nd paragraph
OLD TEXT:
"
   In the following paragraphs an example data correlation mechanism is
   explained and could be use independently of the adopted solutions.
"
NEW TEXT:
"
   In the following paragraphs an example of data correlation mechanism is
   explained and could be use independently of the adopted solutions.
"
4.Section 9
OLD TEXT:
"
The method doesn't raise any specific need for standardization, but
   it could be further improved by means of some extension to existing
   protocols.
"
NEW TEXT:
"
The method doesn't raise any specific need for protocol extension, but
   it could be further improved by means of some extension to existing
   protocols.
"

-Qin
-----Messaggio originale-----
Da: ippm [mailto:[email-masked]] Per conto di Fioccola Giuseppe
Inviato: giovedì 7 luglio 2016 17:24
A: [email-masked]; [email-masked]
Oggetto: [ippm] I: I-D Action: draft-ietf-ippm-alt-mark-01.txt

Hi All,
This new version of draft-ietf-ippm-alt-mark includes part of the contents of draft-chen-ippm-coloring-based-ipfpm-framework.
The authors have merged some Sections regarding Re-ordering Tolerance, Synchronization Aspects, Security Considerations and other general concepts.

Best Regards,

Giuseppe

-----Messaggio originale-----
Da: ippm [mailto:[email-masked]] Per conto di [email-masked]
Inviato: giovedì 7 luglio 2016 16:33
A: [email-masked]
Cc: [email-masked]
Oggetto: [ippm] I-D Action: draft-ietf-ippm-alt-mark-01.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Performance Metrics of the IETF.

        Title           : Alternate Marking method for passive performance monitoring
        Authors         : Giuseppe Fioccola
                          Alessandro Capello
                          Mauro Cociglio
                          Luca Castaldelli
                          Mach(Guoyi) Chen
                          Lianshu Zheng
                          Greg Mirsky
                          Tal Mizrahi
        Filename        : draft-ietf-ippm-alt-mark-01.txt
        Pages           : 29
        Date            : 2016-07-07

Abstract:
   This document describes a passive method to perform packet loss,
   delay and jitter measurements on live traffic.  This method is based
   on Alternate Marking (Coloring) technique.  A report on the
   operational experiment done at Telecom Italia is explained in order
   to give an example and show the method applicability.  This technique
   can be applied in various situations as detailed in this document.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ippm-alt-mark/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-ippm-alt-mark-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-alt-mark-01

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

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.

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

---

From: Fioccola Giuseppe <[email-masked]>
Date: Wed, 28 Sep 2016 17:59:16 +0000

Hi Qin,

Thanks for your detailed reviews and valuable suggestions.

I will address your comments in the next version of the draft.

Please see my answers inline.

Best Regards,

Giuseppe

-----Messaggio originale-----

Da: Qin Wu [mailto:[email-masked]]

Inviato: martedì 27 settembre 2016 09:35

A: IETF IPPM WG

Cc: Fioccola Giuseppe

Oggetto: RE: [ippm] I: I-D Action: draft-ietf-ippm-alt-mark-01.txt

Hi, Giuseppe:

Minor issues:

"

  It doesn't

   of this document.

"

[GF] I fully agree. These sentences are inherited by oldest version of the draft so are now obsolete. For instance in this version we mention the RFC6374 and Overlay OAM use case where a protocol modification is needed.

"

   network.

"

[GF] I agree. I will move it to implementation/report section.

"

"

[GF] I agree. I will move it to acknowledgements section.

4. Section 3.1

What is clock error?

[GF] It is only applied to color switching based on fixed timer. This is preferable to the method based on a fixed number of packets.

I agree, we need to explain better this concept.

In case we have only clock error between network devices, they must be synchronized to the same clock reference with an accuracy of +/- L/2 time units. In this way, in theory, you are able to recognize the right packet marked batch along your path.

But, in practice, you can have also out of order at batch boundaries, strictly related to the maximum delay between measurement points, so, without considering clock error, we wait L/2 after color switching to be sure to take a still counter.

In summary we have two errors: clock error between network devices and the interval we need to wait to avoid out of order because of network delay. If we consider one-by-one these two problems the limit value is L/2.

If we consider both issues we should say:

-L/2 < (maximum clock error + maximum network delay) < L/2

I want to add this formula in the next version.

This will address also the suggestion from Jose Ignacio during Berlin presentation.

[GF] We can do that also with single marking methodology: we store timestamp of the first or last packet of a batch and that timestamp can be compared with the timestamp of the same packet along the path.

But this option does not work in case of out of order. The option in case of single marking, that escapes out of order issue, is average delay.

"

"

[GF] Second marking selects some packets dedicated for delay measurement within first marking. This option works in case of out of order because you can always recognize the second marked packets.

But between this second marked packets we need a security gap in order to avoid out of order issue between these packets.

7. Section 3.3

[GF] The calculation of delay variation is similar to the delay. We refer to the definition in RFC 3393. But I will explain how to do in the next version.

[GF] The strength of this method is that it needs a synchronization accuracy of +/- L/2 (without considering network delay), in this way all network devices consistently match the color bit to the correct block.

"

"

[GF] For instance, if you choose a marking interval of 5minutes, you can have all network devices 2m and 30s asynchronous (without considering network delay).

10. Section 4.2

[GF] We need data correlation to compare counters and timestamps for packet loss, delay and jitter calculation. I will add some text to explain better.

11.Section 5

[GF] We could move that to appendix.

"

"

[GF] This is explained in draft-fioccola-ippm-alt-mark-active. But the application of marking method can simplify also the active measurement and can enable hybrid measurements.

"

In order to have both

"

[GF] Both

OLD TEXT:

"

   Organizations:

"

NEW TEXT:

"

   Organizations(SDOs):

"

OLD TEXT:

"

"

NEW TEXT:

"

"

OLD TEXT:

"

"

NEW TEXT:

"

"

4.Section 9

OLD TEXT:

"

   protocols.

"

NEW TEXT:

"

   protocols.

"

[GF] Thanks for all editorial changes.

-Qin

-----Messaggio originale-----

A: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Hi All,

Best Regards,

Giuseppe

-----Messaggio originale-----

Da: ippm [mailto:[email-masked]] Per conto di [email-masked]<mailto:[email-masked]>

A: [email-masked]<mailto:[email-masked]>

Cc: [email-masked]<mailto:[email-masked]>

                          Alessandro Capello

                          Mauro Cociglio

                          Luca Castaldelli

                          Mach(Guoyi) Chen

                          Lianshu Zheng

                         Greg Mirsky

                          Tal Mizrahi

        Pages           : 29

        Date            : 2016-07-07

Abstract:

ippm mailing list

[email-masked]<mailto:[email-masked]>

ippm mailing list

[email-masked]<mailto:[email-masked]>