Transcript 4th Edition: Chapter 1

Internet structure: network of networks
 “Tier-3” ISPs and local ISPs
 last hop (“access”) network (closest to end systems)
local
ISP
Local and tier3 ISPs are
customers of
higher tier
ISPs
connecting
them to rest
of Internet
Tier 3
ISP
Tier-2 ISP
local
ISP
local
ISP
local
ISP
Tier-2 ISP
Tier 1 ISP
Tier 1 ISP
Tier-2 ISP
local
local
ISP
ISP
Tier 1 ISP
Tier-2 ISP
local
ISP
Tier-2 ISP
local
ISP
Introduction
1-1
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
r Note: applications with
P2P architectures have
client processes &
server processes
2: Application Layer
2
Sockets
 process sends/receives
messages to/from its
socket
 socket analogous to door


sending process shoves
message out door
sending process relies on
transport infrastructure
on other side of door which
brings message to socket
at receiving process
host or
server
host or
server
process
controlled by
app developer
process
socket
socket
TCP with
buffers,
variables
Internet
TCP with
buffers,
variables
controlled
by OS
r API: (1) choice of transport protocol; (2) ability to fix
a few parameters (lots more on this later)
2: Application Layer
3
Addressing processes
 to receive messages,

Q: does IP address of
host on which process
process must have
runs suffice for
identifier
identifying the process?
 host device has unique
 A: No, many processes
32-bit IP address
can be running on
 Exercise: use ipconfig
same
from command prompt to  Identifier includes both
get your IP address
IP address and port
(Windows)
numbers associated with
process on host.
 Example port numbers:


HTTP server: 80
Mail server: 25
2: Application Layer
4
Scenario: Alice sends message to Bob
1) Alice uses UA to compose
message and “to”
[email protected]
2) Alice’s UA sends message
to her mail server; message
placed in message queue
3) Client side of SMTP opens
TCP connection with Bob’s
mail server
1
user
agent
2
mail
server
3
4) SMTP client sends Alice’s
message over the TCP
connection
5) Bob’s mail server places the
message in Bob’s mailbox
6) Bob invokes his user agent
to read message
mail
server
4
5
6
user
agent
2: Application Layer
5
Transport service requirements of common apps
Data loss
Throughput
Time Sensitive
file transfer
e-mail
Web documents
real-time audio/video
no loss
no loss
no loss
loss-tolerant
no
no
no
yes, 100’s msec
stored audio/video
interactive games
instant messaging
loss-tolerant
loss-tolerant
no loss
elastic
elastic
elastic
audio: 5kbps-1Mbps
video:10kbps-5Mbps
same as above
few kbps up
elastic
Application
yes, few secs
yes, 100’s msec
yes and no
2: Application Layer
6
Rdt2.0: channel with bit errors
 underlying channel may flip bits in packet
 checksum to detect bit errors

the question: how to recover from errors:

acknowledgements (ACKs): receiver explicitly tells sender

negative acknowledgements (NAKs): receiver explicitly

that pkt received OK
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 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 retransmits current
pkt if ACK/NAK garbled
 sender adds sequence
number to each pkt
 receiver discards (doesn’t
deliver up) duplicate pkt
stop and wait
Sender sends one packet,
then waits for receiver
response
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
TCP: retransmission scenarios
Host A
X
loss
Sendbase
= 100
SendBase
= 120
SendBase
= 100
time
SendBase
= 120
lost ACK scenario
Host B
Seq=92 timeout
Host B
Seq=92 timeout
timeout
Host A
time
premature timeout
TCP retransmission scenarios (more)
timeout
Host A
Host B
X
loss
SendBase
= 120
time
Cumulative ACK scenario
Host A
seq # x1
seq # x2
seq # x3
seq # x4
seq # x5
timeout
triple
duplicate
ACKs
time
Host B
X
ACK x1
ACK x1
ACK x1
ACK x1
TCP Flow Control
flow control
sender won’t overflow
receiver’s buffer by
transmitting too much,
too fast
 receive side of TCP
connection has a
receive buffer:
(currently)
TCP data application
IP
unused buffer
(in buffer)
process
datagrams
space
 app process may be
slow at reading from
buffer

speed-matching
service: matching
send rate to receiving
application’s drain rate
TCP congestion control:

goal: TCP sender should transmit as fast as possible,
but without congesting network

Q: how to find rate just below congestion level
 decentralized: each TCP sender sets its own rate,
based on implicit feedback:
 ACK: segment received (a good thing!), network not
congested, so increase sending rate
 lost segment: assume loss due to congested
network, so decrease sending rate
TCP Slow Start
 when connection begins, cwnd =
Host A
Host B
RTT
1 MSS
 example: MSS = 500 bytes
& RTT = 200 msec
 initial rate = 20 kbps
 available bandwidth may be >>
MSS/RTT
 desirable to quickly ramp up
to respectable rate
 increase rate exponentially
until first loss event or when
threshold reached
 double cwnd every RTT
 done by incrementing cwnd
by 1 for every ACK received
time
Summary: TCP Congestion Control
 when cwnd < ssthresh, sender in slow-start
