263350100 lecture2:( principles( - systems group · advanced(computer(networks((263350100...
TRANSCRIPT
Advanced Computer Networks 263-‐3501-‐00
Lecture 2: Principles
Patrick Stuedi
Spring Semester 2013
© Oriana Riva, Department of Computer Science | ETH Zürich
Last Bme
• Course introducBon 1. Principles 2. Wireless networking and mobility
3. Datacenter-‐ and high-‐performance network and virtualizaBon
• Recap: – Network performance
– UBlity funcBons – Network naming
3 Slides adapted from Prof. Roscoe
This week…
Principles: • Layering and modularity • Tunnels and virtual networks • The Internet Hourglass • In-‐band vs. Out-‐of-‐band signalling • The End-‐to-‐End argument • SoS state vs. Hard state • Postel’s Law (robustness principle) • Fate-‐sharing
4 Slides adapted from Prof. Roscoe
Layering and Modularity
5 Slides adapted from Prof. Roscoe
Layering and modularity
• Decompose system into layers
– Each layer only relies on services from lower layer – Each layer exports services only to layer above
• Interface between layers defines interacBon – Hide implementaBon details
6 Slides adapted from Prof. Roscoe
ISO/OSI Reference Model
ApplicaBon
Transport
Network
Physical
Link
Syntax, format, and semanBcs of informaBon
transmi^ed
Long-‐term transport issues, such as checkpoinBng
PresentaBon
Session
3 key concepts! 1. Service: Tells what the layer does 2. Interface: Tells the process above
how to access the layer 3. Protocol: How the service is
performed; the layer‘s own business.
7 Slides adapted from Prof. Roscoe
Why layering?
• Dealing with complex systems
• Explicit structure: – IdenBficaBon of complex system’s various pieces – Clear relaBonship between them
• Eases maintenance, updaBng of system
– change of implementaBon of layer’s service transparent to rest of system
– e.g. change in gateway procedure doesn’t affect rest of system
8 Slides adapted from Prof. Roscoe
Internet protocol stack (TCP/IP reference model)�
ApplicaBon
Transport
Network
Physical
Link
HTTP, SMTP, BitTorrent, …
Host-‐host data transfer TCP, UDP, RTP, …
RouBng of datagrams from source to desBnaBon IP, rouBng protocols, …
Data transfer between neighbouring elements PPP, Ethernet, WiFi, …
Bits “on the wire” UTP, Fiber, wireless, …
9 Slides adapted from Prof. Roscoe
Layering disadvantages
• DuplicaBon of funcBonality in mulBple layers – E.g., error recovery to retransmit lost data
• MulBple layers may need same informaBon – E.g. Max Transfer Size (MTU) for TCP segments
• Performance – Cannot exploit some per-‐link-‐layer techniques
• Headers can be very large – Headers can be much larger than payload
• Layer separaBon is not clean – Performance opBmizaBons
10 Slides adapted from Prof. Roscoe
Layer ViolaBons: someBmes a good idea
• Expose lower-‐layer informaBon to higher layers – E.g. TCP-‐over-‐wireless system – Pass loss informaBon up to TCP (congesBon vs. corrupBon)
• Expose higher-‐layer informaBon to lower layers – Firewalls – Network Address Translators – Transparent proxies
11 Slides adapted from Prof. Roscoe
12
Hardware reality
• All-‐in-‐one box: IP RouBng Switch – Was someBmes called a “Brouter” (Bridge + Router) – Ethernet, VLANs, IP, etc. – IP forwarding, mulBcast, etc. – RouBng: RIP, OSPF, BGP, – Policy rouBng – Etc. etc.
• QuesBon: where are the layers any more?
Slides adapted from Prof. Roscoe
Tunnels and virtual networks
13 Slides adapted from Prof. Roscoe
Tunnelling Eth.
IP pkt IP
Eth.
IP pkt Eth.
IP pkt
Tunnel
New York Zurich
Tunneling protocol over IP e.g. GRE, IP-‐IP, PPTP, IPSec, …
14 Slides adapted from Prof. Roscoe
15
Tunnelling: a few examples
Network Transport Applica1on
Applica1on SOCKS SSL/TLS
Transport IPsec Transport SSH tunnels HTTP CONNECT
Network
MPLS GRE IPIP
IPsec Tunnel
L2TP PPTP IP over DNS
Link LANE
Delivery Protocol
Payload Protocol
Also: layers are approximate! Slides adapted from Prof. Roscoe
16
Tunnelling: Why?
• Many uses!
• A few examples:
– Personal rouBng / NAT avoidance (e.g., HTTP Connect) – Traffic aggregaBon and management – Security – Mobility
Slides adapted from Prof. Roscoe
17
Mobility
• Problem: – When computer moves, address has to change (why?) – Breaks ongoing TCP connecBons
• SoluBon: computer has two addresses! – Locally acquired one (e.g. WiFi in coffee shop) – Semi-‐permanent (acquired from “home” or provider)
• MobileIP: IP traffic sent to semi-‐permanent address can be tunnelled by provider to the local interface (and vice versa)
Slides adapted from Prof. Roscoe
18
Tunnel with care…
• Complicates rouBng – Adding addiBonal “links” to a network – StaBcally routed ⇒ subopBmal (ignores rouBng protocol) – Dynamically routed ⇒ rouBng protocol doesn’t know it’s a tunnel
– EncapsulaBon can lead to rouBng pathologies • Complicates management / provisioning
– Unexpected traffic pa^erns (loops?) – Traffic is now “opaque” to the carrier
• Complicates forwarding (for IP) – Packets require “shim” header for encapsulaBon ⇒ reduced MTU, or fragmentaBon
Slides adapted from Prof. Roscoe
19
Virtual private networks • Idea: use tunnels as link layers
• ⇒ Can build private IP network over tunnels over public IP network.
• Cloud providers sell VPNs – Amazon VPN, Hybrid Cloud
• ISPs and Cloud providers sell VPN services to large customers – Router support makes this easy (though complex) – Probably pays for the Internet…
• Typically IP over IP tunnels – GRE, IPIP, PPTP, AYIYA…
• VPNs are the face of a more general class of Overlay Networks.
Slides adapted from Prof. Roscoe
20
Overlay Networks
• ObservaBon: – Can use IP connecBons as tunnels for other protocols
• Including IP – If you can establish enough “points of presence”, you can run your own network!
• RouBng protocols, addressing, etc. • Examples:
– Content distribuBon networks – ApplicaBon-‐layer mulBcast – RON (Resilient Overlay Networks)
• Be^er than IP, over IP!
Slides adapted from Prof. Roscoe
Virtual LANs (VLANS)
• Problem: – create mulBple networks from a single physical network
• Why? – IsolaBon, security, management – Rewiring is too expensive / difficult / Bme-‐consuming
21
AB C
D
E F G H
I
J
K
M
N
NS2 S1
Slides adapted from Prof. Roscoe
Virtual LANs (VLANS)
• Observe: – Switches are part of mulBple virtual networks – Hosts are usually on one network – Some links are shared between mulBple virtual networks
22
A
E G H
I
J
K S2 S1<
B C D
F
M
N
NS2 S1
Link used by both networks
Slides adapted from Prof. Roscoe
23
Moral (contd):
• Layers are useful – How else to talk about protocols? – SeparaBon of funcBon is important
• Layers include encapsulaBon ⇒ New layers can be inserted ⇒ Layers can be “looped” (tunnelling) at any level
• EncapsulaBon can be broken – “Deep packet inspecBon”, combined rouBng/switching – “Cross layer visibility” (expose underlying informaBon (both fashionable research topics!)
Slides adapted from Prof. Roscoe
The Internet Hourglass
24 Slides adapted from Prof. Roscoe
The Internet “Hourglass”
• Layering by itself does not solve all problems
• Many applicaBon layers and link layers have evolved
– Can’t have every protocol implemented over every other
Ethernet WiFi UMTS PoS
HTTP DNS NTP IM Skype CIFS
25 Slides adapted from Prof. Roscoe
The Internet “Hourglass”
ApplicaBon
Transport
Link Layer
Ethernet WiFi UMTS PoS
IPv4
TCP UDP
HTTP DNS NTP IM
“Thin waist” of IPv4
26 Slides adapted from Prof. Roscoe
The “thin waist”
• Single Network-‐layer protocol: IP • Easy to absorb new networks
– just implement IP above ⇒ supports innovaBon below the layer
• Easy to support new applicaBons anywhere – just use a transport protocol over IP ⇒ supports innovaBon above the layer
• Changing the layer itself is very difficult!
– C.f. IPv6…
27 Slides adapted from Prof. Roscoe
In-‐band vs. out of band signalling
28 Slides adapted from Prof. Roscoe
IP (the waist) is connec1onless
• But most services above it are connec1on-‐oriented!
– TCP, HTTP, SMTP, Skype, BitTorrent, etc. etc.
• So how to set up a connecBon? I.e. how to do signaling?
• TCP uses in-‐band signaling – Sends SYN/ACK/SYNACK/RST/FIN on same channel
29 Slides adapted from Prof. Roscoe
Out-‐of-‐band signalling
• AlternaBve approach • Use separate signaling channel
– Bootstrapped at start-‐of-‐day – Analogous step required in IP: DHCP (or ARP)
• Common in connec1on-‐oriented networks
– E.g. ATM, GSM, …
• Also, mostly used with hard-‐state protocols
30 Slides adapted from Prof. Roscoe
SoS state and hard state
31 Slides adapted from Prof. Roscoe
SoS state vs. Hard state
• Hard state: – Explicit creaBon and deleBon of state – No periodic updates necessary – Examples:
• TCP connecBon setup (sort of) • NFS file handles
• SoS state: – Communicate state updates periodically – All informaBon Bmes out
32 Slides adapted from Prof. Roscoe
Hard state
State
State’
“create”
“update”
“delete”
Time
…
…
33 Slides adapted from Prof. Roscoe
SoS state
State
State’
“update”
“update”
“update”
Time
…
State’
…
<Bmeout>
34 Slides adapted from Prof. Roscoe
Hard state
Simple, intuiBve in non-‐failure case
May have to do a lot of work in response to failure
Can lead to instability – E.g. update storms when “failure” detected
• Examples: – TCP connecBon setup – NFS file handles – Voice circuit setup in GSM, etc.
35 Slides adapted from Prof. Roscoe
SoS state
Failure handled with no new funcBonality (or traffic)
Failure mode is to remove unwanted state (eventually)
Generally requires more bandwidth
• Examples: – Leases (DNS, DHCP, etc.) – QoS Signaling (RSVP) – Recovery and maintenance in robust DHTs (e.g. Bamboo)
36 Slides adapted from Prof. Roscoe
The End-‐to-‐End Argument
37 Slides adapted from Prof. Roscoe
The End-‐to-‐End argument: where to put network funcBonality
If a func1on can only be correctly implemented end-‐to-‐end, it must be implemented in the end systems.
Implemen1ng it in the network can, at best, only be an op1miza1on
• In these cases, end hosts: – Can provide the funcBon without any network help – Must provide it without assuming any network help
38 Slides adapted from Prof. Roscoe
Example: reliable file transfer
• Naïve soluBon: – Make every step reliable – Concatenate the steps into a single reliable transfer
File transfer applicaBon
OS
File transfer applicaBon
OS
file Network
39 Slides adapted from Prof. Roscoe
Example: reliable file transfer
• This soluBon is not reliable! – One component fails (e.g. network corrupBon) – Others will not detect the failure
• Receiver sBll has to perform end-‐to-‐end check
File transfer applicaBon
OS
File transfer applicaBon
OS
file Network
40 Slides adapted from Prof. Roscoe
Example: reliable file transfer
• Correct soluBon: – Both ends checksum the file on disk, and compare
(or use secure hash, etc.) – If check fails, try again – Really ma^ers even today (real disks, real Oses…)
File transfer applicaBon
OS
File transfer applicaBon
OS
file Network
<
41 Slides adapted from Prof. Roscoe
End-‐to-‐End arguments
• Note that reliable transfer requires no network support at all!
• The Internet implements reliability in end hosts – TCP, etc.
• 802.11abgn also implements reliability at link layer – Q. Is this a good idea? – A. It might be for performance…
• The Internet implements rou1ng in the network – But RON shows this is oSen slower
42 Slides adapted from Prof. Roscoe
Other angles to E2E
• SomeBmes, funcBons implemented in the network are bad for the applicaBon
– E.g. reliable transfer for real-‐Bme traffic
• If funcBon has to be end-‐to-‐end, implement it in host systems.
• Don’t put it in a lower layer except: – If it unambiguously improves performance
– Does not burden applicaBons that don’t need it
43 Slides adapted from Prof. Roscoe
Robustness Principle
44 Slides adapted from Prof. Roscoe
Robustness Principle (Postel’s Law)
Be conserva1ve in what you do,
be liberal in what you accept from others
Or
Be conserva1ve in what you send,
liberal in what you accept
• Appeared in RFC 793, Transmission Control Protocol specificaBon, September 1981
45 Slides adapted from Prof. Roscoe
Example: Email
• The MIME standard RFCs define the correct format of a (mulBmedia) email message
• QuesBons: – Should you correctly format all email messages you send?
• Yes! – Should you reject incorrectly forma^ed messages you receive?
• No!
• Spam makes a great test for this
46 Slides adapted from Prof. Roscoe
Example: HTTP
• Most HTTP/1.1 servers tolerate missing header files
– Even when the standard requires them!
47 Slides adapted from Prof. Roscoe
Robustness
• Much less likely that bugs in implementaBons prevent interoperability
– Otherwise: minor bug ⇒ total communicaBon failure
• Easier to evolve protocols – Major version numbers ⇒ incompaBble, probably
– Minor version numbers ⇒ should be compaBble
• Harder to program
– Of course
48 Slides adapted from Prof. Roscoe
Fate sharing
49 Slides adapted from Prof. Roscoe
Fate sharing
• To deal with potenBal failure:
Store cri1cal system state at the nodes which rely on that state
• Only way to lose that state is if the node that relies on it fails…
… in which case it doesn’t ma^er
50 Slides adapted from Prof. Roscoe
Fate sharing example
• Goal: the only failure in the Internet which prevents communicaBon should be total parBBon
– If there exists a possible route, the Internet should find it
• Decision: Where to store connecBon state? I.e.
– Flow control – Retransmission informaBon
– Etc.
51 Slides adapted from Prof. Roscoe
Fate sharing example
• Flow-‐control state in end-‐systems:
– if end-‐systems fail, connecBon state is irrelevant anyway
State State
52 Slides adapted from Prof. Roscoe
Fate sharing example
• Flow-‐control state in end-‐systems:
– if end-‐systems fail, connecBon state is irrelevant anyway
State State
53 Slides adapted from Prof. Roscoe
Fate sharing example
• Flow-‐control state in end-‐systems:
– if end-‐systems fail, connecBon state is irrelevant anyway
State State
54 Slides adapted from Prof. Roscoe
AlternaBve: replicaBon
• Maintain flow control state in routers
– Requires replicaBon and consistency – Failure of router requires state to be recreated
State State State
55 Slides adapted from Prof. Roscoe
AlternaBve: replicaBon
• Maintain flow control state in routers
– Requires replicaBon and consistency – Failure of router requires state to be recreated
State State State
56 Slides adapted from Prof. Roscoe
AlternaBve: replicaBon
• Maintain flow control state in routers
– Requires replicaBon and consistency – Failure of router requires state to be recreated
State State State
State must be cleaned
up
57 Slides adapted from Prof. Roscoe
AlternaBve: replicaBon
• Maintain flow control state in routers
– Requires replicaBon and consistency – Failure of router requires state to be recreated
State State State
58 Slides adapted from Prof. Roscoe
AlternaBve: replicaBon
• Maintain flow control state in routers
– Requires replicaBon and consistency – Failure of router requires state to be recreated
State State State
? State must be recreated
59 Slides adapted from Prof. Roscoe
Fate sharing vs. replicaBon
• Two key advantages: 1. Easier to implement (no complex replicaBon protocols) 2. Resilient to any number of failures!
• Other examples:
– HTTP cookies – Packet-‐switching vs. circuit-‐switching
• Compare with End-‐to-‐End arguments
60 Slides adapted from Prof. Roscoe
References • D. Clark. 1988. The design philosophy of the DARPA internet protocols. In Symposium proceedings
on CommunicaBons architectures and protocols (SIGCOMM '88), Vinton Cerf (Ed.). ACM, New York, NY, USA, 106-‐114.
• J. H. Saltzer, D. P. Reed, and D. D. Clark. 1984. End-‐to-‐end arguments in system design. ACM Trans. Comput. Syst. 2, 4 (November 1984), 277-‐288.
• Suchitra Raman and Steven McCanne. A model, analysis, and protocol framework for soC state-‐based communica1on. SIGCOMM Comput. Commun. Rev. 29, 4 (August 1999)
• Jon Postel (ed.). DARPA Internet Program Request For Comments 793, Transmission Control Protocol Specifica1on (September 1981)
• R. R. Kompella, A. Greenberg, J. Rexford, A. C. Snoeren, and J. Yates, "Cross-‐layer Visibility as a Service," in Proc. of Workshop on Hot Topics in Networks, 2005
• Larry Peterson, Tom Anderson, David Culler, and Timothy Roscoe. A blueprint for introducing disrup1ve technology into the Internet. SIGCOMM Comput. Commun. Rev. 33, 1 (January 2003), 59-‐64.
• Anderson, T., L. Peterson S. Shenker and J. Turner. "Overcoming the Internet Impasse through Virtualiza1on," IEEE Computer Magazine, April 2005.
• David Anderson, Hari Balakrishnan, Frans Kaashoek, and Robert Morris. “Resilient Overlay Networks”, SOSP 2011
61 Slides adapted from Prof. Roscoe