Re: [lmap] LMAP regulator use case

James Miller <jamesmilleresquire@gmail.com> Wed, 06 November 2013 06:48 UTC

Return-Path: <jamesmilleresquire@gmail.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 0F8A611E8128 for <lmap@ietfa.amsl.com>; Tue, 5 Nov 2013 22:48:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
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 KZ+d09JJ4VNY for <lmap@ietfa.amsl.com>; Tue, 5 Nov 2013 22:48:08 -0800 (PST)
Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id DD6B111E80F8 for <lmap@ietf.org>; Tue, 5 Nov 2013 22:48:07 -0800 (PST)
Received: by mail-we0-f178.google.com with SMTP id q59so4413520wes.23 for <lmap@ietf.org>; Tue, 05 Nov 2013 22:48:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ASYh5zQzZGtfttrGogY5Gnz2nTZe1dcxD+/yF/fq/vY=; b=XQ2/FHHNogGpPohn+2e0HtRSKYbmAaIHGm7tLH/uU4gMWDLRHCdi1Smbt/ucxSU/83 5eCUjfNMypxhY4mW4OrQgEXF3Ap2rgvfEWrBpPg6hp8Mnzy2JSNsUEUDXa3G48ZiDYuZ ex03diBWyUnZGnZQQHu0mt/Cu+hQJ/bRuK2vy0HqpKZbHTm4LgRAyuUNMUNEmQCTNzFb VQd0JNfVlILB1qNrBVOiSvJcNV9LCvaeIwED7L+O9PJEORun1mHBmjJ5UBCacURuBOOt ugUvAeBGvDC3ODH2ovQz5RA+W3ZlIdURnPDxnQNJhGon3NFoA+5E46YoIfQy1wC8w3W4 +HuA==
X-Received: by 10.180.73.40 with SMTP id i8mr19809730wiv.37.1383720486443; Tue, 05 Nov 2013 22:48:06 -0800 (PST)
MIME-Version: 1.0
Received: by 10.180.211.7 with HTTP; Tue, 5 Nov 2013 22:47:26 -0800 (PST)
In-Reply-To: <6AF4522BD5AB86429CFD3948A9AB2F2F3A22854A@loota.laru.local>
References: <793D91975B99224DA9777562FF192808A27468CB@exmbx01> <A2E337CDB7BC4145B018B9BEE8EB3E0D3FFA6F9802@EMV67-UKRD.domain1.systemhost.net> <6AF4522BD5AB86429CFD3948A9AB2F2F3A22854A@loota.laru.local>
From: James Miller <jamesmilleresquire@gmail.com>
Date: Wed, 06 Nov 2013 01:47:26 -0500
Message-ID: <CANFMejgjHyDGq3CfEUNhFhZwkaqxdWLCtYQDvQyVRgnqXD7qTA@mail.gmail.com>
To: Nieminen Klaus <Klaus.Nieminen@ficora.fi>
Content-Type: multipart/alternative; boundary="f46d0438907d10212b04ea7c889f"
Cc: Henning Schulzrinne <hgs@cs.columbia.edu>, "philip.eardley@bt.com" <philip.eardley@bt.com>, "lmap@ietf.org" <lmap@ietf.org>, Marc Linsner <mlinsner@cisco.com>, "frode.sorensen@npt.no" <frode.sorensen@npt.no>
Subject: Re: [lmap] LMAP regulator use case
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: Wed, 06 Nov 2013 06:48:11 -0000

I would propose adding in section 2 or 4 some text describing a regulators
need to ensure that policies intended to protect the privacy interests of a
potential tester can be enforced using features available in the system.
 Recognizing that
http://www.ietf.org/id/draft-folks-lmap-framework-00.txtand in the
lists there's a view that a single entity will be overseeing a
large scale measurement, there is a clear need for a test infrastructure to
include tools to enforce the privacy policies of the managing entity and
coordinate collaborative activity.  A desire to protect the privacy of
testers contributing to our mobile measurement effort lead our work on the
project, and our decision to adopt changes to our fixed technical
infrastructure and data model to support a totally anonymous collection at
the MA and communications between controllers, and through the collectors
and the test results collected.  I understand there has been discussion on
this point in the past and we had included this in the Section 7 Security
Considerations of our original I-D.  In any event I think the regulator use
case benefits from calling the point out specifically.
http://tools.ietf.org/id/draft-schulzrinne-lmap-requirements-00.txt

Proposed addition in Section 2.2:
:: Regulators role in the development and enforcement of broadband Internet
access service policies also require that the measurement approaches meet a
high level of verifiability, accuracy and provider-independence to support
valid and meaningful comparisons of Internet access service
performance.   Regulators
also require that policies intended to protect the privacy interests of
potential testers can be enforced using features available in the system.


