Error Control in TCP Simplified TCP Sender • Loss detection: sender based (Timer) switch (event) { - adaptive timeout calculation data received from application above: create TCP segment w/sequence number NextSeqNum - triple duplicate ACK if (timer not running) start timer • Acknowledgement: cumulative ACK pass segment to IP - sequence number: next octet that the receiver expects to get. NextSeqNum += length(data) - variable message length; retransmitted messages can include timer timeout: retranmit not-yet-acknowledged segment with more than the original. smallest sequence number • Retransmision: (no specification) start timer - until 1987: GBN ACK received, with ACK field value of y: - since 1987: Selective Retransmit if (y > SendBase) { - proposed modification: selective ACK SendBase = y if (not-yet-acknowledged segments) start timer } } Connection Management Connection Management • Connectionless vs. connection-oriented • Requirements: - no identifier reuse while copies of a PDU/ACK are alive. - identifiers from a previously terminated connections should • Connection: not cause a new connection to be opened/closed. association between a pair of protocol entities. - PDUs from previous connections should not be accepted. • Connection record: - graceful close state information about a particular connection (data • receiver: all possible retransmissions received and responded to them. structure at sender and receiver). • sender: received all ACKs of sent PDUs. • Connection identifier: • Problems: identifier for a particular connection. - reuse of connection id - limited storage (release of connection records) • Handshake-based or timer-based - crash
Connection Management in TCP Connection Management in GSM Connection state only in end nodes (intermediate Mobile Station Network nodes are not aware of the connection) ÚÄ Ä¿ broadcast � PAGING REQUEST � � <------------------------- � RR connection establishment � CHANNEL REQUEST � RR connection channel � -------------------------> � establishment � IMMEDIATE ASSIGNMENT � (MT) � <------------------------ � Connection Establishment: Connection Release: ÀÄ ÄÙ ÚÄ Ä¿ � PAGING RESPONSE � service request dedicated three-way handshake three-way handshake (graceful) � -------------------------> � Service request ÀÄ ÄÙ ÚÄ Ä¿ control � AUTHENTICATION REQUEST � Authentication initial sequence number = clock ... or abort � <------------------------- � authentication channel � AUTHENTICATION RESPONSE � � --------------------------> � ÀÄ ÄÙ ÚÄ Ä¿ � CIPHER MODE COMMAND � ciphering mode setting � <------------------------- � Ciphering [SYN] Seq=X � CIPHER MODE COMPLETE � mode setting [ F I N � --------------------------> � ] ÀÄ ÄÙ ÚÄ Ä¿ � SETUP � � <-------------------------- � Call initiation call initiation 1 � CALL CONFIRMED � + X = � --------------------------> � k c A ] K ÀÄ ÄÙ Y , C = q A [ ÚÄ Ä¿ e S ] K Y � ASSIGNMENT COMMAND � = C A q assignment of a traffic channel e � <-------------------------- � Assignment of N , S Y N ] S � ASSIGNMENT COMPLETE � [ I F Q , traffic � --------------------------> � E S [ ÀÄ ÄÙ ÚÄ Ä¿ [ACK] Ack=Y+1 channel user alerting information � ALERTING � � -------------------------> � User alerting [ACK] Ack=Y+W+1 ÀÄ ÄÙ information ÚÄ Ä¿ � CONNECT � call accepted � --------------------------> � Call accepted � CONNECT ACKNOWLEDGE � � <-------------------------- � ÀÄ ÄÙ Flow and Congestion Control Flow Control: Receive Window • Announce the receive window size to the sender. Flow Control Congestion Control Receiver busy Network congested Consequence: Packet loss Adapt send rate to not overwhelm the receiver (flow control) or the network (congestion control). Source: Kurose&Ross
Flow Control Leaky Bucket • Example: RTS/CTS in modem lines • Problem: control the send rate of data to conform • Receiver Window with specified average rate, peak rate, and burst rate. Receiver: RcvWindow = RcvBuffer - (LastByteRcvd - LastByteRead) Announce RcvWindow to the sender via ACKs. • Bucket can hold b tokens: Sender: LastByteSent - LastByteAcked � RcvWindow - generate r tokens per second Problem: RcvWindow=0 > no send > no ACK > ... - add the token to the bucket if it is not full • Rate Control: Leaky bucket • Packet arrives: - send if there is a token in the bucket, else wait until there is one - Remove one token from the bucket • burst rate: b packets • average rate over time t: tr + b Source: Kurose&Ross Congestion Control Sliding Window • How does a sender know when the network is congested (too much data in the network)? - Explicit (network assisted): feedback from the network - Implicit (end-to-end): acknowledgements > low traffic • Data from application: timeouts > loss in the network - assign nextseqnum to the packet - send if (nextseqnum < base + N) ?? mark as sent but not acknowledged S R - nextseqnum++; • ACK arrives: - if (ack >= base) base = ack + 1 (move window) R S mark all packets with (seqnum < base) as acknowledged - send all packets (seqnum < base + N) 24Mbit/s 1Gbit/s 100Mbit/s 56kbit/s mark them as sent but not acknowledged
Sliding Window Example Sliding Window at Receiver • Sliding-window (with Selective Retransmit) not sent sent, ACK:ed Free no ACK Action: ACK of oldest sent packet arrives Send Action: Application has more data to send Action: ACK arrives in the middle Send Send Action: Application has more data to send Send Action: ACK of already ACK:ed packet arrives Source: Kurose&Ross Sliding Window at Receiver Avoiding Packet Loss (Reminder) • Represents the maximum buffer size for segments • Be conservative about what you send and liberal received but still not red about what you receive. • If a segment that does not fit inside the window • Do not send data that will be lost due to... - a slow receiver arrives (either too new or too old), it is discarded. - a congested network However, an ACK is sent. • Do not inject more data than necessary • To avoid running out of buffer space, the receiver can - it increases the load on the network inform the sender about available buffer space in each • Typical approach: ACK. - keep track of the amount of outstanding data - estimate how much data can be in the pipe - do not put more data in the network than the estimate suggests.
Congestion Control in TCP Congestion Window in TCP • loss event: - Timeout (congestion) - 3 duplicate ACK (sporadic loss) • Congestion window W - loss event: reduce CongWindow significantly - ack: increase CongWindow - sendWindow = min{RecWindow, CongWindow} • Slow Start - W<Threshold: exponential growth (W=W+1 for every ACK) - W>Threshold: linear growth • Reaction to loss events - Timeout: Threshold=W/2; W=1; slow start until Threshold - 3 duplicate ACK: W=W/2 (fast recovery) Source: Kurose&Ross Fairness in TCP Source: Kurose&Ross
Recommend
More recommend