Opt-In Working Group breakout notes from GENI Engineering Conference - 10/10/07 3-6pm

[Matt Sanders-2]

These are my un-edited notes, to be merged with the audio, slides, attendance, and flip-chart content later...

--

charter @ http://wiki.cs.columbia.edu

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@... | 404-894-9107 | 105 Rich

_______________________________________________
opt-in-wg mailing list
opt-in-wg@...
http://lists.geni.net/mailman/listinfo/opt-in-wg