Re: [ippm] Benjamin Kaduk's Discuss on draft-ietf-ippm-multipoint-alt-mark-07: (with DISCUSS and COMMENT)

Giuseppe Fioccola <giuseppe.fioccola@huawei.com> Thu, 12 March 2020 14:10 UTC

Return-Path: <giuseppe.fioccola@huawei.com>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FF693A09E1; Thu, 12 Mar 2020 07:10:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X4Qg4m_rAe13; Thu, 12 Mar 2020 07:10:02 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D1FA3A09DD; Thu, 12 Mar 2020 07:10:02 -0700 (PDT)
Received: from lhreml703-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 1394327180B81AC9B7F1; Thu, 12 Mar 2020 14:09:59 +0000 (GMT)
Received: from fraeml712-chm.china.huawei.com (10.206.15.61) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 12 Mar 2020 14:09:58 +0000
Received: from fraeml714-chm.china.huawei.com (10.206.15.33) by fraeml712-chm.china.huawei.com (10.206.15.61) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Thu, 12 Mar 2020 15:09:58 +0100
Received: from fraeml714-chm.china.huawei.com ([10.206.15.33]) by fraeml714-chm.china.huawei.com ([10.206.15.33]) with mapi id 15.01.1713.004; Thu, 12 Mar 2020 15:09:58 +0100
From: Giuseppe Fioccola <giuseppe.fioccola@huawei.com>
To: Benjamin Kaduk <kaduk@mit.edu>, The IESG <iesg@ietf.org>
CC: "draft-ietf-ippm-multipoint-alt-mark@ietf.org" <draft-ietf-ippm-multipoint-alt-mark@ietf.org>, "ippm-chairs@ietf.org" <ippm-chairs@ietf.org>, "ippm@ietf.org" <ippm@ietf.org>, Tal Mizrahi <tal.mizrahi.phd@gmail.com>
Thread-Topic: Benjamin Kaduk's Discuss on draft-ietf-ippm-multipoint-alt-mark-07: (with DISCUSS and COMMENT)
Thread-Index: AQHV+BJNjqDbNJeAP0uox3g93OMmmKhE4GvQ
Date: Thu, 12 Mar 2020 14:09:58 +0000
Message-ID: <30dd92b7db6c4edba74fd8043182b349@huawei.com>
References: <158397854669.19608.10592898561339579819@ietfa.amsl.com>
In-Reply-To: <158397854669.19608.10592898561339579819@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.9.207]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/XO1TNP9C-8hNgP0Bv2FddlpSphI>
Subject: Re: [ippm] Benjamin Kaduk's Discuss on draft-ietf-ippm-multipoint-alt-mark-07: (with DISCUSS and COMMENT)
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm/>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Mar 2020 14:10:06 -0000

Dear Benjamin,
Thanks for your detailed comment.
Please find below my replies tagged as [GF].

Let me know if you agree with my proposed changes to the draft and I will include them in the next revision.

Best Regards,

Giuseppe

-----Original Message-----
From: Benjamin Kaduk via Datatracker [mailto:noreply@ietf.org] 
Sent: Thursday, March 12, 2020 3:02 AM
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-ippm-multipoint-alt-mark@ietf.org; ippm-chairs@ietf.org; ippm@ietf.org; Tal Mizrahi <tal.mizrahi.phd@gmail.com>; tal.mizrahi.phd@gmail.com
Subject: Benjamin Kaduk's Discuss on draft-ietf-ippm-multipoint-alt-mark-07: (with DISCUSS and COMMENT)

Benjamin Kaduk has entered the following ballot position for
draft-ietf-ippm-multipoint-alt-mark-07: Discuss

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ippm-multipoint-alt-mark/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Let's discuss whether [I-D.mizrahi-ippm-compact-alternate-marking] needs to be a normative reference, to describe how the Hash selection method works for multipoint.  This document alone does not even mention what is used as input to the hash (though I think I have a good guess based on the context).  Even if the intent is that RFC 5474 suffices (avoiding the "dependency on individual document" issue), that is also listed only as an informative reference.

[GF]: Yes, this is an oversight and I think we can surely move RFC 5474 as normative reference. We left [I-D.mizrahi-ippm-compact-alternate-marking] as informative reference because it introduces the use of the Hash Method in combination with Alternate Marking for point-to-point flow and this is not covered by this or other documents. 

Also, if the grouping procedure (section 6.1) does in fact require a distinguished (but arbitrary?) choice of initial endpoint as I suspect it does, that should be clarified.  (See COMMENT.)

[GF]: Ok, I need to clarify better this point in Section 6.1. The grouping procedure implies that the links are unidirectional and you can start from any link. The procedure works anyway. We just need to classify them and put together the links where there is the same starting node in separated groups.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I echo the other reviewers' comments about clarity as to "multipoint"
vs. "multicast" and defining various terms.

I agree with Barry that there's a lot of editorial work to be done; I've to note many instances in these comments even when the proper resolution is unclear to me.

