Q1-1

Review for Quiz-1

ECE3600 - Fall 2015

Prof. John Copeland

These slides include material from Computer Networking: A Top Down Approach Featuring the Internet, 5th edition. Jim Kurose, Keith RossAddison-Wesley.

Base material copyright 1996-2006J.F Kurose and K.W. Ross, All Rights Reserved

Q1-2

What’s the Internet: “nuts and bolts” view

• protocols control sending, receiving of msgs– e.g., TCP, IP, HTTP, FTP, PPP

• Internet: “network of networks”– loosely hierarchical– public Internet versus private

intranet• Internet standards and

assignments– RFC: Request for comments– IETF: Internet Engineering

Task Force– IANA: assigns IP (32-bit)

addresses– Registrars: assign domain

names.

local ISP

companynetwork

regional ISP

router workstation

servermobile

Chapter 1 - Introduction

Q1-3

Network edge: connectionless service

Goal: data transfer between end systems– same as before!

• UDP - User Datagram Protocol [RFC 768]: – connectionless – unreliable data

transfer– no flow control– no congestion

control

App’s using TCP: • HTTP (Web), FTP (file

transfer), Telnet (remote login), SMTP (email)

App’s using UDP:• streaming media,

teleconferencing, DNS, Internet telephony

Q1-4

Network Core: Circuit SwitchingEnd-end resources

reserved for “call”• link bandwidth, switch

capacity• dedicated resources: no

sharing• circuit-like (guaranteed)

performance• call setup required

Used by telephone system. Expensive because unused channel capacity was wasted.

Q1-5

Packet Switching: Statistical Multiplexing

Sequence of A & B packets does not have fixed pattern, shared on demand statistical multiplexing.

Contrast with TDM each host gets same slot in a repeating TDM frame.

A

B

C100 Mb/sEthernet

1.5 Mb/s

D E

statistical multiplexing

queue of packetswaiting for output

link

Q1-6

Company access: local area networks

• company/university local area network (LAN) connects end system to edge router

• Ethernet: – shared or dedicated

link connects end system and router

– 10 Mbs, 100Mbps, Gigabit Ethernet

• LANs: chapter 5

Q1-7

Wireless access networks• shared wireless access network

connects end system to router– via base station aka “access

point”• wireless LANs:

– 802.11b/g (WiFi): 11 or 54 Mbps

• wider-area wireless access– provided by telco operator– 3G ~ 384 kbps

• Will it happen??– GPRS in Europe/US

basestation

mobilehosts

router

Q1-8

Physical Media• Bit: propagates between

transmitter/rcvr pairs• physical link: what lies

between transmitter & receiver

• guided media: – signals propagate in

solid media: copper, fiber, coax

• unguided media: – signals propagate freely,

e.g., radio

Twisted Pair (TP)• two insulated copper

wires– Category 5:

100Mbps Ethernet

Coaxial cable:• two concentric copper

conductors

Fiber optic cable:• glass fiber carrying light

pulses, each pulse a bit• 10’s-100’s Gbps

Q1-9

Internet structure: network of networks

• “Tier-3” ISPs and local ISPs – last hop (“access”) network (closest to end systems)

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

IndividualUsers

Large Organization(Autonomous

System)

Smaller Organization(Autonomous

System)

Q1-10

How do loss and delay occur?packets queue in router buffers

• packet arrival rate to link exceeds output link capacity• packets queue, wait for turn• Delay = (bits ahead in buffer)/(bit-rate)

A

B

packet being transmitted (delay)

packets queueing (delay)

free (available) buffers: arriving packets dropped (loss) if no free buffers

Q1-11

Four sources of packet delay

• 1. nodal processing: – check bit errors– determine output link

A

B

propagation

transmission

nodalprocessing queueing

• 2. queueing– time waiting at output

link for transmission – depends on

congestion level of router

Q1-12

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

nodalprocessing queueing

Note: s and R are very different quantities!

