Transport Protocol Review



Overview



User datagram protocol (UDP)





Packet checksums





Reliability: sliding window

 

TCP connection setup



Transport protocols sit on top of the network layer (IP)

TCP windows, retransmissions, and

acknowledgments

Can provide:
- Application-level multiplexing (ports)
- Error detection, reliability, etc.

UDP user datagram protocol

0

16

31

SrcPort

DstPort

Length

Checksum
Data

Error detection
Transmission errors definitely happen
- Cosmic rays, radio interference, etc.
- If error probability is 230 , thats 1 error per 128 MB!

Some link-layer protocols provide error detection

- But UDP/IP must work over many link layers

Unreliable and unordered datagram service

Adds multiplexing, checksum on whole packet
No flow control, reliability, or order guarantees
Endpoints identified by ports
Checksum aids in error detection

- Not all links on a path may have error detection

- Moreover, recall end-to-end argument!
Need end-to-end check

UDP detects errors with a checksum

- Compute small checksum value, like a hash of the packet
- If packet corrupted in transit, checksum likely to be wrong
- Similar checksum on IP header, but doesnt cover payload

Checksum algorithms
Good checksum algorithms

UDP pseudo-header
0
1
2
3
01234567890123456789012345678901

- Should detect errors that are likely to happen

(E.g., should detect any single bit error)

Source IP address
Destination IP address

- Should be efficient to compute

IP, UDP, and TCP use 1s complement sum:

- Set checksum field to 0
- Sum all 16-bit words in pkt
- Add any carry bits back in
(So 0x8000 + 0x8000 = 0x0001)
- Flip bits (sum = ~sum;) to get checksum (0xf0f0 0x0f0f),
Unless sum is 0xffff, then checksum just 0xffff
- To check: Sum whole packet (including sum), should get 0xffff

Zero

Protocol (=17)
Source Port

UDP length

UDP Payload Destination Port

Checksum actually includes pseudo-header

- Not transmitted, just pre-pended to compute checksum
- Ensures UDP checksum includes IP addresses

Trick question: Is UDP a layer on top of IP?

Finite State Machines

How good is UDP/IP checksum?

+ Very fast to compute in software
- Same implementation works on big & little endian CPUs

16 bits is not very long (misses 1/216 errors)

+ Checksum does catch any 1-bit error
But not any two-bit error
- E.g., increment one word ending 0, decrement one ending 1

Represent protocols using state machines

- Sender and receiver each have a state machine

Checksum also optional on UDP

- Start in some initial state

- All 0s means no checksum calculated

- If checksum word gets wiped to 0 as part of error, bad news

Good thing most link layers have stronger checksums

Next problem: If you discard bad packets, how to
ensure reliable delivery? (E.g., stop & wait lab 1)

- Events cause each side to select a state transition

Transition specifies action taken

- Specified as events/actions
- E.g., software calls send/put packet on network
- E.g., packet arrives/send acknowledgment

Stop and wait FSMs

Receiver FSM:

Problems with Stop and Wait

Wait
for
Packets

receive packet

Might duplicate packet. . . how?

send ACK
deliver packet

Cant keep pipe full

Delay

Sender FSM:
Bandwidth

software called send

send packet

Wait
for
Data

Wait
for
ACK

timeout

- For full utilization want # bytes in flight bandwidthdelay

(But dont want to overload the network, either)

re-send packet

received ACK

Sender

Timeout

Timeout

ACK

Duplicates

ACK

Solve problem with 1-bit counter

Timeout

Fram

(a)

Timeout

Fram
e

Timeout

Fram

ACK

Fram

This still requires some simplifying

assumptions
- Network itself might duplicates packets
- Packet might be heavily delayed and
reordered
- Assume these dont happen for now

ACK

ACK

(d)

- But usually prefer weaker assumption:

Maximum Segment Lifetime (MSL)

Receiver

Fram

- Sender wont interpret duplicate old

ACK as for new packet

