Changes between Initial Version and Version 1 of GeniOptinMinneapolis

Timestamp:

03/03/08 15:37:40 (16 years ago)

Author:

hgs@cs.columbia.edu

Comment:

--

GeniOptinMinneapolis

@@ +1 @@
+= 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