[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