Transcript Course Introduction

CSC/ECE 573
Internet Protocols
Fall 2012, Section 001
Rudra Dutta
Course Objectives

Learn how the Internet works
–

Assume some basic familiarity
–
–


How to design and write basic network programs
Baseline idea of main Internet entities, IP, TCP
Extend knowledge / applicability of knowledge
Depth
–
–

Foundational knowledge
Learn more, examine, experiment with baseline knowledge
Substantiate all answers (prior knowledge)
Breadth
–
–
–
Learn about more protocols
Some idea of capabilities/limitations of the Internet
Architectural issues – possible evolution
Copyright Fall 2012, Rudra Dutta, NCSU
2
Scope

Protocol descriptions and socket programming
only briefly as preliminaries / building blocks
 Focus on
–
–
–

Investigation by doing
RFC reading
Paper reading
Will not address some important and relevant
topics
–
–
Queuing models or other analytical results
Simulation or other performance questions
Copyright Fall 2012, Rudra Dutta, NCSU
3
Background

You need to understand networking
–
ECE/CSC570 or equivalent


You need to be able to program
–
–

Need to be conservative in estimating “equivalent”
Comfortable with C/C++
Familiar with Unity / VCL
You need to “learn-on-the-fly”
–
Basic goal of graduate study
Copyright Fall 2012, Rudra Dutta, NCSU
4
Challenge – Heterogeneity

Class of 100 students
–
–
–
–
–
–

Different stages of degree work
MS / PhD
Major / Non-major
Full-time / Part-time
Student owned computing
Socket programming (and other preparation)
This course attempts to be many things to many
people (with different needs and abilities)
–
Cannot be all things to all people
7
Copyright Fall 2012, Rudra Dutta, NCSU
5
What’s the Internet to you?

What do you know about the Internet?
 What would like to know about it?
 What would you consider “indispensable” to get
out of this course?
 “ … troubleshooting small networks, security
enhancing protocols, domain-specific, mac layer
addresses/registration, next-gen arch, common
protocol limitations, scalability of internet, ipv6,
application development, routing protocols,
mobile IP, proactive and reactive routing,
20 relative importance layers, …”
Copyright Fall 2012, Rudra Dutta, NCSU
6
What’s the Internet to you?

Last year’s responses:

IPv6 IP address autoconfiguration
link speed
autoconfig/neg
socket/kernel programming primer
fragmentation L2 L3 and L4
NAT
QoS protocols
VoIP/mm
RTP
DNS mobile IP
handoff
issues
firewalls
IP futures
routing protocols
(BGP)
flow-based routing
MPLS traffic engg
VLANs router/network virtualization
“hands-on” virtual
router
DDNS multidomain networks
multiprovider/federation caching
VPN related protocols
MANET
WAN optimizations
20
Copyright Fall 2012, Rudra Dutta, NCSU
7
Work Products / Vehicles

Descriptive
–
Consult texts, RFCs, respected papers

–

Homeworks, midterm test questions
Tools
–
Linux tools, Seattle, Wireshark

–

Help pages and man pages
Assignments
Programming
–
–

Any source, but substantiate from definitive
Applications (sockets), kernel
Assignments, projects
Environment
–
–
SoC, VCL, Unity
GENI
Copyright Fall 2012, Rudra Dutta, NCSU
8
Grading

Work Products
–
–
–

Homeworks (40%)
Project (30%)
Tests (15%, 15%)
Homework assignments
–
–
–
Include programming
Use WolfWare submit
Includes quizzes
Copyright Fall 2012, Rudra Dutta, NCSU

Midterm tests
–
–
–
–
–
Open book, open notes (BYON)
Open Internet (only static)
One hour
Answer on test provided
May attach additional sheets for
space if needed
9
Instructional Mode

Self-guided, inquiry-driven, group-based
 No typical lectures except a few introductory / overarching
 Descriptive topics
–
–
–
–
–
–

Programming / lab topics
–
–
25
Question list will be provided – feel free to contribute
Texts, cited papers, RFCs are automatic sources
Other sources may be flagged for some topics
Slidepacks will be provided for most topics
Lecture periods: Q&A, discussion, investigation
Often I will have no answers – at least immediately
–
In-class demos will be provided for baseline
Q&A in some lecture periods
Many will be group
Copyright Fall 2012, Rudra Dutta, NCSU
10
Cheating

I will try not to cheat you.
 I will try not to let you get cheated by others.
35
Copyright Fall 2012, Rudra Dutta, NCSU
11
Quiz – In-class





Write your name + 9-digit ID
Brief answers
Answer only if you know; no guesses please
No consultation with anybody – no Internet
5 minute time limit
45, 60
Copyright Fall 2012, Rudra Dutta, NCSU
12
Project

