1. EEC-484 Computer Networks
Lecture 7
Wenbing Zhao
(Part of the slides are based on Drs. Kurose & Ross’s slides for their Computer Networking book)

2. Outline Administrative changes Reliable data transfer (continued)
Optional comprehensive final exam: May 7, 12:30-2:30pm
Lab: must be done individually, no more team work
Lab report and homework: blackboard only
Project#1 presentation:
March 24 (IP lab time), March 26 (data center tour time)
Project#2 presentation:
April 28, April 30
Reliable data transfer (continued)
Pipelining protocols
UDP, TCP (part I)
EEC484 Computer Networks

3. 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
Sender sends one packet,
then waits for receiver
response
stop and wait
EEC484 Computer Networks

4. rdt2.1: sender handles garbled ACK/NAKs
rdt_send(data)
sndpkt = make_pkt(0, data, checksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
( corrupt(rcvpkt) ||
isNAK(rcvpkt) )
Wait for ACK or NAK 0
Wait for call 0 from above
udt_send(sndpkt)
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt)
&& isACK(rcvpkt)
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt)
&& isACK(rcvpkt)
Stopped here for 1st session 10/1/2012 L L
Wait for ACK or NAK 1
Wait for
call 1 from above
rdt_rcv(rcvpkt) &&
( corrupt(rcvpkt) ||
isNAK(rcvpkt) )
rdt_send(data)
sndpkt = make_pkt(1, data, checksum)
udt_send(sndpkt)
udt_send(sndpkt)
EEC484 Computer Networks