Receiver

Fram

Sender

- Receiver knows if duplicate of last frame

ACK

Sender

Timeout

Receiver

(b)

- Place in both Frame and ACK

(c)

Sender

Timeout

Time

Receiver

Fram

e0

ACK

Fram

e1

1
ACK

Fram

e0

0
ACK

Receiver

Fram

Time

Sender

Effect of RTT on performance

Sliding window protocol

Addresses problem of keeping the pipe full
- Generalize previous protocol with > 1-bit counter
- Allow multiple outstanding (unACKed) frames
- Upper bound on unACKed frames, called window

Time

Stop & wait goodput depends on Round-Trip Time (RTT)

Receiver

Sender

- Capped by packet size/RTT regardless of underlying link b/w

Need pipelineing for goodput to approach link throughput

SW sender
Assign sequence number to each frame (SeqNum)
Maintain three state variables:

SW receiver
Maintain three state variables

- Send Window Size (SWS)

- Last Acknowledgment Received (LAR)

- Receive Window Size (RWS)

- Last Frame Sent (LFS)

- Largest Acceptable Frame (LAF)

SWS

- Last Frame Received (LFR)

RWS

LAR

LFS
LFR

LAF

Maintain invariant: LFS LAR SWS

Advance LAR when ACK arrives

Maintain invariant: LAF LFR RWS

Buffer up to SWS frames

Sequence number space

SW receiver, continued
When frame # SeqNum arrives:
- if LFR < SeqNum LFA accept
- if SeqNum LFR or SeqNum > LFA discarded

Send cumulative ACKs

- I.e., ACK n means received all packets w. SeqNo n
- E.g., if received packets 1, 2, 3, 5, must ACK 3

Or can alternatively use TCP-style ACKs, which

specify first pkt. not received
- E.g., if received packets 1, 2, 3, 5, must ACK 4, not 3
- Note Labs 1 and 2 use TCP-style cumulative ACKs

How big should RWS be?

- At least 1. No bigger than SWS
(Dont accept a packet the sender shouldnt have sent)

How many distinct sequence numbers needed?

If RWS=1, need at least SWS+1
- This protocoal is often called Go-Back-N

If RWS=SWS, need at least 2SWS

- Otherwise, bad news if ACKs are lost
- Sender may retransmit a window that was already received
- Receiver will think retransmissions are from next window

Generally need at least RWS+SWS

- RWS packets in unknown state (ACK may/may not be lost)
- SWS packets in flight must not overflow sequence space

High-level view of TCP

2-minute stretch
Application process

Application process
Read
bytes

Write
bytes

TCP

TCP

Send buffer

Receive buffer

Segment

Segment

Segment

Transmit segments

Full duplex, connection-oriented byte stream

Flow control
- If one end stops reading, writes at other eventuall block/fail

Congestion control
- Keeps sender from overrunning network [more next lecture]

TCP fields

TCP segment
0
1
2
3
01234567890123456789012345678901
source port

destination port
sequence number

data
offset

urgent pointer

options

Seq no. segment position in byte stream

- Unlike Lab 1, sequence #s corresponds to bytes, not packets

Ack no. seq no. sender expects to receive next

acknowledgment number
UA P R S F
reserved R C S S Y I
Window
G K H T NN
checksum

Ports

padding
data

Data offset # of 4-byte header & option words

Window willing to receive
- Lets receiver limit SWS (possibly to 0) for flow control
(more in a few slides)

Checksum
Urgent pointer

TCP Flags
URG urgent data present
ACK ack no. valid (all but first segment)
PSH push data up to application immediately
RST reset connection
SYN synchronize establishes connection
FIN close connection

A TCP Connection (no data)

