Changes between Initial Version and Version 1 of GeniOptinMinneapolis

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



  • GeniOptinMinneapolis

    v1 v1  
     1= Minneapolis Meeting October 2007 =
     3== Opt-In views ==
     4GENI as an ISP: can be transparent - might be too transparent to not reveal to the user that they are part of an experiment
     5Generalized end-user services: issues and potential seti vs botnet
     6In-Network services:
     7different implications on the interface required
     8Retail vs Wholesale:
     10== User Motivation ==
     11faster than I2:
     12individual/institution bandwidth provide local limitations, protocol limitations
     13as easy to fix the performance problems for I2 as it is to opt-in to GENI
     15Do you need to install software in order to opt-in?
     17Value 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)
     18traffic perturbation
     20For wholesale, need a method to opt-out.
     22Is there a history of using IRB process for networking
     23IMC2008 - Internet usage and privacy issues paper, will be posted
     24have generally had limited access
     25as a community we have not done this broadly
     26There are local constraints and capabilities which will also apply
     28Could provide a template, where slices are available based on acceptable thresholds defining experiment attributes
     30Need to bring in experts from other areas who can inform the strategy
     32Another class of incentives -
     33Opt-In requirement on other NSF research - NSF could add incentives to other funded projects
     35Scale - Implies big changes in research incentives, practices, personnel, and budgets
     36User characteristics are not real - especially wrt. attacks
     37Real users require real software
     39Mobile users scale story the worst: 2B -> 4
     40need to partner with existing service providers
     41Issue of understanding an economic model and motivation of the donors - homework that needs to be done
     42Costly 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
     43Potential solution:
     44Involve the central IT departments
     45Graduate to GPO
     46adopt firefox model - large distributed and professional development staff (variants - bsd, apache, etc)
     48Most infrastructure which claims to support research has failed... wired is easier, for wireless need vendors for support
     50Missing technologies
     51residential broadband...
     53Realism: possible course of action
     54Remove or calibrated as a pillar
     55spend real money on clever packet generators
     56confront requirement for robust SW
     57Extend GENI to (all) desktops via sandbox technology
     59Sometimes, the incentive is based on user perception, not necessarily reality
     61Have we justified why we need real data?
     63Can we specify/characterize what real data is?
     65Don't want the observation/operation of the experimental parts to prevent transport as baseline service.
     67Can spectrum lending be used as an incentive?
     69== Organization ==
     71technology (software/vm, etc)
     74== What is a user? ==
     75Wholesale option - AT&T subscribes
     76Service Opt-In - CNN provides CNN' via GENI (wikipedia is being distributed via CODEEN)
     78Research community does not have a history of developing the killer app, but we have provided the means for killer apps to be created.
     80Access to resources they can't get otherwise
     81collection of graphics processors
     82distributed data storage
     83(expensive and large)
     84(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)
     86Layered motivation
     87Users 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)
     88This way we don't compete with our industry partners
     90Should GENI (this WG) be involved in the formalization of IRB parameters and limits
     91NSF is interested in establishing a baseline
     92need to consider, exceptions (honey pots), local restrictions, international differences
     93what about local IRB processes, tools, etc
     953 capabilities:
     96* Disclosure of who can gather data
     97* User can determine what data has been collected
     98* Correction - deletion of data at user request?
     100Differentiate data collection for system administration from data collection for research
     103Can provide a baseline outside of or streamlined IRB process
     104of limited use for some types of research and data
     107Taxonomy of opt-in classes
     108Taxonomy of protections and rights
     110benchmark - 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)
     112How much opt-in do we need? (how many users?)
     114Is there a way to learn from previous test-bed opt-in failures? (impossible to opt-out and no users opted in)
     116Traffic mirroring and synthetic load (use the users data, but don't perturb their packets)
     117Can also provide dual services and provide rollover capabilities
     119Need to make sure the platform supports a continuum of reliability (99% - 5 9's)
     120Platform also needs to support monitor only geni-ized nodes
     122How fast can you make the failover?
     124Two opt-in problems
     125construction phase
     126need to include user opt-in here in order to ensure that they are there and supported post-construction
     127learning experience
     128limited opt-in support
     129needs to be a calculated risk - don't want to scare users
     130post-construction phase
     132Opt-in strategy needs to be consistent with the maturity of the platform
     134Open issues If users can bring in sensors or other devices which could involve other "users"
     136Should the opt-in API be provided by the service or by the infrastructure (slice)
     139Matt Sanders | Research Scientist | Academic and Research Technologies
     140Office of Information Technology | Georgia Institute of Technology | 404-894-9107 | 105 Rich