From trevor.burbridge@bt.com Mon Dec 2 02:31:51 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BEE31AE2BE for ; Mon, 2 Dec 2013 02:31:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XfzS6U08pipq for ; Mon, 2 Dec 2013 02:31:49 -0800 (PST) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.234]) by ietfa.amsl.com (Postfix) with ESMTP id 58E681AE10F for ; Mon, 2 Dec 2013 02:31:48 -0800 (PST) Received: from EVMHT67-UKRD.domain1.systemhost.net (10.36.3.104) by RDW083A005ED61.bt.com (10.187.98.10) with Microsoft SMTP Server (TLS) id 14.3.169.1; Mon, 2 Dec 2013 10:31:48 +0000 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.1.248]) by EVMHT67-UKRD.domain1.systemhost.net ([10.36.3.104]) with mapi; Mon, 2 Dec 2013 10:31:18 +0000 From: To: Date: Mon, 2 Dec 2013 10:31:17 +0000 Thread-Topic: Information Model suggested modifications Thread-Index: Ac7vSaDzC6H/Xz+iTPiI6MKWiFcFHQ== Message-ID: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: marcelo@it.uc3m.es, philip.eardley@bt.com, j.schoenwaelder@jacobs-university.de Subject: [lmap] Information Model suggested modifications X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 10:31:51 -0000 For the forthcoming edit of the Information Model I have been collecting su= ggestions. Aside from the ones dealing with readability, corrections, expla= nations, examples and alignment with the Framework draft, I have the follow= ing suggested amendments: 1) Implementation of status/logging as just another Measurement Task report= ing on just another (if desired) reporting Channel. In nomenclature terms t= his would still go to a Collector, but the Controller is able to implement = a Collector interface of its own if it needs this information. 2) Allow Measurement Tasks multiple outputs than can be separated onto mult= iple Channels. This would allow error output to be separated for example or= for alarms to be escalated immediately. Simple change and already adopted = into the Framework 3) Extend Interface choice to Channels as well as Measurement Tasks. This w= ould, for example, allow a report or an alarm to be sent over GPRS or other= interface. 4) Add Boolean "send null reports" to Channel information. Allows the suppr= ession of empty reports or choice to receive empty reports for heartbeat pu= rposes. 5) Add selection of either "UTC" or "local time" to the Schedule. The suppo= rt of local time is needed, for example, for the probe to manage its own sc= hedule through daylight changing or to test within a defined peak or evenin= g period. 6) Give example of a Channel to a local datastore that can be used by a Mea= surement Task for alarms or aggregate statistics. No changes to the Informa= tion Model itself except: we would need to define when the data expires on = these local datastores. Need to add the concept of a datastore and an expir= y either as "max storage size" or "retention period". The one that I am still tracking but isn't yet formed enough to be included= : A) Include a definition of a way to suppress or back-off measurements/repor= ts if the controller/collector is unreachable. If I don't hear any objections then I'll go ahead and include 1-6. Trevor Burbridge From j.schoenwaelder@jacobs-university.de Mon Dec 2 03:52:22 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E0BA1AE3F6 for ; Mon, 2 Dec 2013 03:52:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sywGyirUCRst for ; Mon, 2 Dec 2013 03:52:18 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id CCE001ADEA6 for ; Mon, 2 Dec 2013 03:52:17 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 15E2720077; Mon, 2 Dec 2013 12:52:15 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id q9efWUgyWJFn; Mon, 2 Dec 2013 12:52:14 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 51A0B2006D; Mon, 2 Dec 2013 12:52:14 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id C2695299B8F6; Mon, 2 Dec 2013 12:52:07 +0100 (CET) Date: Mon, 2 Dec 2013 12:52:06 +0100 From: Juergen Schoenwaelder To: trevor.burbridge@bt.com Message-ID: <20131202115206.GA2384@elstar.local> Mail-Followup-To: trevor.burbridge@bt.com, lmap@ietf.org, philip.eardley@bt.com, marcelo@it.uc3m.es References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: marcelo@it.uc3m.es, philip.eardley@bt.com, lmap@ietf.org Subject: Re: [lmap] Information Model suggested modifications X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 11:52:22 -0000 Trevor, with this becoming a WG document, I think this needs to go to the lmap WG mailing list. For me, it is not clear how much change the various items involve - so it is hard to say something. For example 2), how do you identify the multiple outputs and map them to different channels? Concerning 1), this is really for tracking state in order to do proper data analysis later on. I am not sure this is the right thing to do in order to let the controller know how to set proper parameters for a give probe. /js On Mon, Dec 02, 2013 at 10:31:17AM +0000, trevor.burbridge@bt.com wrote: > For the forthcoming edit of the Information Model I have been collecting suggestions. Aside from the ones dealing with readability, corrections, explanations, examples and alignment with the Framework draft, I have the following suggested amendments: > > 1) Implementation of status/logging as just another Measurement Task reporting on just another (if desired) reporting Channel. In nomenclature terms this would still go to a Collector, but the Controller is able to implement a Collector interface of its own if it needs this information. > > 2) Allow Measurement Tasks multiple outputs than can be separated onto multiple Channels. This would allow error output to be separated for example or for alarms to be escalated immediately. Simple change and already adopted into the Framework > > 3) Extend Interface choice to Channels as well as Measurement Tasks. This would, for example, allow a report or an alarm to be sent over GPRS or other interface. > > 4) Add Boolean "send null reports" to Channel information. Allows the suppression of empty reports or choice to receive empty reports for heartbeat purposes. > > 5) Add selection of either "UTC" or "local time" to the Schedule. The support of local time is needed, for example, for the probe to manage its own schedule through daylight changing or to test within a defined peak or evening period. > > 6) Give example of a Channel to a local datastore that can be used by a Measurement Task for alarms or aggregate statistics. No changes to the Information Model itself except: we would need to define when the data expires on these local datastores. Need to add the concept of a datastore and an expiry either as "max storage size" or "retention period". > > > The one that I am still tracking but isn't yet formed enough to be included: > > A) Include a definition of a way to suppress or back-off measurements/reports if the controller/collector is unreachable. > > > If I don't hear any objections then I'll go ahead and include 1-6. > > Trevor Burbridge -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Mon Dec 2 03:53:30 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D55F1AE3FC for ; Mon, 2 Dec 2013 03:53:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IAN_riydZUtQ for ; Mon, 2 Dec 2013 03:53:29 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 1F3371ADEA6 for ; Mon, 2 Dec 2013 03:53:29 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id A82332007C; Mon, 2 Dec 2013 12:53:26 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id roGJj2-3XLUl; Mon, 2 Dec 2013 12:53:26 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 41AF62007A; Mon, 2 Dec 2013 12:53:26 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id E2549299B95C; Mon, 2 Dec 2013 12:53:21 +0100 (CET) Date: Mon, 2 Dec 2013 12:53:21 +0100 From: Juergen Schoenwaelder To: trevor.burbridge@bt.com, lmap@ietf.org, philip.eardley@bt.com, marcelo@it.uc3m.es Message-ID: <20131202115321.GB2384@elstar.local> Mail-Followup-To: trevor.burbridge@bt.com, lmap@ietf.org, philip.eardley@bt.com, marcelo@it.uc3m.es References: <20131202115206.GA2384@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20131202115206.GA2384@elstar.local> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [lmap] Information Model suggested modifications X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 11:53:30 -0000 On Mon, Dec 02, 2013 at 12:52:06PM +0100, Juergen Schoenwaelder wrote: > Trevor, > > with this becoming a WG document, I think this needs to go to the lmap > WG mailing list. Oops, this is on the lmap mailing list. Good. I guess my brain is still not fully awake. Monday morning problem. Sorry, /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From trevor.burbridge@bt.com Mon Dec 2 04:05:42 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B46151AE45A for ; Mon, 2 Dec 2013 04:05:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.735 X-Spam-Level: X-Spam-Status: No, score=-0.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h8HGprEroum2 for ; Mon, 2 Dec 2013 04:05:40 -0800 (PST) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id EBE301AE40D for ; Mon, 2 Dec 2013 04:05:39 -0800 (PST) Received: from EVMHT63-UKRD.domain1.systemhost.net (10.36.3.100) by RDW083A006ED62.bt.com (10.187.98.11) with Microsoft SMTP Server (TLS) id 14.3.169.1; Mon, 2 Dec 2013 12:05:36 +0000 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.1.248]) by EVMHT63-UKRD.domain1.systemhost.net ([10.36.3.100]) with mapi; Mon, 2 Dec 2013 12:04:49 +0000 From: To: Date: Mon, 2 Dec 2013 12:04:48 +0000 Thread-Topic: Information Model suggested modifications Thread-Index: Ac7vVQTbwfOLJUfGQ463Zu4fFwoWNgAAG27g Message-ID: References: <20131202115206.GA2384@elstar.local> In-Reply-To: <20131202115206.GA2384@elstar.local> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: marcelo@it.uc3m.es, philip.eardley@bt.com, lmap@ietf.org Subject: Re: [lmap] Information Model suggested modifications X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 12:05:42 -0000 >-----Original Message----- >From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] >Sent: 02 December 2013 11:52 >To: Burbridge,T,Trevor,TUB8 R >Cc: lmap@ietf.org; Eardley,PL,Philip,TUB8 R; marcelo@it.uc3m.es >Subject: Re: Information Model suggested modifications > >Trevor, > >with this becoming a WG document, I think this needs to go to the lmap WG >mailing list. For me, it is not clear how much change the various items in= volve - so >it is hard to say something. For example 2), how do you identify the multi= ple >outputs and map them to different channels? I think this is a simple change. Instead of specifying a single Channel in = the Measurement Task Schedule there will instead be an array of Channels. F= irst measurement task output will go to the first Channel etc.=20 Instead of just an array of Channels, I could use a List of OutputID: Chann= el pairs but I think this is unnecessary complexity as the OutputID would j= ust be a positive integer in any case. >Concerning 1), this is really for tracking state in order to do proper dat= a analysis >later on. I am not sure this is the right thing to do in order to let the = controller >know how to set proper parameters for a give probe. I'm just suggesting that everything that is 'pushed' from the probe can be = defined by a Measurement Task. That includes what sync rate, if the Hub has= powered up, memory errors etc. as well as classic measurement results. We = don't need to define where it goes to as that will be left to the specific = measurement system embodiment. >/js > >On Mon, Dec 02, 2013 at 10:31:17AM +0000, trevor.burbridge@bt.com wrote: >> For the forthcoming edit of the Information Model I have been collecting >suggestions. Aside from the ones dealing with readability, corrections, >explanations, examples and alignment with the Framework draft, I have the >following suggested amendments: >> >> 1) Implementation of status/logging as just another Measurement Task >reporting on just another (if desired) reporting Channel. In nomenclature = terms >this would still go to a Collector, but the Controller is able to implemen= t a >Collector interface of its own if it needs this information. >> >> 2) Allow Measurement Tasks multiple outputs than can be separated onto >> multiple Channels. This would allow error output to be separated for >> example or for alarms to be escalated immediately. Simple change and >> already adopted into the Framework >> >> 3) Extend Interface choice to Channels as well as Measurement Tasks. Thi= s >would, for example, allow a report or an alarm to be sent over GPRS or oth= er >interface. >> >> 4) Add Boolean "send null reports" to Channel information. Allows the >suppression of empty reports or choice to receive empty reports for heartb= eat >purposes. >> >> 5) Add selection of either "UTC" or "local time" to the Schedule. The su= pport of >local time is needed, for example, for the probe to manage its own schedul= e >through daylight changing or to test within a defined peak or evening peri= od. >> >> 6) Give example of a Channel to a local datastore that can be used by a >Measurement Task for alarms or aggregate statistics. No changes to the >Information Model itself except: we would need to define when the data exp= ires >on these local datastores. Need to add the concept of a datastore and an e= xpiry >either as "max storage size" or "retention period". >> >> >> The one that I am still tracking but isn't yet formed enough to be inclu= ded: >> >> A) Include a definition of a way to suppress or back-off measurements/re= ports >if the controller/collector is unreachable. >> >> >> If I don't hear any objections then I'll go ahead and include 1-6. >> >> Trevor Burbridge > >-- >Juergen Schoenwaelder Jacobs University Bremen gGmbH >Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Mon Dec 2 05:17:40 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0C491AE21A for ; Mon, 2 Dec 2013 05:17:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IMggkFbdF-GV for ; Mon, 2 Dec 2013 05:17:38 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id E51971AE428 for ; Mon, 2 Dec 2013 05:17:37 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7228420056; Mon, 2 Dec 2013 14:17:35 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ivDRRzerO54l; Mon, 2 Dec 2013 14:17:35 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B433120041; Mon, 2 Dec 2013 14:17:34 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 6D280299BB75; Mon, 2 Dec 2013 14:17:29 +0100 (CET) Date: Mon, 2 Dec 2013 14:17:28 +0100 From: Juergen Schoenwaelder To: Steven Miller Message-ID: <20131202131728.GA2649@elstar.local> Mail-Followup-To: Steven Miller , philip.eardley@bt.com, trevor.burbridge@bt.com, lmap@ietf.org References: <20131128164756.GA70319@elstar.local> <20131129120118.GA72776@elstar.local> <529A6508.2020706@idrathernotsay.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <529A6508.2020706@idrathernotsay.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: philip.eardley@bt.com, trevor.burbridge@bt.com, lmap@ietf.org Subject: Re: [lmap] Defining Status and Logging (Capabilities and Failure) X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 13:17:41 -0000 Steve, my point was to take some details out of the information model - I did not mean to say any of the currently listed state in the information model is not useful. In fact, I believe there is even more stuff that can be useful for certain measurements. My point was that if we make state reporting to support data analysis a measurement task, then we do not have to detail this state information in the information model and we can leave it to a state reporting measurement task definition. The thing I am less clear about is the information needed by the controller to do its job. I prefer that we do not require or assume any complex measurement task specific logic in the controller in order to set parameters for the measurement tasks. I prefer that measurement tasks are smart enough to understand their environment and to generate warnings/errors where appropriate or to adapt where possible. /js On Sat, Nov 30, 2013 at 05:22:00PM -0500, Steven Miller wrote: > FWIW I like the idea that feeding operational state back is just > another measurement task. The stuff in the current I-D does seem > like a long list, though as I read it with an eye to things I > thought could easily be thrown out, I found myself thinking that > most or all of that is stuff I'd like to have available if I was > trying to figure out after the fact why something had started > performing poorly. For example, knowing the gateway that was in use > at a time more-or-less around when a given measurement started > reporting poor results might let me cross-correlate that back to a > device for which I have some other failure information, a la "oh, > that was this router, yeah, there was a device-down alert for that > at the same time, that explains it." > > -Steve > > On 11/29/2013 7:01 AM, Juergen Schoenwaelder wrote: > >On Fri, Nov 29, 2013 at 10:56:05AM +0000, philip.eardley@bt.com wrote: > >>Yes, it's always possible to report info to the Collector and from there (via an out-of-scope mechanism) to the Controller. The example we gave was the results of one test leading to some follow-up tests. Maybe this type of interaction should be assumed where we have to analyse the results before deciding what Task to do next - if you're trying to diagnose a fault. > >>Whereas if you're trying to decide how big a file to use for your download speed test, that depends on operational state (the interface speed) > >You can design this into the test itself by making the test adapt to > >the interface speed and perhaps also at the statistical properties of > >the download, e.g. you request a big file but abort the transfer once > >you have sufficient data received. The more self-contained tests can > >be, the less the controller needs to understand about every test, > >which leads to a great simplification overall. > >>The info model has lots of optional stuff concerning operational state. Who decides what's sent? Does the Controller's Request-for-operational-info include the list of things it wants to learn? Or not - and then does the MA reply with all Operational-info? Everything that's changed since it last sent? Any operational-info at its choice? > >>Do we allow extensibility? Ie can the operator of the measurement system include its own additional operational-info fields? If yes, how? > >> > >>My guesses would be: > >>Request-for-operational-info(list) or (all) > >>Can define own operator /vendor specific fields > >I think it is fair to assume that there is a mechanism that allows a > >controller to select the operational state it is interested > >in. Whether there is an "everything since last time" filter, I do not > >know - this requires some state to be kept on the device. And yes, I > >believe operational state needs to be extensible and hence I suggested > >to actually reduce stuff we currently have in the information model so > >that we do not spend lots of time discussing what operational state > >might all be useful (since this depends to a large extend on the tests > >you are running). > > > >/js > > > > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From philip.eardley@bt.com Mon Dec 2 10:18:37 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D153E1AD9A9 for ; Mon, 2 Dec 2013 10:18:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rOGI5qVwQTjD for ; Mon, 2 Dec 2013 10:18:35 -0800 (PST) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id 381751ADBFF for ; Mon, 2 Dec 2013 10:18:35 -0800 (PST) Received: from EVMHT63-UKRD.domain1.systemhost.net (10.36.3.100) by RDW083A006ED62.bt.com (10.187.98.11) with Microsoft SMTP Server (TLS) id 14.3.169.1; Mon, 2 Dec 2013 18:18:26 +0000 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.1.152]) by EVMHT63-UKRD.domain1.systemhost.net ([10.36.3.100]) with mapi; Mon, 2 Dec 2013 18:18:25 +0000 From: To: , Date: Mon, 2 Dec 2013 18:18:24 +0000 Thread-Topic: Information Model suggested modifications Thread-Index: Ac7vSaDzC6H/Xz+iTPiI6MKWiFcFHQAPcjCw Message-ID: References: In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: marcelo@it.uc3m.es, j.schoenwaelder@jacobs-university.de Subject: Re: [lmap] Information Model suggested modifications X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 18:18:38 -0000 A few comments. Yes, some of these would imply some mods to the framework: 1 - would affect framework But, thinking about it more, personally I'd be inclined to be more direct, = ie define the status /logging (capability /failure) msg as going to the con= troller. Unless we think that these msgs will really go to the collector so= metimes.=20 If we end up with different Controller-MA and MA-Collector protocols, then = it has implications for the implementation of a Controller.=20 2 - not yet in framework, happy to add it 3 - yes, will need to check how well the framework talks about multiple int= erfaces 4 - think this is sensible (also worth mentioning in framework) 5 - ok 6 - I think this is reasonable idea, though doesn't affect protocol on the = wire, so I don't think it's compulsory to include it in lmap1.0=20 if people are happy for it to be included, then it should also be discussed= in the framework.=20 A - the framework says, by implication - if the controller is unreachable then the MA runs to the end of its sched= ule and stops. I prefer this to trying to define what unreachable means, vi= a a heartbeat or something. Ie the MA gets its instruction and then gets on= with it, autonomously. - if the collector is unreachable (no ACK when it sends its measurement Rep= ort) then it sends a failure msg to the Controller. Think I'd leave it to i= mplementation decision what it does beyond this (as there are lots of possi= bilities and don't think the right answer will always be the same. eg keep = or throw away the results? How long to wait to hear about a new reporting c= hannel from the controller?) =09 > -----Original Message----- > From: Burbridge,T,Trevor,TUB8 R > Sent: 02 December 2013 10:31 > To: lmap@ietf.org > Cc: Eardley,PL,Philip,TUB8 R; marcelo bagnulo braun > (marcelo@it.uc3m.es); Juergen Schoenwaelder (j.schoenwaelder@jacobs- > university.de) > Subject: Information Model suggested modifications >=20 > For the forthcoming edit of the Information Model I have been > collecting suggestions. Aside from the ones dealing with readability, > corrections, explanations, examples and alignment with the Framework > draft, I have the following suggested amendments: >=20 > 1) Implementation of status/logging as just another Measurement Task > reporting on just another (if desired) reporting Channel. In > nomenclature terms this would still go to a Collector, but the > Controller is able to implement a Collector interface of its own if it > needs this information. >=20 > 2) Allow Measurement Tasks multiple outputs than can be separated onto > multiple Channels. This would allow error output to be separated for > example or for alarms to be escalated immediately. Simple change and > already adopted into the Framework >=20 > 3) Extend Interface choice to Channels as well as Measurement Tasks. > This would, for example, allow a report or an alarm to be sent over > GPRS or other interface. >=20 > 4) Add Boolean "send null reports" to Channel information. Allows the > suppression of empty reports or choice to receive empty reports for > heartbeat purposes. >=20 > 5) Add selection of either "UTC" or "local time" to the Schedule. The > support of local time is needed, for example, for the probe to manage > its own schedule through daylight changing or to test within a defined > peak or evening period. >=20 > 6) Give example of a Channel to a local datastore that can be used by a > Measurement Task for alarms or aggregate statistics. No changes to the > Information Model itself except: we would need to define when the data > expires on these local datastores. Need to add the concept of a > datastore and an expiry either as "max storage size" or "retention > period". >=20 >=20 > The one that I am still tracking but isn't yet formed enough to be > included: >=20 > A) Include a definition of a way to suppress or back-off > measurements/reports if the controller/collector is unreachable. >=20 >=20 > If I don't hear any objections then I'll go ahead and include 1-6. >=20 > Trevor Burbridge From j.schoenwaelder@jacobs-university.de Mon Dec 2 11:03:51 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CD811ADDD3 for ; Mon, 2 Dec 2013 11:03:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7SvQ6b-TtLk7 for ; Mon, 2 Dec 2013 11:03:49 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id E92CB1ADDCA for ; Mon, 2 Dec 2013 11:03:48 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2EBB420084; Mon, 2 Dec 2013 20:03:46 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id kou6vF2rPFb0; Mon, 2 Dec 2013 20:03:46 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8261C2003E; Mon, 2 Dec 2013 20:03:45 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 1B545299C73D; Mon, 2 Dec 2013 20:03:41 +0100 (CET) Date: Mon, 2 Dec 2013 20:03:41 +0100 From: Juergen Schoenwaelder To: philip.eardley@bt.com Message-ID: <20131202190341.GB3557@elstar.local> Mail-Followup-To: philip.eardley@bt.com, trevor.burbridge@bt.com, lmap@ietf.org, marcelo@it.uc3m.es References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: marcelo@it.uc3m.es, trevor.burbridge@bt.com, lmap@ietf.org Subject: Re: [lmap] Information Model suggested modifications X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 19:03:51 -0000 On Mon, Dec 02, 2013 at 06:18:24PM +0000, philip.eardley@bt.com wrote: > A few comments. > Yes, some of these would imply some mods to the framework: > > 1 - would affect framework > But, thinking about it more, personally I'd be inclined to be more direct, ie define the status /logging (capability /failure) msg as going to the controller. Unless we think that these msgs will really go to the collector sometimes. > If we end up with different Controller-MA and MA-Collector protocols, then it has implications for the implementation of a Controller. Some status information needs to go to the collector so that data analysis can take it into account. Some status information may need to go to the controller if we assume the controller will tune its instructions based on the status information. The question is to what extend we assume the controller to be smart about this or whether we expect measurement tests to be smart to adapt and/or to report proper warnings / errors. > A - the framework says, by implication > - if the controller is unreachable then the MA runs to the end of its schedule and stops. I prefer this to trying to define what unreachable means, via a heartbeat or something. Ie the MA gets its instruction and then gets on with it, autonomously. In other words, an MA that got the instruction to run a download test every hour will do this for years even if the rest of the measurement infrastructure ceased to exist. Or in other words, you are suggesting that as a best practice a controller should send only reasonably time-bound schedules and the controller renew them in due time to address this issue? > - if the collector is unreachable (no ACK when it sends its measurement Report) then it sends a failure msg to the Controller. Think I'd leave it to implementation decision what it does beyond this (as there are lots of possibilities and don't think the right answer will always be the same. eg keep or throw away the results? How long to wait to hear about a new reporting channel from the controller?) To the controller? Or over the logging channel? Do we assume that the logging channel is always "bound" to the controller? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From philip.eardley@bt.com Tue Dec 3 01:07:42 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50D091AE0DA for ; Tue, 3 Dec 2013 01:07:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tVkXAkz5E1RF for ; Tue, 3 Dec 2013 01:07:40 -0800 (PST) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.234]) by ietfa.amsl.com (Postfix) with ESMTP id C1E4C1AE0D8 for ; Tue, 3 Dec 2013 01:07:39 -0800 (PST) Received: from EVMHT66-UKRD.domain1.systemhost.net (10.36.3.103) by RDW083A005ED61.bt.com (10.187.98.10) with Microsoft SMTP Server (TLS) id 14.3.169.1; Tue, 3 Dec 2013 09:07:40 +0000 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.1.152]) by EVMHT66-UKRD.domain1.systemhost.net ([10.36.3.103]) with mapi; Tue, 3 Dec 2013 09:07:11 +0000 From: To: Date: Tue, 3 Dec 2013 09:07:10 +0000 Thread-Topic: Information Model suggested modifications Thread-Index: Ac7vkTwAPqkNxDLGQKOTgbFbmynYjwAdaE8A Message-ID: References: <20131202190341.GB3557@elstar.local> In-Reply-To: <20131202190341.GB3557@elstar.local> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: marcelo@it.uc3m.es, trevor.burbridge@bt.com, lmap@ietf.org Subject: Re: [lmap] Information Model suggested modifications X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 09:07:42 -0000 > > A - the framework says, by implication > > - if the controller is unreachable then the MA runs to the end of its > schedule and stops. I prefer this to trying to define what unreachable > means, via a heartbeat or something. Ie the MA gets its instruction and > then gets on with it, autonomously. >=20 > In other words, an MA that got the instruction to run a download test > every hour will do this for years even if the rest of the measurement > infrastructure ceased to exist. Or in other words, you are suggesting > that as a best practice a controller should send only reasonably time- > bound schedules and the controller renew them in due time to address > this issue? yes From j.schoenwaelder@jacobs-university.de Tue Dec 3 01:15:59 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 486AD1AE0E8 for ; Tue, 3 Dec 2013 01:15:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9dMw6op9_ZMT for ; Tue, 3 Dec 2013 01:15:56 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id BDC1C1AE0F4 for ; Tue, 3 Dec 2013 01:15:56 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id D38682006F; Tue, 3 Dec 2013 10:15:53 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id A-gTtHHK8Xzx; Tue, 3 Dec 2013 10:15:53 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4D2E52006D; Tue, 3 Dec 2013 10:15:53 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 212FD29CC036; Tue, 3 Dec 2013 10:15:47 +0100 (CET) Date: Tue, 3 Dec 2013 10:15:47 +0100 From: Juergen Schoenwaelder To: philip.eardley@bt.com Message-ID: <20131203091547.GA69772@elstar.local> Mail-Followup-To: philip.eardley@bt.com, trevor.burbridge@bt.com, lmap@ietf.org, marcelo@it.uc3m.es References: <20131202190341.GB3557@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: marcelo@it.uc3m.es, trevor.burbridge@bt.com, lmap@ietf.org Subject: Re: [lmap] Information Model suggested modifications X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 09:15:59 -0000 On Tue, Dec 03, 2013 at 09:07:10AM +0000, philip.eardley@bt.com wrote: > > > A - the framework says, by implication > > > - if the controller is unreachable then the MA runs to the end of its > > schedule and stops. I prefer this to trying to define what unreachable > > means, via a heartbeat or something. Ie the MA gets its instruction and > > then gets on with it, autonomously. > > > > In other words, an MA that got the instruction to run a download test > > every hour will do this for years even if the rest of the measurement > > infrastructure ceased to exist. Or in other words, you are suggesting > > that as a best practice a controller should send only reasonably time- > > bound schedules and the controller renew them in due time to address > > this issue? > > yes If we adopt this approach, I think we need to discuss this explicitely somewhere. But where? In the framework? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From philip.eardley@bt.com Tue Dec 3 01:39:11 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B35741AE074 for ; Tue, 3 Dec 2013 01:39:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y4A5_Qcfs2k7 for ; Tue, 3 Dec 2013 01:39:10 -0800 (PST) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id 874091AE067 for ; Tue, 3 Dec 2013 01:39:09 -0800 (PST) Received: from EVMHT61-UKRD.domain1.systemhost.net (10.36.3.127) by RDW083A006ED62.bt.com (10.187.98.11) with Microsoft SMTP Server (TLS) id 14.3.169.1; Tue, 3 Dec 2013 09:39:06 +0000 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.1.152]) by EVMHT61-UKRD.domain1.systemhost.net ([10.36.3.127]) with mapi; Tue, 3 Dec 2013 09:38:58 +0000 From: To: Date: Tue, 3 Dec 2013 09:38:58 +0000 Thread-Topic: Information Model suggested modifications Thread-Index: Ac7wCEWOx0QIdF++R02V20LFjVd4PQAAuknw Message-ID: References: <20131202190341.GB3557@elstar.local> <20131203091547.GA69772@elstar.local> In-Reply-To: <20131203091547.GA69772@elstar.local> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: marcelo@it.uc3m.es, trevor.burbridge@bt.com, lmap@ietf.org Subject: Re: [lmap] Information Model suggested modifications X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 09:39:11 -0000 We (framework authors) are currently preparing a new version. With this draft text:- >> The Controller may want a MA to run the same Measurement Task indefinitely = (for example, "run the 'upload speed' Measurement Task once an hour until f= urther notice"). To avoid the MA generating traffic forever after a Control= ler has permanently failed, it is suggested that the Measurement Schedule i= ncludes a time limit ("run the 'upload speed' Measurement Task once an hour= for the next 30 days") and that the Measurement Schedule is updated regula= rly (say, every 10 days). Does this work? > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > university.de] > Sent: 03 December 2013 09:16 > To: Eardley,PL,Philip,TUB8 R > Cc: Burbridge,T,Trevor,TUB8 R; lmap@ietf.org; marcelo@it.uc3m.es > Subject: Re: Information Model suggested modifications >=20 > On Tue, Dec 03, 2013 at 09:07:10AM +0000, philip.eardley@bt.com wrote: > > > > A - the framework says, by implication > > > > - if the controller is unreachable then the MA runs to the end of > > > > its > > > schedule and stops. I prefer this to trying to define what > > > unreachable means, via a heartbeat or something. Ie the MA gets its > > > instruction and then gets on with it, autonomously. > > > > > > In other words, an MA that got the instruction to run a download > > > test every hour will do this for years even if the rest of the > > > measurement infrastructure ceased to exist. Or in other words, you > > > are suggesting that as a best practice a controller should send > only > > > reasonably time- bound schedules and the controller renew them in > > > due time to address this issue? > > > > yes >=20 > If we adopt this approach, I think we need to discuss this explicitely > somewhere. But where? In the framework? >=20 > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Tue Dec 3 02:26:35 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C2DC1AE0E5 for ; Tue, 3 Dec 2013 02:26:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 51c7CW3e_rVz for ; Tue, 3 Dec 2013 02:26:34 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id EAF5F1AE09C for ; Tue, 3 Dec 2013 02:26:33 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2E49E20066; Tue, 3 Dec 2013 11:26:31 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ORmSWv8Rgt6q; Tue, 3 Dec 2013 11:26:31 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8A25A2004B; Tue, 3 Dec 2013 11:26:30 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id E2E9429CC436; Tue, 3 Dec 2013 11:26:24 +0100 (CET) Date: Tue, 3 Dec 2013 11:26:24 +0100 From: Juergen Schoenwaelder To: philip.eardley@bt.com Message-ID: <20131203102624.GA70078@elstar.local> Mail-Followup-To: philip.eardley@bt.com, trevor.burbridge@bt.com, lmap@ietf.org, marcelo@it.uc3m.es References: <20131202190341.GB3557@elstar.local> <20131203091547.GA69772@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: marcelo@it.uc3m.es, trevor.burbridge@bt.com, lmap@ietf.org Subject: Re: [lmap] Information Model suggested modifications X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 10:26:35 -0000 On Tue, Dec 03, 2013 at 09:38:58AM +0000, philip.eardley@bt.com wrote: > We (framework authors) are currently preparing a new version. > With this draft text:- > > >> > The Controller may want a MA to run the same Measurement Task indefinitely (for example, "run the 'upload speed' Measurement Task once an hour until further notice"). To avoid the MA generating traffic forever after a Controller has permanently failed, it is suggested that the Measurement Schedule includes a time limit ("run the 'upload speed' Measurement Task once an hour for the next 30 days") and that the Measurement Schedule is updated regularly (say, every 10 days). > > Does this work? Yes. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From bs7652@att.com Tue Dec 3 05:14:18 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8B9D1AE126 for ; Tue, 3 Dec 2013 05:14:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HtnvN19EYqx0 for ; Tue, 3 Dec 2013 05:14:16 -0800 (PST) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id B23CC1AE111 for ; Tue, 3 Dec 2013 05:14:16 -0800 (PST) Received: from unknown [144.160.229.23] (EHLO nbfkord-smmo06.seg.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 629dd925.6190b940.3688275.00-537.10363386.nbfkord-smmo06.seg.att.com (envelope-from ); Tue, 03 Dec 2013 13:14:14 +0000 (UTC) X-MXL-Hash: 529dd92620858d63-1d213e08635f1a04f65cf5766bf4ffb389588980 Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 229dd925.0.3688260.00-360.10363339.nbfkord-smmo06.seg.att.com (envelope-from ); Tue, 03 Dec 2013 13:14:12 +0000 (UTC) X-MXL-Hash: 529dd92466290ec7-fe680856a32a8a36e440b01e83466420e8b76501 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id rB3DEAdi020529; Tue, 3 Dec 2013 08:14:10 -0500 Received: from alpi133.aldc.att.com (alpi133.aldc.att.com [130.8.217.3]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id rB3DE00A020481 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Dec 2013 08:14:04 -0500 Received: from GAALPA1MSGHUB9C.ITServices.sbc.com (GAALPA1MSGHUB9C.itservices.sbc.com [130.8.36.89]) by alpi133.aldc.att.com (RSA Interceptor); Tue, 3 Dec 2013 13:13:43 GMT Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9C.ITServices.sbc.com ([130.8.36.89]) with mapi id 14.03.0158.001; Tue, 3 Dec 2013 08:13:43 -0500 From: "STARK, BARBARA H" To: "philip.eardley@bt.com" , "j.schoenwaelder@jacobs-university.de" Thread-Topic: Information Model suggested modifications Thread-Index: AQHO8AuJOrtyT7pz5U+XjDa867vLEZpCcRNQ Date: Tue, 3 Dec 2013 13:13:42 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E611303ADD87@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <20131202190341.GB3557@elstar.local> <20131203091547.GA69772@elstar.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.61.166.223] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] X-AnalysisOut: [v=2.0 cv=cZ5lWA/M c=1 sm=0 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=9mdsuHC9YlkA:10 a=ofMgfj31e3cA:10 a=PCRoD-sj21sA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=7XtTEoISamoA:10 a=Gl6bNPki3zo_5ltZiysA:9 a=CjuIK1] X-AnalysisOut: [q_8ugA:10] Cc: "marcelo@it.uc3m.es" , "trevor.burbridge@bt.com" , "lmap@ietf.org" Subject: Re: [lmap] Information Model suggested modifications X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 13:14:19 -0000 > The Controller may want a MA to run the same Measurement Task > indefinitely (for example, "run the 'upload speed' Measurement Task once > an hour until further notice"). To avoid the MA generating traffic foreve= r > after a Controller has permanently failed, it is suggested that the > Measurement Schedule includes a time limit ("run the 'upload speed' > Measurement Task once an hour for the next 30 days") and that the > Measurement Schedule is updated regularly (say, every 10 days). >=20 > Does this work? So, sort of a Measurement Task Lifetime, similar to lifetimes of IP address= es and such? The Controller could set the lifetime of a measurement task, and then reset= the lifetime once it has passed its half-life. The MA would immediately start decrementing the lifetime once it's set. MA operators would be free to determine what they think the right lifetime = is, just like for DHCP address lifetimes and RA prefix lifetimes. Barbara From trevor.burbridge@bt.com Tue Dec 3 07:00:49 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 262FE1AE164 for ; Tue, 3 Dec 2013 07:00:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FYvMmC47_VCU for ; Tue, 3 Dec 2013 07:00:47 -0800 (PST) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id 719271ADFA2 for ; Tue, 3 Dec 2013 07:00:47 -0800 (PST) Received: from EVMHT68-UKRD.domain1.systemhost.net (10.36.3.105) by RDW083A006ED62.bt.com (10.187.98.11) with Microsoft SMTP Server (TLS) id 14.3.169.1; Tue, 3 Dec 2013 15:00:44 +0000 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.1.248]) by EVMHT68-UKRD.domain1.systemhost.net ([10.36.3.105]) with mapi; Tue, 3 Dec 2013 15:00:43 +0000 From: To: , , Date: Tue, 3 Dec 2013 15:00:41 +0000 Thread-Topic: Information Model suggested modifications Thread-Index: AQHO8AuJOrtyT7pz5U+XjDa867vLEZpCcRNQgAAcmGA= Message-ID: References: <20131202190341.GB3557@elstar.local> <20131203091547.GA69772@elstar.local> <2D09D61DDFA73D4C884805CC7865E611303ADD87@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E611303ADD87@GAALPA1MSGUSR9L.ITServices.sbc.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: marcelo@it.uc3m.es, lmap@ietf.org Subject: Re: [lmap] Information Model suggested modifications X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 15:00:49 -0000 >-----Original Message----- >From: STARK, BARBARA H [mailto:bs7652@att.com] >Sent: 03 December 2013 13:14 >To: Eardley,PL,Philip,TUB8 R; j.schoenwaelder@jacobs-university.de >Cc: marcelo@it.uc3m.es; Burbridge,T,Trevor,TUB8 R; lmap@ietf.org >Subject: RE: Information Model suggested modifications > >> The Controller may want a MA to run the same Measurement Task >> indefinitely (for example, "run the 'upload speed' Measurement Task once >> an hour until further notice"). To avoid the MA generating traffic forev= er >> after a Controller has permanently failed, it is suggested that the >> Measurement Schedule includes a time limit ("run the 'upload speed' >> Measurement Task once an hour for the next 30 days") and that the >> Measurement Schedule is updated regularly (say, every 10 days). >> >> Does this work? > >So, sort of a Measurement Task Lifetime, similar to lifetimes of IP addres= ses and >such? >The Controller could set the lifetime of a measurement task, and then rese= t the >lifetime once it has passed its half-life. >The MA would immediately start decrementing the lifetime once it's set. >MA operators would be free to determine what they think the right lifetime= is, >just like for DHCP address lifetimes and RA prefix lifetimes. The information model already has a start and end date/time for each schedu= le, so the change would be simply recommending this approach as general pra= ctice. I think it's probably still worth leaving the end date/time as optio= nal for those who have small measurement systems and want to ignore best pr= actice. I'm not sure that stopping testing when the MA can't get connectivity is re= ally the requirement though. Maybe the more precise requirement is whether = the MA has a fail-over Controller and how this is done? Should we add an op= tional secondary Controller into the Information Model and specify the fail= -over mechanism in the Framework? >Barbara Trevor. From j.schoenwaelder@jacobs-university.de Tue Dec 3 07:09:20 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F4461AE175 for ; Tue, 3 Dec 2013 07:09:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hNoHtUncOOR4 for ; Tue, 3 Dec 2013 07:09:17 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id BDF5A1AE025 for ; Tue, 3 Dec 2013 07:09:17 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id E026C2006F; Tue, 3 Dec 2013 16:09:14 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id IPdcpwtCG04X; Tue, 3 Dec 2013 16:09:14 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 507E82006D; Tue, 3 Dec 2013 16:09:14 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id CB4BA29CD3ED; Tue, 3 Dec 2013 16:09:09 +0100 (CET) Date: Tue, 3 Dec 2013 16:09:09 +0100 From: Juergen Schoenwaelder To: trevor.burbridge@bt.com Message-ID: <20131203150909.GA71692@elstar.local> Mail-Followup-To: trevor.burbridge@bt.com, bs7652@att.com, philip.eardley@bt.com, marcelo@it.uc3m.es, lmap@ietf.org References: <20131202190341.GB3557@elstar.local> <20131203091547.GA69772@elstar.local> <2D09D61DDFA73D4C884805CC7865E611303ADD87@GAALPA1MSGUSR9L.ITServices.sbc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: marcelo@it.uc3m.es, philip.eardley@bt.com, bs7652@att.com, lmap@ietf.org Subject: Re: [lmap] Information Model suggested modifications X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 15:09:20 -0000 On Tue, Dec 03, 2013 at 03:00:41PM +0000, trevor.burbridge@bt.com wrote: > > The information model already has a start and end date/time for each schedule, so the change would be simply recommending this approach as general practice. I think it's probably still worth leaving the end date/time as optional for those who have small measurement systems and want to ignore best practice. > > I'm not sure that stopping testing when the MA can't get connectivity is really the requirement though. Maybe the more precise requirement is whether the MA has a fail-over Controller and how this is done? Should we add an optional secondary Controller into the Information Model and specify the fail-over mechanism in the Framework? > A fail-over only helps if there is something to fail-over to. For example, if the owner of the measurement infrastructures goes bankrupt, what is going to happen with the deployed probes? This is not a fail-over situation and one would hope that the probes stop at some time to do measurements (and we won't have to wait until the results have eaten up all storage and the box hosting the MA simply fails badly because of resource shortage; sure well implemented MAs will never do this. ;-). Back to fail-over: There are many tricks you can do if the controller is identified by a URI to provide controller service. I am not sure yet fail-over is something we have to engineer into LMAP 1.0. (Lets keep it simple and ship early.) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From bs7652@att.com Tue Dec 3 07:12:23 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1607C1AE158 for ; Tue, 3 Dec 2013 07:12:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id olsHHv93-cx7 for ; Tue, 3 Dec 2013 07:12:21 -0800 (PST) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 5E41B1AE152 for ; Tue, 3 Dec 2013 07:12:21 -0800 (PST) Received: from unknown [144.160.229.23] (EHLO nbfkord-smmo05.seg.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 3d4fd925.5a89d940.3755555.00-590.10562811.nbfkord-smmo05.seg.att.com (envelope-from ); Tue, 03 Dec 2013 15:12:19 +0000 (UTC) X-MXL-Hash: 529df4d3759ebc9b-f540c7d394fb311f29e75cc28b17b80bede0c48e Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id fc4fd925.0.3755507.00-454.10562660.nbfkord-smmo05.seg.att.com (envelope-from ); Tue, 03 Dec 2013 15:12:17 +0000 (UTC) X-MXL-Hash: 529df4d14487d7b4-83d2f3279c39c55c99c32e5b45d8fd0c29f444bb Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id rB3FCEUw005486; Tue, 3 Dec 2013 10:12:15 -0500 Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id rB3FC6NZ005403 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Dec 2013 10:12:11 -0500 Received: from GAALPA1MSGHUB9E.ITServices.sbc.com (GAALPA1MSGHUB9E.itservices.sbc.com [130.8.36.91]) by alpi132.aldc.att.com (RSA Interceptor); Tue, 3 Dec 2013 15:11:54 GMT Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9E.ITServices.sbc.com ([130.8.36.91]) with mapi id 14.03.0158.001; Tue, 3 Dec 2013 10:11:54 -0500 From: "STARK, BARBARA H" To: "trevor.burbridge@bt.com" , "philip.eardley@bt.com" , "j.schoenwaelder@jacobs-university.de" Thread-Topic: Information Model suggested modifications Thread-Index: AQHO8AuJOrtyT7pz5U+XjDa867vLEZpCcRNQgAAcmGCAAAPcsA== Date: Tue, 3 Dec 2013 15:11:53 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E611303ADF18@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <20131202190341.GB3557@elstar.local> <20131203091547.GA69772@elstar.local> <2D09D61DDFA73D4C884805CC7865E611303ADD87@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.61.166.223] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] X-AnalysisOut: [v=2.0 cv=QpHpKyOd c=1 sm=0 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=9mdsuHC9YlkA:10 a=ofMgfj31e3cA:10 a=PCRoD-sj21sA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=7XtTEoISamoA:10 a=rh6BzlGJ_S8jO4SC95UA:9 a=CjuIK1] X-AnalysisOut: [q_8ugA:10] Cc: "marcelo@it.uc3m.es" , "lmap@ietf.org" Subject: Re: [lmap] Information Model suggested modifications X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 15:12:23 -0000 > I'm not sure that stopping testing when the MA can't get connectivity is = really > the requirement though. Maybe the more precise requirement is whether > the MA has a fail-over Controller and how this is done? Should we add an > optional secondary Controller into the Information Model and specify the > fail-over mechanism in the Framework? I would prefer not to have a fail-over Controller. There are plenty of ways= to deal with fail-over in the network, such as using DNS SRV records for t= he Controller URL. Having multiple configured URLs within lots of devices i= s much less flexible than DNS SRV. Other DNS records can also be used. Fail-over should be centrally managed, and not done at the extremities (at = the MAs). IMO. Barbara From bertietf@bwijnen.net Tue Dec 3 07:20:27 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEECB1AE041 for ; Tue, 3 Dec 2013 07:20:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id krYl7j17qfAp for ; Tue, 3 Dec 2013 07:20:26 -0800 (PST) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id 2D1C81AE042 for ; Tue, 3 Dec 2013 07:20:25 -0800 (PST) Received: from titi.ripe.net ([193.0.23.11]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Vnrls-0006dL-Ih; Tue, 03 Dec 2013 16:20:22 +0100 Received: from kitten.ripe.net ([193.0.1.240] helo=guest182.guestnet.ripe.net) by titi.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1Vnrlr-00041p-HP; Tue, 03 Dec 2013 16:20:19 +0100 Message-ID: <529DF6B3.8050007@bwijnen.net> Date: Tue, 03 Dec 2013 16:20:19 +0100 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: trevor.burbridge@bt.com, bs7652@att.com, philip.eardley@bt.com, marcelo@it.uc3m.es, lmap@ietf.org References: <20131202190341.GB3557@elstar.local> <20131203091547.GA69772@elstar.local> <2D09D61DDFA73D4C884805CC7865E611303ADD87@GAALPA1MSGUSR9L.ITServices.sbc.com> <20131203150909.GA71692@elstar.local> In-Reply-To: <20131203150909.GA71692@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816575, check: 20131203 clean X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4d103c7ac64e380f9538f7b86e1f25761 Subject: Re: [lmap] Information Model suggested modifications X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 15:20:27 -0000 I believe that the RIPE-Atlas probes cease to do measurements if they loose connectivity with the RIPE-Atlas infrastructure for a prolonged time. If needed, I can try to get the details posted. Bert On 12/3/13 4:09 PM, Juergen Schoenwaelder wrote: > For example, if the owner of the measurement infrastructures goes > bankrupt, what is going to happen with the deployed probes? This is > not a fail-over situation and one would hope that the probes stop at > some time to do measurements (and we won't have to wait until the > results have eaten up all storage and the box hosting the MA simply > fails badly because of resource shortage; sure well implemented MAs > will never do this.;-). From j.schoenwaelder@jacobs-university.de Tue Dec 3 08:23:48 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 888681A1F65 for ; Tue, 3 Dec 2013 08:23:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yb8KB6wlRUMl for ; Tue, 3 Dec 2013 08:23:46 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id E6E671A1F62 for ; Tue, 3 Dec 2013 08:23:45 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 11C582005B; Tue, 3 Dec 2013 17:23:43 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id vo5GBpJjOJc2; Tue, 3 Dec 2013 17:23:42 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4A71920057; Tue, 3 Dec 2013 17:23:42 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id C44B029CD9B4; Tue, 3 Dec 2013 17:23:37 +0100 (CET) Date: Tue, 3 Dec 2013 17:23:37 +0100 From: Juergen Schoenwaelder To: "Bert Wijnen (IETF)" Message-ID: <20131203162337.GC71914@elstar.local> Mail-Followup-To: "Bert Wijnen (IETF)" , trevor.burbridge@bt.com, bs7652@att.com, philip.eardley@bt.com, marcelo@it.uc3m.es, lmap@ietf.org References: <20131202190341.GB3557@elstar.local> <20131203091547.GA69772@elstar.local> <2D09D61DDFA73D4C884805CC7865E611303ADD87@GAALPA1MSGUSR9L.ITServices.sbc.com> <20131203150909.GA71692@elstar.local> <529DF6B3.8050007@bwijnen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <529DF6B3.8050007@bwijnen.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: marcelo@it.uc3m.es, trevor.burbridge@bt.com, bs7652@att.com, philip.eardley@bt.com, lmap@ietf.org Subject: Re: [lmap] Information Model suggested modifications X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 16:23:48 -0000 Hi, it is always nice to know what existing implementations actually do. If deployed systems do not periodically rewrite the schedule in order to handle this corner case but instead use a different mechanism to stop probes that are loosing connectivity for a longer time, then there might be something to learn from. /js On Tue, Dec 03, 2013 at 04:20:19PM +0100, Bert Wijnen (IETF) wrote: > I believe that the RIPE-Atlas probes cease to do measurements if they loose > connectivity with the RIPE-Atlas infrastructure for a prolonged time. > > If needed, I can try to get the details posted. > > Bert > > On 12/3/13 4:09 PM, Juergen Schoenwaelder wrote: > >For example, if the owner of the measurement infrastructures goes > >bankrupt, what is going to happen with the deployed probes? This is > >not a fail-over situation and one would hope that the probes stop at > >some time to do measurements (and we won't have to wait until the > >results have eaten up all storage and the box hosting the MA simply > >fails badly because of resource shortage; sure well implemented MAs > >will never do this.;-). > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From sharam.hakimi@exfo.com Tue Dec 3 10:45:23 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26DFD1AD7C5 for ; Tue, 3 Dec 2013 10:45:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_32=0.6, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bi70r5fNbFWH for ; Tue, 3 Dec 2013 10:45:21 -0800 (PST) Received: from smtpinqc.exfo.com (smtpinqc.exfo.com [206.162.164.97]) by ietfa.amsl.com (Postfix) with ESMTP id 274051AD6A4 for ; Tue, 3 Dec 2013 10:45:20 -0800 (PST) Received: from spqcexc04.exfo.com ([172.16.48.171]) by smtpinqc.exfo.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Dec 2013 13:45:17 -0500 Received: from spboexc01.exfo.com ([10.10.10.16]) by spqcexc04.exfo.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Dec 2013 13:45:17 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 3 Dec 2013 13:45:28 -0500 Message-ID: <084CDC75FEC1E640B60338273BEACDFA029B1D02@spboexc01.exfo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lmap] Information Model suggested modifications Thread-Index: Ac7wRA2FokvbR3f8R1+vwCz+eUv/6gAEqwYw References: <20131202190341.GB3557@elstar.local> <20131203091547.GA69772@elstar.local> <2D09D61DDFA73D4C884805CC7865E611303ADD87@GAALPA1MSGUSR9L.ITServices.sbc.com> <20131203150909.GA71692@elstar.local> <529DF6B3.8050007@bwijnen.net> <20131203162337.GC71914@elstar.local> From: "Sharam Hakimi" To: , "Juergen Schoenwaelder" , "Bert Wijnen \(IETF\)" X-OriginalArrivalTime: 03 Dec 2013 18:45:17.0182 (UTC) FILETIME=[CF5861E0:01CEF057] Cc: marcelo@it.uc3m.es, trevor.burbridge@bt.com, bs7652@att.com, philip.eardley@bt.com, lmap@ietf.org Subject: Re: [lmap] Information Model suggested modifications X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 18:45:23 -0000 A failover controller would be a nice to have but it gets complicated. A simple hello message sent from the MC to the MAs once a day(or any other agreed time period) would let the MAs know that the Controller is alive. For example if the MA misses 3 hello messages then it would stop it testing operation until it establishes connection with the MC. Sharam=20 -----Original Message----- From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder Sent: Tuesday, December 03, 2013 11:24 AM To: Bert Wijnen (IETF) Cc: marcelo@it.uc3m.es; trevor.burbridge@bt.com; bs7652@att.com; philip.eardley@bt.com; lmap@ietf.org Subject: Re: [lmap] Information Model suggested modifications Hi, it is always nice to know what existing implementations actually do. If deployed systems do not periodically rewrite the schedule in order to handle this corner case but instead use a different mechanism to stop probes that are loosing connectivity for a longer time, then there might be something to learn from. /js On Tue, Dec 03, 2013 at 04:20:19PM +0100, Bert Wijnen (IETF) wrote: > I believe that the RIPE-Atlas probes cease to do measurements if they loose > connectivity with the RIPE-Atlas infrastructure for a prolonged time. >=20 > If needed, I can try to get the details posted. >=20 > Bert >=20 > On 12/3/13 4:09 PM, Juergen Schoenwaelder wrote: > >For example, if the owner of the measurement infrastructures goes > >bankrupt, what is going to happen with the deployed probes? This is > >not a fail-over situation and one would hope that the probes stop at > >some time to do measurements (and we won't have to wait until the > >results have eaten up all storage and the box hosting the MA simply > >fails badly because of resource shortage; sure well implemented MAs > >will never do this.;-). > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap From gregimirsky@gmail.com Tue Dec 3 15:39:09 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BC211ADFB9 for ; Tue, 3 Dec 2013 15:39:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MyV_gzfcAnM8 for ; Tue, 3 Dec 2013 15:39:05 -0800 (PST) Received: from mail-ve0-x236.google.com (mail-ve0-x236.google.com [IPv6:2607:f8b0:400c:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id B94FF1ADFB2 for ; Tue, 3 Dec 2013 15:39:05 -0800 (PST) Received: by mail-ve0-f182.google.com with SMTP id jy13so11422014veb.27 for ; Tue, 03 Dec 2013 15:39:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=eMBXJmPUTjdvdCbdRafRqYwLawYZc8vJYSvAVaDETcM=; b=xc0bn+Gr8urg/TcGfHOR5G1JLGXqb+Qgh4RoYYPnkz12w62n2Jdgu3jXzeG/LupjxL LXByVc9oS8ogbz7C+7+lXirf6pZV9PZsgW1mFogDvKRn9Y5kgCABv64p9/CS+dm6dlDf gqH3BVIksWLUSOJogQNQXuAMDFJtW/59HLsFx8igAj2hqXtpyGnDy48o2d/T6upgd69o bDr5gNUNxJW+GEnmIWSnz9c7n0EW0FAYDJEV9/spciTFWpRZCsYViLlgBNiaBp27jSiV rTXOGswmqtozcfxKUhp9c38oofGEW4dN3NIGNZ65N+tnbthV1uLQlp25HXd/3k7vsGO5 QIHA== MIME-Version: 1.0 X-Received: by 10.220.47.10 with SMTP id l10mr4537vcf.32.1386113942657; Tue, 03 Dec 2013 15:39:02 -0800 (PST) Received: by 10.220.159.143 with HTTP; Tue, 3 Dec 2013 15:39:02 -0800 (PST) Date: Tue, 3 Dec 2013 15:39:02 -0800 Message-ID: From: Greg Mirsky To: lmap@ietf.org Content-Type: multipart/alternative; boundary=001a11c2a58c2bd26304eca9cd29 Subject: [lmap] What is proper track for draft-ietf-lmap-framework- X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 23:39:09 -0000 --001a11c2a58c2bd26304eca9cd29 Content-Type: text/plain; charset=ISO-8859-1 Dear All, the current version of the framework is on Standard track. I'm not sure if this is the intention of the WG as the document doesn't have reference to RFC 2119, nor uses distinctive normative language. I think that Informational track for a framework and/or architecture document is common IETF practice. Perhaps it can be changed in the next revision. Regards, Greg --001a11c2a58c2bd26304eca9cd29 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear All,
the current version of t= he framework is on Standard track. I'm not sure if this is the intentio= n of the WG as the document doesn't have reference to RFC 2119, nor use= s distinctive normative language. I think that Informational track for a fr= amework and/or architecture document is common IETF practice. Perhaps it ca= n be changed in the next revision.

Regards,
Greg
--001a11c2a58c2bd26304eca9cd29-- From philip.eardley@bt.com Wed Dec 4 01:48:58 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C8DE1AE047 for ; Wed, 4 Dec 2013 01:48:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LeSJv5mB-uiD for ; Wed, 4 Dec 2013 01:48:56 -0800 (PST) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.234]) by ietfa.amsl.com (Postfix) with ESMTP id D069A1ADFCC for ; Wed, 4 Dec 2013 01:48:55 -0800 (PST) Received: from EVMHT65-UKRD.domain1.systemhost.net (10.36.3.102) by RDW083A005ED61.bt.com (10.187.98.10) with Microsoft SMTP Server (TLS) id 14.3.169.1; Wed, 4 Dec 2013 09:48:57 +0000 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.1.152]) by EVMHT65-UKRD.domain1.systemhost.net ([10.36.3.102]) with mapi; Wed, 4 Dec 2013 09:48:51 +0000 From: To: , Date: Wed, 4 Dec 2013 09:48:50 +0000 Thread-Topic: [lmap] What is proper track for draft-ietf-lmap-framework- Thread-Index: Ac7wgOBIwHxunp+8TSeTe9RrA0WaYgAVR6iw Message-ID: References: In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_A2E337CDB7BC4145B018B9BEE8EB3E0D403B78D3CAEMV67UKRDdoma_" MIME-Version: 1.0 Subject: Re: [lmap] What is proper track for draft-ietf-lmap-framework- X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 09:48:58 -0000 --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D403B78D3CAEMV67UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think it was supposed to be Info. Thanks for spotting! From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Greg Mirsky Sent: 03 December 2013 23:39 To: lmap@ietf.org Subject: [lmap] What is proper track for draft-ietf-lmap-framework- Dear All, the current version of the framework is on Standard track. I'm not sure if = this is the intention of the WG as the document doesn't have reference to R= FC 2119, nor uses distinctive normative language. I think that Informationa= l track for a framework and/or architecture document is common IETF practic= e. Perhaps it can be changed in the next revision. Regards, Greg --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D403B78D3CAEMV67UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I think it was supposed to be I= nfo. Thanks for spotting!

 

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Greg Mirsky
<= b>Sent: 03 December 2013 23:39
To: lmap@ietf.org
Subjec= t: [lmap] What is proper track for draft-ietf-lmap-framework-

 