Written work products
–
–
–
–

Project proposal (with possible required
resubmission) (5%)
Interim report (5%)
Final report (5%)
Work products should be competently written
Code and demo of realized system (15%)
–
Build instructions (strongly prefer makefile)
– Minimal documentation

Slide pack for final system
Copyright Fall 2012, Rudra Dutta, NCSU
13
Project proposal

Required (graded)
–
–
–
–
–

Identify team
Brief description of functionality of system
Clear description of envisioned final demo
Preliminary entity-level design
Task/timeline/point person decomposition
Receive approval from instructor
–
Mandatory changes may be suggested
– Requires resubmission (short timeline: 2 – 4 days)

If you drop this course, drop early
Copyright Fall 2012, Rudra Dutta, NCSU
14
Interim and Final Reports

Interim report
–
–
–

Course corrections, changes (with reasons)
Changes may incur small penalty based on
reasonableness
(Much larger penalty if undeclared changes in final)
Final report
–
Reiterate problem statement, design
– Description of experiments, results
– Self-contained, correctly sized (paper-level)
Copyright Fall 2012, Rudra Dutta, NCSU
15
Project Topics

Develop a solution/tool for some specific purpose
–

System oriented
–
–


Network related – cannot be simple socket app
Typically require developing
Simply testing somebody else’s code is aiming low
Learn by doing
Topics / platform / framework
–
–
–
–
Delving deeper in some issue
Might seed with paper, app, RFC
Might start with homework, put bells and whistle
Some samples will be provided
Copyright Fall 2012, Rudra Dutta, NCSU
16
Project Teams

Teams of 4 (assigned for previous work products)
–
–
Complement strengths, if possible
All mails copied to all team members

–
Teams attend (or bunk) class as a team


Failure imposes penalty on those copied
Can provide exceptions by mail copying all members
Work product and grade – per team
Individual assessments – confidential to instructor/TA
– Well-oiled machines produce high grades for all
– Malfunctioning teams (rare) pull everybody down
– Broken teams (hardly ever) may cause instructor
intervention
–
Copyright Fall 2012, Rudra Dutta, NCSU
17
Administration and Communication

WolfWare website
 WolfWare Message board
–
–
–

Not instantaneous, but regular
Primary means of communicating with instructor
Archived after each major work product
Office hours
–
–
Blackboard Collaborate
In person
Email …
 WolfWare submit, GradeBook
 Course workspace lockers

Copyright Fall 2012, Rudra Dutta, NCSU
18
Support

Teaching Assistants
–
–
Arpit Gupta
Amlakawit Medhin

Network lab personnel
 Unity / VCL computing help
 GENI support
 Yourself.
70
Copyright Fall 2012, Rudra Dutta, NCSU
19
The Internet
Original Motivation

Interconnecting widely separated (physical)
networks, with possibly dissimilar DLC
 Fundamental characteristics:
–
–

Bandwidth is precious
Traffic is bursty
Many other goals/assumptions
–
BUT: flexibility built in
Copyright Fall 2012, Rudra Dutta, NCSU
21
Some Design Philosophies







KIS,S
Performance, efficiency, cost
Objects should not require context - packets
Working solution in hand is worth more than
perfect solution in bush
Scalability
Modularity (of protocols)
Endpoint control
Copyright Fall 2012, Rudra Dutta, NCSU
22
Node-to-node
End-to-end
The seven layers
Application
Top level user of the system
Presentation
Resolve platform issues (data
representation, possibly encryption)
Session
Full-duplex, expedited data delivery,
session synchronization
Transport
Error control, flow control, multiplex
Reliability
Network
Concatenates links to form end-to-end
abstraction
Data Link Control Organizes bit transmissions into frame
transmissions (LLC, MAC sublayers)
Physical
Copyright Fall 2012, Rudra Dutta, NCSU
Moves bits between physically connected
end-systems
23
Peer Processes
End Node
Copyright Fall 2012, Rudra Dutta, NCSU
DLC
DLC
DLC
DLC
Phy
Phy
Phy
Phy
Intermediate Node
Intermediate Node
End Node
24
Layers in a Router/Switch
Copyright Fall 2012, Rudra Dutta, NCSU
A
R
D
NET
NET
NET
DLC
DLC
DLC
DLC
PHY
PHY
PHY
PHY
25
Software Operation

Some of L2 and all of L3 protocols are software
processes
 Exchange of data requires IPC, and blocking

Buffering may be
employed between
layers
–
Copyright Fall 2012, Rudra Dutta, NCSU
Almost certainly at
higher than the bitpipe
layer
26
Buffering at L3

