CS455 Introduction to Computer Networks

1
CS455 Introduction to Computer Networks
WSU Vancouver

• Dr. Wenzhan Song
• Assistant Professor, Computer Science

2
Course roadmap

• Introduction
• Application Layer WWW, FTP, email, DNS,
  multimedia
• Transport Layer reliable end-end data transfer
  principles, UDP, TCP
• Network Layer routing, congestion control, QoS
• Data Link Layer framing, error control, flow
  control
• Medium Access Control (MAC) Layer
  multiple-access, channel allocation
• Physical Layer wired, wireless, satellite
• Other Topics network security, social issues,
  hot topics, research directions

3
Transport Layer

• learn about transport layer protocols in the
  Internet
• UDP connectionless transport
• TCP connection-oriented transport
• TCP congestion control

• Our goals
• understand principles behind transport layer
  services
• multiplexing/demultiplexing
• connection management
• reliable end-end data transfer
• congestion control

4
Roadmap Transport Layer

• Transport-layer services
• Multiplexing and demultiplexing
• Inside end-end data transfer
• UDP unreliable end-end data transfer,
  connectionless transport
• Reliable end-end data transfer principle
• Simplex protocols
• Pipelined protocols
• TCP reliable end-end data transfer,
  connection-oriented transport
• segment structure
• connection management
• reliable data transfer solution and flow control
• end-end congestion control
• Performance issues and refinement

5
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

6
Transport vs. network layer

• network layer logical communication between
  hosts
• transport layer logical communication between
  processes
• relies on, enhances, network layer services

• Household analogy
• 12 kids sending letters to 12 kids
• processes kids
• app messages letters in envelopes
• hosts houses
• transport protocol Ann and Bill
• network-layer protocol postal service

7
Internet transport-layer protocols

• reliable, in-order delivery (TCP)
• connection management
• flow control
• congestion control
• unreliable, unordered delivery UDP
• no-frills extension of best-effort IP
• services not available
• delay guarantees
• bandwidth guarantees

8
Roadmap Transport Layer

• Transport-layer services
• Multiplexing and demultiplexing
• Inside end-end data transfer
• UDP unreliable end-end data transfer,
  connectionless transport
• Reliable end-end data transfer principle
• Simplex protocols
• Pipelined protocols
• TCP reliable end-end data transfer,
  connection-oriented transport
• segment structure
• connection management
• reliable data transfer solution and flow control
• end-end congestion control
• Performance issues and refinement

9
Multiplexing/demultiplexing
Host delivering received segments to correct
socket
Host gathering data from Multiple sockets,
enveloping data with header (later used for
demultiplexing) and send
process
socket
host 3
host 2
host 1
10
How demultiplexing works

• host receives IP datagrams
• each datagram has source IP address, destination
  IP address
• each datagram carries 1 transport-layer segment
• each segment has source, destination port number
  (recall well-known port numbers for specific
  applications)
• host uses IP addresses port numbers to direct
  segment to appropriate socket

IP Header(with src and dest IP address)
32 bits
source port
dest port
other header fields
application data (message)
TCP/UDP segment format
11
Connectionless demultiplexing

• 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 may be directed to
  same destination socket

• Create sockets with port numbers
• Example server socket
• serverSocket socket(AF_INET , SOCK_STREAM , 0)
• address.sin_family AF_INET
• address.sin_addr.s_addr INADDR_ANY
• address.sin_port htons(9157)
• bind(serverSocket,address,sizeof(address))
• UDP socket identified by two-tuple
• (dest IP address, dest port number)

12
Connectionless demux (cont)
SP provides return address SP Source Port, DP
Destination Port
13
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

14
Connection-oriented demux (cont)
S-IP B
D-IPC
SP 9157
Client IPB
DP 80
server IP C
S-IP A
S-IP B
D-IPC
D-IPC
15
Connection-oriented demux Threaded Web Server
P4
S-IP B
D-IPC
SP 9157
Client IPB
DP 80
server IP C
S-IP A
S-IP B
D-IPC
D-IPC
16
Roadmap Transport Layer

• Transport-layer services
• Multiplexing and demultiplexing
• Inside end-end data transfer
• UDP unreliable end-end data transfer,
  connectionless transport
