CSE 524: TCPIP Internetworking Protocols

1
CSE 524 TCP/IP Internetworking Protocols

• Wu-chang Feng

2
CSE524 Lecture 1

• Overview, Internet architecture

3
Quiz

• How much do you know?

4
Syllabus

• http//www.cse.ogi.edu/class/cse524/
• TA
• Guangzhi Liu gliu_at_cse.ogi.edu
• Office hours
• Thursday 3pm-6pm
• CSE Central 146
• Required book
• Kurose/Ross, Computer Networking A Top-Down
  Approach Featuring the Internet

5
Syllabus

• Grading
• Exams
• 25 Midterm (10/29/2001 Chapters 2, 3)
• 25 Final (11/28/2001 Chapters 1, 4, 5)
• Other
• 25 Research paper (12/5/2001)
• 25 Homework, quizzes, class participation
• Coarse-grained grading

6
Research paper

• You become the expert on X. You teach me.
• Current survey and projected future of X
• X not covered in course
• Any length, no more than 10 pages
• Topic and scope negotiated by e-mail
• Approval by 10/29/2001, Due by 12/5/2001
• Topics Id like to know more about
• Ultra-wide band, sensor networks, high-speed
  switching and routing products, web switching
  products, peer-to-peer networks,
  content-addressable networks, overlay networks,
  IPv6, mobile IP, intrusion detection systems, IP
  traceback, DDoS attacks, DDoS prevention, MPLS,
  lambda switching, Internet worms,

7
Research paper

• Grading
• Correctness
• Completeness
• Content
• References
• Originality
• Each paper will be Google tested
• Quoting and referencing is fine
• Wholesale copying is not

8
Goals of course

• Higher-level design decisions and their impact
• Encyclopedia of essential protocols and algorithms

9
Outline of course

• Internet architecture, history, future (Chapter
  1)
• Physical, data-link layers (Chapter 5)
• Network layer (Chapter 4)
• Transport layer (Chapter 3)
• Application layer (Chapter 2)

10
About the course

• Extremely condensed
• Not comprehensive
• Hundreds of protocols
• PSU/OCATE 510 - Internet Routing
• PSU/OCATE 510 - Network Management/Security
• OHSU 58X - Multimedia Networking
• OHSU 58X Internet Technology and Research

11
Internet Architecture

• http//www.nap.edu/html/coming_of_age/
• http//www.ietf.org/rfc/rfc1958.txt
• Packet switching over circuit switching
• Hourglass design
• End-to-end architecture
• Layering of functionality
• Distributed design, decentralized control
• Superior organizational process

12
The Network Core

• mesh of interconnected routers
• the fundamental question how is data transferred
  through net?
• circuit switching dedicated circuit per call
  telephone net
• packet-switching data sent thru net in discrete
  chunks

13
Network Core Circuit Switching

• Resources reserved for call on an end to end
  basis
• link bandwidth, switch capacity
• dedicated resources no sharing
• circuit-like (guaranteed) performance
• call setup required

14
Network Core Circuit Switching

• network resources (e.g., bandwidth) divided into
  pieces
• pieces allocated to calls
• resource piece idle if not used by owning call
  (no sharing)
• dividing link bandwidth into pieces
• frequency division
• time division

15
Network Core Circuit Switching Example

• 1890-current Phone network
• Fixed bit rate
• Mostly voice
• Not fault-tolerant
• Components extremely reliable
• Global application-level knowledge throughout
  network

16
Network Core Packet Switching

• each end-end data stream divided into packets
• user A, B packets share network resources
• each packet uses full link bandwidth
• resources used as needed,

• resource contention
• aggregate resource demand can exceed amount
  available
• congestion packets queue, wait for link use
• store and forward packets move one hop at a time
• transmit over link
• wait turn at next link

17
Network Core Packet Switching
10 Mbs Ethernet
C
A
statistical multiplexing
1.5 Mbs
B
queue of packets waiting for output link
45 Mbs
18
Network Core Packet Switching Example

• 1981-current Internet network
• Variable bit rate
• Mostly data
• Fault-tolerant
• Components not extremely reliable (versus phone
  components)
• Distributed control and management

19
Packet switching versus circuit switching

• Packet switching allows more users to use network!

• 1 Mbit link
• each user
• 100Kbps when active
• active 10 of time
• circuit-switching
• 10 users
• packet switching
• with 35 users, probability gt 10 active less that
  .004

N users
1 Mbps link
20
Packet switching versus circuit switching

• Is packet switching a slam dunk winner?

• Great for bursty data
• resource sharing
• no call setup
• Excessive congestion packet delay and loss
• protocols needed for reliable data transfer,
  congestion control
• Q How to provide circuit-like behavior?
• bandwidth guarantees needed for audio/video apps
• still an unsolved problem (chapter 6)

21
Hourglass design
22
Hourglass design

• D. Clark, The design philosophy of the DARPA
  internet, SIGCOMM 1988, August 16 - 18, 1988.
• http//www.acm.org/pubs/citations/proceedings/comm
  /52324/p106-clark/

23
Hourglass design

• Only one protocol at the Internet level
• Minimal required elements at the narrowest point
• IP Internet Protocol
• http//www.rfc-editor.org/rfc/rfc791.txt
• http//www.rfc-editor.org/rfc/rfc1812.txt
• Unreliable datagram service
• Addressing and connectionless connectivity
• Fragmentation and assembly
• Innovation at the edge
• Phone network dumb edge devices, intelligent
  network
• Internet dumb network, intelligent edge devices

24
Hourglass design

