Presentation is loading. Please wait.

Presentation is loading. Please wait.

Future Internet Developments: Evolution or Flag Days John C. Klensin, Ph.D. APAN August 2005 © John C Klensin, 2005, All rights reserved.

Similar presentations

Presentation on theme: "Future Internet Developments: Evolution or Flag Days John C. Klensin, Ph.D. APAN August 2005 © John C Klensin, 2005, All rights reserved."— Presentation transcript:

1 Future Internet Developments: Evolution or Flag Days John C. Klensin, Ph.D. APAN August 2005 © John C Klensin, 2005, All rights reserved

2 2005.08.232 Transitions in Network Technologies Parallel development and compatible operation Simultaneous –Shutdown of one service –Starting replacement Latter is “flag day” –Dangerous and nasty –When needed? –How likely for the Internet?

3 2005.08.233 Reviewing Network History Disruptive and non-disruptive changes Smooth evolution, evolutionary jumps, discontinuous shifts Transition and “flag days”

4 2005.08.234 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

5 2005.08.235 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…

6 2005.08.236 Hypothetical Case: Questions Some questions –Why try to think about it globally? –Who would decide? –Why would they decide? –Who would pay attention?

7 2005.08.237 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

8 2005.08.238 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

9 2005.08.239 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”

10 2005.08.2310 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

11 2005.08.2311 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.

12 2005.08.2312 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

13 2005.08.2313 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

14 2005.08.2314 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

15 2005.08.2315 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

16 2005.08.2316 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

17 2005.08.2317 Better to Attract than to Mandate Requires some patience No overnight cures But no overnight disasters, either.

18 2005.08.2318 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

19 2005.08.2319 What is Important to Drive the Internet Forward Interoperability –Creating and preserving a global network with global capabilities Ease of deployment and ease of support –High deployment or support costs lead to negative value for business plans –Unpredictability of infrastructure is another barrier: stability is important

20 2005.08.2320 Remember Internet Innovation Edge design permits applications experiments –No need for global testing to avoid network disruptions –No need for carrier agreement before deploying new applications –Very rapid deployment once an application takes off (but sometimes years before that happens) But everything depends on a completely stable IP infrastructure Conversely, flag day infrastructure changes are a likely disaster in this regard.

21 2005.08.2321 A Stable IP Infrastructure Possible because the network is stupid –No knowledge of what is being routed. –No changes to infrastructure for new applications or optimization for them Hourglass gives applications-media independence

22 2005.08.2322 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

23 2005.08.2323 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

24 2005.08.2324 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

25 2005.08.2325 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”

26 2005.08.2326 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

27 2005.08.2327 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

28 2005.08.2328 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

29 2005.08.2329 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.

30 2005.08.2330 The Bad News – Spam as an Example Because the network is stupid –Don’t look to addressing or routing as a cure for content problems – spam included –Traceability of hosts doesn’t help with users –Especially with relays, proxies –Worse wirh zombies: host authentication permits identifying the victim, not the criminal Spam is easy to stop: if price is accepted –Decide you don’t want to ever receive a message except from those you trust or those formally introduced by them –Deploy strong message-level authentication. Interesting questions about how to do this Critical role for governments and inter-government agreements Maybe mixed with webs of trust –Mystery messages are rejected.

31 2005.08.2331 Flag Days and Reality No foreseeable cases in which global Internet flag days are needed Much 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.

Download ppt "Future Internet Developments: Evolution or Flag Days John C. Klensin, Ph.D. APAN August 2005 © John C Klensin, 2005, All rights reserved."

Similar presentations

Ads by Google