Operation of L3 itself may require buffering data
–

Input-buffer-process-buffer-output cycle
–

Store-and-forward
May fall behind
Discard data  loss
Copyright Fall 2012, Rudra Dutta, NCSU
A
R
D
NET
NET
NET
DLC
DLC
DLC
DLC
PHY
PHY
PHY
PHY
27
Network Performance

Ultimately, measured in quantities the end-user
cares about
–
–

Delay, throughput
Other metrics derived from these
More sophisticated metrics
–
Predictability / Reliability / Survivability
– Variability of delay or throughput
– Guarantees - Quality of Service contracts
– Security
Copyright Fall 2012, Rudra Dutta, NCSU
28
Traffic Characterization

Traffic - that which is carried by network
–
Generated and consumed by end-nodes
– “Demand” for networking services: b/w and switching

Magnitude (bandwidth)
–

Lifetime
–

Could vary with time, if “reasonably long” life
How long it is resident in the network
Arrival and departure patterns
–
Call (like telephony) arrival and departure
– Increment and decrement
– Periodic (scheduled)
– Static (long-term)

Requirement of performance
–
Hard or statistical
Copyright Fall 2012, Rudra Dutta, NCSU
29
Network View

Connectivity is always less than full (esp. in large networks)
 Because of scalability, hierarchy seems inevitable
 Nature of end-nodes and intermediate nodes vary
 All links are TDM (FDM modeled as separate links)
4
2
1
3
Copyright Fall 2012, Rudra Dutta, NCSU
30
Traffic Aggregation - Static Traffic


Consider lowest level networks
Assume each station injects traffic steadily
–

Due to aggregation, magnitude increases as traffic
climbs hierarchy
–


But constant nature of traffic remains
Aggregation/dis-aggregation process is straightforward
for intermediate nodes
–

Number of bits injected per time unit is constant for each source
Effectively same as slotted TDM
Therefore static traffic is stable - remains static at higher
levels of hierarchy
Magnitude and therefore capacity, of course, must
increase at higher levels
Copyright Fall 2012, Rudra Dutta, NCSU
31
Bursty Traffic

Traffic is generated intermittently at each end
node
–

Assume (peak) rates are known
Question of capacity and aggregation become
intertwined
–
One approach: pretend each end node is a steady
source at its peak rate, then provision as before

–
Aggregation will be easy
Another approach: provision for average




Do bursts arrive deterministically?
Sometimes link will be busy when traffic arrives to use it
Must store-and-forward, or discard
Question of slotting TDM comes in - work conservation
Copyright Fall 2012, Rudra Dutta, NCSU
32
A View of Aggregation
1
2
burstiness
4
2
3
1
3
4
4
magnitude (“bandwidth”)
Copyright Fall 2012, Rudra Dutta, NCSU
33
Static Traffic in Real Networks

Aggregation can tend to cancel out bursts
 Finite capacity of pipe will appear as static-ness
of traffic to next level of aggregation
–
Also: Concept of “elastic traffic”



Source-to-destination traffic flows in the Internet are not
static as generated, but congestion slows down bursts
In response, flow duration will increase
Empirical observation tends to confirm
–
–
For example, CAIDA data
Exhibits “busy hour” traffic patterns

Changes from hour to hour, but each pattern stable over
days and weeks
Copyright Fall 2012, Rudra Dutta, NCSU
34
About Loss

Loss may occur on the link
–
–

Loss may occur at intermediate nodes
–
–

Usually very little in guided medium - ignore
Usually handled by L2 transmissions or ignored
Store-and-forward buffers are finite - may overflow
Other mechanism at intermediate node may discard
Does retransmission occur?
–
–
May not be required / desired
If desired,


May be at L2, on link
May be at L4, E2E
Copyright Fall 2012, Rudra Dutta, NCSU
35
Providing Guarantees - About Delay

Controversial proposition:
–
–

“If delay is not important, capacity is not important”
“If delay is important, capacity must be large OR
aggregation must be slotted OR both”
Links must
–
–
Provide connectivity
Have capacity to carry traffic

Routers must have memory and processor
capacity to switch traffic
 Network design / resource provisioning problem
Copyright Fall 2012, Rudra Dutta, NCSU
36
Two Modes of Networking


Traffic Networks and Transport Networks
Traffic networks: where stochastic demand picture is
operative
–
–

Short term switching/routing
Design for connectivity
Transport networks: where traffic demands of static
magnitude are seen to be operative
–
–
–
–
(Semi-) Permanent
QoS considerations paramount
Demands seen to be injected at transport network nodes, lower
level networks not visible
Design for connectivity and capacity
Copyright Fall 2012, Rudra Dutta, NCSU
37
Evolution of Structure