Q1-13

Nodal delay

• dproc = processing delay– typically a few microsecs or less

• dqueue = queuing delay (bits-in-queue/rate)– depends on congestion

• dtrans = transmission delay (bits-in-packet/rate)– = L/R, significant for low-speed links (dialup modems)

• dprop = propagation delay– a few microsecs to hundreds of msecs (15 ms to Los Angeles)

Q1-14

Internet protocol stack• application: supporting network

applications– FTP, SMTP, HTTP

• transport: process-process 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

LLCMAC

Eth

ern

et

TC

P/IP

(voltage, photons, bits/s, media, …)

Q1-15

sourceapplicatio

ntransportnetwork

linkphysical

HtHn M

segment Ht

datagram

destination

application

transportnetwork

linkphysical

HtHnHl M

HtHn M

Ht M

M

networklink

physical

linkphysical

HtHnHl M

HtHn M

HtHn M

HtHnHl M

router

switch

Encapsulationmessage M

Ht M

Hn

frame

Ethernet LAN

PPP

SONET Fiber

Q1-16

Chapter 2

Applications,

Application Layer,

Application Layer Headers

Q1-17

Creating a network appWrite programs that

– run on different end systems and– communicate over a network.– e.g., Web: Web server software

communicates with browser softwarelittle software written for devices in

network core– network core devices do not run user

application code– application on end systems allows

for rapid app development, propagation

application

transportnetworkdata linkphysical

application

transportnetworkdata linkphysical

application

transportnetworkdata linkphysical

Q1-18

Client-server architectureserver:

– always-on host– permanent IP address– server farms for

scalingclients:

– communicate with server

– may be intermittently connected

– may have dynamic IP addresses

– do not communicate directly with each other

Q1-19

Processes communicating

Process: program running within a host.

• within same host, two processes communicate using inter-process communication (defined by OS).

• processes in different hosts communicate by exchanging messages

Client process: process that initiates communication

Server process: process that waits to be contacted

• Note: applications with P2P architectures have both client processes and server processes

Q1-20

Addressing processes• to receive messages,

process must have identifier

• host device has unique32-bit IP address

• Q: does IP address of host on which process runs suffice for identifying the process?– Answer: NO, many

processes can be running on same host

• identifier includes both IP address and port numbers associated with process on host.

• Example port numbers:– HTTP server: 80– Mail server: 25

• to send HTTP message to gaia.cs.umass.edu web server:– IP address:

128.119.245.12– Port number: 80

Q1-21

HTTP overviewHTTP: hypertext transfer

protocol• Web’s application layer

protocol• client/server model

– client: browser that requests, receives, “displays” Web objects

– server: Web server sends objects in response to requests

• HTTP 1.0: RFC 1945• HTTP 1.1: RFC 2068

PC runningExplorer

Server running

Apache Webserver

Mac runningNavigator

HTTP request

HTTP request

HTTP response

HTTP response

Application Layer

Q1-22

Persistent HTTP

Nonpersistent HTTP issues:• requires 2 RTTs per object• OS overhead for each TCP

connection• 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 sent over open 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 [plus the sum of transfer times]

Q1-23

FTP: the file transfer protocol

• transfer file to/from remote host• client/server model

– client: side that initiates transfer (either to/from remote)– server: remote host

• ftp: RFC 959• ftp server: port 21

file transfer FTPserver

FTPuser

interface

FTPclient

local filesystem

remote filesystem

user at host

Q1-24

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 file transfer command, server opens 2nd TCP connection (for file) to client

• After transferring one file, server closes data connection.

FTPclient

FTPserver

TCP control connectionport 21

TCP data connection2 Modes

Active : Server port 20 -> Client listening high

portPassive : Client ->

Server, high-high ports• Server opens another TCP data connection to transfer another file.

• Control connection: “out of band”

• FTP server maintains “state”: current directory, earlier authentication

Q1-25