• Reliable end-end data transfer principle
• Simplex protocols
• Pipelined protocols
• TCP reliable end-end data transfer,
  connection-oriented transport
• segment structure
• reliable data transfer solution and flow control
• connection management
• end-end congestion control
• Performance issues and refinement

17
Inside end-end data transfer
Question why network layer is not reliable ?

• important in transport, data link layers
• top-10 list of important networking topics!

Application Layer -------------- Transport
Layer -------------- Network Layer
Network Layer -------------- Data link
Layer -------------- Physical Layer
from_up_layer
to_up_layer
from_low_layer
to_low_layer

• characteristics of unreliable channel will
  determine complexity of reliable data transfer
  protocol

18
Inside end-end data transfer
Problems may have (1) Packet corruption (2)
Packet loss (3) Packet not in order (4) Long
time delay Problem (3)(4) does not exist in
data link layer

• End-end data transfer protocol in transport layer
  
• UDP unreliable data transfer
• Error control Internet checksum
• TCP reliable data transfer
• Connection management establishment/release
• Error control Internet checksum
• Flow control buffering, retransmission policy,
  timer management
• Congestion control end-end congestion control

19
Data link layer vs Transport layer

• (a) data link layer channel delay is
  predictable(point-to-point case), packet in order
• (b) transport layer subnet delay is
  unpredictable, packet may not in order

20
Roadmap Transport Layer

• Transport-layer services
• Multiplexing and demultiplexing
• Inside end-end data transfer
• UDP unreliable end-end data transfer,
  connectionless transport
• Reliable end-end data transfer principle
• Simplex protocols
• Pipelined protocols
• TCP reliable end-end data transfer,
  connection-oriented transport
• segment structure
• reliable data transfer solution and flow control
• connection management
• end-end congestion control
• Performance issues and refinement

21
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

22
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!

32 bits
source port
dest port
Length, in bytes of UDP segment, including header
checksum
length
Application data (message)
UDP segment format
23
UDP checksum

• Goal detect errors (e.g., flipped bits) in
  transmitted segment

• Sender
• treat segment contents as sequence of 16-bit
  integers
• checksum addition (1s complement sum) of
  segment contents Internet checksum method
• 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
  nonetheless? More later .

24
Internet Checksum Example

• Note
• When adding numbers, a carryout from the most
  significant bit needs to be added to the result
• Example add two 16-bit integers

1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1
0 1 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 1 1 0 1 1 1 0 1 1 1 0 1 1 1 1
0 0 1 0 1 0 0 0 1 0 0 0 1 0 0 0 0
1 1
wraparound
sum
checksum
25
Roadmap Transport Layer

• Transport-layer services
• Multiplexing and demultiplexing
• Inside end-end data transfer
• UDP unreliable end-end data transfer,
  connectionless transport
• Reliable end-end data transfer principle
• Simplex protocols
• Pipelined protocols
• TCP reliable end-end data transfer,
  connection-oriented transport
• segment structure
• reliable data transfer solution and flow control
• connection management
• end-end congestion control
• Performance issues and refinement

26
Reliable end-end data transfer principle

• Simplex protocols
• Reliable channel V1.01.1
• Unreliable channel V2.0V3.0
• Pipelined protocols or Sliding window protocols
• Go Back N (GBN)
• Selective repeat

27
Framework
from_up_layer(data)
to_up_layer(data)
send side
receive side
to_low_layer(packet)
from_low_layer(packet)
28
Simplex protocols

• We first consider simplex protocols single
  packet in-flight
• incrementally develop sender, receiver sides of
  reliable data transfer protocol (V1.0V3.0)
• consider only unidirectional data transfer
• but control info will flow on both directions!
• use finite state machines (FSM) to specify
  sender, receiver

event causing state transition
actions taken on state transition
state when in this state, next state uniquely
determined by next event
29
V1.0 over a reliable channel(Unrestricted
Simplex Protocol)
Q Even with reliable channel, whats the problem
could be? A quick sender, slow
receiver Solution simplex stop-and-wait protocol

• 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 channel