Dear All,

the current version of the framework= is on Standard track. I'm not sure if this is the intention of the WG as t= he document doesn't have reference to RFC 2119, nor uses distinctive normat= ive language. I think that Informational track for a framework and/or archi= tecture document is common IETF practice. Perhaps it can be changed in the = next revision.

Regards,=

Greg

= = --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D403B78D3CAEMV67UKRDdoma_-- From internet-drafts@ietf.org Wed Dec 4 12:47:54 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9A4E1AE2EA; Wed, 4 Dec 2013 12:47:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RK_OiWchaYHi; Wed, 4 Dec 2013 12:47:53 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 062681AE1AA; Wed, 4 Dec 2013 12:47:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131204204753.2562.94661.idtracker@ietfa.amsl.com> Date: Wed, 04 Dec 2013 12:47:53 -0800 Cc: lmap@ietf.org Subject: [lmap] I-D Action: draft-ietf-lmap-use-cases-01.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 20:47:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Large-Scale Measurement of Broadband Perf= ormance Working Group of the IETF. Title : Large-Scale Broadband Measurement Use Cases Author(s) : Marc Linsner Philip Eardley Trevor Burbridge Frode Sorensen Filename : draft-ietf-lmap-use-cases-01.txt Pages : 17 Date : 2013-12-04 Abstract: Measuring broadband performance on a large scale is important for network diagnostics by providers and users, as well for as public policy. To conduct such measurements, user networks gather data, either on their own initiative or instructed by a measurement controller, and then upload the measurement results to a designated measurement server. Understanding the various scenarios and users of measuring broadband performance is essential to development of the system requirements. The details of the measurement metrics themselves are beyond the scope of this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lmap-use-cases There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-lmap-use-cases-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lmap-use-cases-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From mlinsner@cisco.com Wed Dec 4 12:57:38 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFABB1ACCDC for ; Wed, 4 Dec 2013 12:57:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tnKRHH37bVoZ for ; Wed, 4 Dec 2013 12:57:36 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 675061ACC88 for ; Wed, 4 Dec 2013 12:57:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1716; q=dns/txt; s=iport; t=1386190653; x=1387400253; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=3A8pGUY14swC2jGhELfeQlpZGxWyFHyPpO9ZiKd1IsU=; b=WSXiXk96O6P+BV4kZqmqgFrsHUrdBTiaHIHs0JQPK5LDHztaSJ8y1t/2 TmIPdCJLfAss2BWtCPRr4TGZLSphrVSbxxUG9bbw+FiYpz7dgLKu5t4ib xXdA6wVgTv0CKTnki8rrirGL5lnsdG2KXLV/bcuXixA/3ZEGy5cVSJ33Q g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4GAB6Wn1KtJV2c/2dsb2JhbABZgwc4TQa4ZIEkFm0HgiUBAgR3FAEIeBsBBgMCBByHeQgFolWfO48FhDMDiQqPCoEwkGODKYIq X-IronPort-AV: E=Sophos;i="4.93,827,1378857600"; d="scan'208";a="286415936" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-9.cisco.com with ESMTP; 04 Dec 2013 20:57:33 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id rB4KvXaa001468 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 4 Dec 2013 20:57:33 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.25]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Wed, 4 Dec 2013 14:57:32 -0600 From: "Marc Linsner (mlinsner)" To: "lmap@ietf.org" Thread-Topic: New Version Notification for draft-ietf-lmap-use-cases-01.txt Thread-Index: AQHO8TIbE0kULgSp+EGTKNDDYTOl9ZpElUKA Date: Wed, 4 Dec 2013 20:57:31 +0000 Message-ID: In-Reply-To: <20131204204753.2562.46021.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.195.121] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <51A03B3D62A99E4390E2D011CA901F4A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [lmap] FW: New Version Notification for draft-ietf-lmap-use-cases-01.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 20:57:39 -0000 All, We updated the Use Case draft, hopefully we=B9ve addressed all concerns to date. Please review and send comments to the list. Thanks, Marc, Philip, Trevor, and Frode > >A new version of I-D, draft-ietf-lmap-use-cases-01.txt >has been successfully submitted by Marc Linsner and posted to the >IETF repository. > >Filename: draft-ietf-lmap-use-cases >Revision: 01 >Title: Large-Scale Broadband Measurement Use Cases >Creation date: 2013-12-04 >Group: lmap >Number of pages: 17 >URL: =20 >http://www.ietf.org/internet-drafts/draft-ietf-lmap-use-cases-01.txt >Status: http://datatracker.ietf.org/doc/draft-ietf-lmap-use-cases >Htmlized: http://tools.ietf.org/html/draft-ietf-lmap-use-cases-01 >Diff: =20 >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lmap-use-cases-01 > >Abstract: > Measuring broadband performance on a large scale is important for > network diagnostics by providers and users, as well for as public > policy. To conduct such measurements, user networks gather data, > either on their own initiative or instructed by a measurement > controller, and then upload the measurement results to a designated > measurement server. Understanding the various scenarios and users of > measuring broadband performance is essential to development of the > system requirements. The details of the measurement metrics > themselves are beyond the scope of this document. > > > =20 > =20 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >The IETF Secretariat > From jason.weil@twcable.com Thu Dec 5 06:39:27 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 366981AE029 for ; Thu, 5 Dec 2013 06:39:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.234 X-Spam-Level: X-Spam-Status: No, score=0.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y6H0RMCZcLSo for ; Thu, 5 Dec 2013 06:39:25 -0800 (PST) Received: from cdcipgw01.twcable.com (cdcipgw01.twcable.com [165.237.91.110]) by ietfa.amsl.com (Postfix) with ESMTP id AF3B41AE044 for ; Thu, 5 Dec 2013 06:39:21 -0800 (PST) X-SENDER-IP: 10.136.163.12 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.93,833,1378872000"; d="scan'208";a="58857444" Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdcipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 05 Dec 2013 09:38:49 -0500 Received: from PRVPEXVS17.corp.twcable.com ([10.136.163.96]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Thu, 5 Dec 2013 09:39:17 -0500 From: "Weil, Jason" To: "Bert Wijnen (IETF)" , "trevor.burbridge@bt.com" , "bs7652@att.com" , "philip.eardley@bt.com" , "marcelo@it.uc3m.es" , "lmap@ietf.org" Date: Thu, 5 Dec 2013 09:39:15 -0500 Thread-Topic: [lmap] Information Model suggested modifications Thread-Index: Ac7xx8Yfj9ogupjCT6iAf39UCy02ug== Message-ID: In-Reply-To: <529DF6B3.8050007@bwijnen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [lmap] Information Model suggested modifications X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 14:39:27 -0000 /Chair hat off Personally I prefer this approach. I would think an MA should check in with the Controller at some time interval (interval could be provided by the controller along with some number of retry attempts) for a health check. If a Controller goes away for whatever reason and it is responsible for controlling 250,000 probes, it would be nice for those probes to stop performing their assigned tasks until the Controller returns. Jason On 12/3/13 10:20 AM, "Bert Wijnen (IETF)" wrote: >I believe that the RIPE-Atlas probes cease to do measurements if they >loose >connectivity with the RIPE-Atlas infrastructure for a prolonged time. > >If needed, I can try to get the details posted. > >Bert > >On 12/3/13 4:09 PM, Juergen Schoenwaelder wrote: >> For example, if the owner of the measurement infrastructures goes >> bankrupt, what is going to happen with the deployed probes? This is >> not a fail-over situation and one would hope that the probes stop at >> some time to do measurements (and we won't have to wait until the >> results have eaten up all storage and the box hosting the MA simply >> fails badly because of resource shortage; sure well implemented MAs >> will never do this.;-). >_______________________________________________ >lmap mailing list >lmap@ietf.org >https://www.ietf.org/mailman/listinfo/lmap This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From Michael.K.Bugenhagen@centurylink.com Thu Dec 5 07:04:29 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89E6D1AE05C for ; Thu, 5 Dec 2013 07:04:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xiZPjlZeiomA for ; Thu, 5 Dec 2013 07:04:27 -0800 (PST) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by ietfa.amsl.com (Postfix) with ESMTP id 9BCD91AE036 for ; Thu, 5 Dec 2013 07:04:27 -0800 (PST) Received: from lxomavmpc030.qintra.com (emailout.qintra.com [151.117.207.30]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id rB5F4FcA017033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Dec 2013 09:04:15 -0600 (CST) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id E63FE1E0065; Thu, 5 Dec 2013 09:04:09 -0600 (CST) Received: from suomp61i.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id CCFAC1E0098; Thu, 5 Dec 2013 09:04:09 -0600 (CST) Received: from suomp61i.qintra.com (localhost [127.0.0.1]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id rB5F49R0024904; Thu, 5 Dec 2013 09:04:09 -0600 (CST) Received: from vodcwhubex502.ctl.intranet (vodcwhubex502.ctl.intranet [151.117.206.28]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id rB5F49VZ024886 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Dec 2013 09:04:09 -0600 (CST) Received: from PODCWMBXEX505.ctl.intranet ([fe80::f87e:fe44:ad72:b610]) by vodcwhubex502.ctl.intranet ([2002:9775:ce1c::9775:ce1c]) with mapi id 14.03.0158.001; Thu, 5 Dec 2013 09:04:08 -0600 From: "Bugenhagen, Michael K" To: "'Weil, Jason'" , "'Bert Wijnen (IETF)'" , "'trevor.burbridge@bt.com'" , "'bs7652@att.com'" , "'philip.eardley@bt.com'" , "'marcelo@it.uc3m.es'" , "'lmap@ietf.org'" Thread-Topic: [lmap] Information Model suggested modifications Thread-Index: AQHO8AuGLRP3frjunku9IlNF29ZjFppC13cAgAAd5ICAAAJegIAAAx+AgAMZMID//6IwIA== Date: Thu, 5 Dec 2013 15:04:07 +0000 Message-ID: References: <529DF6B3.8050007@bwijnen.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.8] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [lmap] Information Model suggested modifications X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 15:04:29 -0000 What happens if the collector isn't available ... ?? Same behavior? -----Original Message----- From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Weil, Jason Sent: Thursday, December 05, 2013 8:39 AM To: Bert Wijnen (IETF); trevor.burbridge@bt.com; bs7652@att.com; philip.ear= dley@bt.com; marcelo@it.uc3m.es; lmap@ietf.org Subject: Re: [lmap] Information Model suggested modifications /Chair hat off Personally I prefer this approach. I would think an MA should check in with= the Controller at some time interval (interval could be provided by the co= ntroller along with some number of retry attempts) for a health check. If a= Controller goes away for whatever reason and it is responsible for control= ling 250,000 probes, it would be nice for those probes to stop performing t= heir assigned tasks until the Controller returns. Jason On 12/3/13 10:20 AM, "Bert Wijnen (IETF)" wrote: >I believe that the RIPE-Atlas probes cease to do measurements if they=20 >loose connectivity with the RIPE-Atlas infrastructure for a prolonged=20 >time. > >If needed, I can try to get the details posted. > >Bert > >On 12/3/13 4:09 PM, Juergen Schoenwaelder wrote: >> For example, if the owner of the measurement infrastructures goes=20 >> bankrupt, what is going to happen with the deployed probes? This is=20 >> not a fail-over situation and one would hope that the probes stop at=20 >> some time to do measurements (and we won't have to wait until the=20 >> results have eaten up all storage and the box hosting the MA simply=20 >> fails badly because of resource shortage; sure well implemented MAs=20 >> will never do this.;-). >_______________________________________________ >lmap mailing list >lmap@ietf.org >https://www.ietf.org/mailman/listinfo/lmap This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap From jason.weil@twcable.com Thu Dec 5 08:35:24 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D32D51AE0A9 for ; Thu, 5 Dec 2013 08:35:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.234 X-Spam-Level: X-Spam-Status: No, score=0.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t_7WDQruY-1B for ; Thu, 5 Dec 2013 08:35:22 -0800 (PST) Received: from cdcipgw01.twcable.com (cdcipgw01.twcable.com [165.237.91.110]) by ietfa.amsl.com (Postfix) with ESMTP id 07C0A1AE0B3 for ; Thu, 5 Dec 2013 08:35:21 -0800 (PST) X-SENDER-IP: 10.136.163.10 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.93,834,1378872000"; d="scan'208";a="58884851" Received: from unknown (HELO PRVPEXHUB01.corp.twcable.com) ([10.136.163.10]) by cdcipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 05 Dec 2013 11:34:50 -0500 Received: from PRVPEXVS17.corp.twcable.com ([10.136.163.96]) by PRVPEXHUB01.corp.twcable.com ([10.136.163.10]) with mapi; Thu, 5 Dec 2013 11:35:17 -0500 From: "Weil, Jason" To: "Bugenhagen, Michael K" , "'Bert Wijnen (IETF)'" , "'trevor.burbridge@bt.com'" , "'bs7652@att.com'" , "'philip.eardley@bt.com'" , "'marcelo@it.uc3m.es'" , "'lmap@ietf.org'" Date: Thu, 5 Dec 2013 11:35:16 -0500 Thread-Topic: [lmap] Information Model suggested modifications Thread-Index: Ac7x1/rniFhCeS24T/eY+9z52TO8AA== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [lmap] Information Model suggested modifications X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 16:35:25 -0000 The case of an unreachable Collector seems more implementation dependent. It becomes a function of the amount of memory on the MA, the preferred reporting/collection interval, and business requirements of the measurement system. The flexibility to support varying reporting requirements should be supported. I think I need to pull back slightly from my former comment to add that the MA to Controller reachability test resulting action should be flexible as well. A test administrator may want some scheduled tests to not start when the Controller is no longer reachable and others to continue. Of course this could be solved by other means such as having the Controller provide a short test schedule for some tests (e.g. run these tests for the next 24hrs) and long or infinite duration for others and just require the MA to check back frequently (every 24hrs in the former example) to the Controller for its next test schedule. Jason On 12/5/13 10:04 AM, "Bugenhagen, Michael K" wrote: >What happens if the collector isn't available ... ?? > >Same behavior? > > > >-----Original Message----- >From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Weil, Jason >Sent: Thursday, December 05, 2013 8:39 AM >To: Bert Wijnen (IETF); trevor.burbridge@bt.com; bs7652@att.com; >philip.eardley@bt.com; marcelo@it.uc3m.es; lmap@ietf.org >Subject: Re: [lmap] Information Model suggested modifications > >/Chair hat off > >Personally I prefer this approach. I would think an MA should check in >with the Controller at some time interval (interval could be provided by >the controller along with some number of retry attempts) for a health >check. If a Controller goes away for whatever reason and it is >responsible for controlling 250,000 probes, it would be nice for those >probes to stop performing their assigned tasks until the Controller >returns. > >Jason > >On 12/3/13 10:20 AM, "Bert Wijnen (IETF)" wrote: > >>I believe that the RIPE-Atlas probes cease to do measurements if they >>loose connectivity with the RIPE-Atlas infrastructure for a prolonged >>time. >> >>If needed, I can try to get the details posted. >> >>Bert >> >>On 12/3/13 4:09 PM, Juergen Schoenwaelder wrote: >>> For example, if the owner of the measurement infrastructures goes >>> bankrupt, what is going to happen with the deployed probes? This is >>> not a fail-over situation and one would hope that the probes stop at >>> some time to do measurements (and we won't have to wait until the >>> results have eaten up all storage and the box hosting the MA simply >>> fails badly because of resource shortage; sure well implemented MAs >>> will never do this.;-). >>_______________________________________________ >>lmap mailing list >>lmap@ietf.org >>https://www.ietf.org/mailman/listinfo/lmap > > >This E-mail and any of its attachments may contain Time Warner Cable >proprietary information, which is privileged, confidential, or subject to >copyright belonging to Time Warner Cable. This E-mail is intended solely >for the use of the individual or entity to which it is addressed. If you >are not the intended recipient of this E-mail, you are hereby notified >that any dissemination, distribution, copying, or action taken in >relation to the contents of and attachments to this E-mail is strictly >prohibited and may be unlawful. If you have received this E-mail in >error, please notify the sender immediately and permanently delete the >original and any copy of this E-mail and any printout. >_______________________________________________ >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 This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From Michael.K.Bugenhagen@centurylink.com Thu Dec 5 08:49:14 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7213D1AE0C8 for ; Thu, 5 Dec 2013 08:49:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9UXEG3qjIlEJ for ; Thu, 5 Dec 2013 08:49:11 -0800 (PST) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by ietfa.amsl.com (Postfix) with ESMTP id 8805B1AE0C9 for ; Thu, 5 Dec 2013 08:49:09 -0800 (PST) Received: from lxomavmpc030.qintra.com (emailout.qintra.com [151.117.207.30]) by sudnp799.qwest.com (8.14.4/8.14.4) with ESMTP id rB5GmtfP020965 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Dec 2013 09:48:55 -0700 (MST) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 42C071E0063; Thu, 5 Dec 2013 10:48:50 -0600 (CST) Received: from suomp60i.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id 168AB1E0069; Thu, 5 Dec 2013 10:48:50 -0600 (CST) Received: from suomp60i.qintra.com (localhost [127.0.0.1]) by suomp60i.qintra.com (8.14.4/8.14.4) with ESMTP id rB5GmnWF013630; Thu, 5 Dec 2013 10:48:49 -0600 (CST) Received: from vodcwhubex501.ctl.intranet (vodcwhubex501.ctl.intranet [151.117.206.27]) by suomp60i.qintra.com (8.14.4/8.14.4) with ESMTP id rB5GmnbQ013610 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Dec 2013 10:48:49 -0600 (CST) Received: from PODCWMBXEX505.ctl.intranet ([fe80::f87e:fe44:ad72:b610]) by vodcwhubex501.ctl.intranet ([151.117.206.27]) with mapi id 14.03.0158.001; Thu, 5 Dec 2013 10:48:48 -0600 From: "Bugenhagen, Michael K" To: "'Weil, Jason'" , "'Bert Wijnen (IETF)'" , "'trevor.burbridge@bt.com'" , "'bs7652@att.com'" , "'philip.eardley@bt.com'" , "'marcelo@it.uc3m.es'" , "'lmap@ietf.org'" Thread-Topic: [lmap] Information Model suggested modifications Thread-Index: Ac7x1/rnLRP3frjunku9IlNF29ZjFgAAW1cg Date: Thu, 5 Dec 2013 16:48:48 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.8] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [lmap] Information Model suggested modifications X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 16:49:14 -0000 Given it can be difficult to audit the MA list between a Collector, and the= Controller it might be a good thing if they ever lose either connection fo= r the MA to signal the loss to the other side. So if the MA loses the Collector - it would once a day tell the Controller = it's lost collector connectivity If the MA loses the controller - it can inform the collector it's lost cont= roller connectivity This way it's easier (you have a list that can easily be generated) to comm= unicate those to the other person (assuming they are two different groups). Just an idea -=20 -----Original Message----- From: Weil, Jason [mailto:jason.weil@twcable.com]=20 Sent: Thursday, December 05, 2013 10:35 AM To: Bugenhagen, Michael K; 'Bert Wijnen (IETF)'; 'trevor.burbridge@bt.com';= 'bs7652@att.com'; 'philip.eardley@bt.com'; 'marcelo@it.uc3m.es'; 'lmap@iet= f.org' Subject: Re: [lmap] Information Model suggested modifications The case of an unreachable Collector seems more implementation dependent. It becomes a function of the amount of memory on the MA, the preferred repo= rting/collection interval, and business requirements of the measurement sys= tem. The flexibility to support varying reporting requirements should be su= pported. I think I need to pull back slightly from my former comment to add that the= MA to Controller reachability test resulting action should be flexible as = well. A test administrator may want some scheduled tests to not start when = the Controller is no longer reachable and others to continue. Of course thi= s could be solved by other means such as having the Controller provide a sh= ort test schedule for some tests (e.g. run these tests for the next 24hrs) = and long or infinite duration for others and just require the MA to check b= ack frequently (every 24hrs in the former example) to the Controller for it= s next test schedule. Jason On 12/5/13 10:04 AM, "Bugenhagen, Michael K" wrote: >What happens if the collector isn't available ... ?? > >Same behavior? > > > >-----Original Message----- >From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Weil, Jason >Sent: Thursday, December 05, 2013 8:39 AM >To: Bert Wijnen (IETF); trevor.burbridge@bt.com; bs7652@att.com;=20 >philip.eardley@bt.com; marcelo@it.uc3m.es; lmap@ietf.org >Subject: Re: [lmap] Information Model suggested modifications > >/Chair hat off > >Personally I prefer this approach. I would think an MA should check in=20 >with the Controller at some time interval (interval could be provided=20 >by the controller along with some number of retry attempts) for a=20 >health check. If a Controller goes away for whatever reason and it is=20 >responsible for controlling 250,000 probes, it would be nice for those=20 >probes to stop performing their assigned tasks until the Controller=20 >returns. > >Jason > >On 12/3/13 10:20 AM, "Bert Wijnen (IETF)" wrote: > >>I believe that the RIPE-Atlas probes cease to do measurements if they=20 >>loose connectivity with the RIPE-Atlas infrastructure for a prolonged=20 >>time. >> >>If needed, I can try to get the details posted. >> >>Bert >> >>On 12/3/13 4:09 PM, Juergen Schoenwaelder wrote: >>> For example, if the owner of the measurement infrastructures goes=20 >>> bankrupt, what is going to happen with the deployed probes? This is=20 >>> not a fail-over situation and one would hope that the probes stop at=20 >>> some time to do measurements (and we won't have to wait until the=20 >>> results have eaten up all storage and the box hosting the MA simply=20 >>> fails badly because of resource shortage; sure well implemented MAs=20 >>> will never do this.;-). >>_______________________________________________ >>lmap mailing list >>lmap@ietf.org >>https://www.ietf.org/mailman/listinfo/lmap > > >This E-mail and any of its attachments may contain Time Warner Cable=20 >proprietary information, which is privileged, confidential, or subject=20 >to copyright belonging to Time Warner Cable. This E-mail is intended=20 >solely for the use of the individual or entity to which it is=20 >addressed. If you are not the intended recipient of this E-mail, you=20 >are hereby notified that any dissemination, distribution, copying, or=20 >action taken in relation to the contents of and attachments to this=20 >E-mail is strictly prohibited and may be unlawful. If you have received=20 >this E-mail in error, please notify the sender immediately and=20 >permanently delete the original and any copy of this E-mail and any printo= ut. >_______________________________________________ >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 This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From j.schoenwaelder@jacobs-university.de Thu Dec 5 09:00:05 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B3541AE0E2 for ; Thu, 5 Dec 2013 09:00:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g4zO4ZTS8Wqq for ; Thu, 5 Dec 2013 09:00:01 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 4AE9F1AE0C8 for ; Thu, 5 Dec 2013 09:00:01 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5B3A620095; Thu, 5 Dec 2013 17:59:57 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id nMUd2nLiz-e8; Thu, 5 Dec 2013 17:59:57 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DB12A20073; Thu, 5 Dec 2013 17:59:55 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 7957F29D33EB; Thu, 5 Dec 2013 17:59:49 +0100 (CET) Date: Thu, 5 Dec 2013 17:59:48 +0100 From: Juergen Schoenwaelder To: "Weil, Jason" Message-ID: <20131205165948.GA80641@elstar.local> Mail-Followup-To: "Weil, Jason" , "Bugenhagen, Michael K" , "'Bert Wijnen (IETF)'" , "'trevor.burbridge@bt.com'" , "'bs7652@att.com'" , "'philip.eardley@bt.com'" , "'marcelo@it.uc3m.es'" , "'lmap@ietf.org'" References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "'lmap@ietf.org'" , "'trevor.burbridge@bt.com'" , "'Bert Wijnen \(IETF\)'" , "Bugenhagen, Michael K" , "'marcelo@it.uc3m.es'" , "'bs7652@att.com'" , "'philip.eardley@bt.com'" Subject: Re: [lmap] Information Model suggested modifications X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 17:00:05 -0000 Hi, somehow it feels a bit strange to send configuration updates as a keep alive mechanism. We do have a suppression mechanism because we do not want to reconfigure MAs just to suppress execution of tests for a certain (typically short) period of time. We could have solved that by configuration updates as well but we did not (and I think this feels right). Hence, I would expect that we do the same here - one could think of this as an automated suppression that gets activated once connectivity to the controller has been lost for a certain time period. Concerning the collector, if the MA can't report for a while, I assume it will discard results. Ideally the controller will notice at some time (via unspecified mechanisms) that no data is being received anymore and it can take action. If the MA looses connectivity to the controller, there however nothing anymore left to take any actions. So in this case, I believe the MA should stop all measurements. And I would keep things simple - if the MA has not managed to talk to its controller for a certain longer time, it starts to suppress all measurements. A simple 'auto suppression' parameter (set it to a week or a months - whatever is a suitable safety timeout) should be enough. /js On Thu, Dec 05, 2013 at 11:35:16AM -0500, Weil, Jason wrote: > The case of an unreachable Collector seems more implementation dependent. > It becomes a function of the amount of memory on the MA, the preferred > reporting/collection interval, and business requirements of the > measurement system. The flexibility to support varying reporting > requirements should be supported. > > I think I need to pull back slightly from my former comment to add that > the MA to Controller reachability test resulting action should be flexible > as well. A test administrator may want some scheduled tests to not start > when the Controller is no longer reachable and others to continue. Of > course this could be solved by other means such as having the Controller > provide a short test schedule for some tests (e.g. run these tests for the > next 24hrs) and long or infinite duration for others and just require the > MA to check back frequently (every 24hrs in the former example) to the > Controller for its next test schedule. > > Jason > > > > > > > > > > > > > > On 12/5/13 10:04 AM, "Bugenhagen, Michael K" > wrote: > > >What happens if the collector isn't available ... ?? > > > >Same behavior? > > > > > > > >-----Original Message----- > >From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Weil, Jason > >Sent: Thursday, December 05, 2013 8:39 AM > >To: Bert Wijnen (IETF); trevor.burbridge@bt.com; bs7652@att.com; > >philip.eardley@bt.com; marcelo@it.uc3m.es; lmap@ietf.org > >Subject: Re: [lmap] Information Model suggested modifications > > > >/Chair hat off > > > >Personally I prefer this approach. I would think an MA should check in > >with the Controller at some time interval (interval could be provided by > >the controller along with some number of retry attempts) for a health > >check. If a Controller goes away for whatever reason and it is > >responsible for controlling 250,000 probes, it would be nice for those > >probes to stop performing their assigned tasks until the Controller > >returns. > > > >Jason > > > >On 12/3/13 10:20 AM, "Bert Wijnen (IETF)" wrote: > > > >>I believe that the RIPE-Atlas probes cease to do measurements if they > >>loose connectivity with the RIPE-Atlas infrastructure for a prolonged > >>time. > >> > >>If needed, I can try to get the details posted. > >> > >>Bert > >> > >>On 12/3/13 4:09 PM, Juergen Schoenwaelder wrote: > >>> For example, if the owner of the measurement infrastructures goes > >>> bankrupt, what is going to happen with the deployed probes? This is > >>> not a fail-over situation and one would hope that the probes stop at > >>> some time to do measurements (and we won't have to wait until the > >>> results have eaten up all storage and the box hosting the MA simply > >>> fails badly because of resource shortage; sure well implemented MAs > >>> will never do this.;-). > >>_______________________________________________ > >>lmap mailing list > >>lmap@ietf.org > >>https://www.ietf.org/mailman/listinfo/lmap > > > > > >This E-mail and any of its attachments may contain Time Warner Cable > >proprietary information, which is privileged, confidential, or subject to > >copyright belonging to Time Warner Cable. This E-mail is intended solely > >for the use of the individual or entity to which it is addressed. If you > >are not the intended recipient of this E-mail, you are hereby notified > >that any dissemination, distribution, copying, or action taken in > >relation to the contents of and attachments to this E-mail is strictly > >prohibited and may be unlawful. If you have received this E-mail in > >error, please notify the sender immediately and permanently delete the > >original and any copy of this E-mail and any printout. > >_______________________________________________ > >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 > > > This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From internet-drafts@ietf.org Fri Dec 6 00:52:58 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FAD71AE2FE; Fri, 6 Dec 2013 00:52:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a2od-CTHj3zS; Fri, 6 Dec 2013 00:52:57 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F2AC91ACAD7; Fri, 6 Dec 2013 00:52:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131206085256.15796.61299.idtracker@ietfa.amsl.com> Date: Fri, 06 Dec 2013 00:52:56 -0800 Cc: lmap@ietf.org Subject: [lmap] I-D Action: draft-ietf-lmap-framework-02.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 08:52:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Large-Scale Measurement of Broadband Perf= ormance Working Group of the IETF. Title : A framework for large-scale measurement platforms (LMAP) Author(s) : Philip Eardley Al Morton Marcelo Bagnulo Trevor Burbridge Paul Aitken Aamer Akhter Filename : draft-ietf-lmap-framework-02.txt Pages : 39 Date : 2013-12-06 Abstract: Measuring broadband service on a large scale requires a description of the logical architecture and standardisation of the key protocols that coordinate interactions between the components. The document presents an overall framework for large-scale measurements. It also defines terminology for LMAP (large-scale measurement platforms). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lmap-framework There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-lmap-framework-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lmap-framework-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From philip.eardley@bt.com Fri Dec 6 00:58:00 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFE0A1AC404 for ; Fri, 6 Dec 2013 00:58:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id koBlrRxS2GSg for ; Fri, 6 Dec 2013 00:57:59 -0800 (PST) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.234]) by ietfa.amsl.com (Postfix) with ESMTP id E4D1C1AE0A8 for ; Fri, 6 Dec 2013 00:57:58 -0800 (PST) Received: from EVMHT67-UKRD.domain1.systemhost.net (10.36.3.104) by RDW083A005ED61.bt.com (10.187.98.10) with Microsoft SMTP Server (TLS) id 14.3.169.1; Fri, 6 Dec 2013 08:58:03 +0000 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.1.75]) by EVMHT67-UKRD.domain1.systemhost.net ([10.36.3.104]) with mapi; Fri, 6 Dec 2013 08:57:54 +0000 From: To: Date: Fri, 6 Dec 2013 08:57:53 +0000 Thread-Topic: New Version Notification for draft-ietf-lmap-framework-02.txt Thread-Index: Ac7yYI/IlmpYut9kQ+eq+WLfkqpwvwAAAXbw Message-ID: References: <20131206085257.15796.67939.idtracker@ietfa.amsl.com> In-Reply-To: <20131206085257.15796.67939.idtracker@ietfa.amsl.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [lmap] FW: New Version Notification for draft-ietf-lmap-framework-02.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 08:58:01 -0000 V2UgaGF2ZSB1cGRhdGVkIHRoZSBmcmFtZXdvcmsgZHJhZnQuDQoNCldlIHRyaWVkIHRvIHRha2Ug YWNjb3VudCBvZiBhbGwgdGhlIGRpc2N1c3Npb24gaW4gVmFuY291dmVyIGFuZCBtb3JlIHJlY2Vu dGx5IG9uIHRoZSBsaXN0IC0gdGhhbmtzIGZvciBhbGwgdGhlIGNvbW1lbnRzLg0KDQpQZWFzZSBj aGVjayB3ZSBoYXZlbuKAmXQgbWFuZ2xlZCBvciBmb3Jnb3R0ZW4geW91ciBjb21tZW50cywgb3Ig aWYgeW91IGhhdmUgYW55IG1vcmUuDQoNClNpbmNlIHRoZXJlJ3ZlIGJlZW4gYSBmZXcgdXBkYXRl cywgc3VnZ2VzdGlvbiBpcyB0aGF0IHdlIGRvIG9uZSBtb3JlIHF1aWNrIHJldiB0aGlzIG1vbnRo IGFuZCB0aGVuIGFzayBmb3IgV0cgbGFzdCBjYWxsLg0KDQpUaGFua3MhDQoNCmh0dHA6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbG1hcC1mcmFtZXdvcmsgDQoNCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzpp bnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogMDYgRGVjZW1iZXIgMjAxMyAwODo1Mw0K VG86IEFsIEMuTW9ydG9uOyBQYXVsIEFpdGtlbjsgQWwgTW9ydG9uOyBFYXJkbGV5LFBMLFBoaWxp cCxUVUI4IFI7IE1hcmNlbG8gQmFnbnVsbzsgQnVyYnJpZGdlLFQsVHJldm9yLFRVQjggUjsgQWFt ZXIgQWtodGVyDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWll dGYtbG1hcC1mcmFtZXdvcmstMDIudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0 LWlldGYtbG1hcC1mcmFtZXdvcmstMDIudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0 dGVkIGJ5IFBoaWxpcCBFYXJkbGV5IGFuZCBwb3N0ZWQgdG8gdGhlDQpJRVRGIHJlcG9zaXRvcnku DQoNCkZpbGVuYW1lOgkgZHJhZnQtaWV0Zi1sbWFwLWZyYW1ld29yaw0KUmV2aXNpb246CSAwMg0K VGl0bGU6CQkgQSBmcmFtZXdvcmsgZm9yIGxhcmdlLXNjYWxlIG1lYXN1cmVtZW50IHBsYXRmb3Jt cyAoTE1BUCkNCkNyZWF0aW9uIGRhdGU6CSAyMDEzLTEyLTA2DQpHcm91cDoJCSBsbWFwDQpOdW1i ZXIgb2YgcGFnZXM6IDM5DQpVUkw6ICAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50 ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtbG1hcC1mcmFtZXdvcmstMDIudHh0DQpTdGF0dXM6ICAg ICAgICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1sbWFwLWZy YW1ld29yaw0KSHRtbGl6ZWQ6ICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1pZXRmLWxtYXAtZnJhbWV3b3JrLTAyDQpEaWZmOiAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0 Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtbG1hcC1mcmFtZXdvcmstMDINCg0KQWJzdHJh Y3Q6DQogICBNZWFzdXJpbmcgYnJvYWRiYW5kIHNlcnZpY2Ugb24gYSBsYXJnZSBzY2FsZSByZXF1 aXJlcyBhIGRlc2NyaXB0aW9uDQogICBvZiB0aGUgbG9naWNhbCBhcmNoaXRlY3R1cmUgYW5kIHN0 YW5kYXJkaXNhdGlvbiBvZiB0aGUga2V5IHByb3RvY29scw0KICAgdGhhdCBjb29yZGluYXRlIGlu dGVyYWN0aW9ucyBiZXR3ZWVuIHRoZSBjb21wb25lbnRzLiAgVGhlIGRvY3VtZW50DQogICBwcmVz ZW50cyBhbiBvdmVyYWxsIGZyYW1ld29yayBmb3IgbGFyZ2Utc2NhbGUgbWVhc3VyZW1lbnRzLiAg SXQgYWxzbw0KICAgZGVmaW5lcyB0ZXJtaW5vbG9neSBmb3IgTE1BUCAobGFyZ2Utc2NhbGUgbWVh c3VyZW1lbnQgcGxhdGZvcm1zKS4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClBs ZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0 aW1lIG9mIHN1Ym1pc3Npb24NCnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFy ZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoN Cg== From philip.eardley@bt.com Fri Dec 6 08:02:17 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6936C1AE07E for ; Fri, 6 Dec 2013 08:02:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PcEYmcPGpzB5 for ; Fri, 6 Dec 2013 08:02:15 -0800 (PST) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id 053A31AE30E for ; Fri, 6 Dec 2013 08:02:08 -0800 (PST) Received: from EVMHT63-UKRD.domain1.systemhost.net (10.36.3.100) by RDW083A006ED62.bt.com (10.187.98.11) with Microsoft SMTP Server (TLS) id 14.3.169.1; Fri, 6 Dec 2013 16:02:07 +0000 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.1.75]) by EVMHT63-UKRD.domain1.systemhost.net ([10.36.3.100]) with mapi; Fri, 6 Dec 2013 16:02:03 +0000 From: To: , Date: Fri, 6 Dec 2013 16:02:02 +0000 Thread-Topic: [lmap] Information Model suggested modifications Thread-Index: Ac7x226/mb4FBSeFQzaGhwOh//zmeQAv9Idg Message-ID: References: <20131205165948.GA80641@elstar.local> In-Reply-To: <20131205165948.GA80641@elstar.local> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: lmap@ietf.org, trevor.burbridge@bt.com, bertietf@bwijnen.net, Michael.K.Bugenhagen@centurylink.com, marcelo@it.uc3m.es, bs7652@att.com Subject: Re: [lmap] Information Model suggested modifications X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 16:02:17 -0000 I agree with Juergen and Jason on Collector failure. There are various thin= gs the measurement system might want to do. It can report to the Controller= (S5.2 p16, failure reporting).=20 I agree it seems a bit strange to send configuration updates as a keep aliv= e mechanism. However, there was a caution against adding a heartbeat mechan= ism - Steve (?) mentioned that he'd found it gave far more false positives = than true positives. I don't think we can insist on the MA reporting a Controller failure to the= Collector - at least where there are multiple collectors it might get conf= using, and some collectors might not have a link back to the controller.=20 Thanks phil > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > university.de] > Sent: 05 December 2013 17:00 > To: Weil, Jason > Cc: Bugenhagen, Michael K; 'Bert Wijnen (IETF)'; > Burbridge,T,Trevor,TUB8 R; 'bs7652@att.com'; Eardley,PL,Philip,TUB8 R; > 'marcelo@it.uc3m.es'; 'lmap@ietf.org' > Subject: Re: [lmap] Information Model suggested modifications >=20 > Hi, >=20 > somehow it feels a bit strange to send configuration updates as a keep > alive mechanism. We do have a suppression mechanism because we do not > want to reconfigure MAs just to suppress execution of tests for a > certain (typically short) period of time. We could have solved that by > configuration updates as well but we did not (and I think this feels > right). Hence, I would expect that we do the same here - one could > think of this as an automated suppression that gets activated once > connectivity to the controller has been lost for a certain time period. >=20 > Concerning the collector, if the MA can't report for a while, I assume > it will discard results. Ideally the controller will notice at some > time (via unspecified mechanisms) that no data is being received > anymore and it can take action. If the MA looses connectivity to the > controller, there however nothing anymore left to take any actions. So > in this case, I believe the MA should stop all measurements. And I > would keep things simple - if the MA has not managed to talk to its > controller for a certain longer time, it starts to suppress all > measurements. A simple 'auto suppression' parameter (set it to a week > or a months - whatever is a suitable safety timeout) should be enough. >=20 > /js >=20 > On Thu, Dec 05, 2013 at 11:35:16AM -0500, Weil, Jason wrote: > > The case of an unreachable Collector seems more implementation > dependent. > > It becomes a function of the amount of memory on the MA, the > preferred > > reporting/collection interval, and business requirements of the > > measurement system. The flexibility to support varying reporting > > requirements should be supported. > > > > I think I need to pull back slightly from my former comment to add > > that the MA to Controller reachability test resulting action should > be > > flexible as well. A test administrator may want some scheduled tests > > to not start when the Controller is no longer reachable and others to > > continue. Of course this could be solved by other means such as > having > > the Controller provide a short test schedule for some tests (e.g. run > > these tests for the next 24hrs) and long or infinite duration for > > others and just require the MA to check back frequently (every 24hrs > > in the former example) to the Controller for its next test schedule. > > > > Jason > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 12/5/13 10:04 AM, "Bugenhagen, Michael K" > > wrote: > > > > >What happens if the collector isn't available ... ?? > > > > > >Same behavior? > > > > > > > > > > > >-----Original Message----- > > >From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Weil, Jason > > >Sent: Thursday, December 05, 2013 8:39 AM > > >To: Bert Wijnen (IETF); trevor.burbridge@bt.com; bs7652@att.com; > > >philip.eardley@bt.com; marcelo@it.uc3m.es; lmap@ietf.org > > >Subject: Re: [lmap] Information Model suggested modifications > > > > > >/Chair hat off > > > > > >Personally I prefer this approach. I would think an MA should check > > >in with the Controller at some time interval (interval could be > > >provided by the controller along with some number of retry attempts) > > >for a health check. If a Controller goes away for whatever reason > and > > >it is responsible for controlling 250,000 probes, it would be nice > > >for those probes to stop performing their assigned tasks until the > > >Controller returns. > > > > > >Jason > > > > > >On 12/3/13 10:20 AM, "Bert Wijnen (IETF)" > wrote: > > > > > >>I believe that the RIPE-Atlas probes cease to do measurements if > > >>they loose connectivity with the RIPE-Atlas infrastructure for a > > >>prolonged time. > > >> > > >>If needed, I can try to get the details posted. > > >> > > >>Bert > > >> > > >>On 12/3/13 4:09 PM, Juergen Schoenwaelder wrote: > > >>> For example, if the owner of the measurement infrastructures goes > > >>> bankrupt, what is going to happen with the deployed probes? This > > >>> is not a fail-over situation and one would hope that the probes > > >>> stop at some time to do measurements (and we won't have to wait > > >>> until the results have eaten up all storage and the box hosting > > >>> the MA simply fails badly because of resource shortage; sure well > > >>> implemented MAs will never do this.;-). > > >>_______________________________________________ > > >>lmap mailing list > > >>lmap@ietf.org > > >>https://www.ietf.org/mailman/listinfo/lmap > > > > > > > > >This E-mail and any of its attachments may contain Time Warner Cable > > >proprietary information, which is privileged, confidential, or > > >subject to copyright belonging to Time Warner Cable. This E-mail is > > >intended solely for the use of the individual or entity to which it > > >is addressed. If you are not the intended recipient of this E-mail, > > >you are hereby notified that any dissemination, distribution, > > >copying, or action taken in relation to the contents of and > > >attachments to this E-mail is strictly prohibited and may be > > >unlawful. If you have received this E-mail in error, please notify > > >the sender immediately and permanently delete the original and any > copy of this E-mail and any printout. > > >_______________________________________________ > > >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 > > > > > > This E-mail and any of its attachments may contain Time Warner Cable > proprietary information, which is privileged, confidential, or subject > to copyright belonging to Time Warner Cable. This E-mail is intended > solely for the use of the individual or entity to which it is > addressed. If you are not the intended recipient of this E-mail, you > are hereby notified that any dissemination, distribution, copying, or > action taken in relation to the contents of and attachments to this E- > mail is strictly prohibited and may be unlawful. If you have received > this E-mail in error, please notify the sender immediately and > permanently delete the original and any copy of this E-mail and any > printout. > > _______________________________________________ > > lmap mailing list > > lmap@ietf.org > > https://www.ietf.org/mailman/listinfo/lmap >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 From dromasca@avaya.com Tue Dec 10 07:54:19 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 991461ADF7C for ; Tue, 10 Dec 2013 07:54:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mvRHxDUcNZuT for ; Tue, 10 Dec 2013 07:54:16 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 7173A1AD7C5 for ; Tue, 10 Dec 2013 07:54:16 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoIMAM44p1KHCzI1/2dsb2JhbABZgmYhOFOCf6EblQQYgQYWbQeCJQEBAQEDEhERUQYBCA0EBAEBAwIGCwECDwMCBB8RFAEGAQEFBQQTCAELDodOAw8BDKIahEuKQIhqDYEkhUMXgSmLSoE+Iw8HKAQIBgaCTjWBEwEDligBiFeFboU5gymBcTk X-IronPort-AV: E=Sophos;i="4.93,865,1378872000"; d="scan'208";a="40402641" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 10 Dec 2013 10:53:57 -0500 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 10 Dec 2013 10:43:18 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.03.0146.000; Tue, 10 Dec 2013 16:53:55 +0100 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: IETF 89 - Working Group/BOF/IRTF Scheduling Thread-Index: AQHO8GQP5CpJNaBycEKcxcw6GqReu5pNm3mg Date: Tue, 10 Dec 2013 15:53:54 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA129DFE00@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [lmap] FW: IETF 89 - Working Group/BOF/IRTF Scheduling X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 15:54:19 -0000 DQpIaSwNCg0KU2NoZWR1bGluZyBmb3IgdGhlIElFVEYtODggbWVldGluZyBpbiBMb25kb24gaXMg bm93IG9wZW4uIA0KDQpPdXIgcGxhbiBpcyB0byByZXF1ZXN0IG9uZSAyLjUgaG91cnMgbWVldGlu ZyBzbG90LCBhcyB3ZSBoYWQgYXQgSUVURi04OC4gQW55Ym9keSBiZWxpZXZlcyB0aGF0IHdlIG5l ZWQgbW9yZSwgb3IgbGVzcyB0aW1lPyANCg0KQWxzbyBwbGVhc2Ugc2VuZCB1cyB5b3VyIGxpc3Qg b2YgY3JpdGljYWwgY29uZmxpY3RzLCBiZXlvbmQgdGhlIG9idmlvdXMuIA0KDQpUaGFua3MgYW5k IFJlZ2FyZHMsDQoNCkphc29uIGFuZCBEYW4NCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQpGcm9tOiBXR0NoYWlycyBbbWFpbHRvOndnY2hhaXJzLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBJRVRGIEFnZW5kYQ0KU2VudDogVHVlc2RheSwgRGVjZW1iZXIgMDMsIDIwMTMg MTA6MTMgUE0NClRvOiBXb3JraW5nIEdyb3VwIENoYWlycw0KQ2M6IGlyc2dAaXJ0Zi5vcmcNClN1 YmplY3Q6IElFVEYgODkgLSBXb3JraW5nIEdyb3VwL0JPRi9JUlRGIFNjaGVkdWxpbmcNCg0KLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCjg5dGggSUVURiDigJMgTG9uZG9uLCBFbmdsYW5kDQpNZWV0aW5nIERhdGVzOiBNYXJj aCAyIOKAkyA3LCAyMDE0DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KSUVURiBtZWV0aW5ncyBzdGFydCBNb25kYXkgbW9y bmluZyBhbmQgcnVuIHRocm91Z2ggRnJpZGF5IGFmdGVybm9vbiAoMTM6MzApLg0KDQpXZSBhcmUg YWNjZXB0aW5nIHNjaGVkdWxpbmcgcmVxdWVzdHMgZm9yIGFsbCBXb3JraW5nIEdyb3VwcywgQk9G cywgYW5kIFJlc2VhcmNoIEdyb3VwcyBzdGFydGluZyB0b2RheS4gIFRoZSBtaWxlc3RvbmVzIGFu ZCBkZWFkbGluZXMgZm9yIHNjaGVkdWxpbmctcmVsYXRlZCBhY3Rpdml0aWVzIGFyZSBhcyBmb2xs b3dzOg0KDQpOT1RFOiBjdXRvZmYgZGF0ZXMgYXJlIHN1YmplY3QgdG8gY2hhbmdlLg0KDQotIDIw MTMtMTItMDIgKE1vbmRheSk6IFdvcmtpbmcgR3JvdXAgYW5kIEJPRiBzY2hlZHVsaW5nIGJlZ2lu cy4gVG8gcmVxdWVzdCBhIFdvcmtpbmcgR3JvdXAgc2Vzc2lvbiwgdXNlIHRoZSBJRVRGIE1lZXRp bmcgU2Vzc2lvbiBSZXF1ZXN0IFRvb2wuDQotIDIwMTQtMDEtMTcgKEZyaWRheSk6IEN1dC1vZmYg ZGF0ZSBmb3IgcmVxdWVzdHMgdG8gc2NoZWR1bGUgV29ya2luZyBHcm91cCBtZWV0aW5ncyBhdCBV VEMgMjM6NTkuIFRvIHJlcXVlc3QgYSBXb3JraW5nIEdyb3VwIHNlc3Npb24sIHVzZSB0aGUgSUVU RiBNZWV0aW5nIFNlc3Npb24gUmVxdWVzdCBUb29sLg0KLSAyMDE0LTAxLTE3IChGcmlkYXkpOiBD dXQtb2ZmIGRhdGUgZm9yIEJPRiBwcm9wb3NhbCByZXF1ZXN0cyB0byBBcmVhIERpcmVjdG9ycyBh dCBVVEMgMjM6NTkuIFRvIHJlcXVlc3QgYSBCT0YsIHBsZWFzZSBzZWUgaW5zdHJ1Y3Rpb25zIG9u IFJlcXVlc3RpbmcgYSBCT0YuDQotIDIwMTQtMDEtMjQgKEZyaWRheSk6IEN1dC1vZmYgZGF0ZSBm b3IgQXJlYSBEaXJlY3RvcnMgdG8gYXBwcm92ZSBCT0ZzIGF0IFVUQyAyMzo1OS4NCi0gMjAxNC0w MS0zMSAoRnJpZGF5KTogUHJlbGltaW5hcnkgYWdlbmRhIHB1Ymxpc2hlZCBmb3IgY29tbWVudC4N Ci0gMjAxNC0wMi0wMyAoTW9uZGF5KTogQ3V0LW9mZiBkYXRlIGZvciByZXF1ZXN0cyB0byByZXNj aGVkdWxlIFdvcmtpbmcgR3JvdXAgYW5kIEJPRiBtZWV0aW5ncyBVVEMgMjM6NTkuDQotIDIwMTQt MDItMDcgKEZyaWRheSk6IEZpbmFsIGFnZW5kYSB0byBiZSBwdWJsaXNoZWQuDQotIDIwMTQtMDIt MTcgKE1vbmRheSk6IERyYWZ0IFdvcmtpbmcgR3JvdXAgYWdlbmRhcyBkdWUgYnkgVVRDIDIzOjU5 LCB1cGxvYWQgdXNpbmcgSUVURiBNZWV0aW5nIE1hdGVyaWFscyBNYW5hZ2VtZW50IFRvb2wuDQot IDIwMTQtMDItMjQgKE1vbmRheSk6IFJldmlzZWQgV29ya2luZyBHcm91cCBhZ2VuZGFzIGR1ZSBi eSBVVEMgMjM6NTksIHVwbG9hZCB1c2luZyBJRVRGIE1lZXRpbmcgTWF0ZXJpYWxzIE1hbmFnZW1l bnQgVG9vbC4NCi0gMjAxNC0wMy0yOCAoRnJpZGF5KTogUHJvY2VlZGluZ3Mgc3VibWlzc2lvbiBj dXRvZmYgZGF0ZSBieSBVVEMgMjM6NTksIHVwbG9hZCB1c2luZyBJRVRGIE1lZXRpbmcgTWF0ZXJp YWxzIE1hbmFnZW1lbnQgVG9vbC4NCi0gMjAxNC0wNC0xOCAoRnJpZGF5KTogUHJvY2VlZGluZ3Mg c3VibWlzc2lvbiBjb3JyZWN0aW9ucyBjdXRvZmYgZGF0ZSBieSBVVEMgMjM6NTksIHVwbG9hZCB1 c2luZyBJRVRGIE1lZXRpbmcgTWF0ZXJpYWxzIE1hbmFnZW1lbnQgVG9vbC4NCg0KU3VibWl0dGlu ZyBSZXF1ZXN0cyBmb3IgV29ya2luZyBHcm91cCBhbmQgQk9GIFNlc3Npb25zDQoNClBsZWFzZSBz dWJtaXQgcmVxdWVzdHMgdG8gc2NoZWR1bGUgeW91ciBXb3JraW5nIEdyb3VwIHNlc3Npb25zIHVz aW5nIHRoZSAiSUVURiBNZWV0aW5nIFNlc3Npb24gUmVxdWVzdCBUb29sLCIgYSBXZWItYmFzZWQg dG9vbCBmb3Igc3VibWl0dGluZyBhbGwgb2YgdGhlIGluZm9ybWF0aW9uIHRoYXQgdGhlIFNlY3Jl dGFyaWF0IHJlcXVpcmVzIHRvIHNjaGVkdWxlIHlvdXIgc2Vzc2lvbnMuDQoNClRoZSBVUkwgZm9y IHRoZSB0b29sIGlzOg0KDQpodHRwczovL3B1Yi5pZXRmLm9yZy9zcmVxLw0KDQpQbGVhc2Ugc2Vu ZCByZXF1ZXN0cyB0byBzY2hlZHVsZSB5b3VyIEJPRiBzZXNzaW9ucyB0byBhZ2VuZGFAaWV0Zi5v cmcuICBQbGVhc2UgaW5jbHVkZSB0aGUgYWNyb255bSBvZiB5b3VyIEJPRiBpbiB0aGUgc3ViamVj dCBsaW5lIG9mIHRoZSBtZXNzYWdlLCBhbmQgaW5jbHVkZSBhbGwgb2YgdGhlIGluZm9ybWF0aW9u IHNwZWNpZmllZCBpbiBpdGVtICg0KSBvZiAiUmVxdWVzdGluZyBNZWV0aW5nIFNlc3Npb25zIGF0 IElFVEYgTWVldGluZ3MiIGluIHRoZSBib2R5LiAgKFRoaXMgZG9jdW1lbnQgaXMgaW5jbHVkZWQg YmVsb3cuKQ0KDQpTdWJtaXR0aW5nIFNlc3Npb24gQWdlbmRhcw0KDQpGb3IgdGhlIGNvbnZlbmll bmNlIG9mIG1lZXRpbmcgYXR0ZW5kZWVzLCB3ZSBhc2sgdGhhdCB5b3Ugc3VibWl0IHRoZSBhZ2Vu ZGFzIGZvciB5b3VyIFdvcmtpbmcgR3JvdXAgc2Vzc2lvbnMgYXMgZWFybHkgYXMgcG9zc2libGUu ICBEcmFmdCBXb3JraW5nIEdyb3VwIGFnZW5kYXMgYXJlIGR1ZSBNb25kYXksIEZlYnJ1YXJ5IDE3 dGgsIDIwMTQgYXQgVVRDIDIzOjU5LiAgUmV2aXNlZCBXb3JraW5nIEdyb3VwIGFnZW5kYXMgYXJl IGR1ZSBubyBsYXRlciB0aGFuIE1vbmRheSwgRmVicnVhcnkgMjR0aCwgMjAxNCBhdCBVVEMgMjM6 NTkuICBUaGUgcHJvcG9zZWQgYWdlbmRhIGZvciBhIEJPRiBzZXNzaW9uIHNob3VsZCBiZSBzdWJt aXR0ZWQgYWxvbmcgd2l0aCB5b3VyIHJlcXVlc3QgZm9yIGEgc2Vzc2lvbi4gIFBsZWFzZSBiZSBz dXJlIHRvIGNvcHkgeW91ciBBcmVhIERpcmVjdG9yIG9uIHRoYXQgbWVzc2FnZS4NCg0KUGxlYXNl IHN1Ym1pdCB0aGUgYWdlbmRhcyBmb3IgeW91ciBXb3JraW5nIEdyb3VwIHNlc3Npb25zIHVzaW5n IHRoZSAiSUVURiBNZWV0aW5nIE1hdGVyaWFscyBNYW5hZ2VtZW50IFRvb2wsIiBhIFdlYi1iYXNl ZCB0b29sIGZvciBtYWtpbmcgeW91ciBtZWV0aW5nIGFnZW5kYSwgbWludXRlcywgYW5kIHByZXNl bnRhdGlvbiBzbGlkZXMgYXZhaWxhYmxlIHRvIHRoZSBjb21tdW5pdHkgYmVmb3JlLCBkdXJpbmcs IGFuZCBhZnRlciBhbiBJRVRGIG1lZXRpbmcuICBJZiB5b3UgYXJlIGEgQk9GIGNoYWlyLCB0aGVu IHlvdSBtYXkgdXNlIHRoZSB0b29sIHRvIHN1Ym1pdCBhIHJldmlzZWQgYWdlbmRhIGFzIHdlbGwg YXMgb3RoZXIgbWF0ZXJpYWxzIGZvciB5b3VyIEJPRiBvbmNlIHRoZSBCT0YgaGFzIGJlZW4gYXBw cm92ZWQuDQoNClRoZSBVUkwgZm9yIHRoZSB0b29sIGlzOg0KDQpodHRwczovL3B1Yi5pZXRmLm9y Zy9wcm9jZWVkaW5ncy8NCg0KQWRkaXRpb25hbCBpbmZvcm1hdGlvbiBhYm91dCB0aGlzIHRvb2wg aXMgYXZhaWxhYmxlIGF0Og0KDQpodHRwOi8vd3d3LmlldGYub3JnL2luc3RydWN0aW9ucy9tZWV0 aW5nX21hdGVyaWFsc190b29sLmh0bWwNCg0KQWdlbmRhcyBzdWJtaXR0ZWQgdmlhIHRoZSB0b29s IHdpbGwgYmUgYXZhaWxhYmxlIHRvIHRoZSBwdWJsaWMgb24gdGhlICJJRVRGIE1lZXRpbmcgTWF0 ZXJpYWxzIiB3ZWJwYWdlIGFzIHNvb24gYXMgdGhleSBhcmUgc3VibWl0dGVkLg0KDQpUaGUgVVJM IGZvciB0aGUgIklFVEYgODkgTWVldGluZyBNYXRlcmlhbHMiIFdlYiBwYWdlIGlzOg0KDQpodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcvODkvbWF0ZXJpYWxzLmh0bWwNCg0KSWYg eW91IGFyZSBhIFdvcmtpbmcgR3JvdXAgY2hhaXIsIHRoZW4geW91IGFscmVhZHkgaGF2ZSBhY2Nv dW50cyBvbiB0aGUgIklFVEYgTWVldGluZyBTZXNzaW9uIFJlcXVlc3QgVG9vbCIgYW5kIHRoZSAi SUVURiBNZWV0aW5nIE1hdGVyaWFscyBNYW5hZ2VtZW50IFRvb2wuIiAgVGhlIHNhbWUgVXNlciBJ RCBhbmQgcGFzc3dvcmQgd2lsbCB3b3JrIGZvciBib3RoIHRvb2xzLiAgSWYgeW91IGFyZSBhIEJP RiBjaGFpciB3aG8gaXMgbm90IGFsc28gYSBXb3JraW5nIEdyb3VwIGNoYWlyLCB0aGVuIHlvdSB3 aWxsIGJlIGdpdmVuIGFuIGFjY291bnQgb24gdGhlICJJRVRGIE1lZXRpbmcgTWF0ZXJpYWxzIE1h bmFnZW1lbnQgVG9vbCIgd2hlbiB5b3VyIEJPRiBoYXMgYmVlbiBhcHByb3ZlZC4gIElmIHlvdSBy ZXF1aXJlIGFzc2lzdGFuY2UgaW4gdXNpbmcgZWl0aGVyIHRvb2wsIG9yIHdpc2ggdG8gcmVwb3J0 IGEgYnVnLCB0aGVuIHBsZWFzZSBzZW5kIGEgbWVzc2FnZSB0bzoNCmlldGYtYWN0aW9uQGlldGYu b3JnLg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09DQpGb3IgeW91ciBjb252ZW5pZW5jZSwgY29tcHJlaGVuc2l2ZSBpbmZvcm1h dGlvbiBvbiByZXF1ZXN0aW5nIG1lZXRpbmcgc2Vzc2lvbnMgZm9yIElFVEYgODkgaXMgYmVsb3c6 DQoNCjEuIFJlcXVlc3RzIHRvIHNjaGVkdWxlIFdvcmtpbmcgR3JvdXAgc2Vzc2lvbnMgc2hvdWxk IGJlIHN1Ym1pdHRlZCB1c2luZyB0aGUgIklFVEYgTWVldGluZyBTZXNzaW9uIFJlcXVlc3QgVG9v bCwiIGEgV2ViLWJhc2VkIHRvb2wgZm9yIHN1Ym1pdHRpbmcgYWxsIG9mIHRoZSBpbmZvcm1hdGlv biByZXF1aXJlZCBieSB0aGUgU2VjcmV0YXJpYXQgdG8gc2NoZWR1bGUgeW91ciBzZXNzaW9ucy4g IFRoZSBVUkwgZm9yIHRoZSB0b29sIGlzOg0KDQpodHRwczovL3B1Yi5pZXRmLm9yZy9zcmVxLw0K DQpJbnN0cnVjdGlvbnMgZm9yIHVzaW5nIHRoZSB0b29sIGFyZSBhdmFpbGFibGUgYXQ6DQoNCmh0 dHA6Ly93d3cuaWV0Zi5vcmcvaW5zdHJ1Y3Rpb25zL3Nlc3Npb25fcmVxdWVzdF90b29sX2luc3Ry dWN0aW9uLmh0bWwNCg0KSWYgeW91IHJlcXVpcmUgYW4gYWNjb3VudCBvbiB0aGlzIHRvb2wsIG9y IGFzc2lzdGFuY2UgaW4gdXNpbmcgaXQsIHRoZW4gcGxlYXNlIHNlbmQgYSBtZXNzYWdlIHRvIGll dGYtYWN0aW9uQGlldGYub3JnLiAgSWYgeW91IGFyZSB1bmFibGUgdG8gdXNlIHRoZSB0b29sLCB0 aGVuIHlvdSBtYXkgc2VuZCB5b3VyIHJlcXVlc3QgdmlhIGUtbWFpbCB0byBhZ2VuZGFAaWV0Zi5v cmcsIHdpdGggYSBjb3B5IHRvIHRoZSBhcHByb3ByaWF0ZSBBcmVhIERpcmVjdG9yKHMpLg0KDQpS ZXF1ZXN0cyB0byBzY2hlZHVsZSBCT0Ygc2Vzc2lvbnMgbXVzdCBiZSBzZW50IHRvIGFnZW5kYUBp ZXRmLm9yZyB3aXRoIGEgY29weSB0byB0aGUgYXBwcm9wcmlhdGUgQXJlYSBEaXJlY3RvcihzKS4N Cg0KV2hlbiBzdWJtaXR0aW5nIGEgV29ya2luZyBHcm91cCBvciBCT0Ygc2Vzc2lvbiByZXF1ZXN0 IGJ5IGUtbWFpbCwgcGxlYXNlIGluY2x1ZGUgdGhlIFdvcmtpbmcgR3JvdXAgb3IgQk9GIGFjcm9u eW0gaW4gdGhlIFN1YmplY3QgbGluZS4NCg0KMi4gQk9GcyB3aWxsIE5PVCBiZSBzY2hlZHVsZWQg dW5sZXNzIHRoZSBBcmVhIERpcmVjdG9yIGFwcHJvdmVzIHRoZSBCT0YuIFRoZSBwcm9wb25lbnRz IGJlaGluZCBhIEJPRiBuZWVkIHRvIGNvbnRhY3QgYSByZWxldmFudCBBcmVhIERpcmVjdG9yLCBw cmVmZXJhYmx5IHdlbGwgaW4gYWR2YW5jZSBvZiB0aGUgQk9GIGFwcHJvdmFsIGRlYWRsaW5lIGRh dGUuIFRoZSBBRCBuZWVkcyB0byBoYXZlIHRoZSBmdWxsIG5hbWUgb2YgdGhlIEJPRiwgaXRzIGFj cm9ueW0sIHN1Z2dlc3RlZCBuYW1lcyBvZiBjaGFpcnMsIGFuIGFnZW5kYSwgZnVsbCBkZXNjcmlw dGlvbiBvZiB0aGUgQk9GIGFuZCB0aGUgaW5mb3JtYXRpb24gY292ZXJlZCBpbiBpdGVtIDQuIFBs ZWFzZSByZWFkIFJGQyA1NDM0IGZvciBpbnN0cnVjdGlvbnMgb24gaG93IHRvIGRyaXZlIGEgc3Vj Y2Vzc2Z1bCBCT0YgZWZmb3J0LiBUaGUgYXBwcm92YWwgZGVwZW5kcyBvbiwgZm9yIGluc3RhbmNl LCBJbnRlcm5ldC1EcmFmdHMgYW5kIGxpc3QgZGlzY3Vzc2lvbiBvbiB0aGUgc3VnZ2VzdGVkIHRv cGljLiBCT0YgYWdlbmRhIHJlcXVlc3RzLCBpZiBhcHByb3ZlZCwgd2lsbCBiZSBzdWJtaXR0ZWQg dG8gdGhlIElFVEYgU2VjcmV0YXJpYXQgYnkgdGhlIEFEcy4NCg0KMy4gQSBXb3JraW5nIEdyb3Vw IG1heSByZXF1ZXN0IGVpdGhlciBvbmUgb3IgdHdvIHNlc3Npb25zLiAgSWYgeW91ciBXb3JraW5n IEdyb3VwIHJlcXVpcmVzIG1vcmUgdGhhbiB0d28gc2Vzc2lvbnMsIHRoZW4geW91ciByZXF1ZXN0 IG11c3QgYmUgYXBwcm92ZWQgYnkgYW4gQXJlYSBEaXJlY3Rvci4gIEFkZGl0aW9uYWwgc2Vzc2lv bnMgd2lsbCBiZSBhc3NpZ25lZCwgYmFzZWQgb24gYXZhaWxhYmlsaXR5LCBhZnRlciBNb25kYXks IEZlYnJ1YXJ5IDNyZCwgMjAxNCwgdGhlIGN1dC1vZmYgZGF0ZSBmb3IgcmVxdWVzdHMgdG8gcmVz Y2hlZHVsZSBhIHNlc3Npb24uDQoNCjQuIFlvdSBNVVNUIHByb3ZpZGUgdGhlIGZvbGxvd2luZyBp bmZvcm1hdGlvbiBiZWZvcmUgYSBXb3JraW5nIEdyb3VwIG9yIEJPRiBzZXNzaW9uIHdpbGwgYmUg c2NoZWR1bGVkOg0KDQogICAgYS4gV29ya2luZyBHcm91cCBvciBCT0YgZnVsbCBuYW1lIHdpdGgg YWNyb255bSBpbiBicmFja2V0czogDQoNCiAgICBiLiBBUkVBIHVuZGVyIHdoaWNoIFdvcmtpbmcg R3JvdXAgb3IgQk9GIGFwcGVhcnM6DQoNCiAgICBjLiBDT05GTElDVFMgeW91IHdpc2ggdG8gYXZv aWQsIHBsZWFzZSBiZSBhcyBzcGVjaWZpYyBhcyBwb3NzaWJsZToNCg0KICAgIGQuIEV4cGVjdGVk IEF0dGVuZGFuY2U6DQoNCiAgICBlLiBTcGVjaWFsIHJlcXVlc3RzOg0KDQogICAgZi4gTnVtYmVy IG9mIHNlc3Npb25zOg0KDQogICAgZy4gTGVuZ3RoIG9mIHNlc3Npb246IA0KICAgICAgIC0gMSBo b3VyIA0KICAgICAgIC0gMSAxLzIgaG91cnMNCiAgICAgICAtIDIgaG91cnMgDQogICAgICAgLSAy IDEvMiBob3Vycw0KDQpGb3IgbW9yZSBpbmZvcm1hdGlvbiBvbiBzY2hlZHVsaW5nIFdvcmtpbmcg R3JvdXAgYW5kIEJPRiBzZXNzaW9ucywgcGxlYXNlIHJlZmVyIHRvIFJGQyAyNDE4IChCQ1AgMjUp LCAiSUVURiBXb3JraW5nIEdyb3VwIEd1aWRlbGluZXMgYW5kIFByb2NlZHVyZXMiIChodHRwOi8v d3d3LmlldGYub3JnL3JmYy9yZmMyNDE4LnR4dCkuDQo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCkZvciB5b3VyIGNvbnZlbmll bmNlIHBsZWFzZSBmaW5kIGhlcmUgYSBsaXN0IG9mIHRoZSBJRVRGIEFyZWEgRGlyZWN0b3JzIHdp dGggdGhlaXIgZS1tYWlsIGFkZHJlc3NlczoNCg0KSUVURiBDaGFpcg0KSmFyaSBBcmtrbyA8amFy aS5hcmtrb0BwaXVoYS5uZXQ+DQoNCkFwcGxpY2F0aW9ucyBBcmVhIChhcHApDQpCYXJyeSBMZWli YSA8YmFycnlsZWliYUBjb21wdXRlci5vcmc+DQpQZXRlIFJlc25pY2sgPHByZXNuaWNrQHF1YWxj b21tLmNvbT4NCg0KSW50ZXJuZXQgQXJlYSAoaW50KQ0KQnJpYW4gSGFiZXJtYW4gPGJyaWFuQGlu bm92YXRpb25zbGFiLm5ldD4gVGVkIExlbW9uIDx0ZWQubGVtb25Abm9taW51bS5jb20+DQoNCk9w ZXJhdGlvbnMgJiBNYW5hZ2VtZW50IEFyZWEgKG9wcykNCkJlbm9pdCBDbGFpc2UgPGJjbGFpc2VA Y2lzY28uY29tPg0KSm9lbCBKYWVnZ2xpIDxqb2VsamFAYm9ndXMuY29tPg0KDQpSZWFsLXRpbWUg QXBwbGljYXRpb25zIGFuZCBJbmZyYXN0cnVjdHVyZSBBcmVhIChyYWkpIEdvbnphbG8gQ2FtYXJp bGxvIDxnb256YWxvLmNhbWFyaWxsb0Blcmljc3Nvbi5jb20+IFJpY2hhcmQgQmFybmVzIDxybGJA aXB2LnN4PiAgDQoNClJvdXRpbmcgQXJlYSAocnRnKQ0KU3Rld2FydCBCcnlhbnQgPHN0YnJ5YW50 QGNpc2NvLmNvbT4NCkFkcmlhbiBGYXJyZWwgPGFkcmlhbkBvbGRkb2cuY28udWs+ICANCg0KU2Vj dXJpdHkgQXJlYSAoc2VjKQ0KU3RlcGhlbiBGYXJyZWxsIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNk LmllPiBTZWFuIFR1cm5lciA8dHVybmVyc0BpZWNhLmNvbT4gIA0KDQpUcmFuc3BvcnQgQXJlYSAo dHN2KQ0KTWFydGluIFN0aWVtZXJsaW5nIDxtYXJ0aW4uc3RpZW1lcmxpbmdAbmVjbGFiLmV1PiBT cGVuY2VyIERhd2tpbnMgIDxzcGVuY2VyZGF3a2lucy5pZXRmQGdtYWlsLmNvbT4gID09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQo4OHRo IElFVEYgTWVldGluZyBBdHRlbmRhbmNlIE51bWJlcnMNCg0KNmxvIC0gNTINCjZtYW4gLSAxNDMN CjZ0aXNjaCAtIDQ1DQphYmZhYiAtIDIwDQphbHRvICAtIDM1DQphcHBzYXdnL2FwcGFyZWEgLSAx MzgNCmFxbSAtIDEwOA0KYXFtICgybmQgc2Vzc2lvbikgLSA0NQ0KYXZ0Y29yZSAtIDUxDQphdnRl eHQg4oCTIDU5DQpiZmQgLSAxNw0KYm13ZyAtIDE5DQpjY2FtcCAtIDQ5DQpjY2FtcCAoMm5kIHNl c3Npb24pIC0gNDQNCmNkbmkgLSAzOQ0KY2x1ZSAtIDQxDQpjbHVlICgybmQgc2Vzc2lvbikgLSAz Mg0KY29yZSAtIDYyDQpjb3JlICgybmQgc2Vzc2lvbikgLSA1MA0KZGhjIC0gNTkNCmRpY2UgLSA2 NQ0KZGltZSAtIDIzDQpkaXNwYXRjaCAtIDU1DQpkbW0gLSAzNw0KZG5zb3AgLSAxMjUNCmRuc3Nk IC0gMTA4DQplY3JpdCAtIDMxDQplbWFuIC0gMTkNCmZvcmNlcyAtIDQwDQpnZW9uZXQgKEJvRikg LSA5OQ0KZ2VvcHJpdiAtIDQxDQpob21lbmV0IC0gMTU2DQpodHRwYXV0aCAtIDQzDQpodHRwYmlz IC0gODkNCmh0dHBiaXMgKDJuZCBzZXNzaW9uKSAtIDEyNw0KaTJycyAtIDIyMw0KaWNjcmcgKFJH KSAtIDY4DQppY25yZyAoUkcpIC0gNDMNCmlkciAtIDkwDQppZ292dXBkYXRlIEJvRiAtIDIyMA0K aW5zaXBpZCAtIDMyDQppbnRhcmVhIChBRykgLSA5OA0KaXBmaXggLSAyMw0KaXBwbSAtIDQ4DQpp cHNlY21lIC0gMjcNCklSVEYgT3BlbiBNZWV0aW5nIC0gMTAwDQppc2lzIC0gNTgNCmpvc2UgLSA0 Mg0KanNvbiAtIDQ5DQprYXJwIC0gMjINCmtpdHRlbiAtIDIzDQpsMnZwbiAtIDcxDQpsM3ZwbiAt IDY1DQpsaXNwIC0gNTYNCmxtYXAgLSA1Mg0KbHdpZyAtIDM1DQptYW5ldCAtIDM1DQptYm9uZWQg LSAyNQ0KbWlmIC0gNDENCm1tdXNpYyAtIDY5DQptbXVzaWMgKDJuZCBzZXNzaW9uKSAtIDUzDQpt cGxzIC0gNzENCm1wbHMgKDJuZCBzZXNzaW9uKSAtIDcyDQptcHRjcCAtIDQ1DQptcHRjcCAoMm5k IHNlc3Npb24pIC0gNzANCm5jcmcgKFJHKSAtIDMzDQpuZXRjb25mIC0gNjINCm5ldGV4dCAtIDI3 DQpuZXRtb2QgLSA2OQ0KbmZzdjQgLSAxNg0Kbm1yZyAoUkcpIC0gMzUNCm5tcmcgKFJHKSAoMm5k IHNlc3Npb24pIC0gMTcNCm50cCAoY29tYmluZWQgd2l0aCB0aWN0b2MpIC0gMzINCm52bzMgLSAx OTMNCm53Y3JnIChQUkcpIC0gMjUNCm9hdXRoIC0gMzgNCm9wc2F3Zy9vcHNhcmVhIC0gNjgNCm9w c2VjIC0gNDgNCm9zcGYgLSAzOA0KcGF3cyAtIDE3DQpwY2UgLSA3Mg0KcGNwIC0gMzANCnBlcnBh c3MgKEJvRikgLSAzMTMNCnBpbSAtIDI0DQpwcHNwIC0gMTINCnByZWNpcyAtIDMyDQpwd2UzIC0g NDANCnJhZGV4dCAtIDIwDQpyZmNmb3JtIChCb0YpIC0gNTINCnJtY2F0IC0gNjANCnJ0Y3dlYiAt IDE3NA0KcnRjd2ViICgybmQgc2Vzc2lvbikgLSAxODgNCnJ0Z2FyZWEgKEFHKSAtIDEwMQ0KcnRn d2cgLSAxMTgNCnNhYWcgKEFHKSAtIDE0OA0Kc2FjbSAtIDQwDQpzY2ltIC0gMzINCnNkbnJnIChS RykgLSAyNTkNCnNpZHIgLSA2MQ0Kc2lwcmVjIC0gMzENCnNvZnR3aXJlIC0gNTINCnNwcmluZyAt IDE1OA0Kc3RpciAtIDgyDQpzdGlyICgybmQgc2Vzc2lvbikgLSA3OQ0Kc3Rvcm0gLSAyMQ0KdGNw bSAtIDM2DQp0aWN0b2MgKGNvbWJpbmVkIHdpdGggbnRwKSAtIDMyDQp0bHMgLSAxMTENCnRyaWxs IC0gMzMNCnRzdmFyZWEgKEFHKSAtIDE1Mw0KdHN2d2cgLSA2Mw0KdHN2d2cgKDJuZCBzZXNzaW9u KSAtIDQ3DQp2Nm9wcyAtIDEzNQ0KdjZvcHMgKDJuZCBzZXNzaW9uKSAtIDkyDQp3ZWlyZHMgLSA1 NQ0Kd3Brb3BzIC0gMzQNCnhtcHAgLSAzMQ0KeHJibG9jayAtIDI0DQo= From dromasca@avaya.com Tue Dec 10 07:55:55 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B6091ADFA4 for ; Tue, 10 Dec 2013 07:55:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5yqOH6cq-cT1 for ; Tue, 10 Dec 2013 07:55:53 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 01E451ADF7C for ; Tue, 10 Dec 2013 07:55:52 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvMLAM44p1LGmAcV/2dsb2JhbABZgmYhOEgLgn+hGwOVARiBBhZ0giUBAQEBAxIREVEGAQgNBAQBAQMCBgsBAg8DAgQfERQBCAoEARIIAQsOh04DDwEMpmWKQIhqDYEkhUMXgSmLSoE+IxYoBAgGBoJONYETAQOWKAGIV4VuhTmDKYFxOQ X-IronPort-AV: E=Sophos;i="4.93,865,1378872000"; d="scan'208";a="40402920" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by co300216-co-outbound.net.avaya.com with ESMTP; 10 Dec 2013 10:55:47 -0500 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 10 Dec 2013 10:48:12 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.03.0146.000; Tue, 10 Dec 2013 10:55:44 -0500 From: "Romascanu, Dan (Dan)" To: "Romascanu, Dan (Dan)" , "lmap@ietf.org" Thread-Topic: IETF 89 - Working Group/BOF/IRTF Scheduling Thread-Index: AQHO8GQP5CpJNaBycEKcxcw6GqReu5pNm3mggAAEO5A= Date: Tue, 10 Dec 2013 15:55:44 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA129DFE22@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [lmap] IETF 89 - Working Group/BOF/IRTF Scheduling X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 15:55:55 -0000 SXQgd2lsbCBiZSBJRVRGLTg5LCBvZiBjb3Vyc2UuIA0KDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPiBGcm9tOiBSb21hc2NhbnUsIERhbiAoRGFuKQ0KPiBTZW50OiBUdWVzZGF5 LCBEZWNlbWJlciAxMCwgMjAxMyA1OjU0IFBNDQo+IFRvOiBsbWFwQGlldGYub3JnDQo+IFN1Ympl Y3Q6IEZXOiBJRVRGIDg5IC0gV29ya2luZyBHcm91cC9CT0YvSVJURiBTY2hlZHVsaW5nDQo+IA0K PiANCj4gSGksDQo+IA0KPiBTY2hlZHVsaW5nIGZvciB0aGUgSUVURi04OCBtZWV0aW5nIGluIExv bmRvbiBpcyBub3cgb3Blbi4NCj4gDQo+IE91ciBwbGFuIGlzIHRvIHJlcXVlc3Qgb25lIDIuNSBo b3VycyBtZWV0aW5nIHNsb3QsIGFzIHdlIGhhZCBhdCBJRVRGLTg4Lg0KPiBBbnlib2R5IGJlbGll dmVzIHRoYXQgd2UgbmVlZCBtb3JlLCBvciBsZXNzIHRpbWU/DQo+IA0KPiBBbHNvIHBsZWFzZSBz ZW5kIHVzIHlvdXIgbGlzdCBvZiBjcml0aWNhbCBjb25mbGljdHMsIGJleW9uZCB0aGUgb2J2aW91 cy4NCj4gDQo+IFRoYW5rcyBhbmQgUmVnYXJkcywNCj4gDQo+IEphc29uIGFuZCBEYW4NCj4gDQo+ IA0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogV0dDaGFpcnMgW21h aWx0bzp3Z2NoYWlycy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSUVURg0KPiBBZ2Vu ZGENCj4gU2VudDogVHVlc2RheSwgRGVjZW1iZXIgMDMsIDIwMTMgMTA6MTMgUE0NCj4gVG86IFdv cmtpbmcgR3JvdXAgQ2hhaXJzDQo+IENjOiBpcnNnQGlydGYub3JnDQo+IFN1YmplY3Q6IElFVEYg ODkgLSBXb3JraW5nIEdyb3VwL0JPRi9JUlRGIFNjaGVkdWxpbmcNCj4gDQo+IC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ IDg5dGggSUVURiDigJMgTG9uZG9uLCBFbmdsYW5kDQo+IE1lZXRpbmcgRGF0ZXM6IE1hcmNoIDIg 4oCTIDcsIDIwMTQNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gSUVURiBtZWV0aW5ncyBzdGFydCBNb25kYXkgbW9y bmluZyBhbmQgcnVuIHRocm91Z2ggRnJpZGF5IGFmdGVybm9vbg0KPiAoMTM6MzApLg0KPiANCj4g V2UgYXJlIGFjY2VwdGluZyBzY2hlZHVsaW5nIHJlcXVlc3RzIGZvciBhbGwgV29ya2luZyBHcm91 cHMsIEJPRnMsIGFuZA0KPiBSZXNlYXJjaCBHcm91cHMgc3RhcnRpbmcgdG9kYXkuICBUaGUgbWls ZXN0b25lcyBhbmQgZGVhZGxpbmVzIGZvcg0KPiBzY2hlZHVsaW5nLXJlbGF0ZWQgYWN0aXZpdGll cyBhcmUgYXMgZm9sbG93czoNCj4gDQo+IE5PVEU6IGN1dG9mZiBkYXRlcyBhcmUgc3ViamVjdCB0 byBjaGFuZ2UuDQo+IA0KPiAtIDIwMTMtMTItMDIgKE1vbmRheSk6IFdvcmtpbmcgR3JvdXAgYW5k IEJPRiBzY2hlZHVsaW5nIGJlZ2lucy4gVG8NCj4gcmVxdWVzdCBhIFdvcmtpbmcgR3JvdXAgc2Vz c2lvbiwgdXNlIHRoZSBJRVRGIE1lZXRpbmcgU2Vzc2lvbiBSZXF1ZXN0DQo+IFRvb2wuDQo+IC0g MjAxNC0wMS0xNyAoRnJpZGF5KTogQ3V0LW9mZiBkYXRlIGZvciByZXF1ZXN0cyB0byBzY2hlZHVs ZSBXb3JraW5nDQo+IEdyb3VwIG1lZXRpbmdzIGF0IFVUQyAyMzo1OS4gVG8gcmVxdWVzdCBhIFdv cmtpbmcgR3JvdXAgc2Vzc2lvbiwgdXNlIHRoZQ0KPiBJRVRGIE1lZXRpbmcgU2Vzc2lvbiBSZXF1 ZXN0IFRvb2wuDQo+IC0gMjAxNC0wMS0xNyAoRnJpZGF5KTogQ3V0LW9mZiBkYXRlIGZvciBCT0Yg cHJvcG9zYWwgcmVxdWVzdHMgdG8gQXJlYQ0KPiBEaXJlY3RvcnMgYXQgVVRDIDIzOjU5LiBUbyBy ZXF1ZXN0IGEgQk9GLCBwbGVhc2Ugc2VlIGluc3RydWN0aW9ucyBvbg0KPiBSZXF1ZXN0aW5nIGEg Qk9GLg0KPiAtIDIwMTQtMDEtMjQgKEZyaWRheSk6IEN1dC1vZmYgZGF0ZSBmb3IgQXJlYSBEaXJl Y3RvcnMgdG8gYXBwcm92ZSBCT0ZzDQo+IGF0IFVUQyAyMzo1OS4NCj4gLSAyMDE0LTAxLTMxIChG cmlkYXkpOiBQcmVsaW1pbmFyeSBhZ2VuZGEgcHVibGlzaGVkIGZvciBjb21tZW50Lg0KPiAtIDIw MTQtMDItMDMgKE1vbmRheSk6IEN1dC1vZmYgZGF0ZSBmb3IgcmVxdWVzdHMgdG8gcmVzY2hlZHVs ZSBXb3JraW5nDQo+IEdyb3VwIGFuZCBCT0YgbWVldGluZ3MgVVRDIDIzOjU5Lg0KPiAtIDIwMTQt MDItMDcgKEZyaWRheSk6IEZpbmFsIGFnZW5kYSB0byBiZSBwdWJsaXNoZWQuDQo+IC0gMjAxNC0w Mi0xNyAoTW9uZGF5KTogRHJhZnQgV29ya2luZyBHcm91cCBhZ2VuZGFzIGR1ZSBieSBVVEMgMjM6 NTksDQo+IHVwbG9hZCB1c2luZyBJRVRGIE1lZXRpbmcgTWF0ZXJpYWxzIE1hbmFnZW1lbnQgVG9v bC4NCj4gLSAyMDE0LTAyLTI0IChNb25kYXkpOiBSZXZpc2VkIFdvcmtpbmcgR3JvdXAgYWdlbmRh cyBkdWUgYnkgVVRDIDIzOjU5LA0KPiB1cGxvYWQgdXNpbmcgSUVURiBNZWV0aW5nIE1hdGVyaWFs cyBNYW5hZ2VtZW50IFRvb2wuDQo+IC0gMjAxNC0wMy0yOCAoRnJpZGF5KTogUHJvY2VlZGluZ3Mg c3VibWlzc2lvbiBjdXRvZmYgZGF0ZSBieSBVVEMgMjM6NTksDQo+IHVwbG9hZCB1c2luZyBJRVRG IE1lZXRpbmcgTWF0ZXJpYWxzIE1hbmFnZW1lbnQgVG9vbC4NCj4gLSAyMDE0LTA0LTE4IChGcmlk YXkpOiBQcm9jZWVkaW5ncyBzdWJtaXNzaW9uIGNvcnJlY3Rpb25zIGN1dG9mZiBkYXRlIGJ5DQo+ IFVUQyAyMzo1OSwgdXBsb2FkIHVzaW5nIElFVEYgTWVldGluZyBNYXRlcmlhbHMgTWFuYWdlbWVu dCBUb29sLg0KPiANCj4gU3VibWl0dGluZyBSZXF1ZXN0cyBmb3IgV29ya2luZyBHcm91cCBhbmQg Qk9GIFNlc3Npb25zDQo+IA0KPiBQbGVhc2Ugc3VibWl0IHJlcXVlc3RzIHRvIHNjaGVkdWxlIHlv dXIgV29ya2luZyBHcm91cCBzZXNzaW9ucyB1c2luZyB0aGUNCj4gIklFVEYgTWVldGluZyBTZXNz aW9uIFJlcXVlc3QgVG9vbCwiIGEgV2ViLWJhc2VkIHRvb2wgZm9yIHN1Ym1pdHRpbmcgYWxsDQo+ IG9mIHRoZSBpbmZvcm1hdGlvbiB0aGF0IHRoZSBTZWNyZXRhcmlhdCByZXF1aXJlcyB0byBzY2hl ZHVsZSB5b3VyDQo+IHNlc3Npb25zLg0KPiANCj4gVGhlIFVSTCBmb3IgdGhlIHRvb2wgaXM6DQo+ IA0KPiBodHRwczovL3B1Yi5pZXRmLm9yZy9zcmVxLw0KPiANCj4gUGxlYXNlIHNlbmQgcmVxdWVz dHMgdG8gc2NoZWR1bGUgeW91ciBCT0Ygc2Vzc2lvbnMgdG8gYWdlbmRhQGlldGYub3JnLg0KPiBQ bGVhc2UgaW5jbHVkZSB0aGUgYWNyb255bSBvZiB5b3VyIEJPRiBpbiB0aGUgc3ViamVjdCBsaW5l IG9mIHRoZQ0KPiBtZXNzYWdlLCBhbmQgaW5jbHVkZSBhbGwgb2YgdGhlIGluZm9ybWF0aW9uIHNw ZWNpZmllZCBpbiBpdGVtICg0KSBvZg0KPiAiUmVxdWVzdGluZyBNZWV0aW5nIFNlc3Npb25zIGF0 IElFVEYgTWVldGluZ3MiIGluIHRoZSBib2R5LiAgKFRoaXMNCj4gZG9jdW1lbnQgaXMgaW5jbHVk ZWQgYmVsb3cuKQ0KPiANCj4gU3VibWl0dGluZyBTZXNzaW9uIEFnZW5kYXMNCj4gDQo+IEZvciB0 aGUgY29udmVuaWVuY2Ugb2YgbWVldGluZyBhdHRlbmRlZXMsIHdlIGFzayB0aGF0IHlvdSBzdWJt aXQgdGhlDQo+IGFnZW5kYXMgZm9yIHlvdXIgV29ya2luZyBHcm91cCBzZXNzaW9ucyBhcyBlYXJs eSBhcyBwb3NzaWJsZS4gIERyYWZ0DQo+IFdvcmtpbmcgR3JvdXAgYWdlbmRhcyBhcmUgZHVlIE1v bmRheSwgRmVicnVhcnkgMTd0aCwgMjAxNCBhdCBVVEMgMjM6NTkuDQo+IFJldmlzZWQgV29ya2lu ZyBHcm91cCBhZ2VuZGFzIGFyZSBkdWUgbm8gbGF0ZXIgdGhhbiBNb25kYXksIEZlYnJ1YXJ5DQo+ IDI0dGgsIDIwMTQgYXQgVVRDIDIzOjU5LiAgVGhlIHByb3Bvc2VkIGFnZW5kYSBmb3IgYSBCT0Yg c2Vzc2lvbiBzaG91bGQNCj4gYmUgc3VibWl0dGVkIGFsb25nIHdpdGggeW91ciByZXF1ZXN0IGZv ciBhIHNlc3Npb24uICBQbGVhc2UgYmUgc3VyZSB0bw0KPiBjb3B5IHlvdXIgQXJlYSBEaXJlY3Rv ciBvbiB0aGF0IG1lc3NhZ2UuDQo+IA0KPiBQbGVhc2Ugc3VibWl0IHRoZSBhZ2VuZGFzIGZvciB5 b3VyIFdvcmtpbmcgR3JvdXAgc2Vzc2lvbnMgdXNpbmcgdGhlDQo+ICJJRVRGIE1lZXRpbmcgTWF0 ZXJpYWxzIE1hbmFnZW1lbnQgVG9vbCwiIGEgV2ViLWJhc2VkIHRvb2wgZm9yIG1ha2luZw0KPiB5 b3VyIG1lZXRpbmcgYWdlbmRhLCBtaW51dGVzLCBhbmQgcHJlc2VudGF0aW9uIHNsaWRlcyBhdmFp bGFibGUgdG8gdGhlDQo+IGNvbW11bml0eSBiZWZvcmUsIGR1cmluZywgYW5kIGFmdGVyIGFuIElF VEYgbWVldGluZy4gIElmIHlvdSBhcmUgYSBCT0YNCj4gY2hhaXIsIHRoZW4geW91IG1heSB1c2Ug dGhlIHRvb2wgdG8gc3VibWl0IGEgcmV2aXNlZCBhZ2VuZGEgYXMgd2VsbCBhcw0KPiBvdGhlciBt YXRlcmlhbHMgZm9yIHlvdXIgQk9GIG9uY2UgdGhlIEJPRiBoYXMgYmVlbiBhcHByb3ZlZC4NCj4g DQo+IFRoZSBVUkwgZm9yIHRoZSB0b29sIGlzOg0KPiANCj4gaHR0cHM6Ly9wdWIuaWV0Zi5vcmcv cHJvY2VlZGluZ3MvDQo+IA0KPiBBZGRpdGlvbmFsIGluZm9ybWF0aW9uIGFib3V0IHRoaXMgdG9v bCBpcyBhdmFpbGFibGUgYXQ6DQo+IA0KPiBodHRwOi8vd3d3LmlldGYub3JnL2luc3RydWN0aW9u cy9tZWV0aW5nX21hdGVyaWFsc190b29sLmh0bWwNCj4gDQo+IEFnZW5kYXMgc3VibWl0dGVkIHZp YSB0aGUgdG9vbCB3aWxsIGJlIGF2YWlsYWJsZSB0byB0aGUgcHVibGljIG9uIHRoZQ0KPiAiSUVU RiBNZWV0aW5nIE1hdGVyaWFscyIgd2VicGFnZSBhcyBzb29uIGFzIHRoZXkgYXJlIHN1Ym1pdHRl ZC4NCj4gDQo+IFRoZSBVUkwgZm9yIHRoZSAiSUVURiA4OSBNZWV0aW5nIE1hdGVyaWFscyIgV2Vi IHBhZ2UgaXM6DQo+IA0KPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcvODkv bWF0ZXJpYWxzLmh0bWwNCj4gDQo+IElmIHlvdSBhcmUgYSBXb3JraW5nIEdyb3VwIGNoYWlyLCB0 aGVuIHlvdSBhbHJlYWR5IGhhdmUgYWNjb3VudHMgb24gdGhlDQo+ICJJRVRGIE1lZXRpbmcgU2Vz c2lvbiBSZXF1ZXN0IFRvb2wiIGFuZCB0aGUgIklFVEYgTWVldGluZyBNYXRlcmlhbHMNCj4gTWFu YWdlbWVudCBUb29sLiIgIFRoZSBzYW1lIFVzZXIgSUQgYW5kIHBhc3N3b3JkIHdpbGwgd29yayBm b3IgYm90aA0KPiB0b29scy4gIElmIHlvdSBhcmUgYSBCT0YgY2hhaXIgd2hvIGlzIG5vdCBhbHNv IGEgV29ya2luZyBHcm91cCBjaGFpciwNCj4gdGhlbiB5b3Ugd2lsbCBiZSBnaXZlbiBhbiBhY2Nv dW50IG9uIHRoZSAiSUVURiBNZWV0aW5nIE1hdGVyaWFscw0KPiBNYW5hZ2VtZW50IFRvb2wiIHdo ZW4geW91ciBCT0YgaGFzIGJlZW4gYXBwcm92ZWQuICBJZiB5b3UgcmVxdWlyZQ0KPiBhc3Npc3Rh bmNlIGluIHVzaW5nIGVpdGhlciB0b29sLCBvciB3aXNoIHRvIHJlcG9ydCBhIGJ1ZywgdGhlbiBw bGVhc2UNCj4gc2VuZCBhIG1lc3NhZ2UgdG86DQo+IGlldGYtYWN0aW9uQGlldGYub3JnLg0KPiA9 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT0NCj4gRm9yIHlvdXIgY29udmVuaWVuY2UsIGNvbXByZWhlbnNpdmUgaW5mb3JtYXRpb24g b24gcmVxdWVzdGluZyBtZWV0aW5nDQo+IHNlc3Npb25zIGZvciBJRVRGIDg5IGlzIGJlbG93Og0K PiANCj4gMS4gUmVxdWVzdHMgdG8gc2NoZWR1bGUgV29ya2luZyBHcm91cCBzZXNzaW9ucyBzaG91 bGQgYmUgc3VibWl0dGVkIHVzaW5nDQo+IHRoZSAiSUVURiBNZWV0aW5nIFNlc3Npb24gUmVxdWVz dCBUb29sLCIgYSBXZWItYmFzZWQgdG9vbCBmb3Igc3VibWl0dGluZw0KPiBhbGwgb2YgdGhlIGlu Zm9ybWF0aW9uIHJlcXVpcmVkIGJ5IHRoZSBTZWNyZXRhcmlhdCB0byBzY2hlZHVsZSB5b3VyDQo+ IHNlc3Npb25zLiAgVGhlIFVSTCBmb3IgdGhlIHRvb2wgaXM6DQo+IA0KPiBodHRwczovL3B1Yi5p ZXRmLm9yZy9zcmVxLw0KPiANCj4gSW5zdHJ1Y3Rpb25zIGZvciB1c2luZyB0aGUgdG9vbCBhcmUg YXZhaWxhYmxlIGF0Og0KPiANCj4gaHR0cDovL3d3dy5pZXRmLm9yZy9pbnN0cnVjdGlvbnMvc2Vz c2lvbl9yZXF1ZXN0X3Rvb2xfaW5zdHJ1Y3Rpb24uaHRtbA0KPiANCj4gSWYgeW91IHJlcXVpcmUg YW4gYWNjb3VudCBvbiB0aGlzIHRvb2wsIG9yIGFzc2lzdGFuY2UgaW4gdXNpbmcgaXQsIHRoZW4N Cj4gcGxlYXNlIHNlbmQgYSBtZXNzYWdlIHRvIGlldGYtYWN0aW9uQGlldGYub3JnLiAgSWYgeW91 IGFyZSB1bmFibGUgdG8gdXNlDQo+IHRoZSB0b29sLCB0aGVuIHlvdSBtYXkgc2VuZCB5b3VyIHJl cXVlc3QgdmlhIGUtbWFpbCB0byBhZ2VuZGFAaWV0Zi5vcmcsDQo+IHdpdGggYSBjb3B5IHRvIHRo ZSBhcHByb3ByaWF0ZSBBcmVhIERpcmVjdG9yKHMpLg0KPiANCj4gUmVxdWVzdHMgdG8gc2NoZWR1 bGUgQk9GIHNlc3Npb25zIG11c3QgYmUgc2VudCB0byBhZ2VuZGFAaWV0Zi5vcmcgd2l0aCBhDQo+ IGNvcHkgdG8gdGhlIGFwcHJvcHJpYXRlIEFyZWEgRGlyZWN0b3IocykuDQo+IA0KPiBXaGVuIHN1 Ym1pdHRpbmcgYSBXb3JraW5nIEdyb3VwIG9yIEJPRiBzZXNzaW9uIHJlcXVlc3QgYnkgZS1tYWls LCBwbGVhc2UNCj4gaW5jbHVkZSB0aGUgV29ya2luZyBHcm91cCBvciBCT0YgYWNyb255bSBpbiB0 aGUgU3ViamVjdCBsaW5lLg0KPiANCj4gMi4gQk9GcyB3aWxsIE5PVCBiZSBzY2hlZHVsZWQgdW5s ZXNzIHRoZSBBcmVhIERpcmVjdG9yIGFwcHJvdmVzIHRoZSBCT0YuDQo+IFRoZSBwcm9wb25lbnRz IGJlaGluZCBhIEJPRiBuZWVkIHRvIGNvbnRhY3QgYSByZWxldmFudCBBcmVhIERpcmVjdG9yLA0K PiBwcmVmZXJhYmx5IHdlbGwgaW4gYWR2YW5jZSBvZiB0aGUgQk9GIGFwcHJvdmFsIGRlYWRsaW5l IGRhdGUuIFRoZSBBRA0KPiBuZWVkcyB0byBoYXZlIHRoZSBmdWxsIG5hbWUgb2YgdGhlIEJPRiwg aXRzIGFjcm9ueW0sIHN1Z2dlc3RlZCBuYW1lcyBvZg0KPiBjaGFpcnMsIGFuIGFnZW5kYSwgZnVs bCBkZXNjcmlwdGlvbiBvZiB0aGUgQk9GIGFuZCB0aGUgaW5mb3JtYXRpb24NCj4gY292ZXJlZCBp biBpdGVtIDQuIFBsZWFzZSByZWFkIFJGQyA1NDM0IGZvciBpbnN0cnVjdGlvbnMgb24gaG93IHRv IGRyaXZlDQo+IGEgc3VjY2Vzc2Z1bCBCT0YgZWZmb3J0LiBUaGUgYXBwcm92YWwgZGVwZW5kcyBv biwgZm9yIGluc3RhbmNlLA0KPiBJbnRlcm5ldC1EcmFmdHMgYW5kIGxpc3QgZGlzY3Vzc2lvbiBv biB0aGUgc3VnZ2VzdGVkIHRvcGljLiBCT0YgYWdlbmRhDQo+IHJlcXVlc3RzLCBpZiBhcHByb3Zl ZCwgd2lsbCBiZSBzdWJtaXR0ZWQgdG8gdGhlIElFVEYgU2VjcmV0YXJpYXQgYnkgdGhlDQo+IEFE cy4NCj4gDQo+IDMuIEEgV29ya2luZyBHcm91cCBtYXkgcmVxdWVzdCBlaXRoZXIgb25lIG9yIHR3 byBzZXNzaW9ucy4gIElmIHlvdXINCj4gV29ya2luZyBHcm91cCByZXF1aXJlcyBtb3JlIHRoYW4g dHdvIHNlc3Npb25zLCB0aGVuIHlvdXIgcmVxdWVzdCBtdXN0IGJlDQo+IGFwcHJvdmVkIGJ5IGFu IEFyZWEgRGlyZWN0b3IuICBBZGRpdGlvbmFsIHNlc3Npb25zIHdpbGwgYmUgYXNzaWduZWQsDQo+ IGJhc2VkIG9uIGF2YWlsYWJpbGl0eSwgYWZ0ZXIgTW9uZGF5LCBGZWJydWFyeSAzcmQsIDIwMTQs IHRoZSBjdXQtb2ZmDQo+IGRhdGUgZm9yIHJlcXVlc3RzIHRvIHJlc2NoZWR1bGUgYSBzZXNzaW9u Lg0KPiANCj4gNC4gWW91IE1VU1QgcHJvdmlkZSB0aGUgZm9sbG93aW5nIGluZm9ybWF0aW9uIGJl Zm9yZSBhIFdvcmtpbmcgR3JvdXAgb3INCj4gQk9GIHNlc3Npb24gd2lsbCBiZSBzY2hlZHVsZWQ6 DQo+IA0KPiAgICAgYS4gV29ya2luZyBHcm91cCBvciBCT0YgZnVsbCBuYW1lIHdpdGggYWNyb255 bSBpbiBicmFja2V0czoNCj4gDQo+ICAgICBiLiBBUkVBIHVuZGVyIHdoaWNoIFdvcmtpbmcgR3Jv dXAgb3IgQk9GIGFwcGVhcnM6DQo+IA0KPiAgICAgYy4gQ09ORkxJQ1RTIHlvdSB3aXNoIHRvIGF2 b2lkLCBwbGVhc2UgYmUgYXMgc3BlY2lmaWMgYXMgcG9zc2libGU6DQo+IA0KPiAgICAgZC4gRXhw ZWN0ZWQgQXR0ZW5kYW5jZToNCj4gDQo+ICAgICBlLiBTcGVjaWFsIHJlcXVlc3RzOg0KPiANCj4g ICAgIGYuIE51bWJlciBvZiBzZXNzaW9uczoNCj4gDQo+ICAgICBnLiBMZW5ndGggb2Ygc2Vzc2lv bjoNCj4gICAgICAgIC0gMSBob3VyDQo+ICAgICAgICAtIDEgMS8yIGhvdXJzDQo+ICAgICAgICAt IDIgaG91cnMNCj4gICAgICAgIC0gMiAxLzIgaG91cnMNCj4gDQo+IEZvciBtb3JlIGluZm9ybWF0 aW9uIG9uIHNjaGVkdWxpbmcgV29ya2luZyBHcm91cCBhbmQgQk9GIHNlc3Npb25zLA0KPiBwbGVh c2UgcmVmZXIgdG8gUkZDIDI0MTggKEJDUCAyNSksICJJRVRGIFdvcmtpbmcgR3JvdXAgR3VpZGVs aW5lcyBhbmQNCj4gUHJvY2VkdXJlcyIgKGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjL3JmYzI0MTgu dHh0KS4NCj4gPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09DQo+IEZvciB5b3VyIGNvbnZlbmllbmNlIHBsZWFzZSBmaW5kIGhlcmUg YSBsaXN0IG9mIHRoZSBJRVRGIEFyZWEgRGlyZWN0b3JzDQo+IHdpdGggdGhlaXIgZS1tYWlsIGFk ZHJlc3NlczoNCj4gDQo+IElFVEYgQ2hhaXINCj4gSmFyaSBBcmtrbyA8amFyaS5hcmtrb0BwaXVo YS5uZXQ+DQo+IA0KPiBBcHBsaWNhdGlvbnMgQXJlYSAoYXBwKQ0KPiBCYXJyeSBMZWliYSA8YmFy cnlsZWliYUBjb21wdXRlci5vcmc+DQo+IFBldGUgUmVzbmljayA8cHJlc25pY2tAcXVhbGNvbW0u Y29tPg0KPiANCj4gSW50ZXJuZXQgQXJlYSAoaW50KQ0KPiBCcmlhbiBIYWJlcm1hbiA8YnJpYW5A aW5ub3ZhdGlvbnNsYWIubmV0PiBUZWQgTGVtb24NCj4gPHRlZC5sZW1vbkBub21pbnVtLmNvbT4N Cj4gDQo+IE9wZXJhdGlvbnMgJiBNYW5hZ2VtZW50IEFyZWEgKG9wcykNCj4gQmVub2l0IENsYWlz ZSA8YmNsYWlzZUBjaXNjby5jb20+DQo+IEpvZWwgSmFlZ2dsaSA8am9lbGphQGJvZ3VzLmNvbT4N Cj4gDQo+IFJlYWwtdGltZSBBcHBsaWNhdGlvbnMgYW5kIEluZnJhc3RydWN0dXJlIEFyZWEgKHJh aSkgR29uemFsbyBDYW1hcmlsbG8NCj4gPGdvbnphbG8uY2FtYXJpbGxvQGVyaWNzc29uLmNvbT4g UmljaGFyZCBCYXJuZXMgPHJsYkBpcHYuc3g+DQo+IA0KPiBSb3V0aW5nIEFyZWEgKHJ0ZykNCj4g U3Rld2FydCBCcnlhbnQgPHN0YnJ5YW50QGNpc2NvLmNvbT4NCj4gQWRyaWFuIEZhcnJlbCA8YWRy aWFuQG9sZGRvZy5jby51az4NCj4gDQo+IFNlY3VyaXR5IEFyZWEgKHNlYykNCj4gU3RlcGhlbiBG YXJyZWxsIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPiBTZWFuIFR1cm5lcg0KPiA8dHVybmVy c0BpZWNhLmNvbT4NCj4gDQo+IFRyYW5zcG9ydCBBcmVhICh0c3YpDQo+IE1hcnRpbiBTdGllbWVy bGluZyA8bWFydGluLnN0aWVtZXJsaW5nQG5lY2xhYi5ldT4gU3BlbmNlciBEYXdraW5zDQo+IDxz cGVuY2VyZGF3a2lucy5pZXRmQGdtYWlsLmNvbT4NCj4gPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCj4gODh0aCBJRVRGIE1lZXRpbmcg QXR0ZW5kYW5jZSBOdW1iZXJzDQo+IA0KPiA2bG8gLSA1Mg0KPiA2bWFuIC0gMTQzDQo+IDZ0aXNj aCAtIDQ1DQo+IGFiZmFiIC0gMjANCj4gYWx0byAgLSAzNQ0KPiBhcHBzYXdnL2FwcGFyZWEgLSAx MzgNCj4gYXFtIC0gMTA4DQo+IGFxbSAoMm5kIHNlc3Npb24pIC0gNDUNCj4gYXZ0Y29yZSAtIDUx DQo+IGF2dGV4dCDigJMgNTkNCj4gYmZkIC0gMTcNCj4gYm13ZyAtIDE5DQo+IGNjYW1wIC0gNDkN Cj4gY2NhbXAgKDJuZCBzZXNzaW9uKSAtIDQ0DQo+IGNkbmkgLSAzOQ0KPiBjbHVlIC0gNDENCj4g Y2x1ZSAoMm5kIHNlc3Npb24pIC0gMzINCj4gY29yZSAtIDYyDQo+IGNvcmUgKDJuZCBzZXNzaW9u KSAtIDUwDQo+IGRoYyAtIDU5DQo+IGRpY2UgLSA2NQ0KPiBkaW1lIC0gMjMNCj4gZGlzcGF0Y2gg LSA1NQ0KPiBkbW0gLSAzNw0KPiBkbnNvcCAtIDEyNQ0KPiBkbnNzZCAtIDEwOA0KPiBlY3JpdCAt IDMxDQo+IGVtYW4gLSAxOQ0KPiBmb3JjZXMgLSA0MA0KPiBnZW9uZXQgKEJvRikgLSA5OQ0KPiBn ZW9wcml2IC0gNDENCj4gaG9tZW5ldCAtIDE1Ng0KPiBodHRwYXV0aCAtIDQzDQo+IGh0dHBiaXMg LSA4OQ0KPiBodHRwYmlzICgybmQgc2Vzc2lvbikgLSAxMjcNCj4gaTJycyAtIDIyMw0KPiBpY2Ny ZyAoUkcpIC0gNjgNCj4gaWNucmcgKFJHKSAtIDQzDQo+IGlkciAtIDkwDQo+IGlnb3Z1cGRhdGUg Qm9GIC0gMjIwDQo+IGluc2lwaWQgLSAzMg0KPiBpbnRhcmVhIChBRykgLSA5OA0KPiBpcGZpeCAt IDIzDQo+IGlwcG0gLSA0OA0KPiBpcHNlY21lIC0gMjcNCj4gSVJURiBPcGVuIE1lZXRpbmcgLSAx MDANCj4gaXNpcyAtIDU4DQo+IGpvc2UgLSA0Mg0KPiBqc29uIC0gNDkNCj4ga2FycCAtIDIyDQo+ IGtpdHRlbiAtIDIzDQo+IGwydnBuIC0gNzENCj4gbDN2cG4gLSA2NQ0KPiBsaXNwIC0gNTYNCj4g bG1hcCAtIDUyDQo+IGx3aWcgLSAzNQ0KPiBtYW5ldCAtIDM1DQo+IG1ib25lZCAtIDI1DQo+IG1p ZiAtIDQxDQo+IG1tdXNpYyAtIDY5DQo+IG1tdXNpYyAoMm5kIHNlc3Npb24pIC0gNTMNCj4gbXBs cyAtIDcxDQo+IG1wbHMgKDJuZCBzZXNzaW9uKSAtIDcyDQo+IG1wdGNwIC0gNDUNCj4gbXB0Y3Ag KDJuZCBzZXNzaW9uKSAtIDcwDQo+IG5jcmcgKFJHKSAtIDMzDQo+IG5ldGNvbmYgLSA2Mg0KPiBu ZXRleHQgLSAyNw0KPiBuZXRtb2QgLSA2OQ0KPiBuZnN2NCAtIDE2DQo+IG5tcmcgKFJHKSAtIDM1 DQo+IG5tcmcgKFJHKSAoMm5kIHNlc3Npb24pIC0gMTcNCj4gbnRwIChjb21iaW5lZCB3aXRoIHRp Y3RvYykgLSAzMg0KPiBudm8zIC0gMTkzDQo+IG53Y3JnIChQUkcpIC0gMjUNCj4gb2F1dGggLSAz OA0KPiBvcHNhd2cvb3BzYXJlYSAtIDY4DQo+IG9wc2VjIC0gNDgNCj4gb3NwZiAtIDM4DQo+IHBh d3MgLSAxNw0KPiBwY2UgLSA3Mg0KPiBwY3AgLSAzMA0KPiBwZXJwYXNzIChCb0YpIC0gMzEzDQo+ IHBpbSAtIDI0DQo+IHBwc3AgLSAxMg0KPiBwcmVjaXMgLSAzMg0KPiBwd2UzIC0gNDANCj4gcmFk ZXh0IC0gMjANCj4gcmZjZm9ybSAoQm9GKSAtIDUyDQo+IHJtY2F0IC0gNjANCj4gcnRjd2ViIC0g MTc0DQo+IHJ0Y3dlYiAoMm5kIHNlc3Npb24pIC0gMTg4DQo+IHJ0Z2FyZWEgKEFHKSAtIDEwMQ0K PiBydGd3ZyAtIDExOA0KPiBzYWFnIChBRykgLSAxNDgNCj4gc2FjbSAtIDQwDQo+IHNjaW0gLSAz Mg0KPiBzZG5yZyAoUkcpIC0gMjU5DQo+IHNpZHIgLSA2MQ0KPiBzaXByZWMgLSAzMQ0KPiBzb2Z0 d2lyZSAtIDUyDQo+IHNwcmluZyAtIDE1OA0KPiBzdGlyIC0gODINCj4gc3RpciAoMm5kIHNlc3Np b24pIC0gNzkNCj4gc3Rvcm0gLSAyMQ0KPiB0Y3BtIC0gMzYNCj4gdGljdG9jIChjb21iaW5lZCB3 aXRoIG50cCkgLSAzMg0KPiB0bHMgLSAxMTENCj4gdHJpbGwgLSAzMw0KPiB0c3ZhcmVhIChBRykg LSAxNTMNCj4gdHN2d2cgLSA2Mw0KPiB0c3Z3ZyAoMm5kIHNlc3Npb24pIC0gNDcNCj4gdjZvcHMg LSAxMzUNCj4gdjZvcHMgKDJuZCBzZXNzaW9uKSAtIDkyDQo+IHdlaXJkcyAtIDU1DQo+IHdwa29w cyAtIDM0DQo+IHhtcHAgLSAzMQ0KPiB4cmJsb2NrIC0gMjQNCg== From Michael.K.Bugenhagen@centurylink.com Tue Dec 10 14:17:15 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 932E11AE17C for ; Tue, 10 Dec 2013 14:17:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e0hp4bpnu9nE for ; Tue, 10 Dec 2013 14:17:13 -0800 (PST) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by ietfa.amsl.com (Postfix) with ESMTP id 8496D1AE104 for ; Tue, 10 Dec 2013 14:17:13 -0800 (PST) Received: from lxomavmpc030.qintra.com (emailout.qintra.com [151.117.207.30]) by sudnp799.qwest.com (8.14.4/8.14.4) with ESMTP id rBAMH5eb029723 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Dec 2013 15:17:06 -0700 (MST) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 80B141E0073; Tue, 10 Dec 2013 16:17:00 -0600 (CST) Received: from suomp61i.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id 656601E0067; Tue, 10 Dec 2013 16:17:00 -0600 (CST) Received: from suomp61i.qintra.com (localhost [127.0.0.1]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id rBAMH0Kc010406; Tue, 10 Dec 2013 16:17:00 -0600 (CST) Received: from vodcwhubex502.ctl.intranet (vodcwhubex502.ctl.intranet [151.117.206.28]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id rBAMGxYm010393 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 10 Dec 2013 16:16:59 -0600 (CST) Received: from PODCWMBXEX505.ctl.intranet ([fe80::f87e:fe44:ad72:b610]) by vodcwhubex502.ctl.intranet ([2002:9775:ce1c::9775:ce1c]) with mapi id 14.03.0158.001; Tue, 10 Dec 2013 16:16:59 -0600 From: "Bugenhagen, Michael K" To: "'STARK, BARBARA H'" , "'lmap@ietf.org'" Thread-Topic: degrees of Measurement Suppression Thread-Index: Ac7fxy6a9B101VqJQi6oteMX5LjSDgWLXOxQ Date: Tue, 10 Dec 2013 22:16:58 +0000 Message-ID: References: <2D09D61DDFA73D4C884805CC7865E611303993CD@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E611303993CD@GAALPA1MSGUSR9L.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.7] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [lmap] degrees of Measurement Suppression X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 22:17:15 -0000 I concur with Barbara - Stated a bit differently - If LMAP says put this probe on everything (Par= t of the introduction statement)... Then=20 1) They will want a suppression method that allows them to disable it in c= ase of national emergency - saving lives via emergency communication takes = priority in their minds. So they typically will ask for 2 each Safety breaks. 1 from the controller A second from a element controller or whatever configures the element in = the first place. =20 These "MA unavailable" states should also be recorded for transparency s= ake. 2) Op's folks like to test - even when things are going bad.. otherwise fa= ult isolation is hard to do. So suppression should have 3 levels (again this goes back to everyone has = a probe) - Green =3D do as you will (test anything) Yellow - don't load anything - restrict testing that will load the network= , or kick up CPU cycles ...but allow fault testing (NO Saturation tests, ..= ..)( RED - Stop, don't pass go, ... ADHOC testing only If USE case 1 is the ISP - not adopting those types of Op's requirements wo= uld get a significant amount of pushback on the implementation side. Regards, Mike -----Original Message----- From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of STA= RK, BARBARA H Sent: Tuesday, November 12, 2013 10:50 AM To: lmap@ietf.org Subject: [lmap] degrees of Measurement Suppression A number of providers have discussed a model of Measurement Suppression tha= t supports more granular degrees of suppression (other than just suppress a= nd don't suppress). Michael Bugenhagen presented the original version of th= is model, and he said it would be ok if I brought it up to IETF. Following are highlights of the proposal (with some modifications I've incl= uded as a result of additional discussion): 1. Measurement Methods (or perhaps Tasks) have a configurable parameter tha= t indicates whether the Controller operator considers them to be "critical = for OAM", "not critical, but not resource intensive", and "not critical and= resource intensive". 2. The Controller can specify degrees of Measurement Suppression, which sho= uld include: halt all non-critical tasks immediately but allow OAM tasks; h= alt resource-intensive tasks immediately but allow non-resource-intensive t= asks; finish resource intensive tasks but do not start new resource-intensi= ve tasks and allow all non-resource-intensive tasks; allow all tasks. 3. It may also be possible for the unspecified bootstrap mechanism to instr= uct the MA to suppress measurements. Where multiple channels exist for Meas= urement Suppression (e.g., Controller and bootstrap), the MA is to use the = most restrictive setting. Barbara _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap From steve@idrathernotsay.com Tue Dec 10 14:40:01 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABE341AE23D for ; Tue, 10 Dec 2013 14:40:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kj4xi94z8r9f for ; Tue, 10 Dec 2013 14:39:59 -0800 (PST) Received: from colo3.idrathernotsay.com (colo3.idrathernotsay.com [74.207.251.199]) by ietfa.amsl.com (Postfix) with ESMTP id 541301AE071 for ; Tue, 10 Dec 2013 14:39:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by colo3.idrathernotsay.com (Postfix) with ESMTP id 1B111FC59; Tue, 10 Dec 2013 22:39:54 +0000 (UTC) X-Virus-Scanned: amavisd-new at idrathernotsay.com Received: from colo3.idrathernotsay.com ([127.0.0.1]) by localhost (colo3.idrathernotsay.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ec8EtX86WZM8; Tue, 10 Dec 2013 22:39:49 +0000 (UTC) Received: from newbie.idrathernotsay.com (pool-173-79-225-215.washdc.fios.verizon.net [173.79.225.215]) by colo3.idrathernotsay.com (Postfix) with ESMTPSA id 89D87FC1A; Tue, 10 Dec 2013 22:39:49 +0000 (UTC) Received: from newbie.idrathernotsay.com (localhost [127.0.0.1]) by newbie.idrathernotsay.com (Postfix) with ESMTP id A60D44FCAC4; Tue, 10 Dec 2013 17:39:48 -0500 (EST) X-Virus-Scanned: amavisd-new at idrathernotsay.com Received: from newbie.idrathernotsay.com ([127.0.0.1]) by newbie.idrathernotsay.com (newbie.idrathernotsay.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WXuWfoJR6C-Z; Tue, 10 Dec 2013 17:39:47 -0500 (EST) Received: by newbie.idrathernotsay.com (Postfix, from userid 1000) id AFCC74FCAC9; Tue, 10 Dec 2013 17:39:47 -0500 (EST) Date: Tue, 10 Dec 2013 17:39:47 -0500 From: Steve Miller To: "Bugenhagen, Michael K" Message-ID: <20131210223947.GD39105@idrathernotsay.com> References: <2D09D61DDFA73D4C884805CC7865E611303993CD@GAALPA1MSGUSR9L.ITServices.sbc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "'STARK, BARBARA H'" , "'lmap@ietf.org'" Subject: Re: [lmap] degrees of Measurement Suppression X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 22:40:01 -0000 If we are testing at a rate where leaving the tests running during a national emergency will make a meaningful difference as to whether or not lives are saved, we shouldn't be testing at that rate even during normal operation. Relying on the ability to turn anything off -- in an active manner at least -- during an emergency seems like something we should avoid: I'd think that anyone who's experienced making a phone call just after a natural disaster would be able to testify as to the flakiness of any communications medium under those circumstances. A key (and maybe *the* key) element here is that in many cases the time you must want to hit the big red off switch is the time at which you are least able to communicate with the MAs. The other autoshutdown stuff that's been discussed so far would give people the flexibility to implement the only policy that truly seems important: the one that disables measurements after N seconds/minutes/hours/days in which the MA can't reach the controller. It's been my experience that no matter how important that seems on paper, it ends up being much, much less critical than it seems in the Real World. Still, leaving this binary on/off level of control in place makes some sense: it's easy to code, it's pretty innocuous, the additional load on the controller infrastructure shouldn't be that bad, and it avoids the "three million old devices hammering some poor destination that belongs to the people who bought some defunct ISP" problem. It's also been my experience that even that level of control isn't needed and can in fact cause problems of its own, but I recognize that this scenario is a little different. I still think we should not overcomplicate things. -Steve (who still needs to read the updated I-Ds, hopefully early next week, sorry) On Tue, Dec 10, 2013 at 10:16:58PM +0000, Bugenhagen, Michael K wrote: > I concur with Barbara - > > Stated a bit differently - If LMAP says put this probe on everything (Part of the introduction statement)... > > Then > > 1) They will want a suppression method that allows them to disable it in case of national emergency - saving lives via emergency communication takes priority in their minds. > So they typically will ask for 2 each Safety breaks. > 1 from the controller > A second from a element controller or whatever configures the element in the first place. > > These "MA unavailable" states should also be recorded for transparency sake. > > > 2) Op's folks like to test - even when things are going bad.. otherwise fault isolation is hard to do. > > So suppression should have 3 levels (again this goes back to everyone has a probe) - > Green = do as you will (test anything) > Yellow - don't load anything - restrict testing that will load the network, or kick up CPU cycles ...but allow fault testing (NO Saturation tests, ....)( > RED - Stop, don't pass go, ... ADHOC testing only > > > If USE case 1 is the ISP - not adopting those types of Op's requirements would get a significant amount of pushback on the implementation side. > > Regards, > Mike > > > > > -----Original Message----- > From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of STARK, BARBARA H > Sent: Tuesday, November 12, 2013 10:50 AM > To: lmap@ietf.org > Subject: [lmap] degrees of Measurement Suppression > > A number of providers have discussed a model of Measurement Suppression that supports more granular degrees of suppression (other than just suppress and don't suppress). Michael Bugenhagen presented the original version of this model, and he said it would be ok if I brought it up to IETF. > > Following are highlights of the proposal (with some modifications I've included as a result of additional discussion): > > 1. Measurement Methods (or perhaps Tasks) have a configurable parameter that indicates whether the Controller operator considers them to be "critical for OAM", "not critical, but not resource intensive", and "not critical and resource intensive". > > 2. The Controller can specify degrees of Measurement Suppression, which should include: halt all non-critical tasks immediately but allow OAM tasks; halt resource-intensive tasks immediately but allow non-resource-intensive tasks; finish resource intensive tasks but do not start new resource-intensive tasks and allow all non-resource-intensive tasks; allow all tasks. > > 3. It may also be possible for the unspecified bootstrap mechanism to instruct the MA to suppress measurements. Where multiple channels exist for Measurement Suppression (e.g., Controller and bootstrap), the MA is to use the most restrictive setting. > > Barbara > > > _______________________________________________ > 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 From charles.cook2@centurylink.com Tue Dec 10 15:24:28 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4E361ADEA6 for ; Tue, 10 Dec 2013 15:24:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZTUMwNuG4oVE for ; Tue, 10 Dec 2013 15:24:26 -0800 (PST) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by ietfa.amsl.com (Postfix) with ESMTP id F40361AE147 for ; Tue, 10 Dec 2013 15:24:25 -0800 (PST) Received: from lxdenvmpc030.qintra.com (emailout.qintra.com [10.1.51.30]) by sudnp799.qwest.com (8.14.4/8.14.4) with ESMTP id rBANOGNH017190 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Dec 2013 16:24:16 -0700 (MST) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 459E21E0049; Tue, 10 Dec 2013 16:24:11 -0700 (MST) Received: from suomp61i.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id 1C9951E0070; Tue, 10 Dec 2013 16:24:11 -0700 (MST) Received: from suomp61i.qintra.com (localhost [127.0.0.1]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id rBANOAF2020620; Tue, 10 Dec 2013 17:24:10 -0600 (CST) Received: from [10.188.230.23] (x1069818.dhcp.intranet [10.188.230.23]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id rBANO9Ni020608; Tue, 10 Dec 2013 17:24:09 -0600 (CST) Message-ID: <52A7A298.7000900@centurylink.com> Date: Tue, 10 Dec 2013 16:24:08 -0700 From: Charles Cook User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121005 Thunderbird/16.0 MIME-Version: 1.0 To: Steve Miller References: <2D09D61DDFA73D4C884805CC7865E611303993CD@GAALPA1MSGUSR9L.ITServices.sbc.com> <20131210223947.GD39105@idrathernotsay.com> In-Reply-To: <20131210223947.GD39105@idrathernotsay.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-CFilter-Loop: Reflected Cc: "'lmap@ietf.org'" , "Bugenhagen, Michael K" , "'STARK, BARBARA H'" Subject: Re: [lmap] degrees of Measurement Suppression X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: charles.cook2@centurylink.com List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 23:24:29 -0000 Just some thoughts... I just finished reading the framework draft. As written, it talks about large-scale measurements, but does not really define the magnitude of large-scale. It also states that end-users can request that measurements be done on their behalf, and that measurements can potentially run indefinitely. Although not mentioned in the framework, a service provider could offer a measurement service that under normal conditions runs essentially continuously when the end user is not transmitting their own data. In other words, we don't know what the upper bound is on what can be running in the network as measurements.=20 Consequently, we need to assume worst case.=20 Using the national emergency analogy, I suggest that during an emergency is when you want to do everything possible to improve communications as much as possible. It is essential that there be a mechanism that eliminates measurements almost immediately, if necessary. If "large-scale" measurements are being done, it probably is not scalable for a Controller to send an individual message to each MA. Furthermore, the emergency may directly affect the Controller and prevent it from sending messages. The MA needs an easy way to assess the state of the network and respond accordingly. It is relatively easy for the MA to poll the network before starting a measurement, and then continue to periodically poll during the measurement. If there is no response, the MA assumes there is a network issue and terminates the measurement.=20 There probably needs to be more than a go / no-go response from the network to account for varying degrees of the condition of the network.=20 There probably needs to be at least three states, but if there are too many states it complicates the measurement system. If there are three states then an MA can run the measurement, terminate the measurement, or complete certain measurements and then cease further measurements until the appropriate network conditions are restored. MA behavior in response to network conditions to a certain extent could be pre-provisioned in the MA by the operational domain owner responsible for the MA. There may also be some benefit in dictating behavior in the Instruction from the Controller. Charles On 12/10/2013 3:39 PM, Steve Miller wrote: > If we are testing at a rate where leaving the tests running during a= national emergency will make a meaningful difference as to whether or no= t lives are saved, we shouldn't be testing at that rate even during norma= l operation. Relying on the ability to turn anything off -- in an active= manner at least -- during an emergency seems like something we should av= oid: I'd think that anyone who's experienced making a phone call just aft= er a natural disaster would be able to testify as to the flakiness of any= communications medium under those circumstances. > > A key (and maybe *the* key) element here is that in many cases the t= ime you must want to hit the big red off switch is the time at which you = are least able to communicate with the MAs. > > The other autoshutdown stuff that's been discussed so far would give= people the flexibility to implement the only policy that truly seems imp= ortant: the one that disables measurements after N seconds/minutes/hours/= days in which the MA can't reach the controller. It's been my experience= that no matter how important that seems on paper, it ends up being much,= much less critical than it seems in the Real World. Still, leaving this= binary on/off level of control in place makes some sense: it's easy to c= ode, it's pretty innocuous, the additional load on the controller infrast= ructure shouldn't be that bad, and it avoids the "three million old devic= es hammering some poor destination that belongs to the people who bought = some defunct ISP" problem. It's also been my experience that even that l= evel of control isn't needed and can in fact cause problems of its own, b= ut I recognize that this scenario is a little different. I still think w= e should not overcomplicate things. > > -Steve > (who still needs to read the updated I-Ds, hopefully early next week, = sorry) > > On Tue, Dec 10, 2013 at 10:16:58PM +0000, Bugenhagen, Michael K wrote: >> I concur with Barbara - >> >> Stated a bit differently - If LMAP says put this probe on everything= (Part of the introduction statement)... >> >> Then=20 >> >> 1) They will want a suppression method that allows them to disable it= in case of national emergency - saving lives via emergency communication= takes priority in their minds. >> So they typically will ask for 2 each Safety breaks. >> 1 from the controller >> A second from a element controller or whatever configures the elemen= t in the first place. =20 >> >> These "MA unavailable" states should also be recorded for transpare= ncy sake. >> >> >> 2) Op's folks like to test - even when things are going bad.. otherwi= se fault isolation is hard to do. >> >> So suppression should have 3 levels (again this goes back to everyone= has a probe) - >> Green =3D do as you will (test anything) >> Yellow - don't load anything - restrict testing that will load the ne= twork, or kick up CPU cycles ...but allow fault testing (NO Saturation te= sts, ....)( >> RED - Stop, don't pass go, ... ADHOC testing only >> >> >> If USE case 1 is the ISP - not adopting those types of Op's requiremen= ts would get a significant amount of pushback on the implementation side.= >> >> Regards, >> Mike >> >> >> >> >> -----Original Message----- >> From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf O= f STARK, BARBARA H >> Sent: Tuesday, November 12, 2013 10:50 AM >> To: lmap@ietf.org >> Subject: [lmap] degrees of Measurement Suppression >> >> A number of providers have discussed a model of Measurement Suppressio= n that supports more granular degrees of suppression (other than just sup= press and don't suppress). Michael Bugenhagen presented the original vers= ion of this model, and he said it would be ok if I brought it up to IETF.= >> >> Following are highlights of the proposal (with some modifications I've= included as a result of additional discussion): >> >> 1. Measurement Methods (or perhaps Tasks) have a configurable paramete= r that indicates whether the Controller operator considers them to be "cr= itical for OAM", "not critical, but not resource intensive", and "not cri= tical and resource intensive". >> >> 2. The Controller can specify degrees of Measurement Suppression, whic= h should include: halt all non-critical tasks immediately but allow OAM t= asks; halt resource-intensive tasks immediately but allow non-resource-in= tensive tasks; finish resource intensive tasks but do not start new resou= rce-intensive tasks and allow all non-resource-intensive tasks; allow all= tasks. >> >> 3. It may also be possible for the unspecified bootstrap mechanism to = instruct the MA to suppress measurements. Where multiple channels exist f= or Measurement Suppression (e.g., Controller and bootstrap), the MA is to= use the most restrictive setting. >> >> Barbara >> >> >> _______________________________________________ >> 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 --=20 Charles Cook=20 Principal Architect Network 5325 Zuni Street; Suite 224 Denver, CO 80221 Tel: 303.992.8952 Fax: 925.281.0662 charles.cook2@centurylink.com From steve@idrathernotsay.com Wed Dec 11 02:43:03 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8D401A1F71 for ; Wed, 11 Dec 2013 02:43:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hwn_kM1BpNyD for ; Wed, 11 Dec 2013 02:43:02 -0800 (PST) Received: from colo3.idrathernotsay.com (colo3.idrathernotsay.com [74.207.251.199]) by ietfa.amsl.com (Postfix) with ESMTP id 735E71AD944 for ; Wed, 11 Dec 2013 02:43:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by colo3.idrathernotsay.com (Postfix) with ESMTP id 195C7FC3E; Wed, 11 Dec 2013 10:42:56 +0000 (UTC) X-Virus-Scanned: amavisd-new at idrathernotsay.com Received: from colo3.idrathernotsay.com ([127.0.0.1]) by localhost (colo3.idrathernotsay.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e+Iu-SUIBG4k; Wed, 11 Dec 2013 10:42:54 +0000 (UTC) Received: from misc-185.idrathernotsay.com (pool-173-79-225-215.washdc.fios.verizon.net [173.79.225.215]) by colo3.idrathernotsay.com (Postfix) with ESMTPSA id BD935FC1C; Wed, 11 Dec 2013 10:42:53 +0000 (UTC) Message-ID: <52A841AC.8020505@idrathernotsay.com> Date: Wed, 11 Dec 2013 05:42:52 -0500 From: Steven Miller User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: charles.cook2@centurylink.com References: <2D09D61DDFA73D4C884805CC7865E611303993CD@GAALPA1MSGUSR9L.ITServices.sbc.com> <20131210223947.GD39105@idrathernotsay.com> <52A7A298.7000900@centurylink.com> In-Reply-To: <52A7A298.7000900@centurylink.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "'lmap@ietf.org'" , "Bugenhagen, Michael K" , "'STARK, BARBARA H'" Subject: Re: [lmap] degrees of Measurement Suppression X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 10:43:03 -0000 [ This may not be a marvel of clarity: getting up at 4AM to write emails doesn't always end as well as one might hope. (-: ] I thought we'd discussed putting in text (and I don't remember if it was in the framework draft or elsewhere) that said "you could run a test forever but we really recommend that you don't." We'd talked about having measurements that might look like they run continuously but are just a sequence of "do this this often for a week" measurements, where at some point during the week when the MA checks in with the controller the controller hands it a different schedule with a different cutoff. If a user is requesting a test it seems like we could put a cap on that in the same way that we'd put a cap on the tests being requested by the "main" user of the MA (e.g., the ISP). That is, if a user says "run this forever", we turn that into "until the end of time, run this for a week, renewing every week as part of some normal schedule download." Or as an implementation detail we just don't generally let users run tests for further out than some period. About the national-emergency thing: I'm saying that, in essence, it doesn't matter whether or not you want to do everything in your power to improve communication, because once the emergency has started you won't be able to reach the MAs reliably. Also, this seems to me like a slippery slope: "do anything possible" seems rather broad. To take that a bit to the extreme for purposes of emphasis, do we somehow mandate that CPE all have a "kill Netflix and iTunes Store" switch for use in a national emergency? Our test traffic had better be well down in the weeds in terms of being any sort of routine major contributor to load on the ISPs hosting MAs or on the Internet in general. I think that every bit of complexity we add here makes the overall system much more fragile, in ways that have huge potential for unintended consequences. If we need the ability to talk to every MA in a hurry, initiated from the controller side, now we have all the fun of keeping 2-way communication open through a NAT all of the time (and given how most of those schemes do that, that'll be highly unreliable in the face of serious network issues, if you need a packet every 20 seconds or so to keep the association valid in the CPE, 20 seconds is a short time when the network is so hammered that you have 90% loss). If large-scale means we have millions of MAs, the load we impose to go try to talk to all of them in a hurry to tell them to stop is not entirely insignificant. If we try to be clever about detecting network issues and shut down performing some or all measurements, the implementors will get the cleverness wrong and we'll lose the results from the measurements that are the most interesting -- the ones that tell us that the network is having issues. It's hard to be clever at all, and it's even harder to be clever in a device with 8MB of RAM. (-: I think that the operations in the existing framework are adequate to do the intersection of what we want and what will work in times of network stress. -Steve On 12/10/2013 6:24 PM, Charles Cook wrote: > Just some thoughts... > > I just finished reading the framework draft. As written, it talks about > large-scale measurements, but does not really define the magnitude of > large-scale. It also states that end-users can request that > measurements be done on their behalf, and that measurements can > potentially run indefinitely. Although not mentioned in the framework, > a service provider could offer a measurement service that under normal > conditions runs essentially continuously when the end user is not > transmitting their own data. In other words, we don't know what the > upper bound is on what can be running in the network as measurements. > Consequently, we need to assume worst case. > > Using the national emergency analogy, I suggest that during an emergency > is when you want to do everything possible to improve communications as > much as possible. It is essential that there be a mechanism that > eliminates measurements almost immediately, if necessary. If > "large-scale" measurements are being done, it probably is not scalable > for a Controller to send an individual message to each MA. Furthermore, > the emergency may directly affect the Controller and prevent it from > sending messages. The MA needs an easy way to assess the state of the > network and respond accordingly. It is relatively easy for the MA to > poll the network before starting a measurement, and then continue to > periodically poll during the measurement. If there is no response, the > MA assumes there is a network issue and terminates the measurement. > > There probably needs to be more than a go / no-go response from the > network to account for varying degrees of the condition of the network. > There probably needs to be at least three states, but if there are too > many states it complicates the measurement system. If there are three > states then an MA can run the measurement, terminate the measurement, or > complete certain measurements and then cease further measurements until > the appropriate network conditions are restored. MA behavior in > response to network conditions to a certain extent could be > pre-provisioned in the MA by the operational domain owner responsible > for the MA. There may also be some benefit in dictating behavior in the > Instruction from the Controller. > > Charles > > From Michael.K.Bugenhagen@centurylink.com Wed Dec 11 06:20:55 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2A111ADF33 for ; Wed, 11 Dec 2013 06:20:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MznRlL4OtlmY for ; Wed, 11 Dec 2013 06:20:53 -0800 (PST) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by ietfa.amsl.com (Postfix) with ESMTP id 6BA921AD8EB for ; Wed, 11 Dec 2013 06:20:53 -0800 (PST) Received: from lxomavmpc030.qintra.com (emailout.qintra.com [151.117.207.30]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id rBBEKi86007168 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Dec 2013 08:20:44 -0600 (CST) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id C9E8E1E005D; Wed, 11 Dec 2013 08:20:38 -0600 (CST) Received: from suomp60i.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id A763E1E004D; Wed, 11 Dec 2013 08:20:38 -0600 (CST) Received: from suomp60i.qintra.com (localhost [127.0.0.1]) by suomp60i.qintra.com (8.14.4/8.14.4) with ESMTP id rBBEKcSi010842; Wed, 11 Dec 2013 08:20:38 -0600 (CST) Received: from vodcwhubex501.ctl.intranet (vodcwhubex501.ctl.intranet [151.117.206.27]) by suomp60i.qintra.com (8.14.4/8.14.4) with ESMTP id rBBEKbjl010829 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 11 Dec 2013 08:20:38 -0600 (CST) Received: from PODCWMBXEX505.ctl.intranet ([fe80::f87e:fe44:ad72:b610]) by vodcwhubex501.ctl.intranet ([151.117.206.27]) with mapi id 14.03.0158.001; Wed, 11 Dec 2013 08:20:37 -0600 From: "Bugenhagen, Michael K" To: "'Steve Miller'" Thread-Topic: [lmap] degrees of Measurement Suppression Thread-Index: Ac7fxy6a9B101VqJQi6oteMX5LjSDgWLXOxQAA2YtIAAE2A9AA== Date: Wed, 11 Dec 2013 14:20:37 +0000 Message-ID: References: <2D09D61DDFA73D4C884805CC7865E611303993CD@GAALPA1MSGUSR9L.ITServices.sbc.com> <20131210223947.GD39105@idrathernotsay.com> In-Reply-To: <20131210223947.GD39105@idrathernotsay.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.8] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "'STARK, BARBARA H'" , "'lmap@ietf.org'" Subject: Re: [lmap] degrees of Measurement Suppression X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 14:20:56 -0000 Steve - Operational design groups have these frameworks historically - and they= control the deployment of test systems so adoption issues can and do occur= with these types of systems that can load the network. I think it's fairly simple to take away those concerns by addressing them v= s. discarding what may be a legitimate issue for and ISP to adopt the frame= work. =20 If we can't reach consensus on the hard requirement I recommend one of two = paths. 1) Add those added safety measures but make them optional. And or=20 2) Partition the tests (which I think we're doing) so that they can be adop= ted into existing test control schemas that fit the ISP's need. My concern on the way it is currently drafted - I'm just afraid that the current control schema might miss the target for= the #1 use case for all ISP's, which "large" somewhat infers all ISP's wou= ld find the control framework suitable. I understand the added complexity argument, but if it's required to meet ha= rd operational criteria (and this has been discussed else where) then it's = probably worth the effort to ensure that this work is reference-able and re= velent to all. There are a few more Key blind spots in this framework a= s well that make it's current form and longevity suspect. To resolve the "is this a real op's issue" - Let's see if we can't get some IETF ISP members to ping their OP's groups o= n if they restrict load testing the network for any reason - if yes.. then = we need to look at phases. BTW - every Op's group I've been in has situations where they don't from th= e customer level on UP... aka you don't load a congested customer unless yo= u're taking them out of service and they know it, and you don't stress a "t= runk" of shared path that's severely congested and in trouble either throug= h fault or due un-usual circumstance. (an earthquake drops building in a = city and you want every bit available to be there for use, not test traffic= ). Cheers -=20 Mike =20 -----Original Message----- From: Steve Miller [mailto:steve@idrathernotsay.com]=20 Sent: Tuesday, December 10, 2013 4:40 PM To: Bugenhagen, Michael K Cc: 'STARK, BARBARA H'; 'lmap@ietf.org' Subject: Re: [lmap] degrees of Measurement Suppression If we are testing at a rate where leaving the tests running during a nat= ional emergency will make a meaningful difference as to whether or not live= s are saved, we shouldn't be testing at that rate even during normal operat= ion. Relying on the ability to turn anything off -- in an active manner at= least -- during an emergency seems like something we should avoid: I'd thi= nk that anyone who's experienced making a phone call just after a natural d= isaster would be able to testify as to the flakiness of any communications = medium under those circumstances. A key (and maybe *the* key) element here is that in many cases the time = you must want to hit the big red off switch is the time at which you are le= ast able to communicate with the MAs. The other autoshutdown stuff that's been discussed so far would give peo= ple the flexibility to implement the only policy that truly seems important= : the one that disables measurements after N seconds/minutes/hours/days in = which the MA can't reach the controller. It's been my experience that no m= atter how important that seems on paper, it ends up being much, much less c= ritical than it seems in the Real World. Still, leaving this binary on/off= level of control in place makes some sense: it's easy to code, it's pretty= innocuous, the additional load on the controller infrastructure shouldn't = be that bad, and it avoids the "three million old devices hammering some po= or destination that belongs to the people who bought some defunct ISP" prob= lem. It's also been my experience that even that level of control isn't ne= eded and can in fact cause problems of its own, but I recognize that this s= cenario is a little different. I still think we should not overcomplicate = things. -Steve (who still needs to read the updated I-Ds, hopefully early next week, sorr= y) On Tue, Dec 10, 2013 at 10:16:58PM +0000, Bugenhagen, Michael K wrote: > I concur with Barbara - >=20 > Stated a bit differently - If LMAP says put this probe on everything (P= art of the introduction statement)... >=20 > Then=20 >=20 > 1) They will want a suppression method that allows them to disable it in= case of national emergency - saving lives via emergency communication take= s priority in their minds. > So they typically will ask for 2 each Safety breaks. > 1 from the controller > A second from a element controller or whatever configures the element i= n the first place. =20 >=20 > These "MA unavailable" states should also be recorded for transparency= sake. >=20 >=20 > 2) Op's folks like to test - even when things are going bad.. otherwise = fault isolation is hard to do. >=20 > So suppression should have 3 levels (again this goes back to everyone ha= s a probe) - > Green =3D do as you will (test anything) > Yellow - don't load anything - restrict testing that will load the netwo= rk, or kick up CPU cycles ...but allow fault testing (NO Saturation tests, = ....)( > RED - Stop, don't pass go, ... ADHOC testing only >=20 >=20 > If USE case 1 is the ISP - not adopting those types of Op's requirements = would get a significant amount of pushback on the implementation side. >=20 > Regards, > Mike >=20 >=20 >=20 >=20 > -----Original Message----- > From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of S= TARK, BARBARA H > Sent: Tuesday, November 12, 2013 10:50 AM > To: lmap@ietf.org > Subject: [lmap] degrees of Measurement Suppression >=20 > A number of providers have discussed a model of Measurement Suppression t= hat supports more granular degrees of suppression (other than just suppress= and don't suppress). Michael Bugenhagen presented the original version of = this model, and he said it would be ok if I brought it up to IETF. >=20 > Following are highlights of the proposal (with some modifications I've in= cluded as a result of additional discussion): >=20 > 1. Measurement Methods (or perhaps Tasks) have a configurable parameter t= hat indicates whether the Controller operator considers them to be "critica= l for OAM", "not critical, but not resource intensive", and "not critical a= nd resource intensive". >=20 > 2. The Controller can specify degrees of Measurement Suppression, which s= hould include: halt all non-critical tasks immediately but allow OAM tasks;= halt resource-intensive tasks immediately but allow non-resource-intensive= tasks; finish resource intensive tasks but do not start new resource-inten= sive tasks and allow all non-resource-intensive tasks; allow all tasks. >=20 > 3. It may also be possible for the unspecified bootstrap mechanism to ins= truct the MA to suppress measurements. Where multiple channels exist for Me= asurement Suppression (e.g., Controller and bootstrap), the MA is to use th= e most restrictive setting. >=20 > Barbara >=20 >=20 > _______________________________________________ > 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 From sharam.hakimi@exfo.com Wed Dec 11 08:14:33 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 152EE1ADFBB for ; Wed, 11 Dec 2013 08:14:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4fw-oRlQaa05 for ; Wed, 11 Dec 2013 08:14:30 -0800 (PST) Received: from smtpinqc.exfo.com (smtpinqc.exfo.com [206.162.164.97]) by ietfa.amsl.com (Postfix) with ESMTP id D27841ADFB2 for ; Wed, 11 Dec 2013 08:14:29 -0800 (PST) Received: from spqcexc04.exfo.com ([172.16.48.171]) by smtpinqc.exfo.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Dec 2013 11:14:23 -0500 Received: from spboexc01.exfo.com ([10.10.10.16]) by spqcexc04.exfo.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Dec 2013 11:14:23 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Dec 2013 11:14:36 -0500 Message-ID: <084CDC75FEC1E640B60338273BEACDFA029B235C@spboexc01.exfo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lmap] degrees of Measurement Suppression Thread-Index: Ac7fxy6a9B101VqJQi6oteMX5LjSDgWLXOxQAA2YtIAAE2A9AAAEr9Zg References: <2D09D61DDFA73D4C884805CC7865E611303993CD@GAALPA1MSGUSR9L.ITServices.sbc.com> <20131210223947.GD39105@idrathernotsay.com> From: "Sharam Hakimi" To: "Bugenhagen, Michael K" , "Steve Miller" X-OriginalArrivalTime: 11 Dec 2013 16:14:23.0109 (UTC) FILETIME=[0E007B50:01CEF68C] Cc: "STARK, BARBARA H" , lmap@ietf.org Subject: Re: [lmap] degrees of Measurement Suppression X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 16:14:33 -0000 Mike, There two ways of having this control which would work in the system and do what you would like. They are 1: The MA device MUST stop testing if it has not heard from the MC in a designated time ( we had talked about putting this in the document. 2: In an emergency the MC can issue a BLANK test schedule that would override whatever the MA is scheduled to do. ( and if MA cannot receive this it will automatically stop) Thanks, Sharam=20 =09 -----Original Message----- From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Bugenhagen, Michael K Sent: Wednesday, December 11, 2013 9:21 AM To: 'Steve Miller' Cc: 'STARK, BARBARA H'; 'lmap@ietf.org' Subject: Re: [lmap] degrees of Measurement Suppression Steve - Operational design groups have these frameworks historically - and they control the deployment of test systems so adoption issues can and do occur with these types of systems that can load the network. I think it's fairly simple to take away those concerns by addressing them vs. discarding what may be a legitimate issue for and ISP to adopt the framework. =20 If we can't reach consensus on the hard requirement I recommend one of two paths. 1) Add those added safety measures but make them optional. And or=20 2) Partition the tests (which I think we're doing) so that they can be adopted into existing test control schemas that fit the ISP's need. My concern on the way it is currently drafted - I'm just afraid that the current control schema might miss the target for the #1 use case for all ISP's, which "large" somewhat infers all ISP's would find the control framework suitable. I understand the added complexity argument, but if it's required to meet hard operational criteria (and this has been discussed else where) then it's probably worth the effort to ensure that this work is reference-able and revelent to all. There are a few more Key blind spots in this framework as well that make it's current form and longevity suspect. To resolve the "is this a real op's issue" - Let's see if we can't get some IETF ISP members to ping their OP's groups on if they restrict load testing the network for any reason - if yes.. then we need to look at phases. BTW - every Op's group I've been in has situations where they don't from the customer level on UP... aka you don't load a congested customer unless you're taking them out of service and they know it, and you don't stress a "trunk" of shared path that's severely congested and in trouble either through fault or due un-usual circumstance. (an earthquake drops building in a city and you want every bit available to be there for use, not test traffic). Cheers -=20 Mike =20 -----Original Message----- From: Steve Miller [mailto:steve@idrathernotsay.com]=20 Sent: Tuesday, December 10, 2013 4:40 PM To: Bugenhagen, Michael K Cc: 'STARK, BARBARA H'; 'lmap@ietf.org' Subject: Re: [lmap] degrees of Measurement Suppression If we are testing at a rate where leaving the tests running during a national emergency will make a meaningful difference as to whether or not lives are saved, we shouldn't be testing at that rate even during normal operation. Relying on the ability to turn anything off -- in an active manner at least -- during an emergency seems like something we should avoid: I'd think that anyone who's experienced making a phone call just after a natural disaster would be able to testify as to the flakiness of any communications medium under those circumstances. A key (and maybe *the* key) element here is that in many cases the time you must want to hit the big red off switch is the time at which you are least able to communicate with the MAs. The other autoshutdown stuff that's been discussed so far would give people the flexibility to implement the only policy that truly seems important: the one that disables measurements after N seconds/minutes/hours/days in which the MA can't reach the controller. It's been my experience that no matter how important that seems on paper, it ends up being much, much less critical than it seems in the Real World. Still, leaving this binary on/off level of control in place makes some sense: it's easy to code, it's pretty innocuous, the additional load on the controller infrastructure shouldn't be that bad, and it avoids the "three million old devices hammering some poor destination that belongs to the people who bought some defunct ISP" problem. It's also been my experience that even that level of control isn't needed and can in fact cause problems of its own, but I recognize that this scenario is a little different. I still think we should not overcomplicate things. -Steve (who still needs to read the updated I-Ds, hopefully early next week, sorry) On Tue, Dec 10, 2013 at 10:16:58PM +0000, Bugenhagen, Michael K wrote: > I concur with Barbara - >=20 > Stated a bit differently - If LMAP says put this probe on everything (Part of the introduction statement)... >=20 > Then=20 >=20 > 1) They will want a suppression method that allows them to disable it in case of national emergency - saving lives via emergency communication takes priority in their minds. > So they typically will ask for 2 each Safety breaks. > 1 from the controller > A second from a element controller or whatever configures the element in the first place. =20 >=20 > These "MA unavailable" states should also be recorded for transparency sake. >=20 >=20 > 2) Op's folks like to test - even when things are going bad.. otherwise fault isolation is hard to do. >=20 > So suppression should have 3 levels (again this goes back to everyone has a probe) - > Green =3D do as you will (test anything) > Yellow - don't load anything - restrict testing that will load the network, or kick up CPU cycles ...but allow fault testing (NO Saturation tests, ....)( > RED - Stop, don't pass go, ... ADHOC testing only >=20 >=20 > If USE case 1 is the ISP - not adopting those types of Op's requirements would get a significant amount of pushback on the implementation side. >=20 > Regards, > Mike >=20 >=20 >=20 >=20 > -----Original Message----- > From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of STARK, BARBARA H > Sent: Tuesday, November 12, 2013 10:50 AM > To: lmap@ietf.org > Subject: [lmap] degrees of Measurement Suppression >=20 > A number of providers have discussed a model of Measurement Suppression that supports more granular degrees of suppression (other than just suppress and don't suppress). Michael Bugenhagen presented the original version of this model, and he said it would be ok if I brought it up to IETF. >=20 > Following are highlights of the proposal (with some modifications I've included as a result of additional discussion): >=20 > 1. Measurement Methods (or perhaps Tasks) have a configurable parameter that indicates whether the Controller operator considers them to be "critical for OAM", "not critical, but not resource intensive", and "not critical and resource intensive". >=20 > 2. The Controller can specify degrees of Measurement Suppression, which should include: halt all non-critical tasks immediately but allow OAM tasks; halt resource-intensive tasks immediately but allow non-resource-intensive tasks; finish resource intensive tasks but do not start new resource-intensive tasks and allow all non-resource-intensive tasks; allow all tasks. >=20 > 3. It may also be possible for the unspecified bootstrap mechanism to instruct the MA to suppress measurements. Where multiple channels exist for Measurement Suppression (e.g., Controller and bootstrap), the MA is to use the most restrictive setting. >=20 > Barbara >=20 >=20 > _______________________________________________ > 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 From Michael.K.Bugenhagen@centurylink.com Wed Dec 11 08:47:03 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 242341AE07C for ; Wed, 11 Dec 2013 08:47:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F4boZhuoMHEE for ; Wed, 11 Dec 2013 08:47:00 -0800 (PST) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by ietfa.amsl.com (Postfix) with ESMTP id A4CEB1AE066 for ; Wed, 11 Dec 2013 08:47:00 -0800 (PST) Received: from lxomavmpc030.qintra.com (emailout.qintra.com [151.117.207.30]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id rBBGklrK005791 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Dec 2013 10:46:47 -0600 (CST) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id E91691E0063; Wed, 11 Dec 2013 10:46:41 -0600 (CST) Received: from sudnp796.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id B8AB91E0032; Wed, 11 Dec 2013 10:46:41 -0600 (CST) Received: from sudnp796.qintra.com (localhost [127.0.0.1]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id rBBGkfpb005927; Wed, 11 Dec 2013 09:46:41 -0700 (MST) Received: from vodcwhubex501.ctl.intranet (vodcwhubex501.ctl.intranet [151.117.206.27]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id rBBGkdUc005815 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 11 Dec 2013 09:46:41 -0700 (MST) Received: from PODCWMBXEX505.ctl.intranet ([fe80::f87e:fe44:ad72:b610]) by vodcwhubex501.ctl.intranet ([151.117.206.27]) with mapi id 14.03.0158.001; Wed, 11 Dec 2013 10:46:39 -0600 From: "Bugenhagen, Michael K" To: "'Sharam Hakimi'" , "'Steve Miller'" Thread-Topic: [lmap] degrees of Measurement Suppression Thread-Index: Ac7fxy6a9B101VqJQi6oteMX5LjSDgWLXOxQAA2YtIAAE2A9AAAEr9ZgAAELKfA= Date: Wed, 11 Dec 2013 16:46:37 +0000 Message-ID: References: <2D09D61DDFA73D4C884805CC7865E611303993CD@GAALPA1MSGUSR9L.ITServices.sbc.com> <20131210223947.GD39105@idrathernotsay.com> <084CDC75FEC1E640B60338273BEACDFA029B235C@spboexc01.exfo.com> In-Reply-To: <084CDC75FEC1E640B60338273BEACDFA029B235C@spboexc01.exfo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.8] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "'STARK, BARBARA H'" , "'lmap@ietf.org'" Subject: Re: [lmap] degrees of Measurement Suppression X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 16:47:03 -0000 Sharam - Those are some options - But again the Op's guys are responsible for keeping the customer "not impac= ted" and the network alive. So they will want more than "on / off" for probe functions - they will want= , load test (Service activation test), OAM / fault test, and Stop all testi= ng controls. - Your suggestion doesn't cover the 3 states required for Op's... Let's put it this way - the Op's teams have either already driven this in= to probes, are as asking you probe makers to do this. IF they have an option they are going to pick the probe that has the states= that match their operational practices. It always goes to the needs of the customer, and when we are talking about = ISP's - that's the Op's organization. Sorry if I appear a bit jaded on the subject, but in the past I've had to e= xplain why some of these new technologies can't be tested and don't have th= ese features when they break. Not an enjoyable endeavor whatsoever... Otherwise stated - I do think it's worthwhile to have those 3 levels of = testing control (or suppression), and 2 ways to shut it down (EMS or elemen= t manager, and Measurement Controller) available so the Op's guys can pass = it without question.=20 Cheers, Mike =20 -----Original Message----- From: Sharam Hakimi [mailto:sharam.hakimi@exfo.com]=20 Sent: Wednesday, December 11, 2013 10:15 AM To: Bugenhagen, Michael K; Steve Miller Cc: STARK, BARBARA H; lmap@ietf.org Subject: RE: [lmap] degrees of Measurement Suppression Mike, There two ways of having this control which would work in the system and do= what you would like. They are 1: The MA device MUST stop testing if it has not heard from the MC in a designated time ( we had talked about putting this in the document. 2: In an emergency the MC can issue a BLANK test schedule that would overr= ide whatever the MA is scheduled to do. ( and if MA cannot receive this it will automatically stop) Thanks, Sharam=20 =09 -----Original Message----- From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Bugenhagen, Michael = K Sent: Wednesday, December 11, 2013 9:21 AM To: 'Steve Miller' Cc: 'STARK, BARBARA H'; 'lmap@ietf.org' Subject: Re: [lmap] degrees of Measurement Suppression Steve - Operational design groups have these frameworks historically - and they= control the deployment of test systems so adoption issues can and do occur= with these types of systems that can load the network. I think it's fairly simple to take away those concerns by addressing them v= s. discarding what may be a legitimate issue for and ISP to adopt the framework. =20 If we can't reach consensus on the hard requirement I recommend one of two = paths. 1) Add those added safety measures but make them optional. And or 2) Partition the tests (which I think we're doing) so that they can be adop= ted into existing test control schemas that fit the ISP's need. My concern on the way it is currently drafted - I'm just afraid that the current control schema might miss the target for the #1 use case for all ISP's, which "large" somewhat infers all ISP's would find the control framework suitable. I understand the added complexity argument, but if it's required to meet hard operational criteria (and this has been discussed else where) then it's probably worth the effort to ensure that this work is reference-able and revelent to all. There are a few more Key blind spots in this framework as well that make it's current form and longevity suspect. To resolve the "is this a real op's issue" - Let's see if we can't get some IETF ISP members to ping their OP's groups on if they restrict load testing the network for any reason - if yes.. then we need to look at phases. BTW - every Op's group I've been in has situations where they don't from the customer level on UP... aka you don't load a congested customer unless you're taking them out of service and they know it, and you don't stress a "trunk" of shared path that's severely congested and in trouble either through fault or due un-usual circumstance. (an earthquake drops building in a city and you want every bit available to be there for use, not test traffic). Cheers -=20 Mike =20 -----Original Message----- From: Steve Miller [mailto:steve@idrathernotsay.com]=20 Sent: Tuesday, December 10, 2013 4:40 PM To: Bugenhagen, Michael K Cc: 'STARK, BARBARA H'; 'lmap@ietf.org' Subject: Re: [lmap] degrees of Measurement Suppression If we are testing at a rate where leaving the tests running during a national emergency will make a meaningful difference as to whether or not lives are saved, we shouldn't be testing at that rate even during normal operation. Relying on the ability to turn anything off -- in an active manner at least -- during an emergency seems like something we should avoid: I'd think that anyone who's experienced making a phone call just after a natural disaster would be able to testify as to the flakiness of any communications medium under those circumstances. A key (and maybe *the* key) element here is that in many cases the time you must want to hit the big red off switch is the time at which you are least able to communicate with the MAs. The other autoshutdown stuff that's been discussed so far would give people the flexibility to implement the only policy that truly seems important: the one that disables measurements after N seconds/minutes/hours/days in which the MA can't reach the controller. It's been my experience that no matter how important that seems on paper, it ends up being much, much less critical than it seems in the Real World. Still, leaving this binary on/off level of control in place makes some sense: it's easy to code, it's pretty innocuous, the additional load on the controller infrastructure shouldn't be that bad, and it avoids the "three million old devices hammering some poor destination that belongs to the people who bought some defunct ISP" problem. It's also been my experience that even that level of control isn't needed and can in fact cause problems of its own, but I recognize that this scenario is a little different. I still think we should not overcomplicate things. -Steve (who still needs to read the updated I-Ds, hopefully early next week, sorry) On Tue, Dec 10, 2013 at 10:16:58PM +0000, Bugenhagen, Michael K wrote: > I concur with Barbara - >=20 > Stated a bit differently - If LMAP says put this probe on everything (Part of the introduction statement)... >=20 > Then=20 >=20 > 1) They will want a suppression method that allows them to disable it in case of national emergency - saving lives via emergency communication takes priority in their minds. > So they typically will ask for 2 each Safety breaks. > 1 from the controller > A second from a element controller or whatever configures the element in the first place. =20 >=20 > These "MA unavailable" states should also be recorded for transparency sake. >=20 >=20 > 2) Op's folks like to test - even when things are going bad.. otherwise fault isolation is hard to do. >=20 > So suppression should have 3 levels (again this goes back to everyone has a probe) - > Green =3D do as you will (test anything) > Yellow - don't load anything - restrict testing that will load the network, or kick up CPU cycles ...but allow fault testing (NO Saturation tests, ....)( > RED - Stop, don't pass go, ... ADHOC testing only >=20 >=20 > If USE case 1 is the ISP - not adopting those types of Op's requirements would get a significant amount of pushback on the implementation side. >=20 > Regards, > Mike >=20 >=20 >=20 >=20 > -----Original Message----- > From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of STARK, BARBARA H > Sent: Tuesday, November 12, 2013 10:50 AM > To: lmap@ietf.org > Subject: [lmap] degrees of Measurement Suppression >=20 > A number of providers have discussed a model of Measurement Suppression that supports more granular degrees of suppression (other than just suppress and don't suppress). Michael Bugenhagen presented the original version of this model, and he said it would be ok if I brought it up to IETF. >=20 > Following are highlights of the proposal (with some modifications I've included as a result of additional discussion): >=20 > 1. Measurement Methods (or perhaps Tasks) have a configurable parameter that indicates whether the Controller operator considers them to be "critical for OAM", "not critical, but not resource intensive", and "not critical and resource intensive". >=20 > 2. The Controller can specify degrees of Measurement Suppression, which should include: halt all non-critical tasks immediately but allow OAM tasks; halt resource-intensive tasks immediately but allow non-resource-intensive tasks; finish resource intensive tasks but do not start new resource-intensive tasks and allow all non-resource-intensive tasks; allow all tasks. >=20 > 3. It may also be possible for the unspecified bootstrap mechanism to instruct the MA to suppress measurements. Where multiple channels exist for Measurement Suppression (e.g., Controller and bootstrap), the MA is to use the most restrictive setting. >=20 > Barbara >=20 >=20 > _______________________________________________ > 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 From sharam.hakimi@exfo.com Wed Dec 11 09:12:28 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43F591ACB4E for ; Wed, 11 Dec 2013 09:12:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BrthniHoJkvK for ; Wed, 11 Dec 2013 09:12:24 -0800 (PST) Received: from smtpinqc.exfo.com (smtpinqc.exfo.com [206.162.164.97]) by ietfa.amsl.com (Postfix) with ESMTP id 381081AC403 for ; Wed, 11 Dec 2013 09:12:23 -0800 (PST) Received: from spqcexc04.exfo.com ([172.16.48.171]) by smtpinqc.exfo.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Dec 2013 12:12:17 -0500 Received: from spboexc01.exfo.com ([10.10.10.16]) by spqcexc04.exfo.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Dec 2013 12:12:16 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Dec 2013 12:12:29 -0500 Message-ID: <084CDC75FEC1E640B60338273BEACDFA029B2375@spboexc01.exfo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lmap] degrees of Measurement Suppression Thread-Index: Ac7fxy6a9B101VqJQi6oteMX5LjSDgWLXOxQAA2YtIAAE2A9AAAEr9ZgAAELKfAAARVaUA== References: <2D09D61DDFA73D4C884805CC7865E611303993CD@GAALPA1MSGUSR9L.ITServices.sbc.com> <20131210223947.GD39105@idrathernotsay.com> <084CDC75FEC1E640B60338273BEACDFA029B235C@spboexc01.exfo.com> From: "Sharam Hakimi" To: "Bugenhagen, Michael K" , "Steve Miller" X-OriginalArrivalTime: 11 Dec 2013 17:12:16.0890 (UTC) FILETIME=[248965A0:01CEF694] Cc: "STARK, BARBARA H" , lmap@ietf.org Subject: Re: [lmap] degrees of Measurement Suppression X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 17:12:28 -0000 Mike, My comments was to respond to your emergency case point. The other tests are part of the normal test operation covered by the use cases. Thanks, Sharam -----Original Message----- From: Bugenhagen, Michael K [mailto:Michael.K.Bugenhagen@centurylink.com]=20 Sent: Wednesday, December 11, 2013 11:47 AM To: Sharam Hakimi; 'Steve Miller' Cc: 'STARK, BARBARA H'; 'lmap@ietf.org' Subject: RE: [lmap] degrees of Measurement Suppression Sharam - Those are some options - But again the Op's guys are responsible for keeping the customer "not impacted" and the network alive. So they will want more than "on / off" for probe functions - they will want, load test (Service activation test), OAM / fault test, and Stop all testing controls. - Your suggestion doesn't cover the 3 states required for Op's... Let's put it this way - the Op's teams have either already driven this into probes, are as asking you probe makers to do this. IF they have an option they are going to pick the probe that has the states that match their operational practices. It always goes to the needs of the customer, and when we are talking about ISP's - that's the Op's organization. Sorry if I appear a bit jaded on the subject, but in the past I've had to explain why some of these new technologies can't be tested and don't have these features when they break. Not an enjoyable endeavor whatsoever... Otherwise stated - I do think it's worthwhile to have those 3 levels of testing control (or suppression), and 2 ways to shut it down (EMS or element manager, and Measurement Controller) available so the Op's guys can pass it without question.=20 Cheers, Mike =20 -----Original Message----- From: Sharam Hakimi [mailto:sharam.hakimi@exfo.com]=20 Sent: Wednesday, December 11, 2013 10:15 AM To: Bugenhagen, Michael K; Steve Miller Cc: STARK, BARBARA H; lmap@ietf.org Subject: RE: [lmap] degrees of Measurement Suppression Mike, There two ways of having this control which would work in the system and do what you would like. They are 1: The MA device MUST stop testing if it has not heard from the MC in a designated time ( we had talked about putting this in the document. 2: In an emergency the MC can issue a BLANK test schedule that would override whatever the MA is scheduled to do. ( and if MA cannot receive this it will automatically stop) Thanks, Sharam=20 =09 -----Original Message----- From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Bugenhagen, Michael K Sent: Wednesday, December 11, 2013 9:21 AM To: 'Steve Miller' Cc: 'STARK, BARBARA H'; 'lmap@ietf.org' Subject: Re: [lmap] degrees of Measurement Suppression Steve - Operational design groups have these frameworks historically - and they control the deployment of test systems so adoption issues can and do occur with these types of systems that can load the network. I think it's fairly simple to take away those concerns by addressing them vs. discarding what may be a legitimate issue for and ISP to adopt the framework. =20 If we can't reach consensus on the hard requirement I recommend one of two paths. 1) Add those added safety measures but make them optional. And or 2) Partition the tests (which I think we're doing) so that they can be adopted into existing test control schemas that fit the ISP's need. My concern on the way it is currently drafted - I'm just afraid that the current control schema might miss the target for the #1 use case for all ISP's, which "large" somewhat infers all ISP's would find the control framework suitable. I understand the added complexity argument, but if it's required to meet hard operational criteria (and this has been discussed else where) then it's probably worth the effort to ensure that this work is reference-able and revelent to all. There are a few more Key blind spots in this framework as well that make it's current form and longevity suspect. To resolve the "is this a real op's issue" - Let's see if we can't get some IETF ISP members to ping their OP's groups on if they restrict load testing the network for any reason - if yes.. then we need to look at phases. BTW - every Op's group I've been in has situations where they don't from the customer level on UP... aka you don't load a congested customer unless you're taking them out of service and they know it, and you don't stress a "trunk" of shared path that's severely congested and in trouble either through fault or due un-usual circumstance. (an earthquake drops building in a city and you want every bit available to be there for use, not test traffic). Cheers -=20 Mike =20 -----Original Message----- From: Steve Miller [mailto:steve@idrathernotsay.com]=20 Sent: Tuesday, December 10, 2013 4:40 PM To: Bugenhagen, Michael K Cc: 'STARK, BARBARA H'; 'lmap@ietf.org' Subject: Re: [lmap] degrees of Measurement Suppression If we are testing at a rate where leaving the tests running during a national emergency will make a meaningful difference as to whether or not lives are saved, we shouldn't be testing at that rate even during normal operation. Relying on the ability to turn anything off -- in an active manner at least -- during an emergency seems like something we should avoid: I'd think that anyone who's experienced making a phone call just after a natural disaster would be able to testify as to the flakiness of any communications medium under those circumstances. A key (and maybe *the* key) element here is that in many cases the time you must want to hit the big red off switch is the time at which you are least able to communicate with the MAs. The other autoshutdown stuff that's been discussed so far would give people the flexibility to implement the only policy that truly seems important: the one that disables measurements after N seconds/minutes/hours/days in which the MA can't reach the controller. It's been my experience that no matter how important that seems on paper, it ends up being much, much less critical than it seems in the Real World. Still, leaving this binary on/off level of control in place makes some sense: it's easy to code, it's pretty innocuous, the additional load on the controller infrastructure shouldn't be that bad, and it avoids the "three million old devices hammering some poor destination that belongs to the people who bought some defunct ISP" problem. It's also been my experience that even that level of control isn't needed and can in fact cause problems of its own, but I recognize that this scenario is a little different. I still think we should not overcomplicate things. -Steve (who still needs to read the updated I-Ds, hopefully early next week, sorry) On Tue, Dec 10, 2013 at 10:16:58PM +0000, Bugenhagen, Michael K wrote: > I concur with Barbara - >=20 > Stated a bit differently - If LMAP says put this probe on everything (Part of the introduction statement)... >=20 > Then=20 >=20 > 1) They will want a suppression method that allows them to disable it in case of national emergency - saving lives via emergency communication takes priority in their minds. > So they typically will ask for 2 each Safety breaks. > 1 from the controller > A second from a element controller or whatever configures the element in the first place. =20 >=20 > These "MA unavailable" states should also be recorded for transparency sake. >=20 >=20 > 2) Op's folks like to test - even when things are going bad.. otherwise fault isolation is hard to do. >=20 > So suppression should have 3 levels (again this goes back to everyone has a probe) - > Green =3D do as you will (test anything) > Yellow - don't load anything - restrict testing that will load the network, or kick up CPU cycles ...but allow fault testing (NO Saturation tests, ....)( > RED - Stop, don't pass go, ... ADHOC testing only >=20 >=20 > If USE case 1 is the ISP - not adopting those types of Op's requirements would get a significant amount of pushback on the implementation side. >=20 > Regards, > Mike >=20 >=20 >=20 >=20 > -----Original Message----- > From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of STARK, BARBARA H > Sent: Tuesday, November 12, 2013 10:50 AM > To: lmap@ietf.org > Subject: [lmap] degrees of Measurement Suppression >=20 > A number of providers have discussed a model of Measurement Suppression that supports more granular degrees of suppression (other than just suppress and don't suppress). Michael Bugenhagen presented the original version of this model, and he said it would be ok if I brought it up to IETF. >=20 > Following are highlights of the proposal (with some modifications I've included as a result of additional discussion): >=20 > 1. Measurement Methods (or perhaps Tasks) have a configurable parameter that indicates whether the Controller operator considers them to be "critical for OAM", "not critical, but not resource intensive", and "not critical and resource intensive". >=20 > 2. The Controller can specify degrees of Measurement Suppression, which should include: halt all non-critical tasks immediately but allow OAM tasks; halt resource-intensive tasks immediately but allow non-resource-intensive tasks; finish resource intensive tasks but do not start new resource-intensive tasks and allow all non-resource-intensive tasks; allow all tasks. >=20 > 3. It may also be possible for the unspecified bootstrap mechanism to instruct the MA to suppress measurements. Where multiple channels exist for Measurement Suppression (e.g., Controller and bootstrap), the MA is to use the most restrictive setting. >=20 > Barbara >=20 >=20 > _______________________________________________ > 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 From charles.cook2@centurylink.com Wed Dec 11 13:49:30 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C2EA1AE11B for ; Wed, 11 Dec 2013 13:49:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QEXKvZk9-bMQ for ; Wed, 11 Dec 2013 13:49:25 -0800 (PST) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by ietfa.amsl.com (Postfix) with ESMTP id 4DAE91AE117 for ; Wed, 11 Dec 2013 13:49:25 -0800 (PST) Received: from lxomavmpc030.qintra.com (lxomavmpc030.qintra.com [151.117.207.30]) by sudnp799.qwest.com (8.14.4/8.14.4) with ESMTP id rBBLnF1L028443 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Dec 2013 14:49:15 -0700 (MST) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id CC8EC1E006F; Wed, 11 Dec 2013 15:49:09 -0600 (CST) Received: from suomp60i.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id A7AF51E0058; Wed, 11 Dec 2013 15:49:09 -0600 (CST) Received: from suomp60i.qintra.com (localhost [127.0.0.1]) by suomp60i.qintra.com (8.14.4/8.14.4) with ESMTP id rBBLn9QK014933; Wed, 11 Dec 2013 15:49:09 -0600 (CST) Received: from [10.188.113.236] (x1069818.dhcp.intranet [10.188.113.236]) by suomp60i.qintra.com (8.14.4/8.14.4) with ESMTP id rBBLn6m9014830; Wed, 11 Dec 2013 15:49:07 -0600 (CST) Message-ID: <52A8DDD2.1060606@centurylink.com> Date: Wed, 11 Dec 2013 14:49:06 -0700 From: Charles Cook User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121005 Thunderbird/16.0 MIME-Version: 1.0 To: Sharam Hakimi References: <2D09D61DDFA73D4C884805CC7865E611303993CD@GAALPA1MSGUSR9L.ITServices.sbc.com> <20131210223947.GD39105@idrathernotsay.com> <084CDC75FEC1E640B60338273BEACDFA029B235C@spboexc01.exfo.com> In-Reply-To: <084CDC75FEC1E640B60338273BEACDFA029B235C@spboexc01.exfo.com> X-Enigmail-Version: 1.4.6 Content-Type: multipart/alternative; boundary="------------090602030408000308000508" X-CFilter-Loop: Reflected Cc: Steve Miller , "Bugenhagen, Michael K" , lmap@ietf.org, "STARK, BARBARA H" Subject: Re: [lmap] degrees of Measurement Suppression X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: charles.cook2@centurylink.com List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 21:49:30 -0000 This is a multi-part message in MIME format. --------------090602030408000308000508 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Summarizing this email chain: · Although not prohibited, measurements without end times (ones that could run forever) should be discouraged. (I do think I saw a sentence in the draft along these lines.) · It may be beneficial to place caps on end-user requested measurements. · In the absence of a crystal ball, it is important to have a measurement system that will scale, and be able to successfully turn off measurement activities should there be a need to do so. · We don't want to literally do "anything possible" to improve communications in an emergency. But we do want to have simple-to-implement mechanisms to control measurement traffic that will help improve overall non-measurement communications. · We want the measurement system to have sufficient flexibility that ISP Operations can use it to conduct various exercises in their own network. · We don't want to make the measurement system complex. · Measurement traffic should be a small fraction, "way down in the weeds", of the overall traffic in the network. · In an emergency, it may not be possible to reliably reach an MA. Possible Suppression Solutions: 1) Continual (periodic) 2-way communications between the Measurement Controller and the MA. This was given as an example, and it was pointed out that in an emergency this approach may be unreliable. 2) A two-state on/off mechanism that is controlled by the Measurement Controller sending Instructions to the MA. This has the issue that communication between the Measurement Controller and MA may not be reliable in an emergency. Additionally, this requires the Measurement Controller to send a message to each MA that has a schedule that permits it to participate in measurements at the time of the emergency. 3) A two-state on/off mechanism that is controlled by a timeout at the MA if the MA has not heard anything from the Measurement Controller. This results in the MA eventually terminating measurements, but it requires that the Measurement Controller to periodically send keep-alive messages when the network is not in an emergency state. Also, the responsiveness of the network depends on what the Measurement Controller keep-alive period is set to, and the length that the timer in the MA is set to. 4) A two-state on/off mechanism where the MA periodically checks the state of the network and conducts behavior based on the state of the network. If the MA is unable to retrieve network state information, it assumes the network is in an emergency state and acts accordingly. The state of the network could be provided by the Measurement Controller, a server in the Operational Domain that is responsible for the MAs belonging to that Operational Domain, or both. The Operational Domain can provision the MA as appropriate (frequency of network state checks, address of network state server(s)). I don't think that any of these solutions would preclude a Measurement Controller sending a blank Instruction to the MA to shut down measurements (assuming the network is able to reliably deliver the Instruction to the MA). I am sure there are other solutions. Of the ones listed so far, I prefer #4. There is also a question of whether two network states are sufficient. We don't want too many states because that results in additional complexity. Possible solutions include: 1) Two states: on (continue measurements), and off (cease measurements immediately). 2) Three states: on (continue measurements), off (cease measurements immediately), and limited (limit measurements per parameters in the Instruction sent by the Measurement Controller). 3) N states: ??? 4) Two states mandated, but additional states allowed. Simple MAs will support two states (on and off). More advanced MAs can support more elaborate responses to a network emergency. Again, I am sure there are other solutions. Of the ones listed so far, I prefer #2 and #4. Charles On 12/11/2013 9:14 AM, Sharam Hakimi wrote: > Mike, > There two ways of having this control which would work in the system and > do what you would like. They are > > > 1: The MA device MUST stop testing if it has not heard from the > MC in a designated time ( we had talked about putting this in > the document. > > 2: In an emergency the MC can issue a BLANK test schedule that > would override whatever the MA is scheduled to do. > ( and if MA cannot receive this it will automatically > stop) > > > Thanks, > Sharam > > > > > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Bugenhagen, > Michael K > Sent: Wednesday, December 11, 2013 9:21 AM > To: 'Steve Miller' > Cc: 'STARK, BARBARA H'; 'lmap@ietf.org' > Subject: Re: [lmap] degrees of Measurement Suppression > > Steve - > > Operational design groups have these frameworks historically - and > they control the deployment of test systems so adoption issues can and > do occur with these types of systems that can load the network. > I think it's fairly simple to take away those concerns by addressing > them vs. discarding what may be a legitimate issue for and ISP to adopt > the framework. > > > If we can't reach consensus on the hard requirement I recommend one of > two paths. > 1) Add those added safety measures but make them optional. > And or > 2) Partition the tests (which I think we're doing) so that they can be > adopted into existing test control schemas that fit the ISP's need. > > > > My concern on the way it is currently drafted - > I'm just afraid that the current control schema might miss the target > for the #1 use case for all ISP's, which "large" somewhat infers all > ISP's would find the control framework suitable. > I understand the added complexity argument, but if it's required to meet > hard operational criteria (and this has been discussed else where) then > it's probably worth the effort to ensure that this work is > reference-able and revelent to all. There are a few more Key blind > spots in this framework as well that make it's current form and > longevity suspect. > > > > To resolve the "is this a real op's issue" - > Let's see if we can't get some IETF ISP members to ping their OP's > groups on if they restrict load testing the network for any reason - if > yes.. then we need to look at phases. > BTW - every Op's group I've been in has situations where they don't from > the customer level on UP... aka you don't load a congested customer > unless you're taking them out of service and they know it, and you don't > stress a "trunk" of shared path that's severely congested and in trouble > either through fault or due un-usual circumstance. (an earthquake > drops building in a city and you want every bit available to be there > for use, not test traffic). > > Cheers - > Mike > > > > > > > > > > > > > > -----Original Message----- > From: Steve Miller [mailto:steve@idrathernotsay.com] > Sent: Tuesday, December 10, 2013 4:40 PM > To: Bugenhagen, Michael K > Cc: 'STARK, BARBARA H'; 'lmap@ietf.org' > Subject: Re: [lmap] degrees of Measurement Suppression > > If we are testing at a rate where leaving the tests running during a > national emergency will make a meaningful difference as to whether or > not lives are saved, we shouldn't be testing at that rate even during > normal operation. Relying on the ability to turn anything off -- in an > active manner at least -- during an emergency seems like something we > should avoid: I'd think that anyone who's experienced making a phone > call just after a natural disaster would be able to testify as to the > flakiness of any communications medium under those circumstances. > > A key (and maybe *the* key) element here is that in many cases the > time you must want to hit the big red off switch is the time at which > you are least able to communicate with the MAs. > > The other autoshutdown stuff that's been discussed so far would give > people the flexibility to implement the only policy that truly seems > important: the one that disables measurements after N > seconds/minutes/hours/days in which the MA can't reach the controller. > It's been my experience that no matter how important that seems on > paper, it ends up being much, much less critical than it seems in the > Real World. Still, leaving this binary on/off level of control in place > makes some sense: it's easy to code, it's pretty innocuous, the > additional load on the controller infrastructure shouldn't be that bad, > and it avoids the "three million old devices hammering some poor > destination that belongs to the people who bought some defunct ISP" > problem. It's also been my experience that even that level of control > isn't needed and can in fact cause problems of its own, but I recognize > that this scenario is a little different. I still think we should not > overcomplicate things. > > -Steve > (who still needs to read the updated I-Ds, hopefully early next > week, sorry) > > On Tue, Dec 10, 2013 at 10:16:58PM +0000, Bugenhagen, Michael K wrote: >> I concur with Barbara - >> >> Stated a bit differently - If LMAP says put this probe on everything > (Part of the introduction statement)... >> Then >> >> 1) They will want a suppression method that allows them to disable it > in case of national emergency - saving lives via emergency communication > takes priority in their minds. >> So they typically will ask for 2 each Safety breaks. >> 1 from the controller >> A second from a element controller or whatever > configures the element in the first place. >> These "MA unavailable" states should also be recorded for > transparency sake. >> >> 2) Op's folks like to test - even when things are going bad.. > otherwise fault isolation is hard to do. >> So suppression should have 3 levels (again this goes back to > everyone has a probe) - >> Green = do as you will (test anything) >> Yellow - don't load anything - restrict testing that will load > the network, or kick up CPU cycles ...but allow fault testing (NO > Saturation tests, ....)( >> RED - Stop, don't pass go, ... ADHOC testing only >> >> >> If USE case 1 is the ISP - not adopting those types of Op's > requirements would get a significant amount of pushback on the > implementation side. >> Regards, >> Mike >> >> >> >> >> -----Original Message----- >> From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf > Of STARK, BARBARA H >> Sent: Tuesday, November 12, 2013 10:50 AM >> To: lmap@ietf.org >> Subject: [lmap] degrees of Measurement Suppression >> >> A number of providers have discussed a model of Measurement > Suppression that supports more granular degrees of suppression (other > than just suppress and don't suppress). Michael Bugenhagen presented the > original version of this model, and he said it would be ok if I brought > it up to IETF. >> Following are highlights of the proposal (with some modifications I've > included as a result of additional discussion): >> 1. Measurement Methods (or perhaps Tasks) have a configurable > parameter that indicates whether the Controller operator considers them > to be "critical for OAM", "not critical, but not resource intensive", > and "not critical and resource intensive". >> 2. The Controller can specify degrees of Measurement Suppression, > which should include: halt all non-critical tasks immediately but allow > OAM tasks; halt resource-intensive tasks immediately but allow > non-resource-intensive tasks; finish resource intensive tasks but do not > start new resource-intensive tasks and allow all non-resource-intensive > tasks; allow all tasks. >> 3. It may also be possible for the unspecified bootstrap mechanism to > instruct the MA to suppress measurements. Where multiple channels exist > for Measurement Suppression (e.g., Controller and bootstrap), the MA is > to use the most restrictive setting. >> Barbara >> >> >> _______________________________________________ >> 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 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap -- Charles Cook Principal Architect Network 5325 Zuni Street; Suite 224 Denver, CO 80221 Tel: 303.992.8952 Fax: 925.281.0662 charles.cook2@centurylink.com --------------090602030408000308000508 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Summarizing this email chain:

·         Although not prohibited, measurements without end times (ones that could run forever) should be discouraged.  (I do think I saw a sentence in the draft along these lines.)

·         It may be beneficial to place caps on end-user requested measurements.

·         In the absence of a crystal ball, it is important to have a measurement system that will scale, and be able to successfully turn off measurement activities should there be a need to do so.

·         We don’t want to literally do “anything possible” to improve communications in an emergency.  But we do want to have simple-to-implement mechanisms to control measurement traffic that will help improve overall non-measurement communications.

·         We want the measurement system to have sufficient flexibility that ISP Operations can use it to conduct various exercises in their own network.

·         We don’t want to make the measurement system complex.

·         Measurement traffic should be a small fraction, “way down in the weeds”, of the overall traffic in the network.

·         In an emergency, it may not be possible to reliably reach an MA.

 

Possible Suppression Solutions:

1)      Continual (periodic) 2-way communications between the Measurement Controller and the MA.  This was given as an example, and it was pointed out that in an emergency this approach may be unreliable.

2)      A two-state on/off mechanism that is controlled by the Measurement Controller sending Instructions to the MA.  This has the issue that communication between the Measurement Controller and MA may not be reliable in an emergency.  Additionally, this requires the Measurement Controller to send a message to each MA that has a schedule that permits it to participate in measurements at the time of the emergency.