Initially, an adaptation of the hierarchical
structure of POTS
–

But with flexibility in topology at each level
Number of levels also flexible
–
–
Core routing phase of the Internet
Core also called “backbone”
Copyright Fall 2012, Rudra Dutta, NCSU
38
It’s Who You Know

Know a smarter router!
–
–
–
–
If you are a host, know your local router
If .. Local router, .. Site router
If .. Site router, .. Core router
If .. Core router, you have to know everything !
Copyright Fall 2012, Rudra Dutta, NCSU
39
Evolution of Structure

From one to multiple backbones (ISPs)
–

Exchange points connect backbones
CAIDA MAPNET Link
Copyright Fall 2012, Rudra Dutta, NCSU
40
Who Manages/Controls the Internet?

ISOC (Internet Society): non-profit
organization established to foster interest in
the Internet
–
–

organizes conferences (similar to ACM or IEEE)
hosts IANA (assigns numbers used in TCP/IP
protocols)
IAB (Internet Architecture Board)
–
–
–
originally set up by DoD to oversee ARPAnet
sets policy and direction for TCP/IP and the
Internet
elected by ISOC
Copyright Fall 2012, Rudra Dutta, NCSU
41
Who Manages/Controls the Internet?

IETF: concentrates on short-, medium-term
engineering problems, develops standards
 IESG: (committee consisting of IETF chair
and area managers)
–

coordinates IETF activities and approves
standards
IRTF: concentrates on long-term research
issues
Copyright Fall 2012, Rudra Dutta, NCSU
42
IAB Organization
General
Copyright Fall 2012, Rudra Dutta, NCSU
Sub-IP
43
Standards Making Processes
Copyright Fall 2012, Rudra Dutta, NCSU
44
IETF




Small, focused efforts preferred to larger
comprehensive ones
Published goals and milestones
No formal voting
Disputes resolved by discussion and demonstration
(mostly)
–




“Rough consensus and running code” (D. Clark)
Mailing list and face-to-face meetings
Open, no-fee membership (compare: ATM Forum)
Standardization only after several implementations
Specifications, in text format, available without
charge by FTP or HTTP (compare: ITU, IEEE)
Copyright Fall 2012, Rudra Dutta, NCSU
45
RFCs, including Internet Standards




“Request for Comments”, since 1969
“A series of notes that contain surveys,
measurements, ideas, techniques, and observations,
as well as proposed and accepted TCP/IP protocol
standards” (Comer)
Many RFCs are not standards
Internet drafts: working documents, but often used for
prototypes
–

RFCs numbered sequentially
–

edited, but not refereed
Currently at:
6704
Forcerenew Nonce Authentication D. Miles,
W. Dec, J. Bristow, R. Maglione [ August 2012 ] (TXT
= 26538) (Updates RFC3203) (Status: PROPOSED
STANDARD) (Stream: IETF, Area: int, WG: dhc)
Copyright Fall 2012, Rudra Dutta, NCSU
46
A Timeline
Prehistory
.
.
Early 1960’s: Importance of packet switching – Kleinrock / Baran
67: Roberts at MIT proposes ARPANET to DARPA
68: ARPANET contract awarded to BBN
69: Four ARPANET nodes, starting with Kleinrock’s center
72: E-mail becomes available
73: TCP/IP – Bob Kahn and Vint Cerf
England and Norway connect to ARPANET
79: ARPANET at a 100 nodes
80’s: DARPA funds Berkely UNIX with TCP/IP
Split in ARPANET – MILNET
83: Jan 1st – ARPANET starts using TCP
84: DNS
86: NSFNET
88: Nov 1st – Internet worm
89: More than 100,000 nodes, proposal for WWW, NSFNET  T1
90: ARPANET retired
93: NCSA Mosaic
95: NSFNET backbone decommissioned, NSF funds MCI for vBNS
99: Abilene goes on line, Internet has more than 50,000,000 nodes
00: Internet2 backbone deploys IPv6
01: Dutch SURFnet and Internet2's Abilene connect via gigabit ethernet
02: Internet2 has 200 university, 60 corporate, and 40 affiliate members
03: Last Abilene segment upgraded to 10Gbps
04: DNS update moves to nearly real-time for .com/.net
Copyright Fall 2012, Rudra Dutta, NCSU
47
Recent Directions

Increasing concern about
–
–

Increasing importance of
–
–
–

Predictability / availability
Accountability / measurement
“Untethered edge”
Cloud computing
Virtualization
Architectural reexamination
Copyright Fall 2012, Rudra Dutta, NCSU
48