Electronic Mail: mail servers

Mail 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

mailserver

useragent

useragent

useragent

mailserver

useragent

useragent

mailserver

useragent

SMTP

SMTP

SMTP

Recently, Enhanced SMTP (ESMTP)is used to provide authentication,and encryption for privacy.

Q1-26

Mail message formatSMTP: protocol for

exchanging email msgsRFC 822: standard for text

message format:• header lines, e.g.,

– To:– From:– Subject:different from SMTP

commands!

• body– the “message”, ASCII

characters only

header

body

blankline

Q1-27

Mail access protocols

• SMTP: delivery/storage to receiver’s server

• Mail access protocol: retrieval from server– POP: Post Office Protocol [RFC 1939]

• authorization (agent <-->server) and download – IMAP: Internet Mail Access Protocol [RFC 1730]

• more features (more complex)• manipulation of stored msgs on server

– HTTP: Hotmail , Yahoo! Mail, etc.

Transport Layer Security (TLS), like SSL for HTTP > HTTPS]

useragent

sender’s mail server

useragent

SMTP SMTP accessprotocol

receiver’s mail server

Q1-28

POP3 and IMAPMore about POP3• Previous example uses

“download and delete” mode.

• Bob cannot re-read e-mail if he changes client

• “Download-and-keep”: copies of messages on different clients

• POP3 is stateless across sessions

IMAP• Keep all messages in

one place: the server• Allows user to organize

messages in folders• IMAP keeps user state

across sessions:– names of folders and

mappings between message IDs and folder name

Q1-29

DNS: Domain Name System

People: many identifiers:– SSN, name, passport #

Internet hosts, routers:– IP address (32 bit) - used

for addressing datagrams

– “name”, e.g., www.yahoo.com - used by humans

Q: map between IP addresses and name ?

Domain Name System:• distributed database

implemented in hierarchy of many name servers

• application-layer protocol host, routers, name servers to communicate to resolve names (address/name translation)– note: core Internet

function, implemented as application-layer protocol

– complexity at network’s “edge”

Q1-30

Root DNS Servers

.com DNS servers .org DNS servers .edu DNS servers

poly.eduDNS servers

umass.eduDNS servers

yahoo.comDNS servers

amazon.comDNS servers

pbs.orgDNS servers

Distributed, Hierarchical Database

Client wants IP for www.amazon.com; 1st approx:• Client* queries a root server to find com DNS server• Client* queries com DNS server to get amazon.com DNS

server• Client* queries amazon.com DNS server to get IP

address for www.amazon.com– * This is usually your local DNS server, that does this "recursive"

search for you.

Q1-31

TLD and Authoritative Servers

• Top-level domain (TLD) servers: responsible for com, org, net, edu, etc, and all top-level country domains uk, fr, ca, jp.– Network solutions maintains servers for com TLD– Educause for edu TLD– [2007 - TLD servers share responsibilities]

• Authoritative DNS servers: organization’s DNS servers, providing authoritative hostname to IP mappings for organization’s servers (e.g., Web and mail).– Can be maintained by organization or service provider

• Local DNS servers: organization’s DNS servers located on various subnets to provide DNS lookups for hosts on the subnet. May not be accessible from outside the subnet. Their IP addresses are part of the host's network configuration (manual setup or DHCP*).

* DHCP - dynamic host configuration protocol (automatic network configuration)

Q1-32

requesting hostcis.poly.edu

gaia.cs.umass.edu

root DNS server

local DNS serverdns.poly.edu

1

23

4

5

6

authoritative DNS serverdns.cs.umass.edu

78

TLD DNS server

Example• Host at cis.poly.edu wants

IP address for gaia.cs.umass.edu

• Host sends a "recursion-requested" query request to dns.poly.edu.

• [Host is doing a non-recursive search]

• Local DNS server does a "recursive" search. This requires contacting several other DNS servers before the final answer is given to host.

Q1-33

