Re: [lmap] Feedback on draft-eardley-lmap-terminology

Paul Aitken <paitken@cisco.com> Wed, 24 July 2013 21:07 UTC

Return-Path: <paitken@cisco.com>
X-Original-To: lmap@ietfa.amsl.com
Delivered-To: lmap@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C541021F90FB for <lmap@ietfa.amsl.com>; Wed, 24 Jul 2013 14:07:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KhmmtCBnoGkj for <lmap@ietfa.amsl.com>; Wed, 24 Jul 2013 14:07:37 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 93EB811E8268 for <lmap@ietf.org>; Wed, 24 Jul 2013 14:07:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1579; q=dns/txt; s=iport; t=1374700048; x=1375909648; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=eYmmOhpgB7DmMuNQUC8PUhoUMHybXL8Sl+Nd6OXWR/4=; b=HgxXZnFVDSJdiyuyzTo734OUcEzJvpD/WFn/NaX1O6bFF6CPDVDqzIDz DZEyyTosaHjLQDfQf2vylI3blkhse8r7qAIgO/1nw5Nub98mbdunKNN4m tmPs80LKyoIh8GKFIwxal2m/FbGQAE/pOXJAo7DiUNY/Rjawlv+3OU4i/ M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AjcFAEZB8FGQ/khM/2dsb2JhbABbgwY2vjaBFhZ0giQBAQEDATg0DAYLCxgJFg8JAwIBAgFFBgEMCAEBiAYGugyQBIQAA5dfhiOLKoMVgWcE
X-IronPort-AV: E=Sophos;i="4.89,737,1367971200"; d="scan'208";a="157502982"
Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 24 Jul 2013 21:07:14 +0000
Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r6OL7CFZ020464 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Jul 2013 21:07:12 GMT
Received: from [10.61.164.215] ([10.61.164.215]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r6OL79kq011962; Wed, 24 Jul 2013 22:07:11 +0100 (BST)
Message-ID: <51F041FD.4050408@cisco.com>
Date: Wed, 24 Jul 2013 22:07:09 +0100
From: Paul Aitken <paitken@cisco.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130623 Thunderbird/17.0.7
MIME-Version: 1.0
To: marcelo bagnulo braun <marcelo@it.uc3m.es>, lmap@ietf.org
References: <51ED59B3.3040701@cisco.com> <9904FB1B0159DA42B0B887B7FA8119CA1287FC5D@AZ-FFEXMB04.global.avaya.com> <51EFEC2A.9010701@cisco.com> <51F0297A.7040407@it.uc3m.es> <51F0367F.1060905@cisco.com> <20130724204924.GA40227@elstar.local>
In-Reply-To: <20130724204924.GA40227@elstar.local>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [lmap] Feedback on draft-eardley-lmap-terminology
X-BeenThere: lmap@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Large Scale Measurement of Access network Performance <lmap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lmap>, <mailto:lmap-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/lmap>
List-Post: <mailto:lmap@ietf.org>
List-Help: <mailto:lmap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lmap>, <mailto:lmap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Jul 2013 21:07:43 -0000

Juergen,

> On Wed, Jul 24, 2013 at 09:18:07PM +0100, Paul Aitken wrote:
>   
>> MA's should do what they're requested by controllers as best as
>> they're able. I can't immediately think of a situation where an MA
>> could be given conflicting instructions. However, if conflicts are
>> possible the MA could enqueue the requested tests to be run
>> sequentially to avoid inter-test conflict. If conflict can arise
>> from two controllers, then it can also arise by requesting the same
>> tests from a single controller - so designing this limitation into
>> the system gains nothing.
> C1: do test X
> C2: don't do test X

You're supposing inter-controller communication, such that C2 knows that 
C1 requested X ?

The MA should do test X as requested by C1. It should ignore the command 
from C2, because C2 didn't request test X.

It's clearer if the sequence was:

C2: do test X
C1: do test X
C2: don't do test X


Then C2 is cancelling its previous command, whereas C1's command stands.


> or
>
> C1: do test X every 10 minutes
> C2: do test X every 8 minutes
>
> What should the MA do?

The MA should do test X multiple times exactly as requested.

If both requests are received at exactly the same instant (which is a 
corner case, even if we're talking about multiple processors + multiple 
interfaces), then every 40 minutes test X could be run just once as an 
optimisation.

More realistically, test X will be run at t0, t10, t20, t30, ... for C1 
and at t1, t9, t17, t25, ... for C2. These times never coincide.

P.