Transcript ppt
Computer Networks Lecture 1: Introduction Prof. Younghee Lee Some part of this teaching materials are prepared referencing the lecture note made by F. Kurose and Keith W. Ross Prof. Younghee Lee 1 1 Computer Networks Overview o graduate level course on basic knowledge on computer networks. » o Also introduces the current status and direction of computer networks. » o Multicast, Mobility, QoS, Security, Mobility, Overlay networks, P2P, Active networks, Sensor networks, Network supports for Pervasive computing and finally Future Internet Difference from undergraduate course “Computer Networks” » o o Protocol and Network Fundamentals, Layering, Internet architecture, Routing (IP), Transport (TCP), Naming (DNS), Performance Modeling and Estimation Basic knowledge for training network programmers vs. Profound Basic knowledge plus advanced issues for training network researchers lecture, reading/discussion, home assignment and term project The projects can be either of following type: design/implementation, measurements and simulation Text o For students who are not familiar with networking o o Computer Networking: A Top-down Approach Featuring the Internet by Jim Kurose and Keith Ross, Addison Wesley, 2008 For students who had taken “computer network” related courses o Lecture notes, reading materials Prof. Younghee Lee 2 2 Computer Networks TA: TBD – Kim, Jinchul, [email protected], 6287 Course info – http://cnlab.icu.ac.kr/~yhlee – Please check regularly » Course schedule, reading assignments, lecture notes,… What do you want to get out of this class? Prof. Younghee Lee 3 3 Applications of computer networks Access to Remote Programs Access to Remote Data Bases Communication Medium – Electronic Funds Transfer System, Electronic Mail, Teleconferencing – Worldwide Newsgroups, International Contacts by Humans Entertainment Industry – Video On Demand, Multiperson real-time simulation games – Selecting any movie/TV program ever made – Live TV may becomes interactive with audience Web – Web based applications, UCC Pervasive computing – – – – Context-aware networking Resource Management for Application-Aware Networks Autoconfiguration, Registration, Mobility management Service discovery for wireless ad hoc network Prof. Younghee Lee 4 4 Lecture Contents - - - Introduction Protocol and network fundamentals, TCP/IP Suite, OSI systems Simulator: NS Internet Routing, Scheduling, active queue management Congestion/Flow control, IntServ/DiffServ Performance estimation TCP, wireless TCP Midterm exam IP multicast, reliable multicast Traffic Measurements Wireless computer network P2P, Overlay network Sensor network, Ad hoc network, Mesh network, Network supports for Pervasive Computing * autoconfiguration, service discovery, naming, context awareness Future direction for network research * Future Internet * bio-inspired network technologies Project presentation Final exam Prof. Younghee Lee 5 5 Evaluation Evaluation – – – – – – – Assignment Midterm exam Final exam Quiz Term project Paper reviews Class participation 15 % 25 % 25 % 0% 20 % 10 % 5% Prof. Younghee Lee 6 6 Term Project Important Deadlines – Project Proposal: your own design, subject to the instructor’s approval, March 6 – Consultation: March 11, 13 – Progress Report and Consultation: April 15, 17 – Final Report: May 9 – Presentation: May 13, 15, 20 Proposal – A statement of objectives – A short description of what the project will entail(what you’ll do, when you’ll do it, what your final report will consist of, etc.) – A list of all the people working on this project: (1 - 5 persons) Progress Report – describe your progress at that time, and any difficulties you’re encountering Prof. Younghee Lee 7 7 Term Project Evaluation of Projects(total 20 %) – Proposal & progress report: 8 % – Final report and presentation: 12 % » Relevance: » Creativity: » Organization: » Communication: – Your final project write-up should be of sufficient quality to submit to a conference or journal for publication Prof. Younghee Lee 8 8 Term Project Term – – – – – – – Project format(recommended) Introduction and related works Problem description Problem formulation Description of the solution approach Software implementation Result analysis, evaluation(recommending NS etc.,) Conclusion Time estimate: – not less than 50 hours on a project Prof. Younghee Lee 9 9 Term Project The areas of term projects (for reference) – Ad hoc networks, overlay networks, mesh networks, – P2P networking – Multicast, QoS in wireless network, the Internet protocols in wireless environments and various networks such as Ad hoc networks, overlay networks, mesh networks, – Mobility supports in various layer – Network supports for pervasive computing: auto-configuration, context aware service discovery, naming – Internet traffic measurements, engineering – Future Internet Much work usually should be done to make a proposal. Term projects are not the extension of your lab. projects but the research projects to practice the knowledge learning from this course. Prof. Younghee Lee 10 10 Reading Assignments 1 paper-readings per almost every lecture. 1 page executive summary of each paper – Including your observation to the points that the papers deal with Presentation by the students for each paper – Presentation schedule: 1 team(2 students) per each paper Discussions – Discussion summary by each students including the conclusion made by yourself » Can be submitted together with the executive summaries of the paper dealt at next lecture Will be the major issues for exam. Prof. Younghee Lee 11 11 What you want to get out of this class Basic/profound understanding on “computer networks” Trends/tendency/research issues – Details on Prof. Younghee Lee 12 12 Computer Networks? Computer Networks: Interconnected Collection of Autonomous Computers – Bus, LAN, MAN, WAN (The Internet, The TCP/IP Internet): The set of subnetwork that are interconnected through TCP/IP – interconnection of many networks:an internetwork => an internet Prof. Younghee Lee 13 13 Internet History 1961-1972: Early packet-switching principles 1961: Kleinrock queueing theory shows effectiveness of packetswitching 1964: Baran - packetswitching in military nets 1967: ARPAnet conceived by Advanced Research Projects Agency 1969: first ARPAnet node operational 1972: – ARPAnet demonstrated publicly – NCP (Network Control Protocol) first hosthost protocol – first e-mail program – ARPAnet has 15 nodes Prof. Younghee Lee 14 14 Internet History 1972-1980: Internetworking, new and proprietary nets 1970: ALOHAnet satellite network in Hawaii 1973: Metcalfe’s PhD thesis proposes Ethernet 1974: Cerf and Kahn architecture for interconnecting networks late70’s: proprietary architectures: DECnet, SNA, XNA late 70’s: switching fixed length packets (ATM precursor) 1979: ARPAnet has 200 nodes Cerf and Kahn’s internetworking principles: – minimalism, autonomy - no internal changes required to interconnect networks – best effort service model – stateless routers – decentralized control define today’s Internet architecture Prof. Younghee Lee 15 15 Internet History 1980-1990: new protocols, a proliferation of networks 1983: deployment of TCP/IP 1982: smtp e-mail protocol defined 1983: DNS defined for name-to-IP-address translation 1985: ftp protocol defined 1988: TCP congestion control new national networks: Csnet, BITnet, NSFnet, Minitel 100,000 hosts connected to confederation of networks Prof. Younghee Lee 16 16 Internet History 1990’s: commercialization, the WWW Early 1990’s: ARPAnet decommissioned 1991: NSF lifts restrictions on commercial use of NSFnet (decommissioned, 1995) early 1990s: WWW – hypertext [Bush 1945, Nelson 1960’s] – HTML, http: Berners-Lee – 1994: Mosaic, later Netscape – late 1990’s: commercialization of the Late 1990’s: est. 50 million computers on Internet est. 100 million+ users backbone links runnning at 1 Gbps WWW Prof. Younghee Lee 17 17 A brief Network History ISDN Frame Relay Broadband ISDN ATM 3G, 4G Prof. Younghee Lee 18 18 A brief Network History Prof. Younghee Lee 19 19 Next Generation Internet NGI: Next Generation Internet – federal program to unify and focus federal activities in advanced networking » » » » proposed $100 million per year for 3 years government, university, industry partnership coordinate network R&D across agencies coordinate federal research networks – implementation planning team in LSN – joint engineering team Prof. Younghee Lee 20 20 Next Generation Internet NGI: goal – To advance R&D, experimentation in the next generation of networking tech. to add functionality and improve performance – To develop a NGI testbed, emphasizing endto-end performance – To develop and demonstrate revolutionary applications Prof. Younghee Lee 21 21 Next Generation Internet: Technology Spiral Commercialization Privatization 21st Century Networking SprintLink, InternetMCI Active Nets wireless WDM Ubi-net Research and Development Interoperable High Perf R&E nets Agency Nets ANS ARPAnet NSFNET gigabit testbeds vBNS, ESnet, NSI, DREN QoS Prof. Younghee Lee Partnerships 22 22 Advanced TCP/IP and ATM Networks IP based Internet – – – – – – – – – TCP and IP Dynamic routing Wireless network Ethernet IPv6 RTP for multimedia Multicast routing protocols Integrated service/Differentiated service Overlay networks ATM Networks – – – – Internal signaling: SS7 External signaling: UNI signaling, QoS negotiation.. Physical layer specification: SDH/SONET ATM adaptation: AAL Prof. Younghee Lee 23 23 ATM: Asynchronous Transfer Mode nets Internet: today’s de facto standard for global data networking 1980’s: telco’s develop ATM: competing network standard for carrying high-speed voice/data standards bodies: – ATM Forum – ITU ATM principles: small (48 byte payload, 5 byte header) fixed length cells (like packets) – fast switching – small size good for voice virtual-circuit network: switches maintain state for each “call” well-defined interface between “network” and “user” (think of telephone company) Prof. Younghee Lee 24 24 Design Philosophy of Internet Protocols 1. Effective for multiplexed utilization of existing interconnected networks – Packet switching – Gateways to interconnect networks: router 2. Second level goals – – – – – – – Survivability in the face of failure: stateless, fate sharing Support multiple types of communication services Accommodate a variety of networks Permit distributed management of its resources Cost effective Host attachment with a low level of effort Be accountable Prof. Younghee Lee Less important 25 25 Design Philosophy of Internet Protocols Problems – Inefficiency – High cost of attaching a host to the Internet – Poor implementation or malicious implementations may hurt the network as well as host Soft-state – – – – Announce state Refresh state Timeout state Penalty for timeout – poor performance Flow concept – Robust way to identify communication flows » Possible mechanism to provide non-best effort service Prof. Younghee Lee 26 26 End-to-End Argument Rationale: Moving function upward in a layered system, closer to the application that uses the function – Application requirements the function Think twice before implementing a functionality that you believe that is useful to an application at a lower layer If the application can implement a functionality correctly, implement it a lower layer only as a performance enhancement Prof. Younghee Lee 27 27 Reading Assignments [Saltzer84] J.H. Saltzer, D.P. Reed and D.D. Clark, “END-TO-END ARGUMENTS IN SYSTEM DESIGN” [cla00] David D. Clark et al., “Rethinking the design of the Internet :The end to end arguments vs. the brave new world” [moors04?] Tim Moors “A critical review of “ENDTO-END ARGUMENTS IN SYSTEM DESIGN” Prof. Younghee Lee 28 28 Example: Reliable File Transfer Host A Host B Appl. OS Appl. OK OS Solution 1: make each step reliable, and then concatenate them – Requires correct programs for systematic countering of threats » Program for file transfer. What about other applications? – Acceptably small probability of each of the individual threat » Brute force countermeasures e.g.) doing 3 times => uneconomical Solution 2: end-to-end check and retry – Multiple e2e check & retry? => some part of the system is in need of repair – Local error control vs e2e error control Prof. Younghee Lee 29 29 Discussion Solution 1 not complete – What happens if the sender or/and receiver misbehave? The receiver has to do the check anyway! Thus, full functionality can be entirely implemented at application layer; no need for reliability from lower layers Is there any need to implement reliability at lower layers? Yes, but only to improve performance Example: – assume a high error rate on communication network – then, a reliable communication service at datalink layer might help Prof. Younghee Lee 30 30 Trade-offs Application has more information about the data and the semantic of the service it requires (e.g., can check only at the end of each data unit) A lower layer has more information about constraints in data transmission (e.g., packet size, error rate) – Note: these trade-offs are a direct result of layering! Rule of Thumb – Implementing a functionality at a lower level should have minimum performance impact on the application that do not use the functionality Prof. Younghee Lee 31 31 Other Examples Secure transmission of data – CDMA eavesdropping case in Korea Duplicate message suppression Transaction management RISC vs. CISC Prof. Younghee Lee 32 32 Internet & End-to-End Argument At network layer provides one simple service: best effort datagram (packet) delivery Only one higher level service implemented at transport layer: reliable data delivery (TCP) – performance enhancement; used by a large variety of applications (Telnet, FTP, HTTP) – does not impact other applications (can use UDP) Everything else implemented at application level Why ? – 1. The complexity of the core network is reduced, which reduces costs and facilitates future upgrades to the network. – 2. Generality in the network increases the chances that a new application can be added without having to change the core of the network. – 3. Applications do not have to depend on the successful implementation and operation of application-specific services in the network, which may increase their reliability. Prof. Younghee Lee 33 33 Internet & End-to-End Argument Occam’s razor – "Entities should not be multiplied unnecessarily." » "God's existence cannot be deduced by reason alone." – "when you have two competing theories which make exactly the same predictions, the one that is simpler is the better.“ » "If you have two theories which both explain the observed facts then you should use the simplest until more evidence comes along" » "The simplest explanation for some phenomenon is more likely to be accurate than more complicated explanations." » "If you have two equally likely solutions to a problem, pick the simplest." » "The explanation requiring the fewest assumptions is most likely to be correct." » Many scientific researches : Newton, Einstein, Heisenberg, Steven Hawking….. Communication subsystem is frequently specified before applications that use the subsystem are known: What I had done during around 1987 ~ 1993. » May be tempted to take on more function than necessary » E2e to reduce such temptations Prof. Younghee Lee 34 34 Key Advantages The service can be implemented by a large variety of network technologies Does not require routers to maintain any fined grained state about traffic. Thus, network architecture is – Robust – Scalable What About Other Services? – Multicast? – Quality of Service (QoS)? Prof. Younghee Lee 35 35 Problem of e2e arguments Inefficiency – End hosts do the network level functions such as retransmission, congestion control Difficulties to implement some functions which need network level control information Inappropriate implementation hurt the network as well as the hosts – Greedy sources aren’t handled well Weak accounting and pricing tools Weak administration and management tools Incremental deployment difficult at times – Result of no centralized control: distributed control needed to be upgraded » Too many systems at the same time to upgrade: No more “flag” days – Are active networks the solution? Prof. Younghee Lee 36 36 Summary: End-to-End Arguments If the application can do it, don’t do it at a lower layer -- anyway the application knows the best what it needs – add functionality in lower layers iff it is (1) used and improves performances of a large number of applications, and (2) does not hurt other applications Success story: Internet Prof. Younghee Lee 37 37 Tussle Design Principles Design for variation in outcome – Allow design to be flexible to different uses/results Isolate tussles – QoS designs isolate ToS bits from other parts of packet : ToS : tussle space -> network IP level – Separate QoS decisions from application design » Port: tussle space -> service provider or applications Provide choice – Creates competition fear between providers – Helps shape the tussle Prof. Younghee Lee 38 38 Tussle Design Principles The future of e2e arguments – Innovation » Core of network modification for new application -> high hurdle, unproven – Reliability and robustness » If Bits of application are “in the network” => increase the number of points of failure Processing module for certain application services » The more simple the core of the network, the more reliable it’s likely to be – – – – Evolution and enhancement of existing, mature applications is inevitable The most we can do to protect maturing applications is to bias the tussle Keeping the net open and transparent for new applications is the most important goal Failures of transparency will occur-fault reporting- for tussle management (not only for tool of fault repair) – Peeking is irresistible – Separation of policy and mechanism: value-neutral Lesson for designer – Failure of QoS deployment: » ISP to deploy QoS: Why risk investment in this case?; value-transfer mechanism possibility of being rewarded » User need to be able to exercise choice to select the ISP: competitive fear: ToS routing-through another ISP? – Analyze the tussle: surrounding context – Powerful force is “Tussle of competition” » Protocol design by creating opportunities for competition => direction of evolution Prof. Younghee Lee 39 39 Rethinking the design of the Internet Application level function can’t be built in the core of the network – Should be implemented with the knowledge and help of the applications at the end host But – Operation in an untrustworthy world: attacks on end-point, spam email, .. » need more mechanism in the center of the network to enforce “good” behavior. Police in the network? – More demanding applications: QoS? » Installing stream servers close to the recipient? – ISP service differentiation – The rise of third party involvement: taxation to law enforcement, public safety, blocking of certain content – Less sophisticated users: ease of use, cell-phone, PDA, Prof. Younghee Lee 40 40 Rethinking the design of the Internet Technical responses – The different forms of e2e arguments » Two version: 1. best effort, 2. to the design of applications, some intermediate server? » Modify the e2e: placement of function at the edge of the network for deleting spam, pornography, eavesdrop on suspected terrorists » Adding functions to the core of the network (Firewalls, traffic filters, NAT) Stream of data must be routed through the device – Control element into the path of communication The device must have ability to see what sort of information is in the stream – Revealing or hiding the content of messages » Labels on information » Trusted third parties: public-key certificates Prof. Younghee Lee 41 41 A critical review of e2e arguments in system design E2e arguments – Firewalls, caches and NATs, active networks, multicasting and network QoS Ends? – People – File transfer applications? – TCP? » Applications should check integrity according to the e2e arguments. » 1. application writers do not wish to be burdened with xxx What about banking? » 2. error rate within the end system is negligible » Can’t be justified on the basis of e2e arguments, => trust base Prof. Younghee Lee 42 42 A critical review of e2e arguments in system design Performance – Performance benefits of localized implementation » Error control: localized error recovery => good for latency, network load » Multicasting: overlay multicast? » QoS: ATM, DiffServ, IntServ, .. – Performance benefits of e2e implementation » Less processing required in the network Simple or stupid network: more scaleable » Easier to design and change – It’s not possible to generalize the performance implications of e2e implementations Redundancy of local implementation, network transparency, ease of deployment, decentralism Prof. Younghee Lee 43 43 A critical review of e2e arguments in system design Responsibility and Trust – Ends?: Transport layer <= need trust Mature operational commercial environment? – E2e check is not weekly needed – Military, R&D network case; unstable environment Security – “Commercial Off The Shelf(COTS) won’t divulge secret information? => link level encryption to use COTS e2e Routing: Source routing? Congestion control – – – – – Congestion? => network layer problem End point : altruistic? Selfish? Unnecessary performance penalty: slow start Hard to detect congestion at end node Network knows when and where adaptation is needed Prof. Younghee Lee 44 44 The Traditional Internet Best effort service. – Network makes honest effort to deliver data Network is black box. – Users have no information about expected performance User User ? Works well for many applications. – Byte streaming (ftp, web) – Interactive data (telnet) But the network provides no help for more advanced applications. – Reservations, proactive feedback, QoS optimization Prof. Younghee Lee 45 45 Integrated Services Networks The Rosy Picture Network offers a choice of network quality of service (QoS). – guaranteed bandwidth, “gold” service, .. – Negotiate expected performance and service – Can get predictable network performance User Distributed Simulation Distance Learning Games Video Conferencing User Network QoS will enable a rich set of value-added electronic services. – Use wide range of resources – Controllable quality/cost – Services adapt to network and system conditions Prof. Younghee Lee 46 46 Why Is It Not Happening? Network QoS model is too primitive. – Large gap between network and application QOS – Too low level; hard to use Applications have insufficient information about the network to make informed decisions. – Am I using a modem or a gigabit Ethernet? – Where can I get more bandwidth Distributed Simulation Distance Learning User Too Complex Games Video Conferencing No Control User No Information Service providers have little control over how their traffic is handled. – No customization Implication to active network, overlay network, ad hoc network? Knowledge plane? Prof. Younghee Lee 47 47