DNS records

DNS: distributed db storing resource records (RR)

• Type=NS– name is domain (e.g.

gatech.com) {assigned by

a “registrar”}– value is hostname of

authoritative name server for this domain

RR format: (name, value, type, ttl)

• Type=A– name is hostname– value is IP address

• Type=CNAME– name is alias name for some

“canonical” (the real) name

www.ibm.com is really

servereast.backup2.ibm.com– value is canonical name

• Type=MX– value is name of mailserver

associated with name

Q1-34

P2P file sharingExample• Alice runs P2P client

application on her notebook computer

• Intermittently connects to Internet; gets new IP address for each connection

• Asks for “Hey Jude”• Application displays

other peers that have copy of Hey Jude.

• Alice chooses one of the peers, Bob.

• File is copied from Bob’s PC to Alice’s notebook: HTTP

• While Alice downloads, other users uploading from Alice.

• Alice’s peer is both a Web client and a transient Web server.

All peers are servers = highly scalable!

Highly insecure!

Q1-35

Internet transport protocols (2 of many)TCP services:• 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?

Transport Layer

Q1-36

Socket-programming using TCP

Socket: a door between application process and end-end-transport protocol (UCP or TCP)

TCP service: reliable transfer of bytes from one process to another

process

TCP withbuffers,

variables

socket

controlled byapplicationdeveloper

controlled byoperating

system

host orserver

process

TCP withbuffers,

variables

socket

controlled byapplicationdeveloper

controlled byoperatingsystem

host orserver

internet

Q1-37

Socket programming with TCPClient must contact server

• server process must first be running

• server must have created socket that welcomes client’s contact (Listening Socket)

Client contacts server by:

• creating client-local TCP socket

• specifying IP address, port number of server process

• When client creates socket: client TCP establishes connection to server TCP

• When contacted by client, server TCP creates new socket for server process to communicate with client– allows server to talk with

multiple clients– source port numbers used

to distinguish clients (more in Chap 3)

TCP provides reliable, in-order transfer of bytes (“pipe”) between client and server

application viewpoint

Q1-38

Chapter 3 - Transport Layer

TCP and UDP, Ports and Sockets

Covered on Quiz 2 (Fall 2014)

TCP Flow and Congestion Control

TCP Flags, Sequence and Ack. No.s

IP Subnets, Routers, Address Blocks

IP Subnets

Q1-39

Transport services and protocols• provide logical communication

between app processes running on different hosts

• transport protocols run in end systems – send side: breaks app

messages into segments, passes to network layer

– rcv side: reassembles segments into messages, passes to app layer

• more than one transport protocol available to apps– Internet: TCP and UDP

application

transportnetworkdata linkphysical

application

transportnetworkdata linkphysical

networkdata linkphysical

networkdata linkphysical

networkdata linkphysical

networkdata linkphysicalnetwork

data linkphysical

logical end-end transport

Q1-40

Internet transport-layer protocols• reliable, in-order

delivery (TCP)– congestion control – flow control– connection setup

• unreliable, unordered delivery: UDP– no-frills extension of

“best-effort” IP

• services not available: – delay guarantees– bandwidth guarantees

application

transportnetworkdata linkphysical

application

transportnetworkdata linkphysical

networkdata linkphysical

networkdata linkphysical

networkdata linkphysical

networkdata linkphysicalnetwork

data linkphysical

logical end-end transport

Q1-41

TCP Multiplexing / Demultiplexing

application

transport

network

link

physical

P1 application

transport

network

link

physical

application

transport

network

link

physical

P2P3 P4P1

host 1 host 2 host 3

= process= socket

delivering received segments tocorrect socket (Listening Portnot shown)

Demultiplexing at rcv host:gathering data from multiplesockets, enveloping data with header (later used for demultiplexing)

Multiplexing at send host:

Q1-42

Connection-oriented demux

• 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

• Server host may support many simultaneous TCP sockets:– each socket identified by

