{
  "fetched_at": "2026-10-20T05:36:38Z",
  "source_url": "https://www.kaggle.com/competitions/cloud-data-geolocation-1-multi-tier-services/data",
  "pages": [
    {
      "name": "data-description",
      "content": "We provide:\n1. Measurements.csv: a list of measurements that are classified by the relevant challenge, probe, front server and data file.\n\nThe structure and naming system of the files are described in the main document.",
      "isPublished": false,
      "hasIsPublished": false,
      "postTitle": "",
      "hasPostTitle": false,
      "mimeType": "",
      "hasMimeType": false
    },
    {
      "name": "Description",
      "content": "## Definitions\nThe following naming conventions were used:\n●\t*AWS-i* - denotes a region of AWS (Amazon Web Services), as defined in *list-1*.\n●\t*Challenge-i* - denotes a featured challenge with index *i*.\n●\t*cdgeb-probe-i* - denotes the *i'th* probing server used to probe the cloud.\n●\t*cdgeb-server-i* - denotes the *i'th* front-end server in the cloud.\n●\t*cdgeb-file-i* - denotes the *i'th* file stored in the cloud storage service.\n\n\n## System Model\nThe first mockup CDGeB service comprises S3 buckets, sample files stored on S3 buckets, and EC2 instances functioning as front-end servers of our application. It relies on a 3-tier architecture (storage-app-client) without load balancing or dynamic caching abilities of cloud-based applications. \n\n17 instances of AWS EC2, each in a different region, were set up. The instances are denoted using a numerical convention throughout this challenge: *cdgeb-server-01*, *cdgeb-server-02*, etc.\n\nThe same 17 regions were used to employ AWS S3 buckets. Each bucket stores a single file, named with similar convention - *cdgeb-file-01*, *cdgeb-file-02*, etc. However, THE NUMBERING OF FILES IS NOT THE SAME AS THE NUMBERING OF EC2 SERVERS! E.g., *cdgeb-file-01* does not imply that the file is located in the same region as with *cdgeb-server-01*.\n\n    Region ID\tRegion Name\t\t\t\tServer ID\n    AWS-01\tUS East (N. Virginia)\t\tcdgeb-server-01\n    AWS-02\tEU (London)\t\t\t\t\tcdgeb-server-02\n    AWS-03\tSouth America (São Paulo)\tcdgeb-server-03\n    AWS-04\tAsia Pacific (Tokyo)\t\tcdgeb-server-04\n    AWS-05\tAsia Pacific (Singapore)\tcdgeb-server-05\n    AWS-06\tCanada (Central)\t\t\tcdgeb-server-06\n    AWS-07\tUS East (Ohio)\t\t\t\tcdgeb-server-07\n    AWS-08\tUS West (N. California)\t\tcdgeb-server-08\n    AWS-09\tUS West (Oregon)\t\t\tcdgeb-server-09\n    AWS-10\tAsia Pacific (Mumbai)\t\tcdgeb-server-10\n    AWS-11\tAsia Pacific (Osaka)\t\tcdgeb-server-11\n    AWS-12\tAsia Pacific (Seoul)\t\tcdgeb-server-12\n    AWS-13\tAsia Pacific (Sidney)\t\tcdgeb-server-13\n    AWS-14\tEU (Frankfurt)\t\t\t\tcdgeb-server-14\n    AWS-15\tEU (Ireland)\t\t\t\tcdgeb-server-15\n    AWS-16\tEU (Paris)\t\t\t\t\tcdgeb-server-16\n    AWS-17\tEU (Stockholm)\t\t\t\tcdgeb-server-17\n*List 1 - AWS regions, and corresponding front-end server names.*\n\nTo probe the front-end servers, a total of 14 instances of Google Cloud Platform services were employed as Internet clients, distributed across the following locations:\n\n    Probe ID\tRegion Name\t\t\tRegion Code\n    cdgeb-probe-01\tMontreal\tnorthamerica-northeast1\n    cdgeb-probe-02\tToronto\t\tnorthamerica-northeast2\n    cdgeb-probe-03\tSao Paulo\tsouthamerica-east1\n    cdgeb-probe-04\tOregon\t\tus-west1\n    cdgeb-probe-05\tLos Angeles\tus-west2\n    cdgeb-probe-06\tWarsaw\t\tEurope-central2\n    cdgeb-probe-07\tFinland\t\tEurope-north1\n    cdgeb-probe-08\tMadrid\t\tEurope-southwest1\n    cdgeb-probe-09\tDoha\t\tMe-central1\n    cdgeb-probe-10\tTel Aviv\tMe-central2\n    cdgeb-probe-11\tTaiwan\t\tAsia-east1\n    cdgeb-probe-12\tHong Kong\tAsia-east2\n    cdgeb-probe-13\tTokyo\t\tAsia-northeast1\n    cdgeb-probe-14\tOsaka\t\tAsia-northeast2\n*List 2: Locations of probing servers used throughout the benchmark.*\n\n![](https://www.googleapis.com/download/storage/v1/b/kaggle-user-content/o/inbox%2F12498741%2Fe1bad1bdd0a14310055e8d018e063497%2Finfrastructure.jpg?generation=1694031547812556&alt=media)\n                                  *Figure 1: Illustration of the probing process*\n\n### The measurement procedure\nEach one of the probes (*cdgeb-probe-i*) retrieves each one of the files (*cdgeb-file-i*) through multiple front-end servers (*cdgeb-server-i*). \n\n## Dataset Description\nThe following section describes the first CDGeB dataset. The dataset consists of multiple series of measurements, and each line in the dataset contains the following information:\n●\tDifficulty - *Challenge-i*, (i=1,2)\n●\tProbe - *cdgeb-probe-i*, (i=1..14)\n●\tFront Server - *cdgeb-server-i*, (i=1..17)\n●\tData File - *cdgeb-file-i*, (i=1..17)\n●\tRTT - values of 20 sequential probings in units of seconds.\n\n*Challenge-1* and *Challenge-2* correspond to two difficulty levels. *Challenge-1* consists of the measurement of files 1-5 (*cdgeb-file-01*, .., *cdgeb-file-05*), and *Challenge-2* consists of the measurement of files 6-17.\n\nIn both Challenge-1 and Challenge-2, a random set of 8 front-end servers is chosen for the retrieval of each individual file. However, the challenges differ in their level of difficulty. In Challenge-1, which is considered the easier challenge, 1 server out of the 8 is known to be located in the same geographical region as the file itself. In contrast, in Challenge-2, none of the front-end servers within the set reside in the same geographical region as the corresponding file.\n\n![](https://www.googleapis.com/download/storage/v1/b/kaggle-user-content/o/inbox%2F16558320%2F166358a74b028a71e45e4786cdd64ede%2FScreenshot%202023-09-18%20003017.png?generation=1694991095710504&alt=media)\n*Table 1: Dataset Demonstration*\n\n\n## Goal\nThe primary goal of the challenges is to ascertain the AWS region associated with each individual data file.\n",
      "isPublished": false,
      "hasIsPublished": false,
      "postTitle": "",
      "hasPostTitle": false,
      "mimeType": "",
      "hasMimeType": false
    },
    {
      "name": "Evaluation",
      "content": "Submissions are evaluated on the accuracy of their predictions.\nEach correct match results in the acquisition of points, while incorrect matchings do not yield any points.\nThe maximum achievable score for *Challenge-1* is 5/5. And for *Challenge-2* it is 12/12. The final score is computed by #Correct_matches / 17 * 100%.\n\nCompetitors have the opportunity to submit intermediate solutions to the challenge page during the challenge period. This enables competitors to evaluate their performance against a subset of the ground-truth matches. The final score will be calculated based on the evaluation of all 17 matches. Please note that the number of submission attempts is limited.\n\n## Submission File\nFor each data file *cdgeb-file-i* in the system, you should predict the matching AWS region.\nYou should submit a single CSV file, comma (',') separated. The file must contain a header and have the following format:\n\n    Data File,AWS region\n    cdgeb-file-01,AWS-02\n    cdgeb-file-02,AWS-03\n    cdgeb-file-03,AWS-01\n    ..etc.",
      "isPublished": false,
      "hasIsPublished": false,
      "postTitle": "",
      "hasPostTitle": false,
      "mimeType": "",
      "hasMimeType": false
    },
    {
      "name": "rules",
      "content": " - Don't cheat!\n - Apply yourself!\n - Have fun!\n - Anything is allowed. You can use any data mining methods and external sources to determine the geolocation of the retrieved files. \n - The winners will be invited to present their solution at the Robust and Trusted Internet Geolocation (RTIGeo) session at the CCSW workshop co-located with ACM CCS 2023. ",
      "isPublished": false,
      "hasIsPublished": false,
      "postTitle": "",
      "hasPostTitle": false,
      "mimeType": "",
      "hasMimeType": false
    },
    {
      "name": "abstract",
      "content": "CDGeB stands for Cloud Data Geolocation Benchmark. This is the first competition in a series that challenges one of the more difficult Internet geolocation problems - **cloud data geolocation**. \n\n**Why is it important?**\nCloud computing has revolutionized data processing and management, offering a flexible and scalable infrastructure for distributing content, computing power, and services across the globe. Dynamic, flexible, and transparent reallocation of resources increases the ease of use and the effectiveness of cloud-based services. As cloud adoption soars, privacy regulations, and geo-political security introduce new challenges. One is the assessment, validation, and enforcement of data geolocation.\n\nThis competition centers around the domain of verifying the geographical location of data within cloud networks. We present a series of challenges designed to enable researchers to formulate algorithms that contribute to the advancement and enrichment of the research landscape concerning the verification of data location within cloud environments.\n\n\n\n**What is the task?**\nWe present two distinct challenges, both of which require competitors to predict the physical region associated with data files that are retrieved. A total of 17 data files are stored on storage servers provided by a well-known cloud service provider. Competitors are presented with a predefined list of 17 regions, from which they should make their selections.\n\nA dataset containing measurements of the retrieval times is made available for analysis. The files were retrieved by probing a set of front-end servers, which are also operating within the cloud infrastructure.\n\nThe first challenge involves determining the locations of 5 files, with measurements from front-end servers in those same locations also provided. In contrast, the second challenge involves determining the locations of 12 files, where none of the measurements originate from front-end servers in the same location as the corresponding files, adding an extra layer of complexity to the task.\n\n\n**Why is it challenging?**\nEvery file is accessed through a front-end server hosted by AWS. This effectively creates a three-tier probe-server-storage architecture. The delays are affected not only by the (roughly known) locations of the probes and servers but also by the (unknown) locations of the data files. Simple trilateration, as commonly used in IP geolocation, won't work here. More sophisticated methods relying on the Internet topology may provide accurate geolocation of the probes or servers but not of the data files since files cannot be accessed directly. Finally, despite similar specifications, every probe, server, and file storage has its own characteristic processing time, affecting the delay measurements. ",
      "isPublished": false,
      "hasIsPublished": false,
      "postTitle": "",
      "hasPostTitle": false,
      "mimeType": "",
      "hasMimeType": false
    },
    {
      "name": "Winners and Prize",
      "content": "The winning team in this challenge will be determined as the first team to publish a solution with the highest score. The solution will undergo validation by the competition host to ensure its integrity and accuracy.\n\nThe winning solution will be presented at the Robust and Trusted Internet Geolocation (RTIGeo) session at the CCSW workshop co-located with [ACM CCS 2023](https://www.sigsac.org/ccs/CCS2023/).\n\nThe winner will be awarded with flight and accommodation expenses (a fixed sum of USD5,000 will be wire transferred to the winner's account to cover flight, accommodation and registration) subject to the winner attending the CCSW conference and presenting their results.\n\nThe winner is required to provide his/her complete solution as open-source.\n",
      "isPublished": false,
      "hasIsPublished": false,
      "postTitle": "",
      "hasPostTitle": false,
      "mimeType": "",
      "hasMimeType": false
    },
    {
      "name": "Timeline",
      "content": "September 19, 2023 - Start Date.\n\nOctober 25, 2023 - Entry Deadline. You must accept the competition rules before this date in order to compete.\n\nOctober 25, 2023 - Team Merger Deadline. This is the last day participants may join or merge teams.\n\nNovember 1, 2023 - Final Submission Deadline.\n\nAll deadlines are at 11:59 PM UTC on the corresponding day unless otherwise noted. The competition organizers reserve the right to update the contest timeline if they deem it necessary.",
      "isPublished": false,
      "hasIsPublished": false,
      "postTitle": "",
      "hasPostTitle": false,
      "mimeType": "",
      "hasMimeType": false
    },
    {
      "name": "Additional Information",
      "content": "## Appendix A - Suggested locations of probe clients and front-end servers\n\nFor convenience, we offer a catalog of approximate locations, denoted by latitude and longitude, for each of the probing clients. This list is organized in alignment with the list of probe clients (*list 2*). The data has been sourced from [MaxMind's GeoIP2 database](https://www.maxmind.com/en/geoip2-databases), and although it is claimed to possess an accuracy of 1000 km, a validation through [Google Maps](https://www.google.com/maps) suggests that these coordinates do indeed correspond to their respective state-level regions, albeit with potential minor inaccuracies.\n\n    Probe ID\t\t\tLat.\t\tLong.\n    cdgeb-probe-01\t45.5075\t\t-73.5887\n    cdgeb-probe-02\t43.6547\t\t-79.3623\n    cdgeb-probe-03\t-23.5335\t-46.6359\n    cdgeb-probe-04\t45.5999\t\t-121.1871\n    cdgeb-probe-05\t34.0544\t\t-118.2441\n    cdgeb-probe-06\t52.2296\t\t21.0067\n    cdgeb-probe-07\t61.0636\t\t28.189\n    cdgeb-probe-08\t40.4163\t\t-3.6934\n    cdgeb-probe-09\t25.2952\t\t51.5321\n    cdgeb-probe-10\t32.0803\t\t34.7805\n    cdgeb-probe-11\t25.0504\t\t121.5324\n    cdgeb-probe-12\t22.2842\t\t114.1759\n    cdgeb-probe-13\t35.6893\t\t139.6899\n    cdgeb-probe-14\t34.6946\t\t135.5021\n\n\nSimilarly, the locations of the front-end servers are also provided (following *list 1*).\n\n    Server ID\t\t\tLat.\t\tLong.\n    cdgeb-server-01\t39.0469\t\t-77.4903\n    cdgeb-server-02\t51.5088\t\t-0.093\n    cdgeb-server-03\t-23.5335\t-46.6359\n    cdgeb-server-04\t35.6893\t\t139.6899\n    cdgeb-server-05\t1.2929\t\t103.8547\n    cdgeb-server-06\t45.5075\t\t-73.5887\n    cdgeb-server-07\t39.9587\t\t-82.9987\n    cdgeb-server-08\t37.1835\t\t-121.7714\n    cdgeb-server-09\t45.8234\t\t-119.7257\n    cdgeb-server-10\t19.0748\t\t72.8856\n    cdgeb-server-11\t34.6946\t\t135.5021\n    cdgeb-server-12\t37.4585\t\t126.7015\n    cdgeb-server-13\t-33.8715\t151.2006\n    cdgeb-server-14\t50.1188\t\t8.6843\n    cdgeb-server-15\t53.3379\t\t-6.2591\n    cdgeb-server-16\t48.4323\t\t2.4075\n    cdgeb-server-17\t59.3287\t\t18.0717\n\n\n## Appendix B - References\nhttps://dl.acm.org/doi/abs/10.1145/1028788.1028828\nhttps://dl.acm.org/doi/abs/10.1145/2435349.2435353\nhttps://en.wikipedia.org/wiki/Haversine_formula",
      "isPublished": false,
      "hasIsPublished": false,
      "postTitle": "",
      "hasPostTitle": false,
      "mimeType": "",
      "hasMimeType": false
    }
  ]
}