Lecture 3 Design Philosophy Applications Dejian Ye Software school Fudan University Computer Networks
1 Lecture 3 Design Philosophy & Applications Dejian Ye Software School Fudan University Computer Networks
Lecture overview Last time: Protocol stacks and layering oSi and tc∥ P mode|s >)Application requirements from transport protocols Internet Architecture Application examples ftp http Application requirements “ ilities” 》 Sharing 2
2 Lecture Overview Last time: » Protocol stacks and layering » OSI and TCP/IP models » Application requirements from transport protocols Internet Architecture Application examples. » ftp » http Application requirements. » “ilities” » Sharing
Internet Architecture Background 》“ The Design Philosophy of the DARPA Internet Protocols(David clark 1988) Fundamental goal: Effective network interconnection Goals, in order of priority: 1. Continue despite loss of networks or gateways 2. Support multiple types of communication service 3. Accommo date a variety of networks 4. Permit distributed management of Internet resources 5. Cost effective 6. Host attachment should be easy 7. Resource accountability 3
3 Internet Architecture Background » “The Design Philosophy of the DARPA Internet Protocols” (David Clark, 1988). Fundamental goal: Effective network interconnection Goals, in order of priority: 1. Continue despite loss of networks or gateways 2. Support multiple types of communication service 3. Accommodate a variety of networks 4. Permit distributed management of Internet resources 5. Cost effective 6. Host attachment should be easy 7. Resource accountability
Priorities The effects of the order of items in that list are still felt today >)E.g, resource accounting is a hard, current research topic Let's look at them in detail
4 Priorities The effects of the order of items in that list are still felt today » E.g., resource accounting is a hard, current research topic Let’s look at them in detail
Survivability If network disrupted and reconfigured > Communicating entities should not care ))No higher-level state reconfiguration > Ergo, transport interface only knows"working "and"not working. ' Not working== complete partition How to achieve such reliability? Where can communication state be stored Network Host Failure handing Replication Fate sharing Net Engineering Tough Simple Switches Maintain state Stateless Host trust Less More 5
5 Survivability If network disrupted and reconfigured » Communicating entities should not care! » No higher-level state reconfiguration » Ergo, transport interface only knows “working” and “not working.” Not working == complete partition. How to achieve such reliability? » Where can communication state be stored? Network Host Failure handing Replication “Fate sharing” Net Engineering Tough Simple Switches Maintain state Stateless Host trust Less More
Fate Sharing Connection State No State State Lose state information for an entity if (and only if? the entity itself is lost Examples: >)OK to lose TCP state if one endpoint crashes NoT okay to lose if an intermediate router reboots >)Is this still true in today's network? NATs and firewalls Survivability compromise: Heterogenous network - less information available to end hosts and Internet level recovery mechanisms
6 Fate Sharing Lose state information for an entity if (and only if?) the entity itself is lost. Examples: » OK to lose TCP state if one endpoint crashes – NOT okay to lose if an intermediate router reboots » Is this still true in today’s network? – NATs and firewalls Survivability compromise: Heterogenous network -> less information available to end hosts and Internet level recovery mechanisms Connection State No State State
Types of Service Recall from last time tcP ys UDP >) Elastic apps that need reliability: remote login or emai >)Inelastic, loss-tolerant apps: real-time voice or video >)Others in between, or with stronger requirements Biggest cause of delay variation: re liable delivery Today's net: 100ms rtt Reliable delivery can add seconds Original Internet model: TCP/P one layer >) First app was remote login. >)But then came debugging, voice, etc. >)These differences caused the layer split, added UDP No Qos support assumed from below >)In fact, some underlying nets only supported reliable delivery Made Internet datagram service less useful! >)Hard to implement without network support >Qos is an ongoing debate
7 Types of Service Recall from last time TCP vs. UDP » Elastic apps that need reliability: remote login or email » Inelastic, loss-tolerant apps: real-time voice or video » Others in between, or with stronger requirements » Biggest cause of delay variation: reliable delivery – Today’s net: ~100ms RTT – Reliable delivery can add seconds. Original Internet model: “TCP/IP” one layer » First app was remote login… » But then came debugging, voice, etc. » These differences caused the layer split, added UDP No QoS support assumed from below » In fact, some underlying nets only supported reliable delivery – Made Internet datagram service less useful! » Hard to implement without network support » QoS is an ongoing debate…
Varieties of Networks Discussed a lot of this last time o Interconnect the arpanet. x25 networks, LANs, satellite networks, packet networks, serial links. Mininum set of assumptions for underlying net 》 Minimum packet size > Reasonable delivery odds, but not 100% > Some form of addressing unless point to point Important non-assumptions 》 Perfect reliability 》 Broadcast, multicast >) Priority handling of traffic >) Internal knowledge of delays, speeds, failures, etc Much engineering then only has to be done once 8
8 Varieties of Networks Discussed a lot of this last time - » Interconnect the ARPANET, X.25 networks, LANs, satellite networks, packet networks, serial links… Mininum set of assumptions for underlying net » Minimum packet size » Reasonable delivery odds, but not 100% » Some form of addressing unless point to point Important non-assumptions: » Perfect reliability » Broadcast, multicast » Priority handling of traffic » Internal knowledge of delays, speeds, failures, etc. Much engineering then only has to be done once
TheOther" goals Management > Today's Internet is decentralized-BGP >Very coarse tools. Still in the"assembly language"stage Cost effectiveness Economies of scale won out >)Internet cheaper than most dedicated networks >) Packet overhead less important by the year Attaching a host >)Not awful; DHCP and related autoconfiguration technologies helping. A ways to go, but the path is there
9 The “Other” goals Management » Today’s Internet is decentralized - BGP » Very coarse tools. Still in the “assembly language” stage Cost effectiveness » Economies of scale won out » Internet cheaper than most dedicated networks » Packet overhead less important by the year Attaching a host » Not awful; DHCP and related autoconfiguration technologies helping. A ways to go, but the path is there But…
Accountability Huge problem Accounting o Billing? (mostly flat-rate. But phones are moving that way too people like it!) >)Inter-prov ider payments Hornet,'s nest. Complicated. olitical. Hard Accountability and security 》 Huge problem 》 Worms, vIruses,etc Partly a host problem. But hosts very trusted 》 Authentication Purely optional. Many philosophical issues of privacy Vs security. 10
10 Accountability Huge problem. Accounting » Billing? (mostly flat-rate. But phones are moving that way too - people like it!) » Inter-provider payments – Hornet’s nest. Complicated. Political. Hard. Accountability and security » Huge problem. » Worms, viruses, etc. – Partly a host problem. But hosts very trusted. » Authentication – Purely optional. Many philosophical issues of privacy vs. security
