Transcript Information - Eiffel thinktank

Incentives Alignment Whitepaper
Progress since Athens
Some Editor’s Notes
• Paper initiated from an architectural discussion
– Is it best to capture that in the structure of paper?
• Possible alternative:
– Start from current Internet: where can we observe
problems of incentive alignments?
– Describe the fundamental problem: lack of choice and
information as well as design process issues
– Point to potential solutions on process and outcome level
• For the following discussion:
– Still important to get the pieces right!
Current Storyline
• Proper modularization of functions matters
– There are demands and costs for crucial network functions
• Alignment of incentives needs
– (expression of) choices
– Proper information
• Alignment of incentives is a socio-economic not a mere
technical problem!
– Architecture is a combination of process and outcome
– Timescales range from short to very long
• A solution for incentive alignment is mix of
– Proper design process
– Proper architectural approaches for alignment in runtime
• Lessons learned from the Internet today and potential solutions
Assertions Made in the Whitepaper
• Modularity matters
– Modularity of network functions is a matter of technical
and socio-economic influences
– Lesson learned from tussle debate
• Proper modularization achieved through incentive
alignment along modularity boundaries
– Requires demands and costs for major network functions
– Not a single-dimensional optimization problem but a multidimensional satisficing problem
Required: Choice and Information
• Choice in implementing various network functions
and selecting various providers crucial for the
incentive alignment process
– Expressing choice is crucial - MUST not be based on preconceived choices
• Information is crucial for choice
– Evolving set of demands (and costs for fulfilling them)
requires extensible framework for providing right
information (although option is the killer of simplicity)
Examples needed!
Architecture: Process and Outcome
An architecture reflects both the process and product of
planning, designing and constructing space that reflects
functional, social, and aesthetic considerations.
Why important?
• Leads us to process question -> issue of evolution through
process not (seemingly random) outcomes
• Emphasizes optimization being implemented as multidimensionally satisficing socio-economic concerns
• Might offer an answer to the timescale problem in alignment
– Longer timescales -> process?
– Shorter timescales -> implementation?
Major Network Functions
Examples
•
•
•
•
•
•
Address space management
Rendezvous/discovery
Topology formation
Forwarding
Trust management?
Security?
Questions:
• Any missing?
• Generic enough?
• Detailed enough?
• What about (today’s) endpoint roles, e.g., flow control?
Demands
Examples
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Flexible
de-centralized (or centralized)
Heterogeneous
Hierarchy of Identifiers
Information visibility
Information hiding (separation)
Scalability
Resilience
QoS
Security
Isolation
Openness
(Broad) Policy compliance
Aware of social behaviour
Longevity
Availability
Neutrality
Energy preserving
• Questions: any missing? How to formulate?
Costs
• Current text differentiates
– Operational costs
– Opportunity costs
Example: congestion
• Questions:
– How to reflect timescales? Do they matter?
– Does this difference suffice?
– Can we give other examples?
Information
• What information is required?
– Examples needed (see later)
• Timescales matter
– Which information for which timescale?
• Where provided?
– Within design process or implementation?
– Timescale seem to matter (again)
Design for Change
• Allow for choice and information enabling such
choice
-> Allow for incentive alignment to commence at runtime
• Capturing the dynamics of such (potential) change
seems crucial
• Tying the discussion back to the design process
question: can we devise a design process that
incorporates the known and envisioned drivers for
change?
Lessons Learned: Processes in the Current
Internet
• Standards
• Regulation
• (Requirements) Engineering
Do we believe that there is room for improvement?
Lessons Learned: Architectural Approaches
• Generally
– Hour glass?
– Generality of the packet header?
• Specific examples
–
–
–
–
–
–
–
Google (search) as application example
Telecommunications over IP
Generalized mobility and multi-homed
IP communications everywhere
Control of unwanted traffic
Privacy and reputation
Reducing the impact of denial of service attacks
Need more text here!
Lessons for the Future: Processes
• Words on new approaches in standards or
regulation?
• Design processes:
– Optimization approaches
– System dynamics approaches
-> what problem do they try to address?
-> timescales?
Lessons for the Future: Approaches
• Any approaches on the horizon that fundamentally
change the way we could align incentives?
• Examples:
– CCN: expose naming as low-level network function
– PSIRP: expose information and allow structures of
information on network level
– Re-feedback: target resource sharing problem
– User-provided networking: involve end-users
Need more here!
Plan for Release
• Today: get better understanding on
– Missing content
– Structure (see slide before)
– Volunteers for input
• Tomorrow: get started on changes in small group
• End of March: first revised draft with almost final
content
• End of April: release of whitepaper
– Any suggestion for dissemination venue?