from_up_layer(data)
from_low_layer(packet)
Wait for call from below
Wait for call from above
extract (packet,data) to_up_layer(data)
packet make_pkt(data) to_low_layer(packet)
sender
receiver
30
V1.1 over a reliable channel(Simplex
Stop-and-wait Protocol)
from_up_layer(data)
receiver
snkpkt make_pkt(data, checksum) to_low_layer(snd
pkt)
Wait for call from above
from_low_layer(rcvpkt) isACK(rcvpkt)
L
sender
from_low_layer(rcvpkt)
Sender sends one packet, then waits for receiver
response
extract(rcvpkt,data) to_up_layer(data) to_low_laye
r(ACK)
31
V2.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 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 V2.0 (beyond V1.1)
• error detection
• receiver feedback control msgs (ACK,NAK)
  rcvr-gtsender

32
V2.0 FSM specification
from_up_layer(data)
receiver
snkpkt make_pkt(data, checksum) to_low_layer(snd
pkt)
from_low_layer(rcvpkt) isNAK(rcvpkt)
Wait for call from above
to_low_layer(sndpkt)
from_low_layer(rcvpkt) isACK(rcvpkt)
L
sender
from_low_layer(rcvpkt) notcorrupt(rcvpkt)
extract(rcvpkt,data) to_up_layer(data) to_low_laye
r(ACK)
33
V2.0 operation with no errors
from_up_layer(data)
receiver
snkpkt make_pkt(data, checksum) to_low_layer(snd
pkt)
from_low_layer(rcvpkt) isNAK(rcvpkt)
Wait for call from above
to_low_layer(sndpkt)
from_low_layer(rcvpkt) isACK(rcvpkt)
Wait for call from below
L
sender
from_low_layer(rcvpkt) notcorrupt(rcvpkt)
extract(rcvpkt,data) to_up_layer(data) to_low_laye
r(ACK)
34
V2.0 error scenario
from_up_layer(data)
receiver
snkpkt make_pkt(data, checksum) to_low_layer(snd
pkt)
from_low_layer(rcvpkt) isNAK(rcvpkt)
Wait for call from above
to_low_layer(sndpkt)
from_low_layer(rcvpkt) isACK(rcvpkt)
Wait for call from below
L
sender
from_low_layer(rcvpkt) notcorrupt(rcvpkt)
extract(rcvpkt,data) to_up_layer(data) to_low_laye
r(ACK)
35
V2.0 has a fatal flaw!

• What happens if ACK/NAK corrupted?
• sender doesnt know what happened at receiver!
• cant just retransmit possible duplicate

• Handling duplicates
• sender adds sequence number to each pkt
• sender retransmits current pkt if ACK/NAK garbled
• receiver discards (doesnt deliver up) duplicate
  pkt

