Subject: [ippm] REG: draft-fioccola-ippm-multipoint-alt-mark-02

From: Sudhin Jacob <[email-masked]>
Date: Wed, 13 Jun 2018 03:54:12 +0000

Hi Giuseppe,

I had gone through the draft. I have the following queries.

1.      The draft is not clear how to measure the packet in a multi-point scenario.
2.      Can you explain the grouping the network end points, how do you predict traffic.
3.      How do you measure the packets.
4.      Could you please  explain me how the history is captured.
5.      Could you please explain the algorithm for calculate delay variation?

Regards,
Sudhin

---

From: Fioccola Giuseppe <[email-masked]>
Date: Wed, 13 Jun 2018 07:51:22 +0000

Hi Sudhin,
Thank you for reading the draft.
My answers inline tagged as [GF]

Please let me know if I have answered to your queries.
I will fix them in the next revision.

Regards,

Giuseppe

From: Sudhin Jacob [mailto:[email-masked]]
Sent: mercoledì 13 giugno 2018 05:54
To: Fioccola Giuseppe <[email-masked]>
Cc: IETF IPPM WG <[email-masked]>
Subject: REG: draft-fioccola-ippm-multipoint-alt-mark-02

Hi Giuseppe,

1.      The draft is not clear how to measure the packet in a multi-point scenario.
2.      [GF]: RFC8321 explains how to measure packet loss on point-to-point basis. However, in same cases, packet loss can be measured on a multipoint-to-multipoint basis and this is a property of the alternate marking method. With network clustering, it is possible to use the network clusters partition of the entire network to measure packet loss for each cluster. I will highlight better this concept in the draft.
3.
4.      Can you explain the grouping the network end points, how do you predict traffic.
5.      [GF]: This is a good point. In my opinion there are different options: for example you can consider all the possible paths for the traffic or you can check the traffic sometimes and update the monitoring network if needed or you can use traceroute... But I would consider this out of scope for this document. Anyway I will add a paragraph in the next revision.
6.
7.      How do you measure the packets.
8.      [GF]: You can measure the packet loss by comparing the sum of the packet counters for input nodes and output nodes of your monitoring network or of the clusters. In this way in a very large network you don't need to configure detailed filter criteria to inspect the traffic. You can check multipoint network and only in case of problems you can go deep with a step-by-step cluster analysis but only for the cluster where the problem happens. This is useful in an SDN controlled large network and enables a flexible and adaptive performance measurement. Agree, this will be described more in the next revision.
9.
10.   Could you please  explain me how the history is captured.
11.   [GF]: The history can be made also offline by an SDN orchestrator/controller, and as for RFC8321 this can be considered out of scope for this document.
12.
13.   Could you please explain the algorithm for calculate delay variation?
14.   [GF]: The delay variation is calculated by considering RFC3393 and the same packets selected for measuring the delay (single/double marking or hashing) are also evaluated for delay variation.

Regards,
Sudhin

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: Sudhin Jacob <[email-masked]>
Date: Fri, 15 Jun 2018 04:14:05 +0000

Hi Giuseppe,

Kindly find the answer inline.

Regards,
Sudhin

From: Fioccola Giuseppe <[email-masked]>
Sent: Wednesday, June 13, 2018 1:21 PM
To: Sudhin Jacob <[email-masked]>; IETF IPPM WG <[email-masked]>
Subject: RE: draft-fioccola-ippm-multipoint-alt-mark-02

Hi Sudhin,

Regards,

Giuseppe

From: Sudhin Jacob [mailto:[email-masked]]
Sent: mercoledì 13 giugno 2018 05:54
To: Fioccola Giuseppe <[email-masked]<mailto:[email-masked]>>
Cc: IETF IPPM WG <[email-masked]<mailto:[email-masked]>>
Subject: REG: draft-fioccola-ippm-multipoint-alt-mark-02

Hi Giuseppe,

Sudhin>>>>>> Kindly explain, multipoint there are different flows, how about BUM packet, there will be ingress replication sometimes there will be point to multipoint LSP. How to record it.
3.
4.       Can you explain the grouping the network end points, how do you predict traffic.
5.       [GF]: This is a good point. In my opinion there are different options: for example you can consider all the possible paths for the traffic or you can check the traffic sometimes and update the monitoring network if needed or you can use traceroute... But I would consider this out of scope for this document. Anyway I will add a paragraph in the next revision.

Sudhin>>>>>> Good.
6.
7.       How do you measure the packets.
8.       [GF]: You can measure the packet loss by comparing the sum of the packet counters for input nodes and output nodes of your monitoring network or of the clusters. In this way in a very large network you don't need to configure detailed filter criteria to inspect the traffic. You can check multipoint network and only in case of problems you can go deep with a step-by-step cluster analysis but only for the cluster where the problem happens. This is useful in an SDN controlled large network and enables a flexible and adaptive performance measurement. Agree, this will be described more in the next revision.
Sudhin>>>>>>>> the counter details are not mentioned, how to find out CIR, EIR.
9.
10.   Could you please  explain me how the history is captured.
11.   [GF]: The history can be made also offline by an SDN orchestrator/controller, and as for RFC8321 this can be considered out of scope for this document.
Sudhin>>> ok
12.   Could you please explain the algorithm for calculate delay variation?
13.   [GF]: The delay variation is calculated by considering RFC3393 and the same packets selected for measuring the delay (single/double marking or hashing) are also evaluated for delay variation.

Regards,
Sudhin

---

From: Fioccola Giuseppe <[email-masked]>
Date: Fri, 15 Jun 2018 09:51:05 +0000

Hi Sudhin,
Thank you for the comments.
My answers inline tagged as [GF]

Best Regards,

Giuseppe

Sent: venerdì 15 giugno 2018 06:14

Hi Giuseppe,

Regards,
Sudhin

From: Fioccola Giuseppe <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, June 13, 2018 1:21 PM
To: Sudhin Jacob <[email-masked]<mailto:[email-masked]>>; IETF IPPM WG <[email-masked]<mailto:[email-masked]>>
Subject: RE: draft-fioccola-ippm-multipoint-alt-mark-02

Hi Sudhin,

Regards,

Giuseppe

Hi Giuseppe,

[GF]: BUM is not considered here so replication is not possible. Multipoint flows refer only to unicast traffic. Depending on the set of selection rules used to match the unicast packets, the resulting pattern cannot be a point-to-point connection, but, in general, a multipoint-to-multipoint connection.
[GF]: I will add more details on that. The calculation of CIR and EIR is possible because alternate marking method allows both tracing and packet rate calculation. But, you can enable per flow or multipoint alternate marking depending on the level of information you need to achieve (per flow or multipoint basis).

Regards,
Sudhin