wiki:GeniOptinMinneapolis

Version 1 (modified by hgs@cs.columbia.edu, 16 years ago) (diff)

--

Minneapolis Meeting October 2007

Opt-In views

GENI as an ISP: can be transparent - might be too transparent to not reveal to the user that they are part of an experiment Generalized end-user services: issues and potential seti vs botnet In-Network services: different implications on the interface required Retail vs Wholesale:

User Motivation

faster than I2: individual/institution bandwidth provide local limitations, protocol limitations as easy to fix the performance problems for I2 as it is to opt-in to GENI

Do you need to install software in order to opt-in?

Value offered to user vs what pain and suffering is inflicted on the user: installing software - many dimensions to this (uses underlying stack, installs new stack, proxy, vm, etc) traffic perturbation

For wholesale, need a method to opt-out.

Is there a history of using IRB process for networking IMC2008 - Internet usage and privacy issues paper, will be posted have generally had limited access as a community we have not done this broadly There are local constraints and capabilities which will also apply

Could provide a template, where slices are available based on acceptable thresholds defining experiment attributes

Need to bring in experts from other areas who can inform the strategy

Another class of incentives - Opt-In requirement on other NSF research - NSF could add incentives to other funded projects

Scale - Implies big changes in research incentives, practices, personnel, and budgets User characteristics are not real - especially wrt. attacks Real users require real software

Mobile users scale story the worst: 2B -> 4 need to partner with existing service providers Issue of understanding an economic model and motivation of the donors - homework that needs to be done Costly to write "real" (robust) services - this doesn't just happen, costs real money, and needs to be supported after the creator graduates Have to Get real value if they are going to use the service Potential solution: Involve the central IT departments Graduate to GPO adopt firefox model - large distributed and professional development staff (variants - bsd, apache, etc)

Most infrastructure which claims to support research has failed... wired is easier, for wireless need vendors for support

Missing technologies residential broadband...

Realism: possible course of action Remove or calibrated as a pillar spend real money on clever packet generators confront requirement for robust SW Extend GENI to (all) desktops via sandbox technology

Sometimes, the incentive is based on user perception, not necessarily reality

Have we justified why we need real data?

Can we specify/characterize what real data is?

Don't want the observation/operation of the experimental parts to prevent transport as baseline service.

Can spectrum lending be used as an incentive?

Organization

incentives technology (software/vm, etc) legal/ethical/etc...

What is a user?

Wholesale option - AT&T subscribes Service Opt-In - CNN provides CNN' via GENI (wikipedia is being distributed via CODEEN)

Research community does not have a history of developing the killer app, but we have provided the means for killer apps to be created.

Access to resources they can't get otherwise collection of graphics processors distributed data storage (expensive and large) (imposes GENI as a veneer in front of something else - what is the motive for this service to allow GENI to impose itself in front of the service? The Places where GENI can impose itself are places above layer7)

Layered motivation Users want the innovative services that are built upon unique resources made available via the unique network (or services that rely only on the unique network) This way we don't compete with our industry partners

Should GENI (this WG) be involved in the formalization of IRB parameters and limits NSF is interested in establishing a baseline need to consider, exceptions (honey pots), local restrictions, international differences what about local IRB processes, tools, etc

3 capabilities:

  • Disclosure of who can gather data
  • User can determine what data has been collected
  • Correction - deletion of data at user request?

Differentiate data collection for system administration from data collection for research

Anonymization Can provide a baseline outside of or streamlined IRB process of limited use for some types of research and data verifiability

Taxonomy of opt-in classes Taxonomy of protections and rights

benchmark - Need a way to evaluate the opt-in stories in proposals (realize that some experiments can be successful w/o, but that the platform requires it for ultimate success)

How much opt-in do we need? (how many users?)

Is there a way to learn from previous test-bed opt-in failures? (impossible to opt-out and no users opted in)

Traffic mirroring and synthetic load (use the users data, but don't perturb their packets) Can also provide dual services and provide rollover capabilities

Need to make sure the platform supports a continuum of reliability (99% - 5 9's) Platform also needs to support monitor only geni-ized nodes

How fast can you make the failover?

Two opt-in problems construction phase need to include user opt-in here in order to ensure that they are there and supported post-construction learning experience limited opt-in support needs to be a calculated risk - don't want to scare users post-construction phase

Opt-in strategy needs to be consistent with the maturity of the platform

Open issues If users can bring in sensors or other devices which could involve other "users"

Should the opt-in API be provided by the service or by the infrastructure (slice)

– Matt Sanders | Research Scientist | Academic and Research Technologies Office of Information Technology | Georgia Institute of Technology matt.sanders@oit.gatech.edu | 404-894-9107 | 105 Rich