Future Internet Developments: Evolution or Flag Days

John C. Klensin, Ph.D.APAN August 2005

© John C Klensin, 2005, All rights reserved

2005.08.23 2

Transitions in Network Technologies

• Parallel development andcompatible operation

• Simultaneous– Shutdown of one service – Starting replacement

• Latter is “flag day”– Dangerous and nasty– When needed?– How likely for the Internet?

2005.08.23 3

Reviewing Network History

• Disruptive and non-disruptive changes

• Smooth evolution, evolutionary jumps, discontinuous shifts

• Transition and “flag days”

2005.08.23 4

The Norm in Distance Communications

• The norm has been either– Evolution within a network model

• Either within a technology• Or with one technology running in parallel to

another until it fades away

– Shutdown of one, start of another• The “flag day” model• Usually occurs due to political pressures/

decisions, not technology

2005.08.23 5

Exploring a Hypothetical Case

• Suppose it were decided to shut the PSTN down, worldwide, on a single day, leaving only VoIP

• Would not be a true flag day – VoIP runs today, so little risk

• Interesting questions…

2005.08.23 6

Hypothetical Case: Questions

• Some questions– Why try to think about it globally?– Who would decide?– Why would they decide?– Who would pay attention?

2005.08.23 7

Hypothetical Case: Environment

• All of the choices are about politics or economics, not technology– If a shutdown decision actually ever occurred,

• Carrier by carrier• Country by country

– Anyone recently sent • A telegram • A package by horse-borne messenger?• A smoke signal?

they did not disappear by global policy

2005.08.23 8

Four Examples of Superceding Technologies

• Couriers on horseback to trains

• ARPANET to Internet Protocols

• Host tables to the DNS

• Navigation and exploration tools– Gopher, Archie, WAIS, etc. and– The Web

2005.08.23 9

Couriers on horseback to trains

• Relay couriers essentially disappeared overnight on train routes

• No planning or policy, just obsolete

• No flag day either: no technical reason the horses could not keep

running

• Incidentally, no “convergence”

2005.08.23 10

ARPANET to Internet Protocols

• The January 1, 1983 “Internet Flag Day”• All NCP services and transition between NCP

and TCP/IP shut down• Not really a discontinuous flag day:

– Services ran in parallel for a while– TCP/IP was well tested

• Getting rid of NCP– An economic and policy decision

• And forcing TCP/IP adoption– A policy and economic decision

2005.08.23 11

Host Tables to the DNS

• DNS installed, host table continued to be distributed

• Long series of deadlines about host table distribution shutdown

• Even after host tables were not distributed, not all hosts ran DNS

• Full conversion caused by rising inaccessibility, not policy decisions– Pain of not converting exceeded pain to convert.

2005.08.23 12

Navigation and exploration tools

• Several ideas and protocols– Early ideas and techniques– Gopher, Archie, WAIS, etc. and

the Web• Evolution

– Coexistence until no one cared any more– Then disappearance

• No global policy decision, local economic decisions

• Incidentally, some good capabilities got lost in the process

2005.08.23 13

Few Cases Require Real Flag Days

• A Good Thing because– Real flag days are a nasty business

• Service outages– Short if successful– Catastrophic if not

• Coordination problems• Questions of authority in non-centralized network

• Shutdowns of parallel/ redundant services• Can be fairly painless• Still require careful planning

2005.08.23 14

Forcing Transitions

• Many good operational reasons to force transitions

• Parallel operations rarely a problem– Applications in parallel– Or infrastructure in parallel

• Same application, parallel infrastructure– Rarely works as well as we hope– Strong incentives to get the transition finished

2005.08.23 15

The Forcing Functions

• Economics, Scale, or Policy

• Interesting examples…– New email requirements for spam-fighting?– IPv6 ?

• But– neither requires a flag day– either would work better if everyone

transitioned

2005.08.23 16

The Old Questions Come Back

• The policy ones…– Who would decide?– Why would they decide?– Who would pay attention?

• A “no one gets to run the old protocol after…” decision– Would effectively create two networks for the service– Business opportunity for gateway/ conversion

providers

But such conversions often do not work well

2005.08.23 17

Better to Attract than to Mandate

• Requires some patience

• No overnight cures

• But no overnight disasters, either.

2005.08.23 18

IPv6 Example: A New Base

• Appeal should be to – New users and networks– New applications– New areas– For them

• Not already happy with current environment – not using it• No conversion costs: direct to IPv6

• Not trying to force IPv4 conversions until– There is lots of IPv6 out there– Ideally supporting new services

2005.08.23 22

When Do We Need a Flag Day?

• Incompatible protocols that cannot co-exist on the same network

• Most common case:No way for server to tell which protocol is in use

• Usually the result of poor or indifferent design• Getting from IPv4 to IPv6

– Common first part of packet header with version number

– Could have gotten that wrong, but it would have been dumb

2005.08.23 23

Possible Example

• Major change to routing structure– Not just new version of BGP or equivalent– Difference in how we think about routing packets

• But, even then…– Routing within a network is different from routing

between them– Many features of the current model would make it

easy to isolate changes• Roll out new model, one network at a time• Lots of little-network flag days, no global Internet one• And that is the worst case

2005.08.23 24

Getting this Right

• We are good at evolution without flag days Consider Internet Mail– 1982 Limitations

• No multimedia or structured content• ASCII-only• No delivery notifications or security/privacy facilities

– 2005: Those limitations, and others, removed– 2006: Internationalization of addresses and

headers ??

• All without incompatible infrastructure changes, much less flag days

2005.08.23 25

Who Might Like a Flag Day

• Beneficiaries of incompatibility or chaos• Economics:

– “Everyone should be forced onto my network design, so I can make more money”

• Desire for different policy or management model– “We understand circuit networks better than packet

ones, so the Internet should be a circult network”– “The Internet is hard to control, so the solution is to

break it and replace it with something easier to control”

2005.08.23 26

A Dumb, Edge Network

• Should not be looked to as the solution to– Political problems

• National relationships• Cross-border issues

– Social and legal problems• Content regulation• Spam and other offenses

• Strength of the Internet is in the “dumb network, smart edges” model

2005.08.23 27

Preserving Interoperability is Key

• “Internet Telephony” is getting interesting– The superior model in every way is

• Based on standard protocols and open standards• Multivendor, multiprovider environment with

opportunities for– New entrants introducing new services– Competition to provide good service and innovation

• Standard, PSTN-compatible, numbering model

– But Skype has one advantage…• It works• and it is arguably winning

2005.08.23 28

Conclusion

Flag days are one problem we do not need to worry about….. Unless– Network-killing policy decisions are made and

anyone pays attention– We get in too much of a hurry and make

shortcuts with critical infrastructure– We decide we don not care about a global,

interoperable, network

2005.08.23 29

Thanks to Rob Austein, Vint Cerf, and Dan Lynch for generously and quickly filling in some details of the 1 January 1983 transition that I had forgotten or not known.

2005.08.23 31

Flag Days and Reality

• No foreseeable cases in which global Internet flag days are neededMuch as some might secretly wish for them

• That is good because– A flag day transition would

• almost certainly fragment the network• as some ignored the mandate to switch or• were unable to implement it

– There is no plausible mechanism for requiring and managing one.