• Simplicity allowed fast deployment of
  multi-vendor, multi-provider public network
• Ease of implementation
• Limited hardware requirements
• Eventual economies of scale
• Designed independently of hardware
• Hardware addresses decoupled from IP addresses
• IP header contains no data/physical link specific
  information
• Allows IP to run over any fabric

25
Hourglass design

• Waist expands at transport layer
• Two dominant services layered above IP
• TCP Transmission Control Protocol
• Connection-oriented service
• http//www.rfc-editor.org/rfc/rfc793.txt
• UDP User Datagram Protocol
• Connectionless service
• http//www.rfc-editor.org/rfc/rfc768.txt

26
Hourglass design

• TCP Transmission Control Protocol
• Reliable, in-order byte-stream data transfer
• Acknowledgements and retransmissions
• Flow control
• Sender wont overwhelm receiver
• Congestion control
• Senders wont overwhelm network

27
Hourglass design

• UDP User Datagram Protocol
• Unreliable data transfer
• No flow control
• No congestion control

28
Hourglass design

• Check out /etc/services on nix or
  C\WIN\system32\services
• IANA
• http//www.iana.org/assignments/port-numbers
• What uses TCP?
• HTTP, FTP, Telnet, SMTP, NNTP, BGP
• What uses (mainly) UDP?
• SNMP, NTP, NFS, RTP (streaming media, IP
  telephony, teleconferencing), multicast
  applications
• Many protocols can use both

29
Hourglass design

• Question?
• Are TCP, UDP, and IP enough?
• What other functionality would applications need?

30
Hourglass design

• Security?
• Quality-of-service?
• Reliable, out-of-order delivery service?
• Handling greedy sources?
• Accounting and pricing support?
• IPsec, DiffServ, SCTP, .

31
End-to-end principle

• J. H. Saltzer, D. P. Reed and D. D. Clark
  End-to-end arguments in system design,
  Transactions on Computer Systems, Vol. 2, No. 4,
  1984
• http//www.acm.org/pubs/citations/journals/tocs/19
  84-2-4/p277-saltzer/

32
End-to-end principle

• Where to put the functionality?
• In the network? At the edges?
• End-to-end functions best handled by end-to-end
  protocols
• Network provides basic service data transport
• Intelligence and applications located in or close
  to devices at the edge
• Violate principle as a performance enhancement

33
End-to-end principle

• The good
• Basic network functionality allowed for extremely
  quick adoption and deployment using simple
  devices
• The bad
• New network features and functionality are
  impossible to deploy, requiring widespread
  adoption within the network
• IP Multicast, QoS

34
Layering

• Modular approach to network functionality
• Example

Application
Host-to-host connectivity
Link hardware
35
Layering Characteristics

• Each layer relies on services from layer below
  and exports services to layer above
• Interface defines interaction
• Hides implementation - layers can change without
  disturbing other layers (black box)
• Examples
• Topology and physical configuration
• Routing
• Applications require no knowledge of this
• New applications deployed without coordination
  with network operators or operating system vendors

36
Protocols

• Module in layered structure
• Set of rules governing communication between
  network elements (applications, hosts, routers)
• Protocols define
• Interface to higher layers (API)
• Interface to peer
• Format and order of messages
• Actions taken on receipt of a message

37
Layering
User A
User B
Application
Transport
Network
Link
Host
Host
Layering technique to simplify complex systems
38
Layer Encapsulation
User A
User B
Get index.html
Connection ID
Source/Destination
Link Address
39
E.g. OSI Model 7 Protocol Layers

• Physical how to transmit bits
• Data link how to transmit frames
• Network how to route packets
• Transport how to send packets end2end
• Session how to tie flows together
• Presentation byte ordering, security
• Application everything else

40
OSI Layers and Locations
Application
Presentation
Session
Transport
Network
Data Link
Physical
Switch
Host
Router
Host
41
Example Transport Layer

• First end-to-end layer
• End-to-end state
• May provide reliability, flow and congestion
  control

42
Example Network Layer

• Point-to-point communication
• Network and host addressing
• Routing

43
Layering

• Is Layering always good?
• Sometimes..
• Layer N may duplicate lower level functionality
  (e.g., error recovery)
• Layers may need same info (timestamp, MTU)
• Strict adherence to layering may hurt performance

44
Layering

• Need for exposing underlying layers for optimal
  application performance
• D. Tennenhouse and D. Clark. Architectural
  Considerations for a New Generation of Protocols.
  SIGCOMM 1990.
• Intel employees Tennenhouse is a networking
  rock star and your head of research
• Application Layer Framing (ALF)
• Enable application to process data as soon as it
  can
• Expose application processing unit (ADU) to
  protocols
• Integrated Layer Processing (ILP)
• Layering convenient for architecture but not for
  implementations
• Combine data manipulation operations across layers

45
Distributed design and control

• Reliability from intelligent aggregation of
  unreliable components
• Alternate paths, adaptivity, lack of centralized
  control
• Each network owned and managed separately
• Exception TLDs and TLD servers, IP address
  allocation (ICANN)

46
Superior organizational process

• IAB/IETF process allowed for quick specification,
  implementation, and deployment of new standards
• Free and easy download of standards
• Rough consensus and running code
• 2 interoperable implementations
• Bake-offs
• http//www.ietf.org/
• ISO/OSI
• Comparison to IETF left as an exercise

47
Acknowledgements

• Portions of this lecture and all subsequent
  lectures are taken from course slides by
  Kurose/Ross and course slides by Srini Seshans
  Computer Networking course at http//www.cs.cmu.ed
  u/srini/15-744/S01/