View
215
Download
2
Embed Size (px)
Citation preview
Midterm Review
• Homework 1 graded, solutions posted
In class, 9:30-11 am, Th. 2/2
Close Book
One 8.5” by 11” sheet of paper permitted (single side)
Lecture 1
• Internet Architecture
• Network Protocols
• Network Edge
• A taxonomy of communication networks
• The fundamental question: how is data transferred through net (including edge & core)?
• Communication networks can be classified based on how the nodes exchange information:
A Taxonomy of Communication Networks
Communication Networks
SwitchedCommunication
Network
BroadcastCommunication
Network
Circuit-Switched
Communication Network
Packet-Switched
Communication Network
Datagram Network
Virtual Circuit Network
TDM FDM
Packet Switching: Statistical Multiplexing
Sequence of A & B packets does not have fixed pattern statistical multiplexing.
In TDM each host gets same slot in revolving TDM frame.
A
B
C10 MbsEthernet
1.5 Mbs
D E
statistical multiplexing
queue of packetswaiting for output
link
Packet Switching versus Circuit Switching
• Is it true for Packet Switching or Circuit Switching?
– Network resources (e.g., bandwidth) divided into “pieces” for allocation
– Great for bursty data
– Resource piece idle if not used by owning call (no sharing)
– Have excessive congestion: packet delay and loss
– Protocols needed for reliable data transfer, congestion control
Datagram Packet Switching
• Each packet is independently switched
– Each packet header contains destination address which determines next hop
– Routes may change during session
• No resources are pre-allocated (reserved) in advance
• Example: IP networks
Virtual-Circuit Packet Switching
• Hybrid of circuit switching and packet switching
– All packets from one packet stream are sent along a pre-established path (= virtual circuit)
– Each packet carries tag (virtual circuit ID), tag determines next hop
• Guarantees in-sequence delivery of packets
• However, packets from different virtual circuits may be interleaved
• Example: ATM (Asynchronous Transfer Mode) networks
Lecture 2
• Network access and physical media
• Internet structure and ISPs
• Delay & loss in packet-switched networks
• Protocol layers, service models
Internet structure: network of networks
• “Tier-3” ISPs and local ISPs
– last hop (“access”) network (closest to end systems)
– Tier-3: Turkish Telecom, Minnesota Regional Network
Tier 1 ISP
Tier 1 ISP
Tier 1 ISP
NAP
Tier-2 ISPTier-2 ISP
Tier-2 ISP Tier-2 ISP
Tier-2 ISP
localISPlocal
ISPlocalISP
localISP
localISP Tier 3
ISP
localISP
localISP
localISP
Local and tier- 3 ISPs are customers ofhigher tier ISPsconnecting them to rest of Internet
Four sources of packet delay
• 1. processing:
– check bit errors
– determine output link
A
B
propagation
transmission
processingqueueing
• 2. queueing
– time waiting at output link for transmission
– depends on congestion level of router
Delay in packet-switched networks
3. Transmission delay:
• R=link bandwidth (bps)
• L=packet length (bits)
• time to send bits into link = L/R
4. Propagation delay:
• d = length of physical link
• s = propagation speed in medium (~2x108 m/sec)
• propagation delay = d/s
A
B
propagation
transmission
processingqueueing
Note: s and R are very different quantities!
Internet protocol stack• application: supporting network
applications
– FTP, SMTP, STTP
• transport: host-host data transfer
– TCP, UDP
• network: routing of datagrams from source to destination
– IP, routing protocols
• link: data transfer between neighboring network elements
– PPP, Ethernet
• physical: bits “on the wire”
application
transport
network
link
physical
Application Layer• Principles of app layer protocols
• Web and HTTP
• FTP
• Electronic Mail: SMTP, POP3, IMAP
• DNS
• Socket Programming
• Web Caching
HTTP connections
Nonpersistent HTTP
• At most one object is sent over a TCP connection.
• HTTP/1.0 uses nonpersistent HTTP
Persistent HTTP
• Multiple objects can be sent over single TCP connection between client and server.
• HTTP/1.1 uses persistent connections in default mode
• HTTP Message, Format, Response, Methods• HTTP cookies
Response Time of HTTP
Nonpersistent HTTP issues:
• requires 2 RTTs per object
• OS must work and allocate host resources for each TCP connection
• but browsers often open parallel TCP connections to fetch referenced objects
Persistent HTTP
• server leaves connection open after sending response
• subsequent HTTP messages between same client/server are sent over connection
Persistent without pipelining:
• client issues new request only when previous response has been received
• one RTT for each referenced object
Persistent with pipelining:
• default in HTTP/1.1
• client sends requests as soon as it encounters a referenced object
• as little as one RTT for all the referenced objects
FTP: separate control, data connections
• FTP client contacts FTP server at port 21, specifying TCP as transport protocol
• Client obtains authorization over control connection
• Client browses remote directory by sending commands over control connection.
• When server receives a command for a file transfer, the server opens a TCP data connection to client
• After transferring one file, server closes connection.
FTPclient
FTPserver
TCP control connection
port 21
TCP data connectionport 20
• Server opens a second TCP data connection to transfer another file.
• Control connection: “out of band”
• FTP server maintains “state”: current directory, earlier authentication
Electronic Mail: SMTP [RFC 2821]• uses TCP to reliably transfer email message from client to server,
port 25
• direct transfer: sending server to receiving server
• three phases of transfer
– handshaking (greeting)
– transfer of messages
– closure
• command/response interaction
– commands: ASCII text
– response: status code and phrase
• messages must be in 7-bit ASCII
DNS name servers
• no server has all name-to-IP address mappings
local name servers:
– each ISP, company has local (default) name server
– host DNS query first goes to local name server
authoritative name server:
– for a host: stores that host’s IP address, name
– can perform name/address translation for that host’s name
Why not centralize DNS?
• single point of failure
• traffic volume
• distant centralized database
• maintenance
doesn’t scale!
DNS example
Root name server:
• may not know authoritative name server
• may know intermediate name server: who to contact to find authoritative name server
• Iterated vs. recursive queries requesting host
surf.eurecom.fr
www.cs.nwu.edu
root name server
local name serverdns.eurecom.fr
1
23
4 5
6
authoritative name serverdns.cs.nwu.edu
intermediate name serverdns.nwu.edu
7
8
Web caches (proxy server)
• user sets browser: Web accesses via cache
• browser sends all HTTP requests to cache
– object in cache: cache returns object
– else cache requests object from origin server, then returns object to client
• Why web caching?
Goal: satisfy client request without involving origin server
client
Proxyserver
client
HTTP request
HTTP request
HTTP response
HTTP response
HTTP request
HTTP response
origin server
origin server
Caching example (3)Install cache
• suppose hit rate is .4
Consequence
• 40% requests will be satisfied almost immediately
• 60% requests satisfied by origin server
• utilization of access link reduced to 60%, resulting in negligible delays (say 10 msec)
• total delay = Internet delay + access delay + LAN delay
= .6*2 sec + .6*.01 secs + milliseconds < 1.3 secs
originservers
public Internet
institutionalnetwork 10 Mbps LAN
1.5 Mbps access link
institutionalcache
Transport Layer
• Transport-layer services
• Multiplexing and demultiplexing
• Connectionless transport: UDP
• Principles of reliable data transfer
• TCP
– Segment structures
– Flow control
– Congestion control
Demultiplexing• UDP socket identified
by two-tuple:
(dest IP address, dest port number)
• When host receives UDP segment:
– checks destination port number in segment
– directs UDP segment to socket with that port number
• TCP socket identified by 4-tuple:
– source IP address
– source port number
– dest IP address
– dest port number
• recv host uses all four values to direct segment to appropriate socket
UDP: User Datagram Protocol [RFC 768]
Why is there a UDP?
• no connection establishment (which can add delay)
• simple: no connection state at sender, receiver
• small segment header
• no congestion control: UDP can blast away as fast as desired
source port # dest port #
32 bits
Applicationdata
(message)
UDP segment format
length checksum
Rdt1.0: reliable transfer over a reliable channel
• underlying channel perfectly reliable
– no bit errors
– no loss of packets
• separate FSMs for sender, receiver:
– sender sends data into underlying channel
– receiver read data from underlying channelWait for call from above packet = make_pkt(data)
udt_send(packet)
rdt_send(data)
extract (packet,data)deliver_data(data)
Wait for call from
below
rdt_rcv(packet)
sender receiver
Rdt2.0: channel with bit errors• underlying channel may flip bits in packet
– recall: UDP checksum to detect bit errors
• the question: how to recover from errors:
– acknowledgements (ACKs): receiver explicitly tells sender that pkt received OK
– negative acknowledgements (NAKs): receiver explicitly tells sender that pkt had errors
– sender retransmits pkt on receipt of NAK
• new mechanisms in rdt2.0 (beyond rdt1.0):
– error detection
– receiver feedback: control msgs (ACK,NAK) rcvr->sender
rdt2.0: FSM specification
Wait for call from above
snkpkt = make_pkt(data, checksum)udt_send(sndpkt)
extract(rcvpkt,data)deliver_data(data)udt_send(ACK)
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)
rdt_rcv(rcvpkt) && isACK(rcvpkt)
udt_send(sndpkt)
rdt_rcv(rcvpkt) && isNAK(rcvpkt)
udt_send(NAK)
rdt_rcv(rcvpkt) && corrupt(rcvpkt)
Wait for ACK or
NAK
Wait for call from
belowsender
receiverrdt_send(data)
rdt2.0 has a fatal flaw!
What happens if ACK/NAK corrupted?
• sender doesn’t know what happened at receiver!
• can’t just retransmit: possible duplicate
What to do?
• sender ACKs/NAKs receiver’s ACK/NAK? What if sender ACK/NAK lost?
• retransmit, but this might cause retransmission of correctly received pkt!
Handling duplicates:
• sender adds sequence number to each pkt
• sender retransmits current pkt if ACK/NAK garbled
• receiver discards (doesn’t deliver up) duplicate pkt
Sender sends one packet, then waits for receiver response
stop and wait
rdt2.1: sender, handles garbled ACK/NAKs
Wait for call 0 from
above
sndpkt = make_pkt(0, data, checksum)udt_send(sndpkt)
rdt_send(data)
Wait for ACK or NAK 0 udt_send(sndpkt)
rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) ||isNAK(rcvpkt) )
sndpkt = make_pkt(1, data, checksum)udt_send(sndpkt)
rdt_send(data)
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt)
udt_send(sndpkt)
rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) ||isNAK(rcvpkt) )
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt)
Wait for call 1 from
above
Wait for ACK or NAK 1
rdt2.2: a NAK-free protocol
• same functionality as rdt2.1, using NAKs only
• instead of NAK, receiver sends ACK for last pkt received OK
– receiver must explicitly include seq # of pkt being ACKed
• duplicate ACK at sender results in same action as NAK: retransmit current pkt
rdt3.0: channels with errors and loss
New assumption: underlying channel can also lose packets (data or ACKs)
– checksum, seq. #, ACKs, retransmissions will be of help, but not enough
Q: how to deal with loss?
– sender waits until it is certain that data or ACK lost, then retransmits
– yuck: drawbacks?
Approach: sender waits “reasonable” amount of time for ACK
• retransmits if no ACK received in this time
• if pkt (or ACK) just delayed (not lost):
– retransmission will be duplicate, but use of seq. #’s already handles this
– receiver must specify seq # of pkt being ACKed
• requires countdown timer
rdt3.0 sender
sndpkt = make_pkt(0, data, checksum)udt_send(sndpkt)start_timer
rdt_send(data)
Wait for
ACK0
rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) ||isACK(rcvpkt,1) )
Wait for call 1 from
above
sndpkt = make_pkt(1, data, checksum)udt_send(sndpkt)start_timer
rdt_send(data)
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,0)
rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) ||isACK(rcvpkt,0) )
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,1)
stop_timerstop_timer
udt_send(sndpkt)start_timer
timeout
udt_send(sndpkt)start_timer
timeout
rdt_rcv(rcvpkt)
Wait for call 0from
above
Wait for
ACK1
rdt_rcv(rcvpkt)
Go-Back-NSender:
• k-bit seq # in pkt header
• “window” of up to N, consecutive unack’ed pkts allowed
• ACK(n): ACKs all pkts up to, including seq # n - “cumulative ACK”
– may deceive duplicate ACKs (see receiver)
• Single timer for all in-flight pkts
• timeout(n): retransmit pkt n and all higher seq # pkts in window
Selective Repeat
• receiver individually acknowledges all correctly received pkts
– buffers pkts, as needed, for eventual in-order delivery to upper layer
• sender only resends pkts for which ACK not received
– sender timer for each unACKed pkt
• sender window
– N consecutive seq #’s
– again limits seq #s of sent, unACKed pkts
Selective repeat: sender, receiver windows
TCP segment structure
source port # dest port #
32 bits
applicationdata
(variable length)
sequence number
acknowledgement numberReceive window
Urg data pnterchecksum
FSRPAUheadlen
notused
Options (variable length)
URG: urgent data (generally not used)
ACK: ACK #valid
PSH: push data now(generally not used)
RST, SYN, FIN:connection estab(setup, teardown
commands)
# bytes rcvr willingto accept
countingby bytes of data(not segments!)
Internetchecksum
(as in UDP)
TCP Round Trip Time and Timeout
EstimatedRTT = (1- )*EstimatedRTT + *SampleRTT
• Exponential weighted moving average
• influence of past sample decreases exponentially fast
• typical value: = 0.125
TCP Flow control: how it works
(Suppose TCP receiver discards out-of-order segments)
• spare room in buffer
= RcvWindow
= RcvBuffer-[LastByteRcvd - LastByteRead]
• Rcvr advertises spare room by including value of RcvWindow in segments
• Sender limits unACKed data to RcvWindow
– guarantees receive buffer doesn’t overflow
TCP Congestion Control
• end-end control (no network assistance)
• sender limits transmission:
LastByteSent-LastByteAcked
CongWin
• Roughly,
• CongWin is dynamic, function of perceived network congestion
How does sender perceive congestion?
• loss event = timeout or 3 duplicate acks
• TCP sender reduces rate (CongWin) after loss event
three mechanisms:
– AIMD
– slow start
– conservative after timeout events
rate = CongWin
RTT Bytes/sec
Summary: TCP Congestion Control
• When CongWin is below Threshold, sender in slow-start phase, window grows exponentially.
• When CongWin is above Threshold, sender is in congestion-avoidance phase, window grows linearly.
• When a triple duplicate ACK occurs, Threshold set to CongWin/2 and CongWin set to Threshold.
• When timeout occurs, Threshold set to CongWin/2 and CongWin is set to 1 MSS.
Refinement• After 3 dup ACKs:
– CongWin is cut in half
– window then grows linearly
• But after timeout event:
– Enter “slow start”
– CongWin instead set to 1 MSS;
– window then grows exponentially
– to a threshold, then grows linearly
• 3 dup ACKs indicates network capable of delivering some segments• timeout before 3 dup ACKs is “more alarming”
Philosophy:
Why is TCP fair?Two competing sessions:
• Additive increase gives slope of 1, as throughout increases
• multiplicative decrease decreases throughput proportionally
R
R
equal bandwidth share
Connection 1 throughputConnect
ion 2
th
roughput
congestion avoidance: additive increaseloss: decrease window by factor of 2
congestion avoidance: additive increaseloss: decrease window by factor of 2
Delay modeling
Q: How long does it take to receive an object from a Web server after sending a request?
Ignoring congestion, delay is influenced by:
• TCP connection establishment
• data transmission delay
• slow start
Notation, assumptions:
• Assume one link between client and server of rate R
• S: MSS (bits)
• O: object size (bits)
• no retransmissions (no loss, no corruption)
Window size:
• First assume: fixed congestion window, W segments
Fixed congestion window (1)
First case:
WS/R > RTT + S/R: ACK for first segment in window returns before window’s worth of data sent
delay = 2RTT + O/R
Fixed congestion window (2)
Second case:
• WS/R < RTT + S/R: wait for ACK after sending window’s worth of data sent
delay = 2RTT + O/R+ (K-1)[S/R + RTT - WS/R]
HTTP Modeling• Assume Web page consists of:
– 1 base HTML page (of size O bits)
– M images (each of size O bits)
• Non-persistent HTTP: – M+1 TCP connections in series
– Response time = (M+1)O/R + (M+1)2RTT + sum of idle times
• Persistent HTTP:
– 2 RTT to request and receive base HTML file
– 1 RTT to request and receive M images
– Response time = (M+1)O/R + 3RTT + sum of idle times
• Non-persistent HTTP with X parallel connections
– Suppose M/X integer.
– 1 TCP connection for base file
– M/X sets of parallel connections for images.
– Response time = (M+1)O/R + (M/X + 1)2RTT + sum of idle times
02468
101214161820
28Kbps
100Kbps
1Mbps
10Mbps
non-persistent
persistent
parallel non-persistent
HTTP Response time (in seconds)RTT = 100 msec, O = 5 Kbytes, M=10 and X=5
For low bandwidth, connection & response time dominated by transmission time.
Persistent connections only give minor improvement over parallel connections for small RTT.
0
10
20
30
40
50
60
70
28Kbps
100Kbps
1Mbps
10Mbps
non-persistent
persistent
parallel non-persistent
HTTP Response time (in seconds)
RTT =1 sec, O = 5 Kbytes, M=10 and X=5
For larger RTT, response time dominated by TCP establishment & slow start delays. Persistent connections now give important improvement: particularly in high delaybandwidth networks.