orchard.48150 > essex.discard:
S 1871560457:1871560457(0) win 16384
essex.discard > orchard.48150:
S 3249357518:3249357518(0) ack 1871560458 win 17376
orchard.48150 > essex.discard: . ack 1 win 17376
orchard.48150 > essex.discard: F 1:1(0) ack 1 win 17376
essex.discard > orchard.48150: . ack 2 win 17376
essex.discard > orchard.48150: F 1:1(0) ack 2 win 17376
orchard.48150 > essex.discard: . ack 2 win 17375

Connection establishment
Active participant
(client)

Connection termination

SYN,
Sequ
e

Passive participant
(server)

nceN

um =

x
,
m=y
ceNu
n
e
+1
u
Seq
t=x
,
n
K
e
C
+A
dgm
SYN
owle
Ackn
ACK,
Ackno
wledg
ment
=y+
1

Need SYN packet in each direction

- Typically second SYN also acknowledges first
- Supports simultaneous open, seldom used in practice

FIN bit says no more data to send

- Caused by close or shutdown on sending end
- Both sides must send FIN to close a connection

Typical close:
- A B: FIN, seq SA , ack SB
- B A: ack SA + 1
- B A: FIN, seq SB , ack SA + 1
- A B: ack SB + 1

If no program listening: server sends RST

Can also have simultaneous close

If server backlog exceeded: ignore SYN

After last message, can A and B forget about

closed socket?

If no SYN-ACK received: retry, timeout

State summary [RFC 793]

TIME WAIT
CLOSED
Active open/SYN

Problems with closed socket

Passive open

Close

- What if final ack is lost in the network?

Close

- What if the same port pair is immediately reused for a new

connection? (Old packets might still be floating around.)

Solution: active closer goes into TIME WAIT

LISTEN

Send/SYN
SYN/SYN + ACK
SYN/SYN + ACK

SYN_RCVD

- Active close is sending FIN before receiving one

- After receiving ACK and FIN, keep socket around for 2MSL
(twice the maximum segment lifetime)

ACK

ESTABLISHED

Close/FIN

Can pose problems with servers

- OS has too many sockets in TIME WAIT, slows things down
Hack: Can send RST and delete socket, set SO LINGER
socket option to time 0 (useful for benchmark programs)
- OS wont let you re-start server because port still in use
SO REUSEADDR option lets you re-bind used port number

Close/FIN

FIN/ACK

FIN_WAIT_1

CLOSE_WAIT
FIN/ACK

ACK

Close/FIN
FI

FIN_WAIT_2

/A

CLOSING

LAST_ACK

ACK Timeout after two

segment lifetimes

FIN/ACK

ACK
CLOSED

TIME_WAIT

Sliding window revisited

Sending data
Bulk data sent in MSS-sized segments

SYN_SENT

SYN + ACK/ACK

Receiving application

Sending application

- Chosen to avoid fragmentation (e.g., 1460 on ethernet LAN)

- Write of 8K might use 6 segmentsPSH set on last one
- PSH avoids unnecessary context switches on receiver

TCP

TCP
LastByteRead

LastByteWritten

Senders OS can delay sends to get full segments

- Nagle algorithm: Only one unacknowledged short segment
- TCP NODELAY option avoids this behavior

Segments may arrive out of order

- Sequence number used to reassemble in order

Window achieves flow control

- Receiver sets max window w. SO RCVBUF
- If window 0 and senders buffer full, write will block or
return EAGAIN

LastByteAcked

LastByteSent

NextByteExpected

(a)

LastByteRcvd

(b)

Used to guarantee reliable & in-order delivery

New: Used for flow control
- Instead of fixed window size, receiver sends
AdvertisedWindow in window field of TCP header

Next lecture: used for congestion control

- SWS = min(AdvertisedWindow, CongestionWindow)

A TCP connection (3 byte echo)

Path MTU discovery

Problem: How does TCP know what MSS to use?

orchard.38497 > essex.echo:

S 1968414760:1968414760(0) win 16384
essex.echo > orchard.38497:
S 3349542637:3349542637(0) ack 1968414761 win 17376
orchard.38497 > essex.echo: . ack 1 win 17376
orchard.38497 > essex.echo: P 1:4(3) ack 1 win 17376
essex.echo > orchard.38497: . ack 4 win 17376
essex.echo > orchard.38497: P 1:4(3) ack 4 win 17376
orchard.38497 > essex.echo: . ack 4 win 17376
orchard.38497 > essex.echo: F 4:4(0) ack 4 win 17376
essex.echo > orchard.38497: . ack 5 win 17376
essex.echo > orchard.38497: F 4:4(0) ack 5 win 17376
orchard.38497 > essex.echo: . ack 5 win 17375

Delayed ACKs
Goal: Piggy-back ACKs on data

- On local network, obvious, but for more distant machines?

Solution: Exploit ICMPanother protocol on IP

- ICMP for control messages, not intended for buik data
- IP supports DF (dont fragment) bit in IP header
- Set DF to get ICMP cant fragment when segment too big

Can do binary search on packet sizes

- But better: Base algorithm on most common MTUs
- Common algorithm may underestimate slightly (better
than overestimating and loosing packet)
- See RFC1191 for details

Is TCP a layer on top of IP?

Retransmission
TCP dynamically estimates round trip time

- Echo server just echoes, why send separate ack first?

If segment goes unacknowledged, must retransmit

- Can delay ACKs for 200 msec in case application sends data

Use exponential backoff (in case loss from

congestion)

- If more data received, immediately ACK second segment

- Note: Never delay duplicate ACKs (if segment out of order)

Warning: Can interact very badly with Nagle

- My login has 200 msec delays
- Set TCP NODELAY

After 10 minutes, give up and reset connection

Problem: Dont necessarily want to halt everything
for one lost packet
- Next lecture will explain fast retransmit optimization

Other details
Persist timer

32-bit seqno wrap around

- Sender can block because of 0-sized receive window

- Receiver may open window, but ACK message lost
- Sender keeps probing (sending one byte beyond window)

Keep-alives [RFC 1122]

- Detect dead connection even when no data to send
- E.g., remote login server, and client rebooted
- Solution: Send illegal segments with no data and already
acknowledged sequence number (SND.NXT-1)
- Or can include one byte of garbage data
- Remote side will RST (if rebooted), or timeout (if crashed)

Bandwidth
T1 (1.5 Mbps)

Time Until Wrap Around

6.4 hours

Ethernet (10 Mbps)

57 minutes

T3 (45 Mbps)

13 minutes

Ethernet (100 Mbps)

6 minutes

STS-3 (155 Mbps)

4 minutes

STS-12 (622 Mbps)

55 seconds

STS-24 (1.2 Gbps)

28 seconds

How to fill high bwdelay pipe? [RFC 1323]

Delay

Keeping the pipe full w. 100 msec delay

Bandwidth

Bandwidth

Delay Bandwidth Product

T1 (1.5 Mbps)

18KB

Extensions implemented as header options

Ethernet (10 Mbps)

122KB

T3 (45 Mbps)

549KB

- Multiplies window by fixed power of 2 in each direction

Ethernet (100 Mbps)

1.2MB

- Otherwise, could only fill pipe with 64 KB

STS-3 (155 Mbps)

1.8MB

STS-12 (622 Mbps)

7.4MB

STS-24 (1.2 Gbps)

14.8MB

Window scale option for 16-bit window field

Extend sequence space with 32-bit timestamp

- Protection Against Wrapped Sequence #s (PAWS)

Also include most recently received timestamp

- Allows much more accurate RTT estimation

Summary

Limitations of Flow Control

User datagram protocol (UDP)

Packet checksums
Reliability: sliding window
TCP connection setup
TCP sliding windows, retransmissions, and
acknowledgments
Using windows for flow control

Link may be the bottleneck

Sending too fast will cause heavy packet loss
Many retransmissions, lost acks, poor performance
Flow control provides correctness
Need more for performance: congestion control
(Next lecture. . . )