its own 4-tuple

• Web servers have different sockets for each connecting client– non-persistent HTTP will

have different socket for each request

Q1-43

UDP - Connectionless demux

DatagramSocket serverSocket = new DatagramSocket(6428);

ClientIP:B

P2

client IP: A

P1P1P3

serverIP: C

SP: 6428

DP: 9157

SP: 9157

DP: 6428

SP: 6428

DP: 5775

SP: 5775

DP: 6428

Source Port, SP, (and Source IP) provides “return address”Only one socket per local UDP Port Number.

Q1-44

UDP: User Datagram Protocol [RFC 768]

• “no frills,” “bare bones” Internet transport protocol

• “best effort” service, UDP segments may be:– lost– delivered out of order to

app• connectionless:

– no handshaking between UDP sender, receiver

– each UDP segment handled independently of others

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

• Single thread and socket for each local server port number.

Q1-45

UDP: more

• often used for streaming multimedia apps– loss tolerant– rate sensitive

• other UDP uses– DNS– SNMP

• reliable transfer over UDP: add reliability at application layer– application-specific error

recovery!

source port # dest port #

32 bits

Applicationdata

(message)

UDP segment format

length checksumLength, in

bytes of UDPsegment,including

header

Q1-46

UDP checksum

Sender:• treat segment contents as

sequence of 16-bit integers• checksum: addition (1’s

complement sum) of header and some parts of the IP header)

• sender puts bit-wise complement (-checksum) value into UDP checksum field

Receiver:• compute checksum of

received segment, included checksum field.

• check if computed checksum equals zero :– NO - error detected– YES - no error detected.

But maybe errors nonetheless? More later ….

Goal: detect “errors” (e.g., flipped bits) in transmitted segment

Q1-47

Internet Checksum Example• Note

– When adding numbers, a carry out from the most significant bit needs to be shifted (>>16) and added to the result

