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: channels with errors and loss (approach)
approach: sender waits “reasonable” amount of time for ACK
- retransmits if no ACK received in this time
- if ACK is just delayed (not lost):
* retransmission will be duplicate, but seq. #’ s already handles this
- requires countdown timer
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
Pipelined protocols: overview (Go-back-N)
Go-back-N:
- sender may have up to N unacked packets in pipeline (“window”)
- receiver only sends cumulative ack
- doesn’t ack packet if there’ s a gap
- sender has timer for oldest unacked packet
- when timer expires, retransmit all unacked
packets
- when timer expires, retransmit all unacked
Pipelined protocols: overview (Selective Repeat)
- sender can have up to N unack’ed packets in pipeline
- rcvr sends individual ack for each packet
- sender maintains timer for each unacked packet
- when timer expires, retransmit only that unacked packet)
