Paper Structure

--- tags: Paper --- # Paper Structure > Move to Overleaf: https://www.overleaf.com/1394926147pzhxpsgspxgg > Use nomenclature: What comes from Seminar discussion [S], What comes from Emails [E], What comes from Networking Channel [N] > Link to Zoom recordings from Dagstuhl: https://drive.google.com/drive/folders/10jiSKduB6LQV8pg1c7ggy26AFvucVgCg?usp=sharing > Steal from Dagstuhl proposal > Pub venues: CCR? vs CACM? **Possible title**: Lessons learnt from 40+ years in the Internet - A Dagstuhl Perspective > ## Process idea > I. Get feedback on the outline > II. Ask people to volunteer for section > III. Assign people to sections if they don't volunteer (if they don't sign up by a certain date) ---- > Layer independent vs layered approach > Layers: Application, Transport, Data/Control, > 1. Intro > 2. What worked well > 3. What didnt work well > 4. Memory wipe > 5. Conclusion > Factors that affected: Technical, Economic, Regulatory > Verticals that evolved (+vely or -vely): Applications, Security (maybe), Organization, Architecture ## Introduction - Why is looking back important - Time period we looked at? What were the different technical, social, economical and business incentives at play? - Highlight "lessons learnt" and not history of the Internet evolution - General description of who participated (by some classification - e.g. researchers, industry, standards/regulation) including some age/tenure related stats - maybe in a separate subsection of the intro ### Objectives - What would a "Do-over" allow you to do? - Case studies of successful (and unsuccessful) protocol deployments - The PerFail paper on IETF discussions might be useful here [[cite](https://ieeexplore.ieee.org/abstract/document/10150250)] - What might we use when looking forward to the next 40 years of the Internet? - What lessons can we give to newer research areas, e.g. ML/AI ## Description of the Seminar Process - How we approached the dialog (introductions, high-order thoughts on what we did right and wrong, etc) - **Deep dive on subset of the topics via breakout session:** > Carry these as a theme for case-studies throughoput the paper - Security (note we should capture the two divergent views on this in the paper) - Application - Organization (Standards & Policy) - Architecture - Invited talks ## What was the vision early on? - Communication across organizations with loose coupling, non-hierarchical topology, and minimized fate sharing - Incremental Permissionless Innovation - John - Fewer gateways to build between different organizations - Resilience trumped reliability in protocol engineering tradeoffs ## Important principles for Internet to take off ### Technical Aspects - infrastructure build-out (and connectivity - e.g., research labs & universities) subsidized - rapid evolution of protocols & de facto standards in early IETF - small, relatively homogeneous community, with few legacy constraints - open nature (openly documented protocols, anybody could contribute) - Minimal guarantees that allowed interconnections of disparate communication technologies - partly governed by people talking in IETF ### Economic Aspects - Low/zero cost to connect - "Parent pays" model thanks for research funding that helped in rapid development for free (or near free) connections ### Regulatory Aspects - Avoidance of any regulatory entities (such as ITU) by the standardization community - helped by the deregulation of the telecom industry - becomes a "one-time" event that will likely not happen again - Looking at the problem at the correct time (and not tackling everything immediately as later knowledge made problems easier to tackle). ## Important principles that were "problematic" ### Technical Aspects - Ossification of the protocol suite thanks to the intermediaries that limited future design choices. **Case Study:** > Enumerate different examples here and problems they exposed - GetHostByName [Dave Oran] that exposed IP addresses to applications - Seriously slowed down IPv6 deployment - Inhibited the MP-TCP deployment - Increases attack surface by making reflection attack trivial - Inter-layer approaches may open problems many technologies later ### Economic Aspects - Massive scaling and overtake of the "centralization" entities - Unlike the beginning of the Internet which were more "technical" driven, the middle ages were economically driven ### Regulatory - Maturation of IETF that over-values "do no harm" during protocol development? ## Principles that evolved over the years - Applications and their requirements - Understandings and requirements from "security" ## Areas where there’s challenges today, and no clear principle to follow - Centralization? - technical vs. economic - Fragmentation? - anti-globalist movement - after-effects of inherent design? Connecting local LANs via expensive cable to WAN. - Money: direct payment for services (vs. indirect payment via ads) - Surveillance - both governmental and capitalist ## What does this mean in practice today? - capture both the good and the bad things here ## (Retrospective) Memory wipe: what would one do differently if we were to start over? - Economic perspective of Internet. - Internet is essentially a commodity to transport information (which was likely not considered as much as the technical challenge of making it happen) - End-to-end connectivity vs end-to-end application lifecycle - New applications are hot and get a lot of technical attention. However, it mid to late stages of the "hype cycle", the optimization, stability and security are not considered equally importantly - Leads to things like "HTTP over everything" - Pay more attention to layer violations and their effect on independent evolution of layers (e.g. Sockets API) - More extensibility in the addressing scheme - Level of indirection between addresses and identifiers, rather than overloading IP addresses as identifiers (e.g. HIP came too late to get traction, mobility complicated by the assumed permanence of topologically assigned IO addresses) > There were many "clean slate" approaches from research perspective (e.g. ICN) which were cool but went nowhere. [Highlight other approaches]. ## Conclusion - constructive take-aways - integrative architecture (don't replace) - building blocks designed to be part of something bigger --- # Further seminar stuff ## Reading list - sum up all the readings pointers and other materials ### List - https://datatracker.ietf.org/doc/draft-farrell-tenyearsafter/ > ### Writing pointers > Important points to keep in mind for the writing > - Do not state the obvious > - networking taught as a history lesson that is passed down. but never questioned. > - Adoption formula for the technologies. How can we generalize this? > - Initial conditions of networking development is not going to happen again. Can we highlight 'learnings' that can transfer to cousin disciplines such as AI, etc. > - how did economy affect the process? Divide it from technical viewpoint.