36
V2.1 sender, handles garbled ACK/NAKs
from_up_layer(data)
sndpkt make_pkt(0, data, checksum) to_low_layer(
sndpkt)
sender
from_low_layer(rcvpkt) ( corrupt(rcvpkt)
isNAK(rcvpkt) )
Wait for call 0 from above
to_low_layer(sndpkt)
from_low_layer(rcvpkt) notcorrupt(rcvpkt)
isACK(rcvpkt)
from_low_layer(rcvpkt) notcorrupt(rcvpkt)
isACK(rcvpkt)
L
L
from_low_layer(rcvpkt) ( corrupt(rcvpkt)
isNAK(rcvpkt) )
from_up_layer(data)
sndpkt make_pkt(1, data, checksum) to_low_layer(
sndpkt)
to_low_layer(sndpkt)
37
V2.1 receiver, handles garbled ACK/NAKs
from_low_layer(rcvpkt) notcorrupt(rcvpkt)
has_seq0(rcvpkt)
receiver
extract(rcvpkt,data) to_up_layer(data) sndpkt
make_pkt(ACK, chksum) to_low_layer(sndpkt)
from_low_layer(rcvpkt) (corrupt(rcvpkt)
from_low_layer(rcvpkt) (corrupt(rcvpkt)
sndpkt make_pkt(NAK, chksum) to_low_layer(sndpkt
)
sndpkt make_pkt(NAK, chksum) to_low_layer(sndpkt
)
from_low_layer(rcvpkt) not corrupt(rcvpkt)
has_seq1(rcvpkt)
from_low_layer(rcvpkt) not corrupt(rcvpkt)
has_seq0(rcvpkt)
sndpkt make_pkt(ACK, chksum) to_low_layer(sndpkt
)
sndpkt make_pkt(ACK, chksum) to_low_layer(sndpkt
)
from_low_layer(rcvpkt) notcorrupt(rcvpkt)
has_seq1(rcvpkt)
extract(rcvpkt,data) to_up_layer(data) sndpkt
make_pkt(ACK, chksum) to_low_layer(sndpkt)
38
V2.1 discussion

• Sender
• seq added to pkt
• two seq. s (0,1) will suffice. Why?
• must check if received ACK/NAK corrupted
• twice as many states
• state must remember whether current pkt has 0
  or 1 seq.

• Receiver
• must check if received packet is duplicate
• state indicates whether 0 or 1 is expected pkt
  seq
• note receiver can not know if its last ACK/NAK
  received OK at sender

39
V2.2 a NAK-free protocol

• same functionality as V2.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

40
V2.2 sender, receiver fragments
from_up_layer(data)
sndpkt make_pkt(0, data, checksum) to_low_layer(
sndpkt)
from_low_layer(rcvpkt) ( corrupt(rcvpkt)
isACK(rcvpkt,1) )
to_low_layer(sndpkt)
sender FSM fragment
from_low_layer(rcvpkt) notcorrupt(rcvpkt)
isACK(rcvpkt,0)
from_low_layer(rcvpkt) (corrupt(rcvpkt)
has_seq1(rcvpkt))
receiver FSM fragment
L
to_low_layer(sndpkt)
from_low_layer(rcvpkt) notcorrupt(rcvpkt)
has_seq1(rcvpkt)
extract(rcvpkt,data) to_up_layer(data) sndpkt
make_pkt(ACK1, chksum) to_low_layer(sndpkt)
41
V3.0 channels with errors and loss(Simplex
protocol for a noisy channel)

• 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

42
V3.0 sender
from_up_layer(data)
from_low_layer(rcvpkt) ( corrupt(rcvpkt)
isACK(rcvpkt,1) )
sndpkt make_pkt(0, data, checksum) to_low_layer(
sndpkt) start_timer
L
from_low_layer(rcvpkt)
L
timeout
to_low_layer(sndpkt) start_timer
from_low_layer(rcvpkt) notcorrupt(rcvpkt)
isACK(rcvpkt,1)
from_low_layer(rcvpkt) notcorrupt(rcvpkt)
isACK(rcvpkt,0)
stop_timer
stop_timer
timeout
to_low_layer(sndpkt) start_timer
from_low_layer(rcvpkt)
L
from_up_layer(data)
from_low_layer(rcvpkt) ( corrupt(rcvpkt)
isACK(rcvpkt,0) )
sndpkt make_pkt(1, data, checksum) to_low_layer(
sndpkt) start_timer
L
43
V3.0 in action
44
V3.0 in action
45
Summary of simplex protocols

• V1.x low-layer is reliable, e.g., no corruption,
  no loss, but naturally limited buffer size in
  receiver
• V1.1 but need consider fast-sender-slow-receiver
  problem gt Stop-and-Wait with ACK
• V2.x low-layer may corrupt packets, but no
  packet loss
• V2.0 consider sending packet may be corrupted
  gtneed ACK/NAK
• V2.1 consider ACK/NAK may be also corrupted,
  which causes duplication problem gt need
  seq(0,1)
• V2.2 NAK-free version of V2.1 gt add seq in
  ACKs
• V3.0 low-layer may lose packets
• besides with seq in pkt and ACKs
• introduce timers to retransmit lost packets
• Receivers state/protocol is same as V2.2

46
Performance of V3.0

• V3.0 works, but performance stinks
• example 1 Gbps link, 15 ms(milliseconds) e-e
  prop. delay, 1KB packet

L (packet length in bits)
8kb
T


8 microsec
transmit
R (transmission rate, bps)
109 b/sec

• U sender utilization fraction of time sender
  busy sending
• 1KB pkt every 30 msec -gt 33kB/sec thruput over 1
  Gbps link
• network protocol limits use of physical resources!

47
V3.0 stop-and-wait operation
sender
receiver
first packet bit transmitted, t 0
last packet bit transmitted, t L / R
first packet bit arrives
RTT
last packet bit arrives, send ACK
ACK arrives, send next packet, t RTT L / R
48
Reliable end-end data transfer principle

• Simplex protocols
• Reliable channel V1.01.1
• Unreliable channel V2.0V3.0
• Pipelined protocols or Sliding window protocols
• Go Back N (GBN)
• Selective repeat

http//wps.aw.com/aw_kurose_network_3/0,9212,14063
48-,00.html
49
Pipelined protocols (Sliding window protocols)

• Pipelining sender allows multiple, in-flight,
  yet-to-be-acknowledged pkts
• range of sequence numbers must be increased
• buffering at sender and/or receiver

• Two generic forms of pipelined protocols
  go-Back-N, selective repeat

50
Go-Back-N

• Sender
• k-bit seq in pkt header
• window of up to N, consecutive unacked pkts
  allowed

• ACK(n) ACKs all pkts up to, including seq n -
  cumulative ACK
• may receive duplicate ACKs (see receiver)
• timer for each in-flight pkt (actual
  implementation may use one timer only for the
  first unacknowledged pkt)
• timeout(n) retransmit pkt with seq in range
  n, nextseqnum-1

51
GBN in action
What if pkt2 timeoutat this point ?
send pkt 1 send pkt 2 send pkt 3 send pkt 4
52
GBN in action
Q what relationship between seq range and
window size? A window size lt MAX_SEQ (e.g.,
3) Or seq range-1
Both of them will be ignored by the receiver!
53
GBN in action
Note if assume the packet delay is different, as
left picture illustrated, then this question is
meaningless.
Receive pkt 3 Receive pkt 0
Receive pkt 3 Receive pkt 0
54
GBN sender extended FSM
from_up_layer(data)
if (nextseqnum lt baseN) sndpktnextseqnum
make_pkt(nextseqnum,data,chksum)
to_low_layer(sndpktnextseqnum) if (base
nextseqnum) start_timer nextseqnum
else refuse_data(data)
Tanenbaum each packet has its own timer Here
one timer for the oldest unACKed packet, e.g.,
base gt result same
L
base1 nextseqnum1
timeout
start_timer to_low_layer(sndpktbase) to_low_laye
r(sndpktbase1) to_low_layer(sndpktnextseqnum
-1)
from_low_layer(rcvpkt) corrupt(rcvpkt)
L
from_low_layer(rcvpkt) notcorrupt(rcvpkt)
base getacknum(rcvpkt)1 If (base
nextseqnum) stop_timer else start_timer
55
GBN receiver extended FSM
any other packets come(without expectedseqnum)
to_low_layer(sndpkt)
from_low_layer(rcvpkt) notcurrupt(rcvpkt)
hasseqnum(rcvpkt,expectedseqnum)
Wait
L
extract(rcvpkt,data) to_up_layer(data) sndpkt
make_pkt(expectedseqnum,ACK,chksum) to_low_layer(s
ndpkt) expectedseqnum
expectedseqnum1 sndpkt
make_pkt(expectedseqnum,ACK,chksum)

• ACK-only always send ACK for correctly-received
  pkt with highest in-order seq
• may generate duplicate ACKs
• need only remember expectedseqnum
• out-of-order pkt
• discard (dont buffer) -gt no receiver buffering!
• Re-ACK pkt with highest in-order seq

What happen if ACK lost? Why receiver not use
timer?
56
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

57
Selective repeat sender, receiver windows
58
Selective repeat in action
59
Selective repeat

• data from above
• if next available seq in window, send pkt
• timeout(n)
• resend pkt n, restart timer
• ACK(n) in sendbase, sendbaseN
• mark pkt n as received
• if n is smallest unACKed pkt, advance window base
  to next unACKed seq
• Each pkt need its owner timer

• pkt n in rcvbase, rcvbaseN-1
• send ACK(n)
• out-of-order buffer
• in-order deliver (also deliver buffered,
  in-order pkts), advance window to next
  not-yet-received pkt
• pkt n in rcvbase-N, rcvbase-1
• ACK(n)
• otherwise
• ignore

60
Selective repeat dilemma

• Example
• seq s 0, 1, 2, 3, window size3
• receiver sees no difference in two scenarios!
• incorrectly passes duplicate data as new in (a)
• Q what relationship between seq range and
  window size?
• A window size lt (MAX_SEQ1)/2
• Or (seq range)/2

61
Summary of pipelined protocols

• Go-Back-N(GBN)
• Receiver discards out-of-order packets, and
  always ACKs correctly-received pkt with highest
  in-order seq
• Sender retransmits all unACKed packets when time
  out
• Selective repeat
• Receiver buffers out-of-order packets, and ACKs
  each of them
• Sender only retransmits those unACKed packets
  when time out
• The reliable data transfer protocols discussed so
  far consider
• Not duplex one is sender, the other is receiver
• Do not care network traffic condition, and set
  constant window size and constant timeout interval

62
Pipelining increased utilization
sender
receiver
first packet bit transmitted, t 0
last bit transmitted, t L / R
first packet bit arrives
RTT
last packet bit arrives, send ACK
last bit of 2nd packet arrives, send ACK
last bit of 3rd packet arrives, send ACK
ACK arrives, send next packet, t RTT L / R
Increase utilization by a factor of 3!
63
Roadmap Transport Layer

• Transport-layer services
• Multiplexing and demultiplexing
• Inside end-end data transfer
• UDP unreliable end-end data transfer,
  connectionless transport
• Reliable end-end data transfer principle
• Simplex protocols
• Pipelined protocols
• TCP reliable end-end data transfer,
  connection-oriented transport
• segment structure
• reliable data transfer solution and flow control
• connection management
• end-end congestion control
• Performance issues and refinement

64
TCP Transmission Control Protocol
RFCs 793, 1122, 1323, 2018, 2581

• point-to-point
• one sender, one receiver
• reliable, in-order byte stream
• no message boundaries
• pipelined
• TCP congestion and flow control set window size
• send receive buffers

• full duplex data
• bi-directional data flow in same connection
• MSS maximum segment size
• connection-oriented
• handshaking (exchange of control msgs) inits
  sender, receiver state before data exchange
• flow controlled
• sender will not overwhelm receiver

65
TCP segment structure
URG urgent data (generally not used)
counting by bytes of data (not segments!)
ACK ACK valid
PSH push data now (generally not used)
bytes rcvr willing to accept
RST, SYN, FIN connection estab (setup,
teardown commands)
Internet checksum (as in UDP)
66
TCP seq. s and ACKs

• Seq. s
• byte stream number of first byte in segments
  data
• ACKs
• seq of next byte expected from other side
• cumulative ACK
• Q how receiver handles out-of-order segments
• A TCP spec doesnt say, - up to implementor

Host B
Host A
User types CS
Seq42, ACK79, data CS
host ACKs receipt of CS, echoes back CS
Seq79, ACK44, data CS
host ACKs receipt of echoed CS
Seq44, ACK81
simple telnet scenario
67
TCP Round Trip Time and Timeout

• Q how to estimate RTT?
• SampleRTT measured time from segment
  transmission until ACK receipt
• ignore retransmissions
• SampleRTT will vary, want estimated RTT
  smoother
• average several recent measurements, not just
  current SampleRTT

• Q how to set TCP timeout value?
• longer than RTT
• but RTT varies
• too short premature timeout
• unnecessary retransmissions
• too long slow reaction to segment loss

68
TCP Round Trip Time and Timeout
EstimatedRTT ?EstimatedRTT (1- ?)SampleRTT

• exponential weighted moving average
• influence of past sample decreases exponentially
  fast
• typical value ? 0.875
• this algorithm is also called Jacobson algorithm

69
Example RTT estimation
70
TCP Round Trip Time and Timeout

• Setting the timeout
• EstimtedRTT plus safety margin
• large variation in EstimatedRTT -gt larger safety
  margin
• first estimate of how much SampleRTT deviates
  from EstimatedRTT

DevRTT ?DevRTT
(1-?)SampleRTT-EstimatedRTT (typically, ?
0.75)
Then set timeout interval
TimeoutInterval EstimatedRTT 4DevRTT
71
Roadmap Transport Layer

• Transport-layer services
• Multiplexing and demultiplexing
• Inside end-end data transfer
• UDP unreliable end-end data transfer,
  connectionless transport
• Reliable end-end data transfer principle
• Simplex protocols
• Pipelined protocols
• TCP reliable end-end data transfer,
  connection-oriented transport
• segment structure
• reliable data transfer solution and flow control
• connection management
• end-end congestion control
• Performance issues and refinement

72
TCP reliable data transfer

• TCP creates reliable service on top of IPs
  unreliable service ensures the received packets
  uncorrupted, without gaps, without duplication,
  and in sequence
• Pipelined segments
• Cumulative acks
• TCP uses single retransmission timer

• Retransmissions are triggered by
• timeout events
• duplicate acks
• Initially consider simplified TCP sender
• ignore duplicate acks
• ignore flow control, congestion control

73
TCP sender events

• data rcvd from app
• Create segment with seq
• seq is byte-stream number of first data byte in
  segment
• start timer if not already running (kind like the
  timer for the first unacked segment)
• expiration interval TimeOutInterval

• timeout
• retransmit segment that caused timeout (Notice
  not all the unACKed segments different from
  GBN)
• restart timer
• Ack rcvd
• If acknowledges previously unacked segments
• update what is known to be acked
• start timer if there are outstanding segments

74
TCP sender (simplified code )
NextSeqNum InitialSeqNum
SendBase 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 gt SendBase)
SendBase y if (there are
currently not-yet-acknowledged segments)
start timer
/ end of loop forever /

• Comment
• SendBase smallest seq of a transmitted but not
  unacknowledged byte. Hence, SendBase-1 last
  cumulatively acked byte
• NextSeqNum the seq of next byte to be sent
• Example
• SendBase-1 71 y 73, so the rcvr wants 73
  y gt SendBase means some new data are already acked

75
TCP retransmission scenarios
Host A
Host B
Host A
Host B
Seq92, 8 bytes data
Seq92, 8 bytes data
Seq100, 20 bytes data
ACK100
timeout
X
ACK100
ACK120
loss
Seq92, 8 bytes data
Sendbase 100
Seq92, 8 bytes data
SendBase 120
ACK120
Seq92 timeout
ACK100
SendBase 100
SendBase 120
time
lost ACK scenario
premature timeout
76
TCP retransmission scenarios (more)
Host A
Host B
Seq92, 8 bytes data
ACK100
Seq100, 20 bytes data
timeout
X
loss
ACK120
SendBase 120
time
Cumulative ACK scenario
77
TCP ACK generation RFC 1122, RFC 2581
TCP Receiver action Delayed ACK. Wait up to
500ms for next segment. If no next segment, send
ACK Immediately send single cumulative ACK,
ACKing both in-order segments Immediately send
duplicate ACK, indicating seq. of next
expected byte Immediate send ACK, provided
that segment starts at lower end of gap
Event at Receiver Arrival of in-order segment
with expected seq . All data up to expected seq
already ACKed Arrival of in-order segment
with expected seq . One other segment has ACK
pending Arrival of out-of-order
segment higher-than-expect seq. . Gap
detected Arrival of segment that partially or
completely fills gap
78
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

79
Fast retransmit algorithm
event ACK received, with ACK field value of y
if (y gt SendBase)
SendBase y
if (there are currently not-yet-acknowledged
segments) start
timer
else increment count
of dup ACKs received for y
if (count of dup ACKs received for y 3)
resend segment with
sequence number y

a duplicate ACK for already ACKed segment
fast retransmit
80
Discussion

• Compare to GBN and SR, whats the similarity and
  difference?
• Receiver buffers out-of-order packets like SR
• Receiver only ACKs the packets with highest
  in-order seq - like GBN
• Sender only retransmits the first timeouted and
  unACKed packets like SR
• Seq increments according to previous data size
• Other practical concerns initial seq, timeout
  value, connection management, flow control
  (through notifying RcvWindow), congestion control

81
TCP Flow Control

• receive side of TCP connection has a receive
  buffer

• speed-matching service matching the send rate to
  the receiving apps drain rate

• app process may be slow at reading from buffer

82
TCP Flow control how it works

• Rcvr advertises spare room by including value of
  RcvWindow in segments
• Sender limits unACKed data to RcvWindow
• guarantees receive buffer doesnt overflow

• (Suppose TCP receiver discards out-of-order
  segments)
• spare room in buffer
• RcvWindow
• RcvBuffer-LastByteRcvd - LastByteRead

83
TCP flow control example

• Window management in TCP.

84
Bad situations silly window syndrome

• Nagles Algo send first byte and buffer the
  rest
• Clarks Algo prevent receiver from sending
  1-byte window update

• Silly window syndrome.

85
Roadmap Transport Layer

• Transport-layer services
• Multiplexing and demultiplexing
• Inside end-end data transfer
• UDP unreliable end-end data transfer,
  connectionless transport
• Reliable end-end data transfer principle
• Simplex protocols
• Pipelined protocols
• TCP reliable end-end data transfer,
  connection-oriented transport
• segment structure
• reliable data transfer solution and flow control
• connection management
• end-end congestion control

86
Connection management

• It is surprisingly tricky than first glance
• Due to existence of delayed duplicates reqs and
  acks acks even harder to deal with
• Read Chapter 6.2.2 and 6.2.3 (Tanenbaum)

87
Connection Establishment
Three protocol scenarios for establishing a
connection using a three-way handshake. Both
sides choose itselfs low-order k bits of clock
rate as seq. (a) Normal operation, (b) Old
CONNECTION REQUEST appearing out of nowhere.
(c) Duplicate CONNECTION REQUEST and duplicate
ACK. Here CR denotes CONNECTION REQUEST.
three-way handshake no combination of old TPDUs
that can cause the protocol to fail and have a
connection setup by accident when no one wants it.
88
Connection Release
DR denotes DISCONNECT REQUEST

• Asymmetric release abrupt disconnection with
  loss of data.

89
Connection Release (2)

• The two-army problem.

90
Connection Release (3)
6-14, a, b

• Four protocol scenarios for releasing a
  connection.
• (a) Normal case of a three-way handshake.
• (b) final ACK lost.

91
Connection Release (4)

• (c) Response lost.
• (d) Response lost and subsequent DRs lost.
• Discussion what about if initial DR got lost for
  many retrys? Half-open

92
TCP Connection Establishment

• Recall TCP sender, receiver establish
  connection before exchanging data segments
• initialize TCP variables
• seq. s
• buffers, flow control info (e.g. RcvWindow)
• client connection initiator
• connect(clientSocket, srvaddr,
  sizeof(srvaddr))
• server contacted by client
• work_socket accept(serverSocket,
  srvaddr,addrlen)

93
TCP Connection Establishment

• Three way handshake
• Step 1 client host sends TCP SYN segment to
  server
• specifies initial seq
• no data
• Step 2 server host receives SYN, replies with
  SYNACK segment
• server allocates buffers
• specifies server initial seq.
• Step 3 client receives SYNACK, replies with ACK
  segment, which may contain data

client
server
connect
SYN1, SEQx
accept
SYN1,SEQy, ACKx1
SYN0, SEQx1, ACKy1 data
94
TCP Connection Release

• Closing a connection
• client closes socket
• close(clientSocket)
• Step 1 client end system sends TCP FIN control
  segment to server
• Step 2 server receives FIN, replies with ACK.
  Closes connection, sends FIN.

95
TCP Connection Release

• Step 3 client receives FIN, replies with ACK.
• Enters timed wait(30 sec2 min) - will respond
  with ACK to received FINs
• Step 4 server, receives ACK. Connection closed.

client
server
closing
FIN
ACK
closing
FIN
ACK
timed wait
closed
closed
96
TCP Connection Management (cont)
TCP server lifecycle
TCP client lifecycle
97
TCP Connection Management Modeling

• The states used in the TCP connection management
  finite state machine.

98
Suggestions

• Review Chapter 3