• Example: add two 16-bit integers (1's compliment)1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 01 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1

1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1

11 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0

0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1

wraparoundsum bit-invert checksum

BINARY ADD

Q1-48Transport Layer

ProblemPacket may arrive with errors.

Packet may not arrive.

Sender may wait forever for ACK.

ACK may not arrive, dup. sent.

Packets may arrive out-of-order.

Inefficient to send one pkt per RT

Missing packet early in window.

“Go-Back-N” inefficient.

---- Also in TCP ---

Packets may be different sizes.

Slow down when network

congested (as detected by RTO or

triple duplicate ACKs.

Know when receiver buffer will be

full.

SolutionAdd checksum, CRC, or hash.

Receiver sends “ACK” back. If

ACK not received, packet re-sent.

Timeout timer added to sender.

Add sequence no.s to detect dups.

Buffer packets to rearrange order.

Have a “window” to send before ACK

(pipelining).

“Go-Back-N” to last in-order packet.

“Selective Repeat” to fill in gaps only.

----

Sequence number for each byte.

“Slow-Start”, or "Multiplicative

Decrease" to reduce transmit window.

Receiver includes “space left” in every

ACK.

Reliable Data Transport

Q1-49

TCP: Overview RFCs: 793, 1122, 1323, 2018, 2581

• full duplex data:– bi-directional data flow in

same connection– MSS: maximum segment

size• connection-oriented:

– handshaking (exchange of control msgs) init’s sender, receiver state before data exchange

• flow controlled:– sender will not overwhelm

receiver

• point-to-point:– one sender, one receiver

• reliable, in-order byte steam:– no “message boundaries”

• pipelined:– TCP congestion and flow

control set window size• send & receive buffers

Q1-50

TCP segment structure

source port # dest port #

32 bits

applicationdata

(variable length)

sequence number

acknowledgement numberReceive window

Urg data pointerchecksum

FSRPAUheadlen

notused

Options (variable length, MSS)

URG: urgent data (generally not used)

ACK: ACK #valid

PSH: push data now(end of block)

RST, SYN, FIN:connection estab(setup, teardown

commands)

# bytes rcvr willingto accept

countingby bytes of data(not segments!)

Internetchecksum

(as in UDP)

Q1-51

TCP seq. #’s and ACKsSeq. #’s:

– byte stream “number” of first byte in segment’s data

ACKs:– seq # of next byte

expected from other side

– cumulative ACKQ: how receiver handles

out-of-order segments– A: TCP spec doesn’t

say, - up to implementor

Host A Host B

Seq=42, ACK=79, data = ‘C’

Seq=79, ACK=43, data = ‘C’

Seq=43, ACK=80

Usertypes

‘C ’

host ACKsreceipt

of echoed‘C ’

host ACKsreceipt of‘C ’, echoes

back ‘C ’

timesimple telnet scenario

Q1-52

Maximum Segment Size (MSS), in bytes

The initial segments (the SYN and SYN-ACK) contain the MSS in an option field. It stays constant after this.

This tells the other host the maximum size of a segment that can be handled by their local network (without fragmentation).

Examples, one host may say it's MSS value is 1400, the other may say it's MSS value is 1420.

Since segments have to transverse both local networks, the smaller MSS value is used for the connection.

TCP rules involving Window sizes are in units of MSS (bytes), not number of segments.

For simplification, examples may say "the host is sending maximum size segments," so that 1 MSS = 1 segment. Sometimes this is implied without being stated in problems.

MSS includes the TCP header bytes (40 to 64) and data bytes, but not the IP header bytes (20). Since Ethernet and WiFi limit datagram size to 1500 bytes, MSS is never larger than 1480 bytes when either host is on a LAN.

Q1-53

TCP Round Trip Time and TimeoutEstimatedRTT[new] = (1-)* EstimatedRTT[old]

+ * SampleRTT[new]

• Exponential weighted moving average• influence of past sample decreases exponentially fast• typical value: = 0.125

Setting the timeoutEstimtedRTT plus “safety margin”

large variation in EstimatedRTT -> larger safety marginfirst estimate how much SampleRTT deviates from EstimatedRTT:

DevRTT[new] = (1-) * DevRTT[old] + * |SampleRTT[new] - EstimatedRTT[old]|

(typically, = 0.25, note absolute value bars, ||)

TimeoutInterval: RTO = EstimatedRTT + 4 * DevRTT

Also note: Old value of EstimatedRTT is used.

Q1-54

A = 0.875 * 60 + 0.125 * 90 = 63.75 -> 64 D = 0.75 * 10 + 0.25 * | 30 | = 15

A = 0.875 * 64 + 0.125 * 30 = 59.75 -> 60 D = 0.75 * 15 + 0.25 * | -34 | = 19.75 -> 20

Running Average for Calculating the Retransmit Time Out, RTO

Round results up to 1 ms. Alpha = 1/8 (0.125) and Beta = 1/4 (0.250)

124

SampleRTT EstimatedRTT DevRTT TimeOutSampleRTT[new]

- EstimatedRTT[old]

-34

Q1-55

sender won’t overflowreceiver’s buffer by

transmitting too much,

too fast

flow control

TCP Flow control

Receiver-Window =• spare room in buffer

= LastByteInBuffer -

LastByteACKed

• Receiver advertises spare room by including value of RcvWindow in every segment (TCP header "Window" field)

• Sender limits data to RcvWindow– guarantees receive

buffer doesn’t overflow

LastByteInBuffer

LastByteACKed

<- Byte No.s

Q1-56

Causes / costs of congestionEach host sends in data (average bits per second).Buffer output is out (maximum rate is C)

• two senders, two receivers

• one router, infinite buffers

• no retransmission

• large delays when congested

• maximum achievable throughput

unlimited shared output link buffers

Host Ain : original data

Host B

out

Q1-57

TCP Congestion Control

• sender limits transmission: LastByteSent-LastByteAcked CongWin• Roughly*,

• CongWin is dynamic, function of perceived network congestion.

• The sender uses the smaller value of CongWin and or Window (receiver's Window)

How does sender perceive congestion?

• loss event = timeout or 3 duplicate ACKs

• TCP sender reduces rate (CongWin) after loss event

three mechanisms:– AIMD (additive increase,

multiplicative decrease)– slow start initially

(exponential growth until threshold reached)

– conservative after timeout events (slow-start up to CongWin)

rate = CongWin

RTT Bytes/sec

* This is true when this window-limited rate is less that the media bandwidth in bytes per second.

Q1-58

TCP Slow Start

• When connection begins*, increase rate exponentially until first loss event:

– double CongWin every RTT

– done by adding a byte to CongWin for every new byte ACK'ed.

• Summary: initial rate is slow but data rate ramps up exponentially fast (until the Receiver Window is reached)

Host A

one (MSS) segment

RTT

Host B

time

two segments

four segments

*Also done after a Time Out, but changes to Additive Increase when theThreshold is reached.

SYN and SYN-ACK: TCP headers contain MSS values (in option field) and initial Segment Numbers.

Q1-59

TCP congestion control: sender congestion window: "CongWin"

• Approach: increase transmission rate (window size), probing for usable bandwidth, until loss occurs– multiplicative decrease: cut CongWin in half after loss

indicated by 3 duplicate ACKs (to MSS after Time Out*). – additive increase: increase CongWin by 1 MSS every

RTT until loss detected by 3 duplicate ACKs (or Time Out*)

timecong

estio

n w

indo

w s

ize

Saw toothbehavior: probing

for bandwidth

*After a Time Out, CongWin increases by doubling every RTT until 1/2 old CongWin reached

Q1-60

Refinement

Q: When should the exponential increase switch to linear (after RTO)?

A: When CongWin gets to 1/2 of its value before timeout.

Implementation:• Variable Threshold • At loss event, Threshold is

set to 1/2 of CongWin value just before loss event.

Fast Recovery (3 dups)(Fast Retransmission

replaced missing segment)

Time-Out (dt>RTO)

If a Fast Retransmit fixes the gap in ACKs before a timeout, TCP can skip the Slow-Start and immediately use Additive Increase, starting at half the previous CongWin.

Con

gWin

(M

SS

)

(Time/RTT)

Time-Out(CongWin = 16)

TCP Reno

Q1-61

Fast Retransmit (to avoid Timeout)

• 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 4 ACKs for the same data (3 dups), it supposes that segment after ACKed data was lost:– Fast Retransmit:

resend segment before timer expires.

When resent packet is ACKed before a timeout, go to Fast Recovery Mode: - Halve Sender-Window, "CongWin" - Increase CongWin by 1 MSS per CongWin bytes sent and Acked.

Q1-62

CongWin / mss

Threshold = 20

Time Out

3 Dup. ACKs

12

6

CongWin <= Threshold: Doubles each RTT (add MSS for each ACK)CongWin > Threshold: Adds MSS each RTT

Time Out: Threshold = 1/2 CongWin, CongWin = 1 (Slow-Start)3-Dup Ack: Threshold = 1/2 CongWin, CongWin = Threshold (Fast Recovery)

Q1-63

Fairness

Fairness and UDP• Multimedia apps often do not

use TCP– do not want rate throttled by

congestion control

• Instead use UDP:– pump audio/video at

constant rate, tolerate packet loss

• Research area: make UDP more TCP friendly– Solution: reserve 50% of

router buffer space for TCP segments (excess UDP segments dropped).

Fairness and parallel TCP connections

• nothing prevents app from opening parallel connections between 2 hosts.

• Web browsers do this • Example: link of rate R

supporting 9 connections; – new app starts 1 TCP, gets

rate R/10– new app starts 9 TCPs, gets

R/2 !