Date post: | 23-Jun-2015 |
Category: |
Technology |
Upload: | comm-it-affiliated-ggsip-university-delhi |
View: | 385 times |
Download: | 0 times |
The Transport Layer
• Provides a service to the application layer
• Obtains a service from the network layer
application
transport
network
link
physical
The Transport Layer
• Principles behind transport layer services• multiplexing/demultiplexing• reliable data transfer• flow control• congestion control
• Transport layer protocols used in the Internet• UDP: connectionless• TCP: connection-oriented
• TCP congestion control
Transport services and protocols• Provide logical communication
between application processes running on different hosts
• Transport protocols run on end systems• send side: break app messages
into segments, pass to network layer
• recv side: reassemble segments into messages, pass to app layer
• End-to-end transport between sockets• network layer provides end-
to-end delivery between hosts
Internet transport-layer protocols• TCP
• connection-oriented, reliable in-order stream of bytes
• congestion control, flow control, connection setup
• users see stream of bytes - TCP breaks into segments
• UDP• unreliable, unordered• users supply chunks to UDP,
which wraps each chunk into a segment / datagram
• Both TCP and UDP use IP, which is best-effort - no delay or bandwidth guarantees
Multiplexing• Goal: put several transport-layer ‘connections’ over
one network-layer ‘connection’Demultiplexing at rcv host:
delivering received segmentsto correct socket
Multiplexing at send host:gathering data from multiplesockets, enveloping data with
header (used for demultiplexing)
Demultiplexing
• Host receives IP datagrams• each datagram has source IP
address, destination IP address
• each datagram carries one transport-layer segment
• each segment has source, destination port numbers
• Host uses IP addresses and port numbers to direct segment to the appropriate socket
source port # dest port #
other header fields
application data(message)
32 bits
TCP/UDP segment format
Connectionless (UDP) demultiplexing
• Create sockets with port numbersDatagramSocket mySocket1 = new DatagramSocket(99111);
DatagramSocket mySocket2 = new DatagramSocket(99222);
• UDP socket identified by two-tuple:(destination IP address, destination port number)
• When host receives UDP segment• checks destination port number in segment• directs UDP segment to socket with that port number
• IP datagrams with different source IP addresses and/or source port numbers, but same dest address/port, are directed to the same socket
Connection-oriented (TCP) demultiplexing
• TCP socket identified by four-tuple:(source IP address, source port number, destination IP address, destination port number)
• Receiving host uses all four values to direct segment to the correct socket
• Server host may support many simultaneous TCP sockets• each socket identified by own 4-tuple
• Web servers have different sockets for each connecting client• non-persistent HTTP has different socket for each request
TCP demultiplexing
User Datagram Protocol (UDP)
• RFC 768• The ‘no frills’ Internet
transport protocol• ‘best efforť: UDP segments
may be:• lost• delivered out of order
• connectionless• no handshaking between
sender and receiver• each segment handled
independently of others
Why have UDP?� • � no connection establishment (means lower delay)� • � simple; no connection state at sender and receiver� • � small segment header� • � no congestion control: UDP can blast away as fast as desired� • � no retransmits: useful for some applications (lower delay)
UDP
• Often used for streaming multimedia, games• loss-tolerant• rate or delay-sensitive
• Also used for DNS, SNMP• If you need reliable transfer
over UDP, can add reliability at application-layer• application-specific error
recovery• but think about what you are
doing...
source port # dest port #
length(in bytes of UDP
segment, including header)
checksum
application data(message)
32 bits
UDP segment format
UDP checksum• Purpose: to detect errors (e.g., flipped bits) in a
transmitted segment
Sender•� treat segment contents as a sequence of 16-bit integers•� checksum: addition (1’s complement sum) of segment contents•� sender puts checksum value into UDP checksum field
Receiver•� compute checksum of received segment•� check if computed checksum equals checksum field value� • � NO = error detected� • � YES = no error detected (but maybe errors anyway?)
UDP checksum example• e.g., add two 16-bit integers• NB, when adding numbers, carry from MSB is added
to result
1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 01 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_________________________________
1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 00 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1
wraparound
sumchecksum
Reliable data transfer• Principles are important in app, transport, link layers• Complexity of the reliable data transfer (rdt) protocol
determined by characteristics of unreliable channel
rdt_send(): called from above (e.g., by app). Passed data to
deliver to receiver’s upper layer
deliver_data(): called by rdt to deliver data to upper
layer
udt_send(): called by rdt to transfer packet
over unreliable channel to receiver
rdt_recv(): called when packet arrives
on rcv side of channel
SENDSIDE
RECVSIDE
Developing an rdt protocol• Develop sender and receiver sides of rdt protocol• Consider only unidirectional data transfer
• although control information will flow in both directions• Use finite state machines (FSM) to specify sender and
receiver
state1
state2
event causing state transition actions taken on state transition
eventactions
state: when in this state, next
state is uniquely determined by
next eventinitialstate
rdt1.0
SENDER
RECEIVER
• No bit errors, no packet loss, no packet reordering
rdt2.0• What if channel has bit errors (flipped bits)?
• Use a checksum to detect bit errors• How to recover?
• acknowledgements (ACKs): receiver explicitly tells sender that packet was received (“OK”)
• negative acknowledgements (NAKs): receiver explicitly tells sender that packet had errors (“Pardon?”)
• sender retransmits packet on receipt of a NAK• ARQ (Automatic Repeat reQuest)
• New mechanisms needed in rdt2.0 (vs. rdt1.0)• error detectio#• receiver feedback: control messages (ACK, NAK)• retransmissio#
rdt2.0SENDER
RECEIVER
But rdt2.0 doesn’t always work...• If ACK/NAK corrupted
• sender doesn’t know what happened at receiver
• shouldn’t just retransmit: possible duplicate
• Solution:• sender adds sequence number to
each packet• sender retransmits current
packet if ACK/NAK garbled• receiver discards duplicates
• Stop and wai$• Sender sends one packet, then
waits for receiver response
ACK
data1data1
delivered
NAK
data2
ACK
data2
ACK
data3
ACK
data3
!
!NAK
data2 delivered
data3 delivered
data3 delivered
SENDER RECEIVER
rdt2.1 sender
rdt2.1 receiver
rdt2.1
Sender• seq # added• two seq #’s (0,1) sufficient• must check if received ACK/
NAK is corrupted• 2x state
• state must “remember” whether “current” packet has 0 or 1 seq #
Receiver•� must check if received packet is duplicate� • � state indicates whether 0 or 1 is expected seq #•� receiver can not know if its last ACK/NAK was received OK at sender
rdt2.1 works!
ACK
data1/0data1
delivered
NAK
data2/1
ACK
data2/1
ACK
data3/0
ACK
data3/0
!
!NAK
data2 delivered
data3 delivered
SENDER RECEIVER
Do we need NAKs? rdt2.2• Instead of NAK, receiver sends ACK for last packet
received OK• receiver explicitly includes seq # of packet being ACKed
rdt2.2 sender• duplicate ACK at sender results in the same action as
a NAK: retransmit current packe$
rdt2.2 works!
ACK0
data1/0data1
delivered
ACK0
data2/1
ACK1
data2/1
ACK0
data3/0
ACK0
data3/0
!
!#%$
data2 delivered
data3 delivered
SENDER RECEIVER
What about loss? rdt3.0
Assume:• Underlying channel can also
lose packets (both data and ACKs)• checksum, seq #, ACKs,
retransmissions will 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 is duplicate, but seq # handles this� � • � received must specify seq # of packet being ACKed� • � requires countdown timer
rdt3.0 sender
{rdt3.0 in action
ACK0
data1/0 data1 delivered
data2/1
ACK1
data2/1
ACK0
data3/0
ACK0
!
!
data2 delivered
data3 delivered
SENDER RECEIVER
data3/0
{{{{
timeout
timeout
rdt3.0 works, but not very well...
• e.g., 1Gbps link, 15 ms propagation delay, 1KB packet:• L = packet length in bits, R = transmission rate in bps• Usender = utilisation - the fraction of time sender is busy
sending• 1 KB packet every 30 ms 33 kB/s throughput over a 1Gbps
link• good value for money upgrading to Gigabit Ethernet!
• network protocol limits the use of the physical resources!• because rdt3.0 is stop-and-wai$
Ttransmit =L
R=
8kb/pkt
109b/sec= 8microsec
Usender =
L
R
RTT + L
R
=0.008
30.008= 0.00027
Pipelining
• Pipelined protocols• send multiple packets without waiting• number of outstanding packets > 1, but still limited• range of sequence numbers needs to be increased• buffering at sender and/or receiver
• Two generic forms• go-back-N and selective repea$
Go-back-N
• Sender• k-bit sequence number in packet header• “window” of up to N, consecutive unACKed packets allowed• ACK(n): ACKs all packets up to, including sequence number n
= “cumulative ACK”• (this may deceive duplicate ACKs)
• timer for each packet in flight• timeout(n): retransmit packet n and all higher sequence #
packets in window
Go-back-N sender
Go-back-N receiver
• ACK-only: always send ACK for correctly-received packet with highest in-order sequence number• may generate duplicate
ACKs• only need to remember expectedseqnum
• out-of-order packet:• discard (don’t buffer), i.e., no
receiver buffering• reACK packet with highest
in-order sequence number
go-back-N in action
ACK1
data1
data3
SENDER RECEIVER
data2
ACK2!data4
ACK2data5
ACK2data3data3 timeout
ACK3data4
ACK4
Selective Repeat• If we lose one packet in go-back-N
• must send all N packets again• Selective Repeat (SR)
• only retransmit packets that didn’t make it• Receiver individua&y acknowledges all correctly-
received packets• buffers packets as needed for eventual in-order delivery to
upper layer• Sender only resends pkts for which ACK not received
• sender timer for each unACKed packet• Sender window
• N consecutive sequence numbers• as in go-back-N, limits seq numbers of sent, unACKed pkts
Selective repeat windows
Selective RepeatSender• if next available seq # is in
window, send packet• timeout(n): resend pkt n,
restart timer• ACK(n) in [sendbase, sendbase+N]:
• mark packet n as received• if n is smallest unACKed
packet, advance window base to next unACKed seq #
• Need >= 2N sequence numbers• or reuse may confuse
receiver
Receiverpkt n in [rcvbase, rcvbase+N-1]:� • � send ACK(n)� • � if out of order, buffer� • � if in order: deliver (also deliver any buffered, in-order pkts), advance window to next not-yet-received pktpkt n in [rcvbase, rcvbase+n-1]:� • � send ACK(n)� � • even though already ACKedotherwise� • � ignore
SR in action
ACK1
data1
RECEIVER
ACK2data3
data2
!data4
ACK4data5
ACK5
data3data3 timeout
ACK3
1 2 3 4 5 6 7 8 9 10
(window full)
data61 2 3 4 5 6 7 8 9 10
1 2 3 4 5 6 7 8 9 10
1 2 3 4 5 6 7 8 9 10
1 2 3 4 5 6 7 8 9 10
1 2 3 4 5 6 7 8 9 10
1 2 3 4 5 6 7 8 9 10
1 2 3 4 5 6 7 8 9 10
1 2 3 4 5 6 7 8 9 10
1 2 3 4 5 6 7 8 9 10
1 2 3 4 5 6 7 8 9 10
1 2 3 4 5 6 7 8 9 10
(data3 received, so data3-6delivered up, ACK3 sent)
SENDER
(ACK1 received)
TCP
• point-to-point• one sender, one receiver
• reliable, in-order byte strea'• no “message boundaries”
• pipelined• TCP congestion control and flow control set window size
• send and receive buffers• flow-controlled
• sender will not overwhelm receiver
•� full-duplex data� • � bi-directional data flow in same connection� • � MSS: maximum segment size•� connection-oriented� • � handshaking initialises sender, receiver state before data exchange
TCP segment structure
source port # dest port #
sequence number
acknowledgement number
head len
not used UA P R S F receive window
checksum urgent data pointer
options (variable length)
application data(message)
32 bits
counted in bytes (not segments)
#bytes receiver willing to accept
Internet checksum (like
UDP)
U = urgent data (not often used)
A = ACK# valid
P = push data (not often used)
R,S,F = RST, SYN, FIN = connection
setup/teardown commands
TCP sequence numbers & ACKs• Sequence numbers
• byte-stream # of first byte in segmenťs data
• ACKs• seq # of next byte expected
from other side• cumulative ACK
• How does receiver handle out-of-order segments?• Spec doesn’t say; up to
implementor• Most buffer and wait for
missing to be retransmitted
TCP RTT & timeout• How to set TCP timeout?
• longer than RTT• but RTT can vary
• too short premature timeout• unnecessary
retransmissions• too long slow reaction to
loss• So estimate RTT
•� How to estimate RTT?� • � sampleRTT: measured time from segment transmission until ACK receipt� � • ignore retransmissions� • � sampleRTT will vary, but we want � � “smooth” estimated RTT� � • � average several recent measurements, not just current
EstimatedRTT = (1 − α) ∗ EstimatedRTT + α ∗ SampleRTT
•� Exponentially-weighted moving average•� Influence of past samples decrease exponentially fast•� typical α = 0.125
TCP RTT estimation
TCP timeout
• Timeout = EstimatedRTT + “safety margin”• if timeouts too short, too many retransmissions• if margin is too large, timeouts take too long • larger the variation in EstimatedRTT, the larger the margin
• first estimate of deviation
(typical β = 0.25)
• Then set timeout interval
DevRTT = (1 − β) ∗ DevRTT + β ∗ |SampleRTT − EstimatedRTT |
TimeoutInterval = EstimatedRTT + 4 ∗ DevRTT
RDT in TCP
• TCP provides RDT on top of unreliable IP• Pipelined segments• Cumulative ACKs• Single retransmission timer
• Retransmissions triggered by :• timeout events• duplicate ACKs
TCP sender events
Data received from app:• Create segment with seq #• seq # is byte-stream number
of first data byte in segment• start timer if not already
running (timer for oldest unACKed segment)
• expiration interval = TimeOutInterval
Timeout:� •� retransmit segment that caused timeout� •� restart timer
ACK received:� •� If ACK acknowledges previously-unACKed segments� � • � update what is known to be ACKed� � • � start timer if there are outstanding segments
NextSeqNum = InitialSeqNumSendBase = InitialSeqNum
loop (forever) { switch(event)
event: data received from application above create TCP segment with sequence number NextSeqNum if (timer currently not running) start timer pass segment to IP NextSeqNum = NextSeqNum + length(data)
event: timer timeout retransmit not-yet-acknowledged segment with smallest sequence number start timer
event: ACK received, with ACK field value of y if (y > SendBase) { SendBase = y if (there are currently not-yet-acknowledged segments) start timer }
} /* end of loop forever */
TCP sender (simplified)
• SendBase-1 = last cumulatively-ACKed byte
• e.g.,• SendBase-1 = 71; y = 73, so receiver wants 73+
• y > SendBase, so the new data is ACKed
TCP retransmissions - lost ACKSEQ=92, 8 bytes data
HOST A HOST B
ACK=100
SEQ=92, 8 bytes data
ACK=100
!
SendBase = 100
time
timeo
ut
TCP retransmissions - premature timeout
SEQ=92, 8 bytes data
HOST A HOST B
ACK=10
0
SendBase = 100
time
timeo
ut SEQ=100, 20 bytes data
ACK=12
0SEQ=92, 8 bytes data
ACK=120tim
eout
SendBase = 120
SendBase = 120
TCP retransmissions - saving retransmits
SEQ=92, 8 bytes data
HOST A HOST B
time
timeo
ut
ACK=12
0
SendBase = 120
ACK=10
0
!
SEQ=100, 20 bytes data
TCP ACK generationEvent at receiver TCP receiver actio#
Arrival of in-order segment with expected seq #. All data up to expected seq # already ACKed.
Delayed ACK. Wait up to 500ms for next segment. If no next segment, send ACK.
Arrival of in-order segment with expected seq #. One other segment has ACK pending.
Immediately send single cumulative ACK, ACKing both in-order segments.
Arrival of out-of-order segment higher than expected seq #. Gap detected.
Immediately send duplicate ACK, indicating seq # of next expected byte.
Arrival of segment that partially or completely fills gap.
Immediately send ACK, provided that segment starts at lower end of gap.
TCP Fast Retransmit
• Timeout is often quite long• so long delay before resending lost packet
• Lost segments are detected via DUP ACKs• sender often sends many segments back-to-back (pipeline)• if segment is lost, there will be many DUP ACKs
• If a sender receives 3 ACKs for the same data, it assumes that the segment after the ACKed data was lost• fast retransmit: resend segment before the timer expires
TCP flow controlFlow control: prevent sender from overwhelming receiver• Receiver side of TCP connection has a receive buffer
• Application process may be slow at reading from buffer• Need ‘speed-matching’ service: match send rate to
receiving application’s ‘drain’ rate
TCP flow control
• Receiver advertises spare room by including value of RcvWindow in segments• value is dynamic
• Sender limits unACKed data to RcvWindow
• guarantees receive buffer will not overflow
•� Spare room in buffer = RcvWindow = RcvBuffer - [LastByteRcvd- LastByteRead]
TCP connection management
TCP sender and receiver establish ‘connection’ before exchanging data segments
• Initialise TCP variables:• sequence numbers• buffers, flow control info
• Client: initiates connectionSocket clientSocket = new Socket("hostname","port number");
• Server: contacted by clientSocket connectionSocket = welcomeSocket.accept();
Three way handshake
1. Client host sends TCP SYN segment to server� •� specifies initial sequence #� •� no data
2. Server receives SYN, replies with SYNACK segment� •� server allocates buffers� •� specifies server initial seq #
3. Client receives SYNACK, replies with ACK� •� may contain data
TCP connection managementClosing a connection
1. Client host sends TCP FIN segment to server� •� specifies initial sequence #� •� no data
2. Server receives FIN, replies with ACK segment, closes connection, sends FIN
3. Client receives FIN, replies with� ACK, enters ‘timed waiť� •� during timed wait, will respond with ACK to FINs
4. Server receives ACK, closes.
FIN
ACK
CLIENT SERVER
time
timed
wai
t
close
FIN
ACK
close
closed
closed
TCP connection management
TCP clientlifecycle
TCP serverlifecycle
Other TCP flags• RST = reset the connection
• used e.g., to reset non-synchronised handshakes• or if host tries to connect to server on non-listening port
• PSH = push• receiver should pass data to upper layer immediately• receiver pushes all data in window up
• URG = urgent• sender’s upper layer has marked data in segment as urgent
• location of last byte of urgent data indicated by urgent data pointer
• URG and PSH are hardly ever used• except Blitzmail, which appears to use PSH for every segment
• See RFC 793 for more info (also 1122, 1323, 2018, 2581)
Congestion control
• What is congestion?• Too many sources sending too much data too fast for
the network to handle• Not flow control!
• network, not end systems• Manifestations
• lost packets (buffer overflow at routers)• long delays (queueing in router buffers)
• One of the most important problems in networking
Congestion control: scenario 1• 2 senders, 2 receivers• link capacity R• 1 router, infinite
buffers• no retransmissions
• � large delays when congested• � maximum achievable throughput = R/2
Congestion control: scenario 2• 1 router, finite buffers• sender retransmits lost packets• λin = sending rate, λ′in = offered load (inc. retransmits)
Congestion control: scenario 2• λin = λout (goodput)• ‘perfecť retransmission, only when loss: λ′in > λout
• retransmissions of delayed (not lost) packets means λ′in greater than perfect case
• So congestion causes• more work (retransmits) for given goodput• unnecessary retransmissions; link carries multiple copies
Congestion control: scenario 3
• 4 senders• A C• B D
• finite buffers• multihop paths• timeouts/
retransmits
Congestion control: scenario 3
• A C limited by R1 R2 link• B D traffic saturates R2
• A C end-to-end throughput goes to zero
• may as well have used R1 for something else
• So congestion causes• packet drops any
upstream transmission capacity used for that packet is wasted
Approaches to congestion control
End-to-end congestion control
• no explicit feedback from network
• congestion inferred from end-system observed loss and delay
• this is what TCP does
Network-assisted congestion control•� routers provide feedback to end systems� •� direct feedback, e.g. choke packet� •� mark single bit indicating �� � congestion� •� tells sender the explicit rate at which it should send� •� ATM, DECbit, TCP/IP ECN
ATM ABR congestion controlATM (Asynchronous Transfer Mode)
• alternative network architecture
• virtual circuits, fixed-size cells
ABR (Available Bit Rate)• elastic server• if sender’s path is underloaded,
sender should use available bandwidth
• if sender’s path is congested, sender is throttled to the minimum guaranteed rate
RM (Resource Management) Cells•� sent by sender, interspersed � with data cells•� bits in RM cell set by switches (i.e., network-assisted CC)� •� NI bit: no increase in rate (mild congestion)� •� CI bit: congestion indication•� RM cells are returned to the sender by receiver, with bits intact
ATM ABR congestion control
• 2-byte ER (Explicit Rate) field in RM cell• congested switch may lower ER value in cell• sender’s send rate is thus the minimum supportable rate on path
• EFCI bit in data cell is set to 1 in a congested switch• if data cell preceding RM cell has EFCI set, sender sets CI bit in
returned RM cell
• end-to-end (no network assist)• sender limits transmission
• CongWin is dynamic function of perceived congestion• How does sender perceive congestion?
• loss event: timeout or 3 DUP ACKs• TCP sender reduces rate (CongWin) after loss event• 3 mechanisms: AIMD, slow start, conservative after timeouts
• TCP congestion control is self-clocking
TCP congestion control
rate =
CongWin
RTTBytes/sec
LastByteSent − LastByteAcked ≤ min{CongWin,RcvWindow}
TCP AIMDMultiplicative decrease• halve CongWin after loss event
Additive increase•� increase CongWin by 1 MSS every RTT in the absence of loss events (probing)
TCP ‘sawtooth’
TCP Slow Start• When connection begins, CongWin = 1 MSS
• e.g., MSS = 500 bytes, RTT = 200 ms• initial rate = 20 kbps
• But available bandwidth may be ≥ MSS/RTT• want to quickly ramp up to respectable rate
• When connection begins, increase rate exponentially until the first loss event• double CongWin every RTT
• increment CongWin for every ACK received• Slow start: sender starts sending at slow rate, but
quickly speeds up
TCP slow startHOST A HOST B
time
RTT
1 segment
2 segments
4 segments
RTT
TCP - reaction to timeout events• After 3 DUP ACKs
• CongWin halved• window then grows linearly
• But after timeout• CongWin set to 1 MSS• window then grows exponentially• to threshold, then grows linearly (AIMD: congestion
avoidance)• Why?
• 3 DUP ACKs means network capable of delivering some segments, so do Fast Recovery (TCP Reno)
• timeout before 3 DUP ACKs is more troubling
TCP - reaction to timeout events
• When to switch from exponential to linear?• When CongWin gets
to ½ of its value before timeout
• Implementation:• Threshold variable• At loss event, Threshold is set to ½ of CongWin just before loss event
TCP congestion control - summary
• When CongWin is below Threshold, sender in slow start phase; window grows exponentially
• When CongWin is above Threshold, sender 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 set to 1 MSS
TCP throughput
• W = window size when loss occurs• When window = W, throughput = W/RTT• After loss, window = W/2, throughput = W/2RTT• Average throughput = 0.75W/RTT
• (ignoring slow start, assume throughput increases linearly between W/2 and W)
High-speed TCP• assume: 1500 byte MSS (common for Ethernet),
100ms RTT, 10Gbps desired throughput• W = 83,333 segments
• a big CongWin! What if loss?• Throughput in terms of loss:
• so L (loss rate) = 2*10-10 (1 loss every 5m segments)• is this realistic?
• Lots of people working on modifying TCP for high-speed networks
1.22 ∗ MSS
RTT ∗√
L
Fairness• If k TCP sessions share same bottleneck link of
bandwidth R, each should have an average rate of R/*
How is TCP fair?Two competing sessions• additive increase gives slope of 1 as throughput increases• multiplicative decrease decreases throughput proportionally
• � suppose we are at A� • � total < R, so both increase• � B, total > R, so loss� • � both decrease window by a � � factor of 2• � C� • � total < R, so both increase• � etc...
Fairness• multimedia apps often use UDP
• do not want congestion/flow control to throttle rate• pump A/V at constant rate, tolerate packet loss
• How to enforce fairness in UDP?• application-layer congestion control• long-term throughput of a UDP flow is equivalent to a TCP flow on the same link
• Parallel TCP connections• nothing to stop application from opening parallel connections
between two hosts (web browser, download ‘accelerator’)• e.g., link of rate R with 9 connections
• new app asks for 1 TCP, gets rate R/(9+1) = R/10• new app asks for 11 TCP, gets rate R/(9+11) = R/2 (!)
What is ‘fair’?• Max-min fairness
• Give the flow with the lowest rate the largest possible share• Proportional fairness
• TCP favours short flows• Proportional fairness: flows allocated bandwidth in proportion
to number of links traversed• Pareto-fairness
• can’t give another flow any more bandwidth without taking bandwidth away from another flow
• Per-link fairness• each flow gets a fair share of each link traversed
• Utility functions/pricing• I pay/want more, I get more
Quick history of the Internettime
1957-------
Sputnik launched.ARPA created in
response.
early ‘60s-------
Packet-switching independently
invented by Paul Baran (RAND), Donald Davies (NPL, UK) and
Leonard Kleinrock (MIT).
1967-------
Lawrence Robert proposes the “ARPANET”
1968-------
BBN starts work on the IMP (Interface Message
Processor).
1971-------
Ray Tomlinson develops e-mail. By 1973 e-mail is
75% of ARPANET
traffic.
1969-------
First IMP installed at
UCLA (first host on ARPANET).
Second host installed at SRI.
First host-to-host message crashes
on “G” of “LOGIN”.
1973-------
Bob Metcalfe invents Ethernet.
UCL becomes first international ARPANET node.
1974-------
Vint Cerf and Bob Kahn publish “A Protocol for
Packet Network Interconnection”
(TCP)
4hosts
1976-------
The Queen sends an e-mail.
1978-------
TCP becomes TCP/IP.
1979-------
First MUD developed at
Essex.
1982-------
UCL and Norway connect to
ARPANET/Internet using TCP/IP over
SATNET.
1983-------
DNS developed.
1985-------
ISI manages DNS root server, SRI NIC manages registrations.
symbolic.com is first registered
domain.
1986-------
NSFNET created. IETF/IRTF
created.
1000hosts
10000hosts
1988-------
DoD adopts OSI model. Internet
worm infects most of the
ARPANET, leads to formation of
CERT.
1990-------
End of ARPANET. First commercial ISP (world.std.com).
100000hosts
1991-------
CERN releases WWW. First web
server (nsoc01.cern.ch).
1millionhosts
1993-------
Mosaic launched. WWW grows by
341,634%.Doom released.
1994-------
First e-commerce.First cyberbank.
First online pizza-ordering.
First spam.First banner ad.Yahoo! launches.
10millionhosts
1996-------
Hotmail debuts. Internet2
launched. Quake II released.
1995-------
RealAudio, AltaVista debut. Netscape IPO.
1997-------
802.11 standard released.
1998-------
Google launches.
100millionhosts
1999-------
business.com domain sells for
$7.5m.Napster launches.
2001-------
Lawsuits close Napster down.
Code Red, Nimda worms.
BitTorrent introduced.
X-Box debuts with integrated Ethernet port.
2003-------
Slammer, Blaster worms. Flash mobs, blogs
become popular. Verisign almost destroys DNS (Site Finder). RIAA starts
sueing P2P end-users.
2004-------
Network Solutions offers 100 year domain
registrations.
300millionhosts