Subject: [ippm] I: New Version Notification for draft-fioccola-ippm-multipoint-alt-mark-01.txt

From: Fioccola Giuseppe <[email-masked]>
Date: Mon, 30 Oct 2017 11:29:20 +0000

Hi IPPM,
We have updated the draft to address the comment received in Prague from Al Morton about considering RFC5644 relevant for this work.
The feeling is that the multipoint alternate marking considerations extend the scope of RFC5644 to Passive/Hybrid Performance Measurements and also to multi source stream. A new section "Correlation with RFC5644" has been added. Some terminologies and definitions can be re-used from RFC5644 (e.g. spatial, segment, multiparty, one-to-group metrics and also group-to-group topologies), but they have to be rephrased to be applied to the alternate marking schema.

Also, the description of how to use RFC5474 and RFC5475 coupled with alternate marking has been detailed (section "Hashing selection method"). It can be applied to both point-to-point (described in draft-mizrahi-ippm-compact-alternate-marking) and to multipoint-to-multipoint (described in this new version).

In addition, new considerations inspired from Last Call discussion on the foundation draft-ietf-ippm-alt-mark have been included also in this new version.

Best Regards,

Giuseppe

-----Messaggio originale-----
Da: [email-masked] [mailto:[email-masked]] 
Inviato: lunedì 30 ottobre 2017 11:31
A: Riccardo Sisto; Fioccola Giuseppe; Cociglio Mauro; Amedeo Sapio
Oggetto: New Version Notification for draft-fioccola-ippm-multipoint-alt-mark-01.txt

A new version of I-D, draft-fioccola-ippm-multipoint-alt-mark-01.txt
has been successfully submitted by Giuseppe Fioccola and posted to the IETF repository.

Name:		draft-fioccola-ippm-multipoint-alt-mark
Revision:	01
Title:		Multipoint Alternate Marking method for passive and hybrid performance monitoring
Document date:	2017-10-30
Group:		Individual Submission
Pages:		15
URL:            https://www.ietf.org/internet-drafts/draft-fioccola-ippm-multipoint-alt-mark-01.txt
Status:         https://datatracker.ietf.org/doc/draft-fioccola-ippm-multipoint-alt-mark/
Htmlized:       https://tools.ietf.org/html/draft-fioccola-ippm-multipoint-alt-mark-01
Htmlized:       https://datatracker.ietf.org/doc/html/draft-fioccola-ippm-multipoint-alt-mark-01
Diff:           https://www.ietf.org/rfcdiff?url2=draft-fioccola-ippm-multipoint-alt-mark-01

Abstract:
   The Alternate Marking method, as presented in
   [I-D.ietf-ippm-alt-mark], can be applied only to point-to-point flows
   because it assumes that all the packets of the flow measured on one
   node are measured again by a single second node.  This document aims
   to generalize and expand this methodology to measure any kind of
   unicast flows, whose packets can follow several different paths in
   the network, in wider terms a multipoint-to-multipoint network.  For
   this reason the technique here described is called Multipoint
   Alternate Marking.  Some definitions here introduced extend the scope
   of RFC 5644 [RFC5644] in the context of alternate marking schema.

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.

The IETF Secretariat

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. 

Rispetta l'ambiente. Non stampare questa mail se non è necessario.

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Tue, 31 Oct 2017 14:00:19 +0000

Hi Guiseppe,

> -----Original Message-----
> From: ippm [mailto:[email-masked]] On Behalf Of Fioccola Giuseppe
> Sent: Monday, October 30, 2017 7:29 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]'
> Subject: [ippm] I: New Version Notification for draft-fioccola-ippm-
> multipoint-alt-mark-01.txt
> 
> Hi IPPM,
> 
> We have updated the draft to address the comment received in Prague from
> Al Morton about considering RFC5644 relevant for this work.
> 
> The feeling is that the multipoint alternate marking considerations
> extend the scope of RFC5644 to Passive/Hybrid Performance Measurements
> and also to multi source stream. A new section "Correlation with
> RFC5644" has been added. Some terminologies and definitions can be re-
> used from RFC5644 (e.g. spatial, segment, multiparty, one-to-group
> metrics and also group-to-group topologies), but they have to be
> rephrased to be applied to the alternate marking schema.

[ACM] 
Thanks for addressing my comment. It is certainly worthwhile
to re-use what you can. It will be useful to recognize the 
overlap between one-to-group and group-to-group metrics, and
that some group-to-group metrics consolidate many one-to-group
observations, and those are built on one-to-one observations...

In section 3, you indicate the possibility of multi-paths
appearing in the measurements, and then
you raise an important point about specifying
single IP addresses, that: 
 " ... a single source address selects flows following a point-to-
   multipoint, while a multipoint-to-point can be the result of a
   matching on a single destination address."

