Re: [lmap] LMAP framework issue #1 User-initiated Measurement Tasks

I think both are very valid options. Comments below...

>-----Original Message-----
>From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of
>marcelo bagnulo braun
>Sent: 04 September 2013 08:30
>To: lmap@ietf.org
>Subject: Re: [lmap] LMAP framework issue #1 User-initiated Measurement
>Tasks
>
>So, my concern here is that in the first option, it seems that the user
>initiated tests can be controlled by the ISP and the ISP could be aware fo
>what tests the user is trying to do and react accordingly (suppose the ISP
>usually caps some type of traffic and when it realizes the user is trying to
>test for the capacity, it opens the cap).

It is the ISPs measurement system. It is a perfectly valid option for the ISP to allow the users to use the same measurement system. The scenario you describe could actually be a benefit since the test traffic is known to the ISP who will discount this traffic from usage caps.

I really don't see any ISP trying to pretend their line speeds etc. are higher than they actually are - they wouldn't have to modify the network to do this - just lie about the result, but I really don't see this as plausible.

>The second option, i think it is the way to go, but as you wrote it it reads a
>bit weak. I woudl rather a stronger wording, like a MUST or at least a
>SHOULD (i mean, the user initiated measurement function MUST be availabel
>in the MA)

If this is a separate measurement system there IS a Controller. The user owns that Controller. There will be some management interface to that Controller to schedule or request tests, or maybe it's just a standard test schedule that is run. The management interface I think doesn't need to be standardised.

>regards, marcelo
>
>
>El 03/09/13 18:58, philip.eardley@bt.com escribió:
>>
>> We've now started creating an LMAP framework doc that merges 3 I-Ds
>> (terminology and the 2 framework docs) - hoping it could be the basis
>> for a WG doc - as mentioned in Berlin.
>>
>> One section will be about proposed constraints /assumptions -
>> extending
>> http://tools.ietf.org/html/draft-eardley-lmap-framework-02#section-3
>>
>> I'm going to send a series of emails to try and capture where I think
>> the discussion got to in Berlin &/or propose text for the I-D &/or
>> generate discussion on open issues.
>>
>> Constraint: User-initiated Measurement Tasks out of scope of LMAP WG
>>
>> We expect LMAP & IPPM functionality to be used for user-initiated
>> Measurement Tasks, but the WG will not define how. There are at least
>> two ways user-initiation could happen, in outline
>>
>> * a user could somehow (perhaps via a webpage) request the ISP- (or
>> regulator-) run measurement system to test his/her line. The ISP (or
>> regulator) Controller would then send an Instruction to the MA in the
>> usual LMAP way. The Measurement Results could be returned back via the
>> webpage. Note that a user can't directly initiate a Measurement Task
>> on an ISP- (or regulator-) controlled MA in their home
>>
>> * a user could deploy their own measurement system, with their own MA,
>> Controller and Collector (possibly with all three functions in the
>> same box). The user may also want to report Measurement Results to a
>> third party. One possible situation is that the home contains a
>> user-controlled MA and an ISP-controlled MA; then the test traffic of
>> one MA is treated by the other MA just like any other user traffic.
>> Note that a single MA is instructed by a single Controller and is only
>> in one measurement system.
>>
>> For further details see
>> http://www.ietf.org/mail-archive/web/lmap/current/msg00714.html and
>> related messages.
>>
>> Comments?
>>
>> Thanks
>>
>> phil
>>
>>
>>
>> _______________________________________________
>> 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