Re: [lmap] What is broadband?

James Miller <jamesmilleresquire@gmail.com> Fri, 08 March 2013 03:58 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 224DD21F86A1 for <lmap@ietfa.amsl.com>; Thu, 7 Mar 2013 19:58:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.099
X-Spam-Level:
X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.499, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 2qSdPbXZjIjn for <lmap@ietfa.amsl.com>; Thu, 7 Mar 2013 19:58:18 -0800 (PST)
Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) by ietfa.amsl.com (Postfix) with ESMTP id 95C9F21F8698 for <lmap@ietf.org>; Thu, 7 Mar 2013 19:58:17 -0800 (PST)
Received: by mail-wg0-f51.google.com with SMTP id 8so1963090wgl.6 for <lmap@ietf.org>; Thu, 07 Mar 2013 19:58:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=dG5Eo6DtN0LkdEQUbPLHcdxChM6iG2S1WBPSAIcWQ+w=; b=EPbAP6G8Wlrgn1meLstJT1xiCrgsY0K7630z5bxKP/tjq9BgVqxK2iv+GFz/G4g8i7 99qjgVHeqPN+5opfx1K1a/9f8Pj+/U8biCAiEpQx16ePc0Sg2eYUrnee9eRTCmKqZOku 5VZue5TVdjdObZ1jQ6JwSRgP5fu/uD25ehyaVFEPsUQ87Aynw6XiAWbLaNOyDtGA/RCh Lh9vFYLZw3PeaNAY1w9paGhMZeVGtKENn1zd2HiPv4FM1w/IhL3izn5mdMfxJFD125Ez c5dYUVHTaMjuQn8ClRBiVXcjZvL1X92dZ9DAAygX19tBMqw6dKHaozRC1wv8ofSZXt7i HPlw==
X-Received: by 10.180.100.169 with SMTP id ez9mr38140408wib.3.1362715096644; Thu, 07 Mar 2013 19:58:16 -0800 (PST)
MIME-Version: 1.0
Received: by 10.180.24.10 with HTTP; Thu, 7 Mar 2013 19:57:46 -0800 (PST)
In-Reply-To: <EC96D6A7-286D-48FE-93E9-BFA290B75C08@castlepoint.net>
References: <51387034.2040708@cisco.com> <E1565840-E564-439D-85B9-990878BD7DF4@castlepoint.net> <C6E1FAB2-526A-407D-B69C-359E60528A14@centurylink.com> <CANFMejiN=64jTvSAhY0_q91B4PqhJ7PZPPSbOsGNKMbk3=spQw@mail.gmail.com> <EC96D6A7-286D-48FE-93E9-BFA290B75C08@castlepoint.net>
From: James Miller <jamesmilleresquire@gmail.com>
Date: Thu, 07 Mar 2013 22:57:46 -0500
Message-ID: <CANFMejgPTnqvjFMzJFNPxOjFbX6moxbddb1_7y7ZYtynByYxzA@mail.gmail.com>
To: Shane Amante <shane@castlepoint.net>
Content-Type: multipart/alternative; boundary="14dae9cc9c564404c104d761d57f"
Cc: Benoit Claise <bclaise@cisco.com>, "Bugenhagen, Michael K" <Michael.K.Bugenhagen@centurylink.com>, "lmap@ietf.org" <lmap@ietf.org>
Subject: Re: [lmap] What is broadband?
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: Fri, 08 Mar 2013 03:58:20 -0000

I agree Shane--was what I was trying to get at. :)

Our early FCC focus was basically the Access network but I think we're all
making the point that the mix-n-match of the network measurement pieces
will be driven by a particular user's use case.

For our FCC work, the focus (discussed in more detail in our reports) was
on understanding the performance in the segment under the control of a
carrier delivering broadband to a given consumer.  Naturally many other
elements affect an end user's experience but our initial interest was on
understanding that segment for the purposes of providing better information
to the consumer about the portion of Internet performance that the carrier
provides.  The FCC's focus and history is on that piece and so it makes
sense that it might begin there, but a particular carrier's focus might
mirror the access network focus, but perhaps with less market-trend
orientation and more diagnostic in flavor.  Maybe LMAP together with other
protocols (TR69 and other BBForum work for example) could benefit all those
use cases.

In recent meetings we've discussed other more targeted mini-studies on
things like CDN or in-home Wifi performance.  Other potential LMAP users
already focus their work on these or other elements of the network.  I
would envision the LMAP work could provide the glue between any of these
elements and different use cases.  Worth noting that much of the initial
discussions in the FCC's Next-Gen group were on the potential value of
standardized interfaces between such different elements of measurement
infrastructure.

Another element that's probably worth noting is that the use cases also may
direct the actual tests that someone wants to run.  I would imagine the
actual tests you might want to run for evaluating in-home LAN, access
network, CDN, mobile networks may vary.  So I think the work on the test
registry and other IPPM work on new tests will also improve our definitions
and understanding of "broadband performance".

As always my personal views and not the FCC's.. possible valued at less
than $.02  :)

On Thu, Mar 7, 2013 at 10:24 PM, Shane Amante <shane@castlepoint.net> wrote:

> James, All,
>
> On Mar 7, 2013, at 7:30 PM, James Miller <jamesmilleresquire@gmail.com>
> wrote:
>
> I believe that Henning had commented at some point that the LMAP
> definition he contemplated had "architecture" as the 'A' element but
> certainly access is an important piece.  I think one of the problems that
> has been discussed also on the LMAP and our FCC Next-Gen lists is that a
> complete view of LMAP performance measurements would implicate elements
> from the user's laptop, through wireless and other local LAN, carriers
> access networks, Tier 1 and other peering networks, the application host
> side and everything in between.  Clearly there would be a lot of
> technologies included within that functional scope.
>
>
> I agree that access is important, but not to the exclusion of everything
> else that constitutes an Internet end-user customer experience or,
> alternatively, an Enterprise end-user customer experience -- which is what
> I believe you're saying above?  That's why it will be important to, at some
> point, figure out *if*, and then how, to try to segment the portions of the
> end-to-end path that you describe above so we can attribute good or bad
> performance to a particular portion of the path so that, ultimately, the
> correct network operator can be contacted to look into the problem further.
>  I do not believe that this requires us to break down the end-to-end path
> on a router-hop by router-hop basis, but rather we need to be able to
> identify 'sign posts' along the path that can correlate well to end-to-end
> path.
>
> -shane
>
>
> For reference, in the FCC Measuring Broadband America Program we focused
> on measurement from the consumers' broadband modem through the carriers
> network to where it connects to a tier one peering point.  LMAP should be
> able to address the broad mix of other use cases that would have a mix of
> other elements and motivations.
>
> Graphic in Report at page 9.
> http://transition.fcc.gov/cgb/measuringbroadbandreport/2Methodology.pdf
>
> On Thu, Mar 7, 2013 at 5:20 PM, Bugenhagen, Michael K <
> Michael.K.Bugenhagen@centurylink.com> wrote:
>
>>  The word "access" should be key here as part of the definition provided
>> we are talking about an Internet service, which is the second component.
>> I don't really  think we are building tests that won't work on smaller
>> pipes so questioning if it really 'broadband' or not is correct IMO.
>>
>>
>>
>> Sent from my iPhone
>>
>> On Mar 7, 2013, at 9:41 AM, "Shane Amante" <shane@castlepoint.net> wrote:
>>
>>  Benoit,
>>
>>  On Mar 7, 2013, at 3:47 AM, Benoit Claise <bclaise@cisco.com> wrote:
>>
>> Dear all,
>>
>> I started to review the drafts, and I will start posting a few questions
>> to the list.
>> Open questions, clarifying questions, in order to generate some
>> discussions.
>> Disclaimer: I have not yet read the entire list archive. Apologize in
>> advance if some points have been discussed already.
>>
>> Here is my first question. What is broadband in the LMAP context?
>> Is it DSL, cable, ETTH, Fiber to the home?  Is LMAP technology
>> independent?
>> And I see also "enterprise edge router", "cellular data or satellite" in
>> draft-schulzrinne-lmap-requirements. In or out?
>> Or do we have in mind a phase approach, starting with the "enterprise
>> edge router" first, and then home network?
>>
>>
>>  Speaking for the network I operate, I'm very much an advocate of saying
>> that "Enterprise Edge Router" is "in-scope".  We would very much benefit
>> from a standards-based measurement enablement and collection regime vs.
>> mostly proprietary, and non-scalable, approaches that exist today.
>>
>>  This is not to diminish the importance of similar test capabilities for
>> residential broadband use-cases.  We absolutely need to work on those, as
>> well.
>>
>>  With respect to priority, my hope is that we do not have to choose to
>> prioritize one over the other.  Rather, I would hope that both can be
>> developed in parallel, because both -- at least, IMO -- have a
>> substantially overlapping set of requirements/features.
>>
>>  My $0.02,
>>
>>  -shane
>>
>>
>>  Interestingly, I don't know what A stands for in LMAP, if it stands for
>> something.
>> According to http://trac.tools.ietf.org/bof/trac/wiki/WikiStart, the A
>> doesn't stand for anything.
>> However, looking at the different draft titles, there is some confusion.
>>
>>    draft-linsner-lmap-use-cases-0 title is Large-Scale Broadband Measurement Use Cases
>>    draft-schulzrinne-lmap-requirements-00.txt title is Large-Scale Measurement of Broadband Performance
>>    draft-boucadair-lmap-considerations-00, *Large scale Measurement of **Access **network Performance (LMAP)*:
>>       Requirements and Issues from a Network Provider Perspective
>>
>>
>> Some more discussions, on the mailing list or during the BoF, on this
>> topic would be appreciated.
>>
>> Regards, Benoit
>>
>>
>>
>>  _______________________________________________
>> lmap mailing list
>> lmap@ietf.org
>> https://www.ietf.org/mailman/listinfo/lmap
>>
>>
>>   _______________________________________________
>> lmap mailing list
>> lmap@ietf.org
>> https://www.ietf.org/mailman/listinfo/lmap
>>
>>
>> _______________________________________________
>> lmap mailing list
>> lmap@ietf.org
>> https://www.ietf.org/mailman/listinfo/lmap
>>
>>
>
>