[lmap] Feedback regarding draft-linsner-lmap-use-cases
Benoit Claise <bclaise@cisco.com> Mon, 22 July 2013 14:19 UTC
Return-Path: <bclaise@cisco.com>
X-Original-To: lmap@ietfa.amsl.com
Delivered-To: lmap@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D18BF21F99FB for <lmap@ietfa.amsl.com>; Mon, 22 Jul 2013 07:19:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.519
X-Spam-Level:
X-Spam-Status: No, score=-10.519 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fQ122zhqOgtJ for <lmap@ietfa.amsl.com>; Mon, 22 Jul 2013 07:19:21 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 39EA111E8115 for <lmap@ietf.org>; Mon, 22 Jul 2013 07:19:20 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r6MEJHXG018550 for <lmap@ietf.org>; Mon, 22 Jul 2013 16:19:18 +0200 (CEST)
Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r6MEJ1PO027438 for <lmap@ietf.org>; Mon, 22 Jul 2013 16:19:11 +0200 (CEST)
Message-ID: <51ED3F4D.5090403@cisco.com>
Date: Mon, 22 Jul 2013 16:18:53 +0200
From: Benoit Claise <bclaise@cisco.com>
User-Agent: Mozilla/5.0 (Windows NT 5.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: "lmap@ietf.org" <lmap@ietf.org>
Content-Type: multipart/alternative; boundary="------------030604040503080307010804"
Subject: [lmap] Feedback regarding draft-linsner-lmap-use-cases
X-BeenThere: lmap@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Large Scale Measurement of Access network Performance <lmap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lmap>, <mailto:lmap-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/lmap>
List-Post: <mailto:lmap@ietf.org>
List-Help: <mailto:lmap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lmap>, <mailto:lmap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Jul 2013 14:19:25 -0000
Dear authors, A couple of high level points. One of the goal behind this email is to generate discussions, either on the list, or during the IETF meeting next week. - Large-scale measurement efforts in [LMAP-REQ <http://tools.ietf.org/html/draft-linsner-lmap-use-cases-03#ref-LMAP-REQ>] describe three use cases to be considered in deriving the requirements to be used in developing the solution. This documents attempts to describe those use cases in further detail and include additional use cases. Should not refer to the requirements as a starting point. The use case document is supposed to the first document in the LMAP series The charter refers to the provider and regulator use cases. Btw, regarding the end user, the charter mentions: Standardizing control of end users Measurement Agents is out of scope. However, end users can obtain an MA to run measurement tasks if desired and report their results to whomever they want, most likely the supplier of the MA. This provides for user-initiated on-demand measurement, which is an important component of the ISP use case. Btw, these specific aspects of the end user network diagnostics should be stressed in the draft. Therefore, you should focus first on the ISP and regulators use cases in the draft. - o Benchmarking and competitor insight. The operation of sample panels across competitor products can enable and ISP to assess where they play in the market, identify opportunities where other products operate different technology, and assess the performance of network suppliers that are common to both operators. How does it work regarding this sentence in the charter? A key assumption constraining the initial work is that the measurement system is under the control of a single organization (for example, an Internet Service Provider or a regulator). I mean: the regulator can share information about different ISPs, but I doubt that ISP1 will be able to get the ISP2 results by re-directing/duplicating the ISP2 measurement agents to his collector. - I believe that the ISPs use cases miss an entry regarding "checking the service SLA". Maybe this is covered by the entry "Understanding the quality experienced by customers"? - What I don't see in the draft: what is meant by "broadband"? - What I don't see in the draft: IPv4 versus IPv6. Linked to that: what is/are use case(s) for multiple interfaces. The charter says: "Devices containing Measurement Agents may have several interfaces using different link technologies. Multiple address families and interfaces must be considered in the Control and Report protocols." - What I don't see in the draft: how many MAs do we have in mind for LMAP. - Note: the QoS and QoE definition from RFC 6390, along with http://tools.ietf.org/html/rfc6390#section-4 might help. Regards, Benoit
- [lmap] Feedback regarding draft-linsner-lmap-use-… Benoit Claise