TCP: Transmission Control Protocol Flashcards
Principles of reliable data tranfer
Reliable data transfer: getting started
- incrementally develop sender, receiver sides of reliable data transfer protocol (rdt)
- consider only unidirectional data transfer
- but control info will flow on both directions!
- use finite state machines (FSM) to specify sender, receiver
rdt1.0: reliable transfer over a reliable channel
- underlying channel perfectly reliable
- no bit errors
- no loss of packets
- separate FSMs for sender, receiver:
- sender sends data into underlying channel
- receiver reads data from underlying channel
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 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 rdt2.0 (beyond rdt1.0):
- error detection
- feedback: control msgs (ACK,NAK) from receiver to sender
rdt2.0: FSM specification
rdt2.0: operation with no errors
rdt2.0: error scenario
rdt2.0 has a fatal flaw!
what happens if ACK/NAK corrupted?
- sender doesn’t know what happened at receiver!
- sender can’t just retransmit: possible duplicate
how can we handle duplicates?
- sender
* retransmits current pkt if ACK/NAK corrupted
* adds sequence number to each pkt
- receiver discards (doesn’ t deliver up) duplicate pkt
rdt2.1: outline (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 a pkt should have seq # of 0 or 1
rdt2.1: outline (receiver)
§ twice as many states here, too
§ must check if received packet is duplicate
* state indicates whether 0 or 1 is expected pkt seq #
rdt2.1: sender, handles garbled ACK/NAKs
rdt2.1: receiver, handles garbled ACK/NAKs
rdt2.2: a NAK-free protocol
- same functionality as rdt2.1, but 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
rdt2.2: sender, receiver fragments
rdt3.0: channels with errors and loss (new assumption)
underlying channel may also lose packets (data, ACKs)
* checksum, seq. #, ACKs, retransmissions will be of help … but not enough
rdt3.0 sender
rdt 3.0 in action
Performance of rdt3.0
- rdt3.0 is correct, but performance stinks
- transport protocol severely limits potential of
network!
rdt3.0: stop-and-wait operation
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
Pipelining: increased utilization
TCP segment structure
TCP seq. numbers, ACKs
sequence numbers:
* byte stream “index” of first byte in segment’s data
acknowledgements:
* seq # of next byte expected from other side
* cumulative ACK
Q: how receiver handles out-of-order segments
A: TCP spec doesn’t say,
- up to implementor
TCP fast retransmit (a quick example of one TCP optimization)
- time-out period is often relatively long:
- so, long delay before resending lost packet
- as we know, we detect lost segments via
duplicate ACKs.- sender often sends many segments backto-back
- if segment is lost, there will likely be many
duplicate ACKs.
TCP fast retransmit