If specifying a single Source address, for example, the 
point-to-multipoint graph would almost certainly include
multiple paths as well. The risk of combining measurements
on the basis of Source IP-only, is that delay variations
observed across multiple paths would be larger than those 
experienced by single flows. Common Flow classification keeps 
each flow on *one* route through the multi-path topology.

"...alternate marking method is applicable only to a single path",
so it appears you start with the flow-specific information,
just be careful with the aggregations in the multipoint cases.

Measurements of Route variation/sensitivities are on (some of) our minds:
https://tools.ietf.org/html/draft-amf-ippm-route-01
and this is a possible area of interaction where we all benefit:
from your Section 4.1:
   "The Monitoring Network is deduced from the Production Network, by
   identifying the nodes of the graph, that are the measurement points,
   and the links, that are the connections between measurement points."
Even if your org. owns the production network, you may still be 
surprised how packets flow through it when routing choices are made
on IP and higher-layer info.

  "4.4.2.  Mean Delay and Jitter

   Mean delay and jitter measurements can also be generalized to the
   case of multipoint flows."
This is where my comments above on combining measurements across
flows are relevant. Also, we prefer "Packet Delay Variation" over the 
term "Jitter" in IPPM, and RFC 3393 explains why.

hope this helps,
Al

> 
> 
> 
> Also, the description of how to use RFC5474 and RFC5475 coupled with
> alternate marking has been detailed (section "Hashing selection
> method"). It can be applied to both point-to-point (described in draft-
> mizrahi-ippm-compact-alternate-marking) and to multipoint-to-multipoint
> (described in this new version).
> 
> 
> 
> In addition, new considerations inspired from Last Call discussion on
> the foundation draft-ietf-ippm-alt-mark have been included also in this
> new version.
> 
> 
> 
> Best Regards,
> 
> 
> 
> Giuseppe
> 
> 
> 
> URL:            https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_internet-2Ddrafts_draft-2Dfioccola-2Dippm-2Dmultipoint-
> 2Dalt-2Dmark-2D01.txt&d=DwIGaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=suU4T_2RZzOwGp0SQv4djBq7_f7
> o0xSry1botNlPQwo&s=tyA_g2awBepo0xLRkexAz6QGn95n8OsVRPX2uXtim_8&e=
> 
> Status:         https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__datatracker.ietf.org_doc_draft-2Dfioccola-2Dippm-2Dmultipoint-2Dalt-
> 2Dmark_&d=DwIGaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=suU4T_2RZzOwGp0SQv4djBq7_f7
> o0xSry1botNlPQwo&s=nilgR7KGeMnGnZZEino7Eh5bGKNWVqKI_qSQh9oWjiY&e=
> 
> Htmlized:       https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__tools.ietf.org_html_draft-2Dfioccola-2Dippm-2Dmultipoint-2Dalt-
> 2Dmark-2D01&d=DwIGaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=suU4T_2RZzOwGp0SQv4djBq7_f7
> o0xSry1botNlPQwo&s=VLHIDWRJhVWmcY3a_H7varSbbkn8YHRhIuqIm94cSss&e=
> 
> Htmlized:       https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__datatracker.ietf.org_doc_html_draft-2Dfioccola-2Dippm-2Dmultipoint-
> 2Dalt-2Dmark-2D01&d=DwIGaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=suU4T_2RZzOwGp0SQv4djBq7_f7
> o0xSry1botNlPQwo&s=ElLFZugckE4UuIjKvBchXfLJy4pBp6mN2h36_FDJ1_A&e=
> 
> Diff:           https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dfioccola-2Dippm-2Dmultipoint-
> 2Dalt-2Dmark-2D01&d=DwIGaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=suU4T_2RZzOwGp0SQv4djBq7_f7
> o0xSry1botNlPQwo&s=AOC587l3llHlTLOLAMr_worZBB9pM2xdHSicpvIBafc&e=
> 
> 
> 
> Abstract:
> 
> 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.
> 
> 
> 
> The IETF Secretariat
> 
> 
> 
> 
> 
> 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://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_ippm&d=DwIGaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=suU4T_2RZzOwGp0SQv4djBq7_f7
> o0xSry1botNlPQwo&s=eZZXGlSoCg5W4X2VxeWZKmuYkX9zcv2XO6ibfa9lUE4&e=

---

From: Fioccola Giuseppe <[email-masked]>
Date: Tue, 31 Oct 2017 17:38:26 +0000

Hi Al,
Thanks for your comments.
See my answers inline tagged as [GF]

Best Regards,

Giuseppe

-----Messaggio originale-----
Da: MORTON, ALFRED C (AL) [mailto:[email-masked]] 
Inviato: martedì 31 ottobre 2017 15:00
A: Fioccola Giuseppe; [email-masked]; [email-masked]
Cc: [email-masked]'
Oggetto: RE: New Version Notification for draft-fioccola-ippm-multipoint-alt-mark-01.txt

