---
tags: meeting notes, day 1
---

# Intro Talks - Notes

## Dave Oran

- L2 and L1 evolving rapidly - making simple univeral L3 a big win.
- Uninvent GetHostByName. Affected IPv6 and MPTCP operations, opened up trivial reflection attacks.

## Jon Crowcroft

- 43 years ago JIT compiling
- UCL - Internet measurements and overcoming speed of light
- Cambridge - opportunistic, edge

**Successful:**

1. Multicast
- Works for Internet tv/radio,
- Multicast was broken by bugs in code. How much can “good” code affect protocol operation
- Mark Handley SIP implementation had root exploit issue which almost killed it
- Gotchas: stupid code
1. Cloud
- Positives: manageability, resilience
- centralization, work in decentralization stopped with increase in cloud

Accountability

- censorship,

## Mark Nottingham

- First use of Internet in 1990
- Most work on CDNs (now in Cloudflare)
- Work in policy (chair of HTTP WG)

**Success**

- Role of user agent in the web. Introduced a component that addressed the concerns of trust between users and user agent

**Problematic**

- properiatary aspects in the stack

**Change**

- Browsers are complex and become a barrier in competition

## Craig Partridge

- Hired in 1983 as TCP/IP experts
- CSNet in 1985. Was larger than Internet at some point of time.
- Internet End2End Task Force in 1987. Were vicious with the folks presenting tech
- No idea how a lot of things in networking were working (congestion control, etc.)

**Success**

- becoming the dominant networking in 1989
- Open standards mattered as the pool of interested folks were small.
- end-to-end architecture were critical as it did a clear division of labor

**problem**

- Operational focus. “Daddy pays” issue. BBn was controlling majority of the iNternett.
- Management issues were arising which made the network a bit closed loop.
- Problem still exists as we keep adding programming within the network.

**Go back in time and change.**

- Slow down as multiple issues were evolving. BGP, DNS, …
- Lot of things were screwed up as things evolved fast.
- There wasnt much time

**Discussion**

- End to end principle was always resisted. Everyyone wanted to add stuff within the network
- Discussions regarding Haris work on performance enhancement over TCP. Should or should not be done.

## Michael Welzl

- Work on explicit feedback in 1999
- Research needs to think broad and in longer time frame

**Success**

- IP over everything and best effort

**Problem**

- end to end congestion control loop
- TCP friendliness became too limiting

**Go back and change**

- Make PEPs as first class citizens
- PEPs not being part of the architecture created problems: ossification and more.

**Discussion on PEPs.**

- PEPs on every layer are good as they help the end points
- Email was a proxy
- Rootd is a proxy.
- Most pieces in the INternet was built of proxies.

## Erik Huizer

**Failures**

- Lack of security
- Economics: couldne done better than blockchains (virtual money)
- what can we learn from this?

**Change**

- Redesign IPv4 with specs of IPv6.
- Wouldve affected adoptions better

**Discussion**

- We had a lot of good idea about security but couldnt implement it

## Harald Tveit

- WebRTC

**Success**

- Trifecta of IPv4, DNS and SMTP made Internet work

**Failure**

- X.400, chat: no interoperability since they were seen as commercial opportunities
- What happens when dominant driver is less than 50% market share

**Change**

- Remove the source address.
- Tells nothing about sender. As a proxy
- None of the major reasons for having a sender address were useful.
- security policies are undefined.
- Protocols are complex as they need to be.

## Mirja

**Success**

- Chaotic architecture makes it successful

**Failure**

- Security is a not a first order feature

**Change**

- Security
- There is no need to add security in all layers

## Colin Perkins

**Success**

- Early protocols were good enough for criticqal mass

**Failure**

- lack of imagination
- Protocols changed too fast to handle infras
- Internet governance is still the same

**Change**

- PSTN interoperability came to early
- Declaration of Independence of Cyberspace
- get rid of gTLD

## Henning Schulzrinne

- Sudden increase in networking - faculty teaching students

**Success**

- Low bariiers to entry
- International compatibity early on (unlike electrical sockets)
- application evolution
- friendlier to programmers

**Failures**

- Lack of interoperability at application layert
- complexity of simplest application protocols such as HTTP, DNS
- students interested in networking is becoming harder
- Feels like rehashing religion that was fashionable

**Change**

- non ASN.1 mapping for programmers

## Kevin Fall

> NM: Couldnt take notes. Needs populating

## Karen Sollins

> KS: edited

**Successes**

- Clean, minimalist, layered architecture:
- Generality
- Extensibility
- Modularity/abstraction/standardization
- Defining success:
- Generality of purpose
- generality of design
- longevity

**Problems**

- Security:
- threats and vulnerabilities not well thought through
- didn't think through picking which problems to solve (or not) at which layer(s)
- always an afterthought
- Definition of an endpoint
- Didn't ask whether there might be a better, alternative architecture. (Maybe couln't have done this at the time)

## Dirk Kutscher

- Companies were doing Internet innovations in EU. In US it was academic driven

**Success**

- Commercialization phase of the Internet lead to wide deployment

**Problems**

- centralization and concentrations
- It is unclear which of the problems are due to Internet protocol characteristics

## John Wroclawski

**Success**

- fixed-point aspects of the Internet (thin-waist).
- fixed-point enables usecases that were not earlier imagined

**Failures**

- Economy of the Internet
- Poeple in middle are commodity in end-to-end infrastructure

