Midterm Review

In class, 9:30-11 am, Tu. 2/8

Closed 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

• Circuit Switching

– Network resources (e.g., bandwidth) divided into “pieces” for allocation

– Resource piece idle if not used by owning call (no sharing)

– NOT efficient !

• Packet Switching:

– Great for bursty data

– Excessive congestion: packet delay and loss

– protocols needed for reliable data transfer, congestion control

Packet Switching versus Circuit Switching

• 1 Mbit link

• Each user:

– 100 kbps when “active”

– active 10% of time

• Circuit-switching:

– 10 users

• Packet switching:

– with 35 users, probability > 10 active less than .0004

Packet switching allows more users to use network!

N users

1 Mbps link

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

• Q. What is the difference btw. circuit switching and virtual-circuit packet switching?

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, HTTP

• 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

– Application architectures and requirements

• Web and HTTP

• FTP

• Electronic Mail: SMTP, POP3, IMAP

• DNS

• Socket Programming

Application architectures

• Client-server

• Peer-to-peer (P2P)

• Hybrid of client-server and P2P

Client-server archictureserver:

– always-on host

– permanent IP address

– server farms for scaling

clients:

– communicate with server

– may be intermittently connected

– may have dynamic IP addresses

– do not communicate directly with each other

Pure P2P architecture

• no always on server

• arbitrary end systems directly communicate

• peers are intermittently connected and change IP addresses

• example: Gnutella

Highly scalable

But difficult to manage

Hybrid of client-server and P2P

Napster

– File transfer P2P

– File search centralized:

• Peers register content at central server

• Peers query same central server to locate content

Instant messaging

– Chatting between two users is P2P

– Presence detection/location centralized:

• User registers its IP address with central server when it comes online

Internet transport protocols services

TCP service:

• connection-oriented: setup required between client and server processes

• reliable transport between sending and receiving process

• flow control: sender won’t overwhelm receiver

• congestion control: throttle sender when network overloaded

• does not provide: timing, minimum bandwidth guarantees

UDP service:

• unreliable data transfer between sending and receiving process

• does not provide: connection setup, reliability, flow control, congestion control, timing, or bandwidth guarantee

Q: why bother? Why is there a UDP?

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

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

– Consistency problem

• 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

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: mail serversMail Servers • mailbox contains incoming

messages for user

• message queue of outgoing (to be sent) mail messages

• SMTP protocol between mail servers to send email messages

– client: sending mail server

– “server”: receiving mail server

• Example – If the sending mail server

cannot deliver the message, it is queued

mailserver

useragent

useragent

useragent

mailserver

useragent

useragent

mailserver

useragent

SMTP

SMTP

SMTP

DNS Why not centralize DNS?

• single point of failure

• traffic volume

• distant centralized database

• maintenance

doesn’t scale!

DNS services

• Hostname to IP address translation

– E.g., www.northwestern.edu

• Host aliasing

– Canonical and alias names

– E.g., dell.com www.dell.com

• Mail server aliasing

– E.g., bob@hotmail.com

• Load distribution

– Replicated Web servers: set of IP addresses for one canonical name

– E.g., cnn.com

DNS example

Root name server:

• may not know authoritative name server

• may know intermediate name server: who to contact to find authoritative name server

requesting hostsurf.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

DNS: iterated queries

recursive query:

• puts burden of name resolution on contacted name server

• heavy load?

iterated query:

• contacted server replies with name of server to contact

• “I don’t know this name, but ask this server”

requesting hostsurf.eurecom.fr

gaia.cs.umass.edu

root name server

local name serverdns.eurecom.fr

1

23

4

5 6

authoritative name serverdns.cs.umass.edu

intermediate name serverdns.umass.edu

7

8

iterated query

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

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

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.2: a NAK-free protocol

• same functionality as rdt2.1, using ACKs 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

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

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: 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

Fast Retransmit

• Time-out period often relatively long:

– long delay before resending lost packet

• Detect lost segments via duplicate ACKs.

– Sender often sends many segments back-to-back

– If segment is lost, there will likely be many duplicate ACKs.

• If sender receives 3 ACKs for the same data, it supposes that segment after ACKed data was lost:

– fast retransmit: resend segment before timer expires

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:

– Slow start

– AIMD

– Exponential backoff

rate = CongWin

RTT Bytes/sec

TCP Phases

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:

• In exponential backoff:

– RTO doubled after each successive timeout

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 - homework

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

• Then dynamic window, modeling slow start

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]

Where K=O/WS

TCP Delay Modeling: Slow Start (1)

Now suppose window grows according to slow start

Will show that the delay for one object is: R

S

R

SRTTP

R

ORTTLatency P )12(2

where P is the number of times TCP idles at server:

}1,{min KQP

- where Q is the number of times the server idles if the object were of infinite size.

- and K is the number of windows that cover the object.

TCP Delay Modeling: Slow Start (2)

RTT

initia te TCPconnection

requestobject

first w indow= S /R

second w indow= 2S /R

third w indow= 4S /R

fourth w indow= 8S /R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

Example:• O/S = 15 segments• K = 4 windows• Q = 2• P = min{K-1,Q} = 2

Server idles P=2 times

Delay components:• 2 RTT for connection estab and request• O/R to transmit object• time server idles due to slow start

Server idles: P = min{K-1,Q} times

TCP Delay Modeling (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

idleTimeRTTR

O

P

kP

k

P

pp

)12(][2

]2[2

2delay

1

1

1

th window after the timeidle 2 1 kR

SRTT

R

S k

ementacknowledg receivesserver until

segment send tostartsserver whenfrom time RTTR

S

window kth the transmit totime2 1

R

Sk

RTT

initia te TCPconnection

requestobject

first w indow= S /R

second w indow= 2S /R

third w indow= 4S /R

fourth w indow= 8S /R

com pletetransm issionobject

delivered

tim e atc lient

tim e atserver

TCP Delay Modeling (4)

)1(log

)}1(log:{min

}12:{min

}/222:{min

}222:{min

2

2

110

110

S

OS

Okk

S

Ok

SOk

OSSSkK

k

k

k

Calculation of Q, number of idles for infinite-size object,is similar (see HW).

Recall K = number of windows that cover object

How do we calculate K ?