Hi Guiseppe,

> We have updated the draft to address the comment received in Prague 
> from Al Morton about considering RFC5644 relevant for this work.
> 

[ACM]
Thanks for addressing my comment. It is certainly worthwhile to re-use what you can. It will be useful to recognize the overlap between one-to-group and group-to-group metrics, and that some group-to-group metrics consolidate many one-to-group observations, and those are built on one-to-one observations...

In section 3, you indicate the possibility of multi-paths appearing in the measurements, and then you raise an important point about specifying single IP addresses, that: 
 " ... a single source address selects flows following a point-to-
   multipoint, while a multipoint-to-point can be the result of a
   matching on a single destination address."

If specifying a single Source address, for example, the point-to-multipoint graph would almost certainly include multiple paths as well. The risk of combining measurements on the basis of Source IP-only, is that delay variations observed across multiple paths would be larger than those experienced by single flows. Common Flow classification keeps each flow on *one* route through the multi-path topology.

[GF] You are absolutely right, in fact multipoint alternate marking could be useful in a flexible performance measurement application (e.g. an SDN controller can do that), where you can monitor the entire network as a whole or on Clusters basis and in case of problems you can detail more, but only in the portion of the network where you need. The risks you mention are correct, but this is the trade-off between a per-flow performance monitoring that needs resources to be accomplished and a Cluster based performance monitoring that gives a summary of the network with few resources. This method gives the flexibility to perform both the big picture and detailed measurements. For this purpose, Hashing selection method (RFC5474/5) has been introduced to be coupled with alternate marking methodology in order to perform a better delay and delay variation analysis because marking batches anchor the samples selected with hashing and it works for multipoint-to-multipoint path. This is needed because Double Marking measurement cannot work in the Multipoint scenario, so Hashing method enables per-flow delay measurements also for multipoint paths.

"...alternate marking method is applicable only to a single path", so it appears you start with the flow-specific information, just be careful with the aggregations in the multipoint cases.

[GF] Yes, I meant "The alternate marking method, as presented until now, is applicable only to a single path... so the extension proposed in this document is suitable also for the most general case of multipoint-to-multipoint". I have to modify this sentence.

Even if your org. owns the production network, you may still be surprised how packets flow through it when routing choices are made on IP and higher-layer info.

[GF] This is a good point! I can mention that draft-amf-ippm-route can help with the building of the monitoring network.

   Mean delay and jitter measurements can also be generalized to the
   case of multipoint flows."
This is where my comments above on combining measurements across flows are relevant. Also, we prefer "Packet Delay Variation" over the term "Jitter" in IPPM, and RFC 3393 explains why.

[GF] Agree

hope this helps,
Al

> mizrahi-ippm-compact-alternate-marking) and to 
> multipoint-to-multipoint (described in this new version).
> 
> 
> 
> the foundation draft-ietf-ippm-alt-mark have been included also in 
> this new version.
> 
> 
> 
> Best Regards,
> 
> 
> 
> Giuseppe
> 
> 
> 
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=suU4T_2RZzOwGp0SQv4djBq7_
> f7 o0xSry1botNlPQwo&s=tyA_g2awBepo0xLRkexAz6QGn95n8OsVRPX2uXtim_8&e=
> 
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=suU4T_2RZzOwGp0SQv4djBq7_
> f7 o0xSry1botNlPQwo&s=nilgR7KGeMnGnZZEino7Eh5bGKNWVqKI_qSQh9oWjiY&e=
> 
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=suU4T_2RZzOwGp0SQv4djBq7_
> f7 o0xSry1botNlPQwo&s=VLHIDWRJhVWmcY3a_H7varSbbkn8YHRhIuqIm94cSss&e=
> 
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=suU4T_2RZzOwGp0SQv4djBq7_
> f7 o0xSry1botNlPQwo&s=ElLFZugckE4UuIjKvBchXfLJy4pBp6mN2h36_FDJ1_A&e=
> 
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=suU4T_2RZzOwGp0SQv4djBq7_
> f7 o0xSry1botNlPQwo&s=AOC587l3llHlTLOLAMr_worZBB9pM2xdHSicpvIBafc&e=
> 
> 
> 
> Abstract:
> 
> Questo messaggio e i suoi allegati sono indirizzati esclusivamente 
> alle persone indicate. La diffusione, copia o qualsiasi altra azione 
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=suU4T_2RZzOwGp0SQv4djBq7_
> f7 o0xSry1botNlPQwo&s=eZZXGlSoCg5W4X2VxeWZKmuYkX9zcv2XO6ibfa9lUE4&e=