Naturally any use case is going to have some variation among the specific
practices of the parties.  On Klaus and Frode's comments (and excellent
draft contributions thanks!) I would chime in to add that "Transparency" is
a fundamental feature of the rules intended to protect the Open Internet
(or network neutrality in other parlance).  Our rule is intended to enable
"consumers to make informed choices regarding use of such services" but
also "for content, application, service, and device providers to develop,
market, and maintain Internet offerings." 47 CFR 8.3 - Transparency.

Whether protecting consumers is moved I think you find the thought and
regulatory use case solidly grounded in the US approach as well.  I would
also suggest adding some text to emphasize that Transparency is also
important to enabling development in the ecosystem.

Proposed addition in Section 4.1:
:: End users need effective transparency to be able to make informed
choices throughout the different stages of their relationship with ISPs,
when selecting Internet access service offers, and when considering
switching service offer within an ISP or to an alternative ISP.
 Transparency in Internet performance information is also important to
content, application, service, and device providers' to ensure they are
able to develop, market, and maintain Internet offerings.  Quality
information about service offering can be provided based on performance
measurements of the services provided in the market.


On Klaus' comments on what in US jurisdictions might be understand as
"blocking" or "discriminatory" conduct, I'd add that US law includes
similar provisions. 47 C.F.R.§§ 8.5, 8.7.  Recognizing that these topics
including "Quality of Service" are evolving and differ in many respects
across jurisdictions, a high level description focused on the value of
performance information to regulators in this regard may be helpful in the
section.

I would also breach another topic for future discussion on assessing
quality on the test network itself.  To maintain comparability and quality
of the collected data, the architecture itself must be monitored with
auditing of whether the infrastructure is functioning correctly, e.g.
server health and connectivity. MA side is much easier to keep a handle on
with special purpose probes (such as with our fixed "whitebox" approach)
but server side checks on and between controllers is also a very important
issue to keep an eye on.  I don't have a specific proposal how to address
this in an I-D right now but I'd note it as something any large scale
measurement manager will need to address.
--
JamesMillerEsquire@Gmail.com

"Wovon man nicht sprechen kann, darüber muß man schweigen."
(What we cannot speak about we must pass over in silence.  )
Ludwig Josef Johann Wittgenstein


On Wed, Nov 6, 2013 at 12:19 AM, Nieminen Klaus <Klaus.Nieminen@ficora.fi>wrote:

> Hi Philip, Frode and all,
>
> As one of the  regulator friends that Frode mentioned, I would like to
> tell how we see these issues in Finland as I'm working for the Finnish
> telco regulator.
>
> 4.2 Promoting end user empowerment
>
> I would like to see this chapter to be included. As said publishing
> transparent and comparable information is important but so it's also end
> user's ability to verify the performance of the Internet access service
> provided, comparing the measurement results achieved with the information
> given in the contract. If the contracted service quality level is not met,
> end users can use these results when complaining to the ISP to achieve
> improvement and compensation.
>
> If you want to include it to end user requirements it is ok for me to
> reference it from the regulator part. However I do not want it to be
> totally deleted as it is also our requirement not only end user one.
>
> 4.4 Detecting degradation of the Internet access
> 4.5 Detecting degradation of specific applications
>
> Yes I know that this is a hard problem how to measure NN. However it is a
> clear regulatory requirement at least in the EU. See Directive 2009/136/EC
> http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2009:337:0011:01:EN:HTML
>
> According to Art 22(3), “in order to prevent the degradation of service
> and the hindering or slowing down of traffic over networks, Member States
> shall ensure that national regulatory authorities are able to set minimum
> quality of service requirements on an undertaking or undertakings providing
> public communications networks.” The reach of this regulatory tool has been
> extensively examined by BEREC, which sees it as the third and last step of
> the regulatory approach to net neutrality breaches
>
> So we do need tools for this purpose as Frode has described.
>
> best regards,
>
> - Klaus -
> ___________________________________________
> KLAUS NIEMINEN
> Communications Network Specialist
> Finnish Communications Regulatory Authority
> P.O. Box 313
> FIN-00181 HELSINKI, FINLAND
> tel.: +358 29 5390 528
> fax: +358 9 6966 873
> e-mail: klaus.nieminen@ficora.fi
> www: http://www.ficora.fi
>
> -----Original Message-----
> From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]
> Sent: 6. marraskuuta 2013 4:42
> To: frode.sorensen@npt.no; lmap@ietf.org
> Subject: Re: [lmap] LMAP regulator use case
>
> Frode
> thanks very much for the comments - and it is excellent to have detailed
> text suggestions.
>
> 2.2
> I think i'm basically OK with this replacing the current S2.2 (including
> the subsections) I suggest that it should mention comparability in the
> final para (as well as in the penultimate one) - personally I think this is
> the most important characteristic from a regulator's point of view, so that
> it's fair to compare measurements they make across the different ISPs.
> the one thing in the current S2.2 (actually in S2.2.3) that I think is
> worth keeping is a mention of fixed and mobile. I think this could be
> handled by adding to the Intro (S1) something like: "Measurements will take
> place on both fixed and mobile access"
>
> Happy to add a new chapter 4, but comments about some of your sub use cases
>
> 4.1 Promoting competition through transparency
> >>For competition to successfully discipline operators' behaviour in the
> interests of their customers, end users must be fully aware of the
> characteristics of the ISPs' access offers.
> "must be fully aware" over-states things.
>
> >>The system can be operated by a regulator or a measurement provider.
> add "on behalf of the regulator"
>
> >>  However, the quality of an Internet access service is also determined
> by the connectivity to the rest of the Internet. Therefore test
> configurations which measure beyond the ISP's own network may also be
> relevant in some cases.
> true. perhaps worth mentioning that the ISPs can influence this to some
> extent - how well they're connected to the Internet, how they cache popular
> content etc.
>
> 4.2 Promoting end user empowerment
> i think this can be deleted. this is the end user use case, not the
> regulator use case.
>
> 4.3 Monitoring overall market development good for me
>
> 4.4 Detecting degradation of the Internet access
> 4.5 Detecting degradation of specific applications
>
> I don't like these sections about testing for whether the ISP is being net
> neutral.
> I think it would be very hard to design tests.
> In part this is because net neutrality is more of a political concept than
> technical one (in my view)
>
> i tihnk some of the stuff in S4.4 is really part of 4.3, as it's a market
> development issue (the internet has got slower, and doesnt meet the policy
> objective of Superfast broadband by Year 2015 - or whatever)-
>
> best wishes
> phil
>
> ________________________________________
> From: lmap-bounces@ietf.org [lmap-bounces@ietf.org] On Behalf Of
> Sørensen, Frode [frode.sorensen@npt.no]
> Sent: 30 October 2013 14:55
> To: lmap@ietf.org
> Subject: [lmap] LMAP regulator use case
>
> Marc, Phil, Trevor, all,
>
> I have prepared a proposed description of a regulator use case for the
> LMAP use case ID. I noticed the "advertisement" for further input from
> regulators for the use case a couple of weeks ago. Finally I have managed
> to find sufficient time to contribute to the ID, supported by a couple of
> "regulator friends" from the Net Neutrality Working Group of the BEREC
> organization, representing European national regulators. The proposal
> consists of two parts; a modification of section 2.2 "Regulators", plus a
> new chapter after chapter 3 "Details of ISP use case", titled "Details of
> regulator use case".
>
> Thanks,
> Frode
>
>
> Proposed update:
>
> 2.2 Regulators
> -------------------
> Regulators in jurisdictions around the world are responding to consumers'
> adoption of Internet access services for traditional telecommunications and
> media services by promoting competition among providers of electronic
> communications, to ensure that users derive maximum benefit in terms of
> choice, price, and quality.
>
> Some jurisdictions have responded to a need for greater information about
> Internet access service performance in the development of regulatory
> policies and approaches for broadband technologies by developing
> large-scale measurement programs. Programs such as the U.S. Federal
> Communications Commission's Measuring Broadband America, European
> Commission's Quality of Broadband Services in the EU reports and a growing
> list of other programs employ a diverse set of operational and technical
> approaches to gathering data to perform analysis and reporting on diverse
> aspects of broadband performance.
>
> While each jurisdiction responds to distinct consumer, industry, and
> regulatory concerns, much commonality exists in the need to produce
> datasets that are able to compare multiple Internet access service
> providers, diverse technical solutions, geographic and regional
> distributions, and marketed and provisioned levels and combinations of
> broadband Internet access services. In some jurisdictions, the role of
> measuring is provided by a measurement provider.
>
> Measurement providers measure network performance from users towards
> multiple content and application providers, included dedicated test
> measurement servers, to show a performance of the actual Internet access
> service provided by different ISPs. Users need to know the performance that
> are achieving from their own ISP. In addition, they need to know the
> performance of other ISPs of same location as background information for
> selecting their ISP. Measurement providers will provide measurement results
> with associated measurement methods and measurement metrics.
>
> _______________________________________________
> lmap mailing list
> lmap@ietf.org
> https://www.ietf.org/mailman/listinfo/lmap
>