**Change**
- Need to rethink lifecycle
- As application matures, things change.
- How to make protocols capable of handling lifecycles better

**Discussion**

- email is first application that have survived the test of time - can we learn something about lifecycle from this?

## Lars Eggert

**Success**

- Deployment
- Internet can be thought of lego bricks that can be assembled in different ways.
- Feature. Not like 3GPP.

- Speed

**Failure**

- Layer 3 exposed to apps via layer 4 which lead to apps coding against

- Security was an afterthought for BGP, DNS
- Geoff: They became success because we didnt think of security at that time
- We solved it different way because we didnt solve it then
- Lars: We lost the central authority by waiting.

**Change**

- Dont assume that hosts are reachable
- Start with IPv6

## Jari Arkko

**Failure**

- Interoperability within systems above L4

**Change**

- More addresses
- Security from the start
- Privacy and centralization

**Discussions**

HS: Long-term hostility in technical community to defend large corporations. Wizards were trusted beyond the technical world.

## Carsten Bormann

**Success**

- Non-metered usage
- Was good until the capacity got tight
- Invest in capacity only when it was necessary

**Failures**

- Permission-less communication
- Spam and DDoS arises from it

- Weak regulation.

**Change**

- Dont allow software patents to happen
- Discourages improvements
- Security was held back

- Incorporation of Cameron's laws of identity much earlier
- user control
- justifiable parties - avoid rent seeking
- design for choice
- competitions between technologies to encourage thriving

**Discussion**

- HS: Internet was not entirely unmetered but we were only running the network at 90%

## Olaf Kolkman

**Success**

- 5 critical properties at Internet Society
- Accessible infrastructure
- Open architecture of interoperable blocks
- Decentralized management

**Failure**

- Common action and deployment benefits were not obvious
- Marketing issues with IPv6. Could have either been clear with address space size.

**Change**

- Addressable space could have been big enough
- Security comes with tradeoff so its good we didnt handle security much earlier.

**Discussion**

- DNSSec was not designed for operational requirements
- Large address space at the very beginning would have also been abused earlier. Variable address space could have been better.

## Jörg Ott

**Success**

- Dumb networks which could evolve as applications and networks evolved
- BSD sockets actually helped.

**Failures**

- Middleboxes: Worst things with best intentions
- opposed to proxies with well-defined interfaces.

- Targetted ads with cookies
- Price tag on users

- IETF standardization process can also have failures

**Change**

- Larger address space.
- Including semantics

**Discussion**

- JW: How NATs are supposed to work?
- Complexity of the NATs is not due to address translation alone.
- I think the client/server world was an inevitable byproduct of scaling pressures and cost containment. Addresses and names are asymmetrically treated as a consequence. Client side identity is an application role not a network role in this client/server world. Client-side addresses are a locator without an identity overload. I think the yearning for restoring symmetric addresses is somewhat distanced from the reality we find ourselves in.
- LE: The liveness aspects of the network are gone with NATs
- JC: NATs break Metcalfe’s “law”…
- Solves the unidirectional nature of the devices
- DK: NATs are good enough for client-server

## Jan Janak

**Success**

- Internet is easy to understant by understanding the core set of Internet protocols.
- RFCs are (relatively) easy to read and pick up

- Composable and modular protocols

- Generates community feedback

**Failure**

- Networks affected by "disrupted by default"
- Unrealistic about network uptime and reliability
- how would the protocols work if the infrastructure breaks

- Network management is broken
- hard to understand
- new paradigms for tracing and debugging

**Change**

- Focus on how end devices connect to the network and management

**Discussion**

DK: Are you advocating better in-nework telemetary?
- Data analytics, data management, keep IoT devices updated

- Networking is easy to learn and understand but community still manages to do the wrong thing.

## Adrian Perrig

**Success**

- Minimalistic design helped it grow

**Failure**

- Absence of communication guarantees, secure inter-domain routing protocols
- Lack of path choice/transparency
- Suboptimal and slow convergence of BGP
- Issues wil worsen with BGPsec and increased address space

**Change**

- Dangerous to change the past.

**Discussion**
- BGP is affected by several attacks. In blockchains for wrong routing, code updates, etc.

## Leslie Daigle

**Success**

- Protocols that were designed by people from different domains
- e.g. WWW

**Changes**

- More addresses (IPv6 early)

**Discussion**

- JC: I wish more people read IEN1 https://www.rfc-editor.org/ien/ien1.pdf
- DO: DT came to IPv6 to use IPv6 for service classes
- HS: unless and until there is no economic incentive
- RB: Variable space would have been useful
- MK: Sad that we could not swap IPv4 to IPv6 well. Shouldnt we discuss what went wrong?
- JC: IPv4 wasnt a design. It was a way to get network to work fast
- CP: Early on in IPv6 process, our tools dealing with larger addreses were primitive. In 1989, we did not even have a way to parse 128 bits let alone variable addresses.
- QUIC: Effort and agreement. Standardization
- Need to think about what QUIC is? Replacement of TCP?

## Geoff Huston

**Success**

- Decentralized and open
- opposite to the telephone network
- mirrored the increased accessibility of computers
- anything with similar properties would have worked too

**Failure**

- Behemoths (read CISCO) drived the problems and discussions
- Taken over most of the space

**Change**

- Nothing much

## Gorry Fairhurst

**Success**

- Congestion avoidance (no congestion collapse)
- Open standards helped

**Failures**

- Protect protocols to allows evolution below.
- DPI for ECMP

**Change**

- Better curation of RFCs