phase, window grows exponentially.
 when cwnd >= ssthresh, sender is in congestion-
avoidance phase, window grows linearly.
 when triple duplicate ACK occurs, ssthresh set
to cwnd/2, cwnd set to ~ ssthresh
 when timeout occurs, ssthresh set to cwnd/2,
cwnd set to 1 MSS.
Routing Algorithm classification
Global or decentralized
information?
Global:
 all routers have complete
topology, link cost info
 “link state” algorithms
Decentralized:
 router knows physicallyconnected neighbors, link
costs to neighbors
 iterative process of
computation, exchange of
info with neighbors
 “distance vector” algorithms
Static or dynamic?
Static:
 routes change slowly
over time
Dynamic:
 routes change more
quickly
 periodic update
 in response to link
cost changes
A Link-State Routing Algorithm
Dijkstra’s algorithm
 net topology, link costs
known to all nodes
 accomplished via “link
state broadcast”
 all nodes have same info
 computes least cost paths
from one node (‘source”) to
all other nodes
 gives forwarding table
for that node
 iterative: after k
iterations, know least cost
path to k dest.’s
Notation:
 c(x,y): link cost from node
x to y; = ∞ if not direct
neighbors
 D(v): current value of cost
of path from source to
dest. v
 p(v): predecessor node
along path from source to v
 N': set of nodes whose
least cost path definitively
known
Distance vector algorithm (4)
Basic idea:
 From time-to-time, each node sends its own
distance vector estimate to neighbors
 Asynchronous
 When a node x receives new DV estimate from
neighbor, it updates its own DV using B-F equation:
Dx(y) ← minv{c(x,v) + Dv(y)}
for each node y ∊ N
 Under minor, natural conditions, the estimate
Dx(y) converge to the actual least cost dx(y)
Dx(y) = min{c(x,y) + Dy(y), c(x,z) + Dz(y)}
= min{2+0 , 7+1} = 2
node x table
cost to
x y z
= min{2+1 , 7+0} = 3
cost to
x y z
from
from
x 0 2 7
y ∞∞ ∞
z ∞∞ ∞
node y table
cost to
x y z
Dx(z) = min{c(x,y) +
Dy(z), c(x,z) + Dz(z)}
x 0 2 3
y 2 0 1
z 7 1 0
x ∞ ∞ ∞
y 2 0 1
z ∞∞ ∞
node z table
cost to
x y z
from
from
x
x ∞∞ ∞
y ∞∞ ∞
z 71 0
time
2
y
7
1
z
Dx(y) = min{c(x,y) + Dy(y), c(x,z) + Dz(y)}
= min{2+0 , 7+1} = 2
node x table
cost to
x y z
x ∞∞ ∞
y ∞∞ ∞
z 71 0
from
from
from
from
x 0 2 7
y 2 0 1
z 7 1 0
cost to
x y z
x 0 2 7
y 2 0 1
z 3 1 0
x 0 2 3
y 2 0 1
z 3 1 0
cost to
x y z
x 0 2 3
y 2 0 1
z 3 1 0
cost to
x y z
from
from
from
x ∞ ∞ ∞
y 2 0 1
z ∞∞ ∞
node z table
cost to
x y z
x 0 2 3
y 2 0 1
z 7 1 0
= min{2+1 , 7+0} = 3
cost to
x y z
cost to
x y z
from
from
x 0 2 7
y ∞∞ ∞
z ∞∞ ∞
node y table
cost to
x y z
cost to
x y z
Dx(z) = min{c(x,y) +
Dy(z), c(x,z) + Dz(z)}
x 0 2 3
y 2 0 1
z 3 1 0
time
x
2
y
7
1
z
Hierarchical Routing
Our routing study thus far - idealization
 all routers identical
 network “flat”
… not true in practice
scale: with 200 million
destinations:
 can’t store all dest’s in
routing tables!
 routing table exchange
would swamp links!
administrative autonomy
 internet = network of
networks
 each network admin may
want to control routing in its
own network
Slotted ALOHA
Pros
 single active node can
continuously transmit
at full rate of channel
 highly decentralized:
only slots in nodes
need to be in sync
 simple
Cons
 collisions, wasting slots
 idle slots
 nodes may be able to
detect collision in less
than time to transmit
packet
 clock synchronization
Switch
 link-layer device: smarter than hubs, take
active role
store, forward Ethernet frames
 examine incoming frame’s MAC address,
selectively forward frame to one-or-more
outgoing links when frame is to be forwarded on
segment, uses CSMA/CD to access segment

 transparent
 hosts are unaware of presence of switches
 plug-and-play,

self-learning
switches do not need to be configured
DHCP: Dynamic Host Configuration Protocol
Goal: allow host to dynamically obtain its IP address from
network server when it joins network
Can renew its lease on address in use
Allows reuse of addresses (only hold address while connected an
“on”)
Support for mobile users who want to join network (more shortly)
DHCP overview:
 host broadcasts “DHCP discover” msg [optional]
 DHCP server responds with “DHCP offer” msg
[optional]
 host requests IP address: “DHCP request” msg
 DHCP server sends address: “DHCP ack” msg