5. rdt2.1: receiver handles garbled packets
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)
&& has_seq0(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
sndpkt = make_pkt(ACK, chksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) && (corrupt(rcvpkt)
rdt_rcv(rcvpkt) && (corrupt(rcvpkt)
sndpkt = make_pkt(NAK, chksum)
udt_send(sndpkt)
sndpkt = make_pkt(NAK, chksum)
udt_send(sndpkt)
Stopped here 10/2/2014 why does the receiver have to send ack in response to a duplicate data pkt
Wait for
0 from below
Wait for
1 from below
rdt_rcv(rcvpkt) &&
not corrupt(rcvpkt) &&
has_seq1(rcvpkt)
rdt_rcv(rcvpkt) &&
not corrupt(rcvpkt) &&
has_seq0(rcvpkt)
sndpkt = make_pkt(ACK, chksum)
udt_send(sndpkt)
sndpkt = make_pkt(ACK, chksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)
&& has_seq1(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
sndpkt = make_pkt(ACK, chksum)
udt_send(sndpkt)
EEC484 Computer Networks

6. rdt2.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
EEC484 Computer Networks

7. rdt2.2: a NAK-free protocol
Same functionality as rdt2.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
1/1/2019
EEC484 Computer Networks
Wenbing Zhao

8. rdt2.2: sender, receiver fragments
rdt_send(data)
sndpkt = make_pkt(0, data, checksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
( corrupt(rcvpkt) ||
isACK(rcvpkt,1) )
Wait for ACK
Wait for call 0 from above
udt_send(sndpkt)
sender FSM
fragment
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt)
&& isACK(rcvpkt,0)
rdt_rcv(rcvpkt) &&
(corrupt(rcvpkt) ||
has_seq1(rcvpkt)) L
Wait for
0 from below
receiver FSM
fragment
udt_send(sndpkt)
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)
&& has_seq1(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
sndpkt = make_pkt(ACK1, chksum)
udt_send(sndpkt)
1/1/2019
EEC484 Computer Networks
Wenbing Zhao

9. 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
1/1/2019
EEC484 Computer Networks
Wenbing Zhao

10. rdt3.0 sender L L L L rdt_send(data) rdt_rcv(rcvpkt) &&
( corrupt(rcvpkt) ||
isACK(rcvpkt,1) )
sndpkt = make_pkt(0, data, checksum)
udt_send(sndpkt)
start_timer
rdt_rcv(rcvpkt) L L
Wait for
call 0from above
Wait for ACK0
timeout
udt_send(sndpkt)
start_timer
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt)
&& isACK(rcvpkt,1)
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt)
&& isACK(rcvpkt,0)
stop_timer
stop_timer
Wait for ACK1
Wait for
call 1 from above
timeout
udt_send(sndpkt)
start_timer
rdt_rcv(rcvpkt) L
rdt_send(data)
rdt_rcv(rcvpkt) &&
( corrupt(rcvpkt) ||
isACK(rcvpkt,0) )
sndpkt = make_pkt(1, data, checksum)
udt_send(sndpkt)
start_timer L
1/1/2019
EEC484 Computer Networks
Wenbing Zhao

11. rdt3.0 in action
1/1/2019
EEC484 Computer Networks
Wenbing Zhao

12. rdt3.0 in action
1/1/2019
EEC484 Computer Networks
Wenbing Zhao

13. Performance of rdt3.0 rdt3.0 works, but performance stinks
ex: 1 Gbps link, 15 ms prop. delay, 8000 bit packet:
U sender: utilization – fraction of time sender busy sending
1KB pkt every 30 msec -> 33kB/sec thruput over 1 Gbps link
network protocol limits use of physical resources!
1/1/2019
EEC484 Computer Networks
Wenbing Zhao

14. Pipelined 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
EEC484 Computer Networks

15. 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!
EEC484 Computer Networks

16. Pipelining Protocols Go-back-N: big picture:
Sender can have up to N unacked packets in pipeline
Rcvr only sends cumulative acks
Doesn’t accept packet if there’s a gap
Sender has timer for oldest unacked packet
If timer expires, retransmit all unacked packets
Selective Repeat: big pic
Sender can have up to N unacked packets in pipeline
Rcvr acks individual packets
Sender maintains timer for each unacked packet
When timer expires, retransmit only unack packet
EEC484 Computer Networks

17. Go-Back-N Sender: k-bit seq # in pkt header
“window” of up to N consecutive unack’ed pkts allowed
The black bars as not usable sequence numbers are due to the windows size limit, NOT due to non-sequential receive concern!
ACK(n): ACKs all pkts up to, including seq # n - “cumulative ACK”
may receive duplicate ACKs (see receiver)
timer for oldest in-flight pkt
timeout(n): retransmit pkt n and all higher seq # pkts in window
EEC484 Computer Networks

18. GBN: Sender Extended FSM
rdt_send(data)
if (nextseqnum < base+N) {
sndpkt[nextseqnum] = make_pkt(nextseqnum,data,chksum)
udt_send(sndpkt[nextseqnum])
if (base == nextseqnum) // start timer if first unacked pkt
start_timer
nextseqnum++ }
else
refuse_data(data) L
base=1
nextseqnum=1
timeout
Wait
start_timer
udt_send(sndpkt[base])
udt_send(sndpkt[base+1]) …
udt_send(sndpkt[nextseqnum-1)
rdt_rcv(rcvpkt)
&& corrupt(rcvpkt)
rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
base = getacknum(rcvpkt)+1
If (base == nextseqnum) // no more unacked pkts
stop_timer
else
start_timer
EEC484 Computer Networks

19. GBN: Receiver Extended FSM
default
udt_send(sndpkt)
rdt_rcv(rcvpkt)
&& notcurrupt(rcvpkt)
&& hasseqnum(rcvpkt,expectedseqnum) L
Wait
expectedseqnum=1
sndpkt =
make_pkt(expectedseqnum,ACK,chksum)
extract(rcvpkt,data)
deliver_data(data)
sndpkt = make_pkt(expectedseqnum,ACK,chksum)
udt_send(sndpkt)
expectedseqnum++
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 (don’t buffer) -> no receiver buffering!
Re-ACK pkt with highest in-order seq #
EEC484 Computer Networks

20. GBN in action
EEC484 Computer Networks

21. 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
EEC484 Computer Networks

22. Selective Repeat: Sender, Receiver Windows
EEC484 Computer Networks

23. Selective Repeat Receiver Sender pkt n in [rcvbase, rcvbase+N-1]
data from above :
if next available seq # in window, send pkt
timeout(n):
resend pkt n, restart timer
ACK(n) in [sendbase,sendbase+N-1]:
mark pkt n as received
if n smallest unACKed pkt, advance window base to next unACKed seq #
pkt n in [rcvbase, rcvbase+N-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
EEC484 Computer Networks

24. Selective Repeat In Action
Stopped here 10/7/2014
EEC484 Computer Networks

25. Selective Repeat: Dilemma
Example:
seq #’s: 0, 1, 2, 3
window size=3
receiver sees no difference in two scenarios!
incorrectly passes duplicate data as new in (a)
Q: what relationship between seq # size and window size?
EEC484 Computer Networks

26. Non-Sequential Receive Problem
The problem is caused by the overlap of sequence number between the new receiving window and the old receiving window 1 2 3 4 5 6
Note: number buffers at receiver needs = w 1 2 3 4 5 6 7 1 2 3 4 5 6 7 1 2 3 4 5 6 7
Overlap
Overlap
EEC484 Computer Networks

27. Non-Sequential Receive Problem
Solution:
make sure no overlap when receiver advances its window
Make window size w =1/2 range of seq numbers 1 2 3 1 2 3 4 5 6 7 1 2 3 4 5 6 7 1 2 3 4 5 6 7
No Overlap
EEC484 Computer Networks

28. UDP: User Datagram Protocol
“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
Stop here 2/27/12
EEC484 Computer Networks

29. Why is There a UDP? No connection establishment (which can add delay)
Simple: no connection state at sender and receiver
Small segment header
No congestion control: UDP can blast away as fast as desired
EEC484 Computer Networks

30. UDP Other UDP uses Often used for streaming multimedia apps
Loss tolerant
Rate sensitive
Other UDP uses
DNS
SNMP
Reliable transfer over UDP: add reliability at application layer
32 bits
source port #
dest port #
Length, in
bytes of UDP
segment,
including
header
length
checksum
Simple Network Management Protocol (SNMP)
Application
data
(message)
UDP segment format
EEC484 Computer Networks

31. UDP Checksum
Goal: detect “errors” (e.g., flipped bits) in transmitted segment
Sender:
treat segment contents as 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 nonetheless?
Technical details for checksum computation not required
EEC484 Computer Networks

32. TCP: Overview Full duplex data: 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
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
1/1/2019
EEC484 Computer Networks
Wenbing Zhao

33. TCP: Overview
TCP connection is byte stream, not message stream, no message boundaries
TCP may send immediately or buffer before sending
Receiver stores the received bytes in a buffer
Stopped 10/3/2012 session 1
1/1/2019
EEC484 Computer Networks
Wenbing Zhao

34. TCP Segment Structure source port # dest port # application data
32 bits
application
data
(variable length)
sequence number
acknowledgement number
Receive window
Urg data pnter
checksum F S R P A U
head
len
not
used
Options (variable length)
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
Ask: why is there no length field?
Why receive window is there? Recall that TCP offers a duplex channel
Stop 10/2/2013
RST, SYN, FIN:
connection estab
(setup, teardown
commands)
A TCP segment must fit into an IP datagram!
Internet
checksum
(as in UDP)
1/1/2019
EEC484 Computer Networks
Wenbing Zhao 34

35. EEC-484: Computer Networks
The TCP Segment Header
Source port and destination port: identify local end points of the connection
Source and destination end points together identify the connection
Sequence number: identify the byte in the stream of data that the first byte of data in this segment represents
Acknowledgement number: the next sequence number that the sender of the ack expects to receive
Ack # = Last received seq num + 1
Ack is cumulative: e.g., an ack of 5 means 0-4 bytes have been received
TCP header length – number of 32-bit words in header
Ack#: instead of saying “I have received all bytes until ack#-1.”, we say: “the next expected byte number is ack#.”
1/1/2019
EEC-484: Computer Networks
Wenbing Zhao 35

36. The TCP Segment Header URG – indicates urgent pointer field is set
Urgent pointer – points to the seq num of the last byte in a sequence of urgent data
ACK – acknowledgement number is valid
SYN – used to establish a connection
Connection request: ACK = 0, SYN = 1
Connection confirm: ACK=1, SYN = 1
FIN – release a connection, sender has no more data
RST – reset a connection that is confused
PSH – sender asked to send data immediately
Taken from
The Urgent Pointer is used when some information has to reach the server ASAP. When the TCP/IP stack at the other end sees a packet using the Urgent Pointer, it is duty bound to stop all it's doing and immediately send this packet to the relevant server. Since the packet is plucked out of the processing queue and acted upon immediately, it is known as an Out Of Band (OOB) packet and the data is called Out Of Band (OOB) data. The Urgent Pointer is usually used in Telnet, where an immediate response (e.g. the echoing of characters) is desirable.
1/1/2019
EEC484 Computer Networks
Wenbing Zhao 36

37. The TCP Segment Header
Receiver window size –number of bytes that may be sent beyond the byte acked
Checksum – add the header, the data, and the conceptual pseudoheader as 16-bit words, take 1’s complement of sum
For more info:
Options – provides a way to add extra facilities not covered by the regular header
E.g., communicate buffer sizes during set up
1/1/2019
EEC484 Computer Networks
Wenbing Zhao

38. TCP Sequence Numbers and ACKs
Host A
Host B
Sequence numbers:
byte stream “number” of first byte in segment’s data
ACKs:
seq # of next byte expected from other side
cumulative ACK
User
types
‘C’
Seq=42, ACK=79, data = ‘C’
host ACKs
receipt of
‘C’, echoes
back ‘C’
For tcp, seq # usually does not start from 0. If it were, we could interpret seq # as how many number of bytes of payload have been sent previously
Seq=43: seq field contain the next expected number even if the segment does not contain any payload
Seq=79, ACK=43, data = ‘C’
host ACKs
receipt
of echoed
‘C’
Seq=43, ACK=80
time
simple telnet/ssh scenario
1/1/2019
EEC484 Computer Networks
Wenbing Zhao 38

39. EEC-484/584: Computer Networks
Homework 2, Problem #1
Q1. A process at host A wants to establish a TCP connection with another process at host B. Assuming that host A chooses to use 1628 as the initial sequence number, and host B chooses to use 3217 as the initial sequence number for this connection, show the segments involved with the connection establishment process. You must include the following information for each such segment: (1) sequence number, (2) acknowledgement number (if applicable), (3) the SYN flag bit status, and (4) the ACK flag bit status.
EEC-484/584: Computer Networks
Wenbing Zhao