03-10-2012, 04:46 PM
TCP in Painful Detail
TCP in Painful.ppt (Size: 1.76 MB / Downloads: 24)
What TCP does for you (roughly)
UDP features: multiplexing + protection against corruption
ports, checksum
stream-based in-order delivery
segments are ordered according to sequence numbers
only consecutive bytes are delivered
reliability
missing segments are detected (ACK is missing) and retransmitted
flow control
receiver is protected against overload (window based)
congestion control
network is protected against overload (window based)
protocol tries to fill available capacity
connection handling
explicit establishment + teardown
full-duplex communication
e.g., an ACK can be a data segment at the same time (piggybacking)
Error Control: Retransmit Timeout (RTO)
Go-Back-N behavior in response to timeout
RTO timer value difficult to determine:
too long bad in case of msg-loss!
too short risk of false alarms!
General consensus: too short is worse than too long; use conservative estimate
RTO calculation
Problem: retransmission ambiguity
Segment #1 sent, no ACK received segment #1 retransmitted
Incoming ACK #2: cannot distinguish whether original or retransmitted segment #1 was ACKed
Thus, cannot reliably calculate RTO!
Solution [Karn/Partridge]: ignore RTT values from retransmits
Problem: RTT calculation especially important when loss occurs; sampling theorem suggests that RTT samples should be taken more often
Solution: Timestamps option
Sender writes current time into packet header (option)
Receiver reflects value
At sender, when ACK arrives, RTT = (current time) - (value carried in option)
Problems: additional header space; facilitates NAT detection
Silly Window Syndrome (SWS)
Consider telnet: slow typing =large header overhead
Solution: wait until segment isfilled at the sender(exception: PUSH bit)
But what about ls <return>?
Nagle algorithm: sender waitsuntil SMSS bytes can be sent
but 1 small segment /RTT allowed
A TCP implementation mustsupport disabling Nagle
Also, receiver mechanism:slowly reduce rwnd when less than a segment of incoming data until window boundary reached
Explicit Congestion Notification (ECN)
Active Queue Management
monitor queue, do not just drop upon overflow more intelligent decisions
maintain low average queue length, alleviate phase effects, enforce fairness
Explicit Congestion Notification (ECN)
Instead of dropping, set a bit; reduced loss major benefit!
Receiver informs sender about bit; sender behaves as if a packet was dropped
actual communication between end nodes and the network
Typical incentives:
sender = server; efficiently use connection, fairly distribute bandwidth
use ECN as it was designed
receiver = client; goal = high throughput, does not care about others
ignore ECN flag, do not inform sender about it
Need to make it impossible for receiver to lie about ECN flag when it was set
Solution: nonce = random number from sender, deleted by router when setting ECN
Sender believes „no congestion“ iff correct nonce is sent back