Section 1

   This approach fits very well with the Intelligent Network and
   Software Defined Network (SDN) paradigm where the SDN Orchestrator
   and the SDN Controllers are the brains of the network and can manage
   flow control to the switches and routers and, in the same way, can
   calibrate the performance measurements depending on the necessity.

nit: "necessity" doesn't sound right

[GF]: I can replace "necessity" with "desired accuracy"

   An SDN Controller Application can orchestrate how deep the network
   performance monitoring is setup by applying the Multipoint Alternate
   Marking as described in this document.

nit: "how deep the network" doesn't sound right

[GF]: I can replace "how deep" with "how accurate"

Section 3

   In this way the flows to be monitored are selected into the
   monitoring points using packet selection rules, that can also change
   the pattern of the monitored network.

nit: I'm not sure what "this way" refers to.  It also seems like this may be two independent thoughts needlessly joined together with a comma.

[GF]: Yes I can omit "in this way", maybe "so" is better here

Section 4.1

   [I-D.ietf-ippm-route]).  In general there are different options: the
   monitoring network can be obtained by considering all the possible
   paths for the traffic or also by checking the traffic sometimes and
   update the graph consequently.

"also by checking the traffic sometimes and update the graph consequently" feels pretty informal and under-specified.

[GF]: I will modify this sentence. It means that the network graph can be updated in several ways (e.g. daily basis, weekly basis,...). It is up to management system configuration.

Section 5

   Since all the packets of the considered flow leaving the network have
   previously entered the network, the number of packets counted by all
   the input nodes is always greater or equal than the number of packets
   counted by all the output nodes.

[I think I could imagine some exotic cases where this does not hold, but none of them really seem topical for this work.]

[GF]: Yes correct, the hypothesis is that what goes in is the same as what goes out

   It is possible to define the Network Packet Loss of one monitored
   flow for a single period: <<In a packet network, the number of lost
   packets is the number of packets counted by the input nodes minus the
   number of packets counted by the output nodes>>.  This is true for
   every packet flow in each marking period.

As another reviewer implies, this discounts the difference between the number of packets "still in the network" at the start and end of the measurement period.

[GF]: Consider that, with Alternate Marking and this does not happen since we always use a waiting interval to take the counters in order to make sure that they are stable and not still in the network. This is explained in section 7.

      The flow definition is generalized here, indeed, as described
      before, a multipoint packet flow is considered and the
      identification fields of the 5-tuple can be selected without any
      constraints.

I don't think I understand what this means.  If identification is fully general, how are we still limited to a 5-tuple?

[GF]: You are right, no need to refer to 5-tuple here.

Section 6
   In a completely monitored network (a network where every network
   interface is monitored), each network device corresponds to a Cluster
   and each physical link corresponds to two Clusters (one for each
   direction).

("what about unidirectional links?")

[GF]: This is an oversight. We are considering the unidirectional flow here. I can replace "direction" with "device".

Section 6.1

I'm not following how the first step of this algorithm produces the listed groups.  Are the links considered to be bidirectional?  Did we have to pick some arbitrary starting node (R1), and decree that once a link is in one group it cannot be in some other group?

[GF]: The links are unidirectional and we can start from any link not from a node. We can imagine to have a list of all the links as connection between two nodes and we can group them considering the same starting node. I will clarify it better within the draft.

   In this way the calculation of packet loss can be made on Cluster
   basis.  Note that CIR(Committed Information Rate) and EIR(Excess
   Information Rate) can also be deduced on Cluster basis.

Do we use CIR and/or EIR anywhere else?  (Are they references to some other body of work?)

[GF]: this is an oversight. I think we can omit.

   In this way in a very large network there is no 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 or
   combination of clusters where the problem happens.

nits: there at least one missing article here ("a multipoint network") and I think there was something else that feels not quite right.

[GF]: Agree. I will review this paragraph.

   In summary, once defined a flow, the algorithm to build the Cluster
   Partition considers all the possible links and nodes crossed by the

What does "once defined a flow" mean?

[GF]: It means that you can apply the Cluster Partition based on the Network Graph that is valid for a specific flow or you can also apply the partition in general for the entire network. It depends on how we define the approach. I can review this.

   information.  So, if the flow do not enter or traverse all the nodes,
   the counters has a non-zero value for the involved nodes, while a

nit: singular/plural mismatch "the flow"/"do not", "counters"/"has a [...] value"

[GF]: Sure, I will correct.

   The algorithm described above is an Iterative clustering algorithm,
   but it is also possible to apply a Recursive clustering algorithm by
   using the node-node adjacency matrix representation.

Is there a reference for this?  (Do I assume it's the [IEEE-ACM-ToN-MPNPM] at the end of the next paragraph?)

[GF]: Correct! I can highlight it also here.

Section 7
   Therefore, when we expand to multipoint-to-multipoint flows, we have
   to consider that all source nodes mark the traffic and this adds more
   complexity.

I'm not sure what chain of reasoning "therefore" is attempting to indicate.

[GF]: Agree. I can remove/replace.

   But we should now consider an additional contribution.  Since all
   source nodes mark the traffic, the source measurement intervals can
   be of different lengths and with different offsets and this mismatch
   m can be added to d, as shown in figure.

Please define m and d.

[GF]: Sure. I will add more details here. m is misalignment between the marking source routers, while d, already introduced in RFC 8321, takes into account clock error and network delay between network nodes.

   So the misalignment between the marking source routers gives an
   additional constraint and the value of m is added to d (that already
   includes clock error and network delay).

   Thus, three different possible constraints are considered: clock
   error between network devices, network delay between measurement
   points and the misalignment between the marking source routers.

Are these "constraints" or "contributions [to error/uncertainty]"?  RFC
8321 does not seem to use "constraint" in this fashion.

[GF]: They are just little contributions to be considered in order to establish the marking period. We need to ensure an interval available for countins that is > 0. I can change the term.

   In the end, the condition that must be satisfied to enable the method
   to function properly is that the available counting interval must be
   > 0, and that means: L - 2m - 2d > 0 for each measurement point on
   the multipoint path.  Therefore, the mismatch between measurement
   intervals must satisfy this condition.

Is it bad to just make L really large?

[GF]: Not bad :) and this is the practical approach, but it was just to have a mathematical formulation.

Section 8

   period and this is the time reference that can be used.  It is
   important to highlight that both delay and delay variation
   measurements make sense in a multipoint path.  The Delay Variation is
   calculated by considering the same packets selected for measuring the
   Delay.

Is the "variation" considered here just the variation across the separate paths that the selected packets take, or over time, or something else?

[GF]: It can be both the variation across separate paths or valid for the multipoint path. It is the same as for the delay.

   o  Delay measurements on single packets basis means that you can use
      multipoint path just to easily couple packets between inputs and

nit: singular/plural mismatch "packets"/"basis" (also missing "a"?)
nit: "inpur" singular, I think.

[GF]: Ok, I will correct.

Section 8.1.1

I don't understand what weights are used for the "weighted averages".

[GF]: I will explain better. In the calculation of average delay we can consider the number of packets for each end points so we can make a multipoint weighted average delay. We just mentioned it but it is not so useful in practice.

Section 8.2.1

   since they would not be representative of the entire flow.  The
   packets can follow different paths with various delays and in general
   it can be very difficult to recognize marked packets in a multipoint-
   to-multipoint path especially in case they are more than one per
   period.

nits: "the case when there is", comma before "and in general".

[GF]: Ok I will correct.

Section 8.2.2

   [I-D.mizrahi-ippm-compact-alternate-marking] introduces how to use
   the Hash method combined with alternate marking method for point-to-

Is it really appropriate for a WG document to depend on an individual document to introduce a concept?

[GF]: I think we can revise this sentence and add a reference to RFC 5474 too.

   In a multipoint environment the behaviour is similar to point-to
   point flow.  In particular, in the context of multipoint-to-
   multipoint flow, the dynamic hash could be the solution to perform

nits: both of these either need "flows" plural or the article "a".

[GF]: Ok, I will correct

   The management system receives the samples including the timestamps
   and the hash value from all the MPs, and this happens both for point-
   to-point and for multipoint-to-multipoint flow.  Then the longest

nit: "flows"

[GF]: Ok, I will correct

Also, this seems to be the first time we abbreviate "measurement points"; it would be good to provide the abbreviation/expansion together and consistently use the abbreviation.  (Interestingly https://www.rfc-editor.org/materials/abbrev.expansion.txt only has "multiprotocol" and "maintenance point".)

[GF]: Ok

   to-point and for multipoint-to-multipoint flow.  Then the longest
   hash used by MPs is deduced and it is applied to couple timestamps of
   same packets of 2 MPs of a point-to-point path or of input and output
   MPs of a Cluster (or a Super Cluster or the entire network).  But

nit: there appear to be several missing words here.

[GF]: Ok, I will revise and correct

   In summary, the basic hash is logically similar to the double marking
   method, and in case of point-to-point path double marking and basic

I don't really recall any specific discussion of similarities between basic hash and double marking, so calling this a "summary" is perhaps a stretch.

[GF]: I will modify the sentence and add the reference to [I-D.mizrahi-ippm-compact-alternate-marking], where it is mentioned.

Section 9

   An SDN Controller or a Network Management System (NMS) can calibrate
   Performance Measurements since it is aware of the network topology.
   It can start without examining in depth.  In case of necessity
   (packet loss is measured or the delay is too high), the filtering
   criteria could be immediately specified more in order to perform a
   partition of the network by using Clusters and/or different
   combinations of Clusters.  In this way the problem can be localized

nit: "specified more" seems incomplete; perhaps something about detail?

[GF]: Yes, I will correct

Section 11

I don't see much in RFC 8321 to note that "traffic observed by measurement points may contain private information if not protected by transport-layer security protocols, so measurement infrastructure should be as equally protected/secured as routing hardware".  That said, it is hopefully obvious, and not specific to this work, so I don't feel a particular need to have it mentioned here.

[GF]: Ok, we can consider to remove it.