3)      A two-state on/off mechanism that is controlled by a timeout at the MA if the MA has not heard anything from the Measurement Controller.  This results in the MA eventually terminating measurements, but it requires that the Measurement Controller to periodically send keep-alive messages when the network is not in an emergency state.  Also, the responsiveness of the network depends on what the Measurement Controller keep-alive period is set to, and the length that the timer in the MA is set to.

4)      A two-state on/off mechanism where the MA periodically checks the state of the network and conducts behavior based on the state of the network.  If the MA is unable to retrieve network state information, it assumes the network is in an emergency state and acts accordingly.  The state of the network could be provided by the Measurement Controller, a server in the Operational Domain that is responsible for the MAs belonging to that Operational Domain, or both.  The Operational Domain can provision the MA as appropriate (frequency of network state checks, address of network state server(s)).

 

I don’t think that any of these solutions would preclude a Measurement Controller sending a blank Instruction to the MA to shut down measurements (assuming the network is able to reliably deliver the Instruction to the MA). 

 

I am sure there are other solutions.  Of the ones listed so far, I prefer #4.

 

There is also a question of whether two network states are sufficient.  We don’t want too many states because that results in additional complexity.  Possible solutions include:

 

1)      Two states:  on (continue measurements), and off (cease measurements immediately).

2)      Three states:  on (continue measurements), off (cease measurements immediately), and limited (limit measurements per parameters in the Instruction sent by the Measurement Controller). 

3)      N states:  ???

4)      Two states mandated, but additional states allowed.  Simple MAs will support two states (on and off).  More advanced MAs can support more elaborate responses to a network emergency.

 

Again, I am sure there are other solutions.  Of the ones listed so far, I prefer #2 and #4.

 

Charles

On 12/11/2013 9:14 AM, Sharam Hakimi wrote:
Mike,
There two ways of having this control which would work in the system and
do what you would like. They are


	1: The MA device MUST stop testing if it has not heard from the
MC in a designated time  ( we had talked about 		putting this in
the document.

	2: In an emergency the MC can issue a BLANK test schedule that
would override whatever the MA is scheduled to do.
		( and if MA cannot receive this it will automatically
stop)


Thanks,
Sharam 


		

-----Original Message-----
From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Bugenhagen,
Michael K
Sent: Wednesday, December 11, 2013 9:21 AM
To: 'Steve Miller'
Cc: 'STARK, BARBARA H'; 'lmap@ietf.org'
Subject: Re: [lmap] degrees of Measurement Suppression

Steve -

    Operational design groups have these frameworks historically - and
they control the deployment of test systems so adoption issues can and
do occur with these types of systems that can load the network.
I think it's fairly simple to take away those concerns by addressing
them vs. discarding what may be a legitimate issue for and ISP to adopt
the framework.        


If we can't reach consensus on the hard requirement I recommend one of
two paths.
1) Add those added safety measures but make them optional.
And or 
2) Partition the tests (which I think we're doing) so that they can be
adopted into existing test control schemas that fit the ISP's need.



My concern on the way it is currently drafted -
  I'm just afraid that the current control schema might miss the target
for the #1 use case for all ISP's, which "large" somewhat infers all
ISP's would find the control framework suitable.
I understand the added complexity argument, but if it's required to meet
hard operational criteria (and this has been discussed else where) then
it's probably worth the effort to ensure that this work is
reference-able and revelent to all.     There are a few more Key blind
spots in this framework as well that make it's current form and
longevity suspect.



To resolve the "is this a real op's issue"  -
Let's see if we can't get some IETF ISP members to ping their OP's
groups on if they restrict load testing the network for any reason - if
yes.. then we need to look at phases.
BTW - every Op's group I've been in has situations where they don't from
the customer level on UP... aka you don't load a congested customer
unless you're taking them out of service and they know it, and you don't
stress a "trunk" of shared path that's severely congested and in trouble
either through fault or due un-usual circumstance.   (an earthquake
drops building in a city and you want every bit available to be there
for use, not test traffic).

Cheers - 
Mike








 




-----Original Message-----
From: Steve Miller [mailto:steve@idrathernotsay.com] 
Sent: Tuesday, December 10, 2013 4:40 PM
To: Bugenhagen, Michael K
Cc: 'STARK, BARBARA H'; 'lmap@ietf.org'
Subject: Re: [lmap] degrees of Measurement Suppression

   If we are testing at a rate where leaving the tests running during a
national emergency will make a meaningful difference as to whether or
not lives are saved, we shouldn't be testing at that rate even during
normal operation.  Relying on the ability to turn anything off -- in an
active manner at least -- during an emergency seems like something we
should avoid: I'd think that anyone who's experienced making a phone
call just after a natural disaster would be able to testify as to the
flakiness of any communications medium under those circumstances.

   A key (and maybe *the* key) element here is that in many cases the
time you must want to hit the big red off switch is the time at which
you are least able to communicate with the MAs.

   The other autoshutdown stuff that's been discussed so far would give
people the flexibility to implement the only policy that truly seems
important: the one that disables measurements after N
seconds/minutes/hours/days in which the MA can't reach the controller.
It's been my experience that no matter how important that seems on
paper, it ends up being much, much less critical than it seems in the
Real World.  Still, leaving this binary on/off level of control in place
makes some sense: it's easy to code, it's pretty innocuous, the
additional load on the controller infrastructure shouldn't be that bad,
and it avoids the "three million old devices hammering some poor
destination that belongs to the people who bought some defunct ISP"
problem.  It's also been my experience that even that level of control
isn't needed and can in fact cause problems of its own, but I recognize
that this scenario is a little different.  I still think we should not
overcomplicate things.

	-Steve
	(who still needs to read the updated I-Ds, hopefully early next
week, sorry)

On Tue, Dec 10, 2013 at 10:16:58PM +0000, Bugenhagen, Michael K wrote:

I concur with Barbara -

  Stated a bit differently - If LMAP says put this probe on everything

(Part of the introduction statement)...

Then 

1)  They will want a suppression method that allows them to disable it

