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.