in case of national emergency - saving lives via emergency communication
takes priority in their minds.

    So they typically will ask for 2 each Safety breaks.
		1 from the controller
		A second from a element controller or whatever

configures the element in the first place.   

   These "MA unavailable" states should also be recorded for

transparency sake.


2)  Op's folks like to test - even when things are going bad..

otherwise fault isolation is hard to do.

	So suppression should have 3 levels (again this goes back to

everyone has a probe) -

	Green = do as you will (test anything)
	Yellow - don't load anything - restrict testing that will load

the network, or kick up CPU cycles ...but allow fault testing (NO
Saturation tests, ....)(

	RED - Stop, don't pass go, ... ADHOC testing only


If USE case 1 is the ISP - not adopting those types of Op's

requirements would get a significant amount of pushback on the
implementation side.

Regards,
Mike




-----Original Message-----
From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf

Of STARK, BARBARA H

Sent: Tuesday, November 12, 2013 10:50 AM
To: lmap@ietf.org
Subject: [lmap] degrees of Measurement Suppression

A number of providers have discussed a model of Measurement

Suppression that supports more granular degrees of suppression (other
than just suppress and don't suppress). Michael Bugenhagen presented the
original version of this model, and he said it would be ok if I brought
it up to IETF.

Following are highlights of the proposal (with some modifications I've

included as a result of additional discussion):

1. Measurement Methods (or perhaps Tasks) have a configurable

parameter that indicates whether the Controller operator considers them
to be "critical for OAM", "not critical, but not resource intensive",
and "not critical and resource intensive".

2. The Controller can specify degrees of Measurement Suppression,

which should include: halt all non-critical tasks immediately but allow
OAM tasks; halt resource-intensive tasks immediately but allow
non-resource-intensive tasks; finish resource intensive tasks but do not
start new resource-intensive tasks and allow all non-resource-intensive
tasks; allow all tasks.

3. It may also be possible for the unspecified bootstrap mechanism to

instruct the MA to suppress measurements. Where multiple channels exist
for Measurement Suppression (e.g., Controller and bootstrap), the MA is
to use the most restrictive setting.

Barbara


_______________________________________________
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
_______________________________________________
lmap mailing list
lmap@ietf.org
https://www.ietf.org/mailman/listinfo/lmap


-- 

Charles Cook 
Principal Architect
Network
5325 Zuni Street; Suite 224
Denver, CO  80221
Tel:  303.992.8952  Fax:  925.281.0662
charles.cook2@centurylink.com
--------------090602030408000308000508-- From philip.eardley@bt.com Thu Dec 12 01:06:47 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5E631AE201 for ; Thu, 12 Dec 2013 01:06:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zcojf3VJbxEg for ; Thu, 12 Dec 2013 01:06:46 -0800 (PST) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.234]) by ietfa.amsl.com (Postfix) with ESMTP id E0A4F1ADF63 for ; Thu, 12 Dec 2013 01:06:45 -0800 (PST) Received: from EVMHT61-UKRD.domain1.systemhost.net (10.36.3.127) by RDW083A005ED61.bt.com (10.187.98.10) with Microsoft SMTP Server (TLS) id 14.3.169.1; Thu, 12 Dec 2013 09:06:45 +0000 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.1.75]) by EVMHT61-UKRD.domain1.systemhost.net ([10.36.3.127]) with mapi; Thu, 12 Dec 2013 09:06:38 +0000 From: To: , Date: Thu, 12 Dec 2013 09:06:36 +0000 Thread-Topic: [lmap] degrees of Measurement Suppression Thread-Index: Ac7fxy6a9B101VqJQi6oteMX5LjSDgWLXOxQAA2YtIAAE2A9AAAoLzJQ Message-ID: References: <2D09D61DDFA73D4C884805CC7865E611303993CD@GAALPA1MSGUSR9L.ITServices.sbc.com> <20131210223947.GD39105@idrathernotsay.com> In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: bs7652@att.com, lmap@ietf.org Subject: Re: [lmap] degrees of Measurement Suppression X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 09:06:48 -0000 > There are a few more Key blind > spots in this framework as well that make it's current form and > longevity suspect. >=20 Please could you let us know as soon as possible what these are. As far as = I know, suppression is the only open issue. Thanks phil From Michael.K.Bugenhagen@centurylink.com Fri Dec 13 06:56:59 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 144281AE2E7 for ; Fri, 13 Dec 2013 06:56:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PplhAlWOQbPs for ; Fri, 13 Dec 2013 06:56:56 -0800 (PST) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by ietfa.amsl.com (Postfix) with ESMTP id C84631AE2E4 for ; Fri, 13 Dec 2013 06:56:56 -0800 (PST) Received: from lxomavmpc030.qintra.com (lxomavmpc030.qintra.com [151.117.207.30]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id rBDEui7a001954 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Dec 2013 08:56:45 -0600 (CST) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id B11C01E0066; Fri, 13 Dec 2013 08:56:39 -0600 (CST) Received: from suomp61i.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id 92CA81E0063; Fri, 13 Dec 2013 08:56:39 -0600 (CST) Received: from suomp61i.qintra.com (localhost [127.0.0.1]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id rBDEudeZ017737; Fri, 13 Dec 2013 08:56:39 -0600 (CST) Received: from vodcwhubex501.ctl.intranet (vodcwhubex501.ctl.intranet [151.117.206.27]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id rBDEucex017718 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 13 Dec 2013 08:56:39 -0600 (CST) Received: from PODCWMBXEX505.ctl.intranet ([fe80::f87e:fe44:ad72:b610]) by vodcwhubex501.ctl.intranet ([151.117.206.27]) with mapi id 14.03.0158.001; Fri, 13 Dec 2013 08:56:38 -0600 From: "Bugenhagen, Michael K" To: "'philip.eardley@bt.com'" , "'steve@idrathernotsay.com'" Thread-Topic: [lmap] degrees of Measurement Suppression Thread-Index: Ac7fxy6a9B101VqJQi6oteMX5LjSDgWLXOxQAA2YtIAAE2A9AAAoLzJQAAtoqGA= Date: Fri, 13 Dec 2013 14:56:37 +0000 Message-ID: References: <2D09D61DDFA73D4C884805CC7865E611303993CD@GAALPA1MSGUSR9L.ITServices.sbc.com> <20131210223947.GD39105@idrathernotsay.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.8] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "'bs7652@att.com'" , "'lmap@ietf.org'" Subject: Re: [lmap] degrees of Measurement Suppression X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 14:56:59 -0000 >-----Original Message----- >From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]=20 >Sent: Thursday, December 12, 2013 3:07 AM >To: Bugenhagen, Michael K; steve@idrathernotsay.com >Cc: bs7652@att.com; lmap@ietf.org >Subject: RE: [lmap] degrees of Measurement Suppression > >> There are a few more Key blind >> spots in this framework as well that make it's current form and=20 >> longevity suspect. >>=20 > **********>Please could you let us know as soon as possible what these are.= As far as I know, suppression is the only open issue. > >Thanks >Phil ----------------------------------------- Response starts here - Ok - 3 each items I think we could use some more clear visionary planks on= in terms of the state of the industry and the goals of the project (scope)= =20 ** summary statement at the bottom=20 - please note I don't disagree with the current path, I think we need to = ensure strong focus on the project concepts that will make the solution as = relevant as possible (just like the rest of us). So sharing some op's experience background.... and some hopefully reasonabl= e observations As you read this please consider I have a Strategic implementation consulta= nt hat on - as to how do the roadmaps of the ISP, vendor, and our goal of l= ow cost collide.... ----------- 1) The Collapsing down of the number of MA's (aka ISP challenges with multi= ple probes and test solutions) Vendors produce testing solutions follow "operationalization" timelines of= the ISP services. Eg. General IP testing solutions appeared first, then VoIP testing soluti= ons, then Video Over IP .... Different Operation centers "owned" different test solutions (unlike TDM= where a single solution sufficed). Given there is always a "best in bread" test solution, and each vendor t= ends to target their market and focus their development this naturally lead= s to multiple test solutions. The hitch - - Maturity wise ISP's who offer Broadband, VoIP and Video need MA's to tes= t all of those services on the same device - but MA's aren't designed to co= -exist which leads to implementation issues (collision space). =09 Ideal things to address=20 - Cost of 2-3 MA's and test systems vs. a single test system (the risk i= n LMAP is the "yet another test system") cost - Portability of test so if an ISP is collapsing 2-3 test systems into o= ne (ideal solution to lower cost) ** WE ARE DOING THIS... My personal recommendation For #1- Cost is relevant so - focus a bit more= on standardizing portable test that work under any controller / MA combina= tion as this will lower cost vs. them being required to be under a new test= ing system. Otherwise stated, ensure the sticky-ness of the solution. ------------------ 2) New small form factor test devices (aka available Vendor solutions emerg= ing on the scene) If we observe test solution vendors a good amount of them are now providin= g small form factor test engines due to the lower cost CPU's in Modems and = set top boxes NOT having enough power to run probes. This is one heck of a strong signal that the multiple probe approach is fa= iling.... Currently we identify this as possible (hardware to use as a probe) but we= don't define or categorize how that would work. This is a test solution evolution path where by some standard modularity o= r "abstraction model" involves a framework whereby a small form factor hard= ware is added in a standard fashion to an element. Given the industry headed this way we may want to consider figuring out ho= w to frame that as a standard so those devices can be swapped out and suppo= rt this testing (avoid proprietary nature of the implementation). My recommendation for #2 - This infers that each test we define needs to h= ave a general abstraction model for the test that each vendor can implement= (Standard MIB, UML per test) to enable ISP's to swap out vendor hardware y= et have equivalent tests. =20 ------------ 3) NFV (Network function virtualization - aka 2-3 year if not less framewor= ks) Aka Cloud, here we see that NFV under ETSI is actively defining a framewor= k where by modems, STB, .... become virtualized elements, and can support v= irtualization. In this genre probes become virtualized applications much like the Android= , and Iphone app's today where one can download them. Putting on the visionary goggles - that means that one day it would be rea= sonable for a ISP to provide a virtualized application one could download t= o your modem or mobile phone to conduct the testing. It also means that Tight integration between the Service attributes and th= e probe are now possible. ** HUGE amount of man-hour savings here. =09 Recommendations for #3 - NFV means stating that the MA becomes something t= hat can be run in an virtualized environment as a application from the Infr= astructure provider (STB, modem, ... and tweaked for the ISP) That is if you want lowest cost... ------ Summary statement ---=20 Those are the big ones that have me concerned that all the LMAP controller = work could result in Yet another Testing System (YATS) - that's NOT a bad t= hing, and may be required - but we should be aware of the nature of matter = that we're asking for low or no cost, but building something that costs mor= e unless we do the portability to match the industry roadmap.=20 At the end of the day If I'm an ISP offering and testing services, to get t= he low / no cost as an ISP I'm going to have to wind the tests into my curr= ent deck of testing control vs. building another system =20 From Michael.K.Bugenhagen@centurylink.com Fri Dec 13 07:04:34 2013 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B8911AE24A for ; Fri, 13 Dec 2013 07:04:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ly9ynzWJwe_5 for ; Fri, 13 Dec 2013 07:04:31 -0800 (PST) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by ietfa.amsl.com (Postfix) with ESMTP id A56EB1AE22A for ; Fri, 13 Dec 2013 07:04:31 -0800 (PST) Received: from lxdenvmpc030.qintra.com (lxdenvmpc030.qintra.com [10.1.51.30]) by sudnp799.qwest.com (8.14.4/8.14.4) with ESMTP id rBDF4Gux010058 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Dec 2013 08:04:17 -0700 (MST) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id D403B1E009A; Fri, 13 Dec 2013 08:04:04 -0700 (MST) Received: from sudnp796.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id B6D8D1E0089; Fri, 13 Dec 2013 08:04:04 -0700 (MST) Received: from sudnp796.qintra.com (localhost [127.0.0.1]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id rBDF2rsA019524; Fri, 13 Dec 2013 08:02:53 -0700 (MST) Received: from vodcwhubex501.ctl.intranet (vodcwhubex501.ctl.intranet [151.117.206.27]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id rBDF2qO1019504 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 13 Dec 2013 08:02:53 -0700 (MST) Received: from PODCWMBXEX505.ctl.intranet ([fe80::f87e:fe44:ad72:b610]) by vodcwhubex501.ctl.intranet ([151.117.206.27]) with mapi id 14.03.0158.001; Fri, 13 Dec 2013 09:02:52 -0600 From: "Bugenhagen, Michael K" To: "Bugenhagen, Michael K" , "'philip.eardley@bt.com'" , "'steve@idrathernotsay.com'" Thread-Topic: [lmap] degrees of Measurement Suppression Thread-Index: Ac7fxy6a9B101VqJQi6oteMX5LjSDgWLXOxQAA2YtIAAE2A9AAAoLzJQAAtoqGAAM1pcoA== Date: Fri, 13 Dec 2013 15:02:52 +0000 Message-ID: References: <2D09D61DDFA73D4C884805CC7865E611303993CD@GAALPA1MSGUSR9L.ITServices.sbc.com> <20131210223947.GD39105@idrathernotsay.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.8] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "'bs7652@att.com'" , "'lmap@ietf.org'" Subject: Re: [lmap] degrees of Measurement Suppression X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 15:04:34 -0000 When I said "We are doing this" under test portability I'm saying that give= n the test definitions are under the registry they should be portable.... -----Original Message----- From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Bugenhagen, Michael = K Sent: Friday, December 13, 2013 8:57 AM To: 'philip.eardley@bt.com'; 'steve@idrathernotsay.com' Cc: 'bs7652@att.com'; 'lmap@ietf.org' Subject: Re: [lmap] degrees of Measurement Suppression >-----Original Message----- >From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] >Sent: Thursday, December 12, 2013 3:07 AM >To: Bugenhagen, Michael K; steve@idrathernotsay.com >Cc: bs7652@att.com; lmap@ietf.org >Subject: RE: [lmap] degrees of Measurement Suppression > >> There are a few more Key blind >> spots in this framework as well that make it's current form and=20 >> longevity suspect. >>=20 > **********>Please could you let us know as soon as possible what these are.= As far as I know, suppression is the only open issue. > >Thanks >Phil ----------------------------------------- Response starts here - Ok - 3 each items I think we could use some more clear visionary planks on= in terms of the state of the industry and the goals of the project (scope) ** summary statement at the bottom - please note I don't disagree with the current path, I think we need to = ensure strong focus on the project concepts that will make the solution as = relevant as possible (just like the rest of us). So sharing some op's experience background.... and some hopefully reasonabl= e observations As you read this please consider I have a Strategic implemen= tation consultant hat on - as to how do the roadmaps of the ISP, vendor, an= d our goal of low cost collide.... ----------- 1) The Collapsing down of the number of MA's (aka ISP challenges with multi= ple probes and test solutions) Vendors produce testing solutions follow "operationalization" timelines of= the ISP services. Eg. General IP testing solutions appeared first, then VoIP testing soluti= ons, then Video Over IP .... Different Operation centers "owned" different test solutions (unlike TDM= where a single solution sufficed). Given there is always a "best in bread" test solution, and each vendor t= ends to target their market and focus their development this naturally lead= s to multiple test solutions. The hitch - - Maturity wise ISP's who offer Broadband, VoIP and Video need MA's to tes= t all of those services on the same device - but MA's aren't designed to co= -exist which leads to implementation issues (collision space). =09 Ideal things to address=20 - Cost of 2-3 MA's and test systems vs. a single test system (the risk i= n LMAP is the "yet another test system") cost - Portability of test so if an ISP is collapsing 2-3 test systems into o= ne (ideal solution to lower cost) ** WE ARE DOING THIS... My personal recommendation For #1- Cost is relevant so - focus a bit more= on standardizing portable test that work under any controller / MA combina= tion as this will lower cost vs. them being required to be under a new test= ing system. Otherwise stated, ensure the sticky-ness of the solution. ------------------ 2) New small form factor test devices (aka available Vendor solutions emerg= ing on the scene) If we observe test solution vendors a good amount of them are now providin= g small form factor test engines due to the lower cost CPU's in Modems and = set top boxes NOT having enough power to run probes. This is one heck of a strong signal that the multiple probe approach is fa= iling.... Currently we identify this as possible (hardware to use as a probe) but we= don't define or categorize how that would work. This is a test solution evolution path where by some standard modularity o= r "abstraction model" involves a framework whereby a small form factor hard= ware is added in a standard fashion to an element. Given the industry headed this way we may want to consider figuring out ho= w to frame that as a standard so those devices can be swapped out and suppo= rt this testing (avoid proprietary nature of the implementation). My recommendation for #2 - This infers that each test we define needs to h= ave a general abstraction model for the test that each vendor can implement= (Standard MIB, UML per test) to enable ISP's to swap out vendor hardware y= et have equivalent tests. =20 ------------ 3) NFV (Network function virtualization - aka 2-3 year if not less framewor= ks) Aka Cloud, here we see that NFV under ETSI is actively defining a framewor= k where by modems, STB, .... become virtualized elements, and can support v= irtualization. In this genre probes become virtualized applications much like the Android= , and Iphone app's today where one can download them. Putting on the visionary goggles - that means that one day it would be rea= sonable for a ISP to provide a virtualized application one could download t= o your modem or mobile phone to conduct the testing. It also means that Tight integration between the Service attributes and th= e probe are now possible. ** HUGE amount of man-hour savings here. =09 Recommendations for #3 - NFV means stating that the MA becomes something t= hat can be run in an virtualized environment as a application from the Infr= astructure provider (STB, modem, ... and tweaked for the ISP) That is if you want lowest cost... ------ Summary statement --- Those are the big ones that have me concerned that all the LMAP controller = work could result in Yet another Testing System (YATS) - that's NOT a bad t= hing, and may be required - but we should be aware of the nature of matter = that we're asking for low or no cost, but building something that costs mor= e unless we do the portability to match the industry roadmap.=20 At the end of the day If I'm an ISP offering and testing services, to get t= he low / no cost as an ISP I'm going to have to wind the tests into my curr= ent deck of testing control vs. building another system =20 _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap