Chapter 3 outline. TDTS06 Computer networks. Principles of Reliable data transfer. Reliable data transfer: getting started

Transcription

1 Chapter 3 outline TDTS06 Computer networks Lecture 4: Transport layer II Reliable data delivery and TCP Jose M. Peña, jospe@ida.liu.se IDA/ADIT, LiU Transport-layer services 3.2 Multiplexing and demultiplexing 3.3 Connectionless transport: UDP 3.4 Principles of reliable data transfer 3.5 Connection-oriented transport: TCP segment structure reliable data transfer flow control connection management 3.6 Principles of congestion control 3.7 TCP congestion control * Slides are modified from J. F. Kurose and K. W. Ross. Principles of Reliable data transfer Reliable data transfer: getting started important in app., transport, link layers top-10 list of important networking topics! rdt_send(): called from, (e.g., by app.). Passed data to deliver to upper layer deliver_data(): called by rdt to deliver data to upper send side receive side characteristics of unreliable channel will determine complexity of reliable data transfer protocol (rdt) udt_send(): called by rdt, to transfer packet over unreliable channel to rdt_rcv(): called when packet arrives on rcv-side of channel Reliable data transfer: getting started Rdt1.0: reliable transfer over a reliable channel We ll: incrementally develop, 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, event causing state transition actions taken on state transition state: when in this state next state uniquely determined by next event state 1 event actions state 2 underlying channel perfectly reliable no bit errors no loss of packets separate FSMs for, : sends data into underlying channel read data from underlying channel packet = make_pkt(data) udt_send(packet) rdt_rcv(packet) extract (packet,data) 1

2 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): explicitly tells that pkt received OK negative acknowledgements (NAKs): explicitly tells that pkt had errors retransmits pkt on receipt of NAK new mechanisms in rdt2.0 (beyond rdt1.0): error detection feedback: control msgs (ACK,NAK) rcvr-> rdt2.0: FSM specification snkpkt = make_pkt(data, checksum) NAK isack(rcvpkt) isnak(rcvpkt) corrupt(rcvpkt) udt_send(nak) notcorrupt(rcvpkt) udt_send(ack) rdt2.0: operation with no errors snkpkt = make_pkt(data, checksum) NAK isnak(rcvpkt) corrupt(rcvpkt) udt_send(nak) rdt2.0: error scenario snkpkt = make_pkt(data, checksum) NAK isnak(rcvpkt) corrupt(rcvpkt) udt_send(nak) isack(rcvpkt) isack(rcvpkt) notcorrupt(rcvpkt) udt_send(ack) notcorrupt(rcvpkt) udt_send(ack) rdt2.0 has a fatal flaw! rdt2.1:, handles garbled ACK/NAKs What happens if ACK/NAK corrupted? doesn t know what happened at! can t just retransmit: possible duplicate (the can t know whether it is new data or retransmission) Handling duplicates: retransmits current pkt if ACK/NAK garbled adds sequence number to each pkt discards (doesn t deliver up) duplicate pkt stop and wait Sender sends one packet, then waits for response && isack(rcvpkt) isnak(rcvpkt) ) sndpkt = make_pkt(0, data, checksum) call 0 from NAK 1 NAK 0 call 1 from isnak(rcvpkt) ) && isack(rcvpkt) sndpkt = make_pkt(1, data, checksum) 2

3 rdt2.1:, handles garbled ACK/NAKs rdt2.1: discussion (corrupt(rcvpkt) sndpkt = make_pkt(nak, chksum) not corrupt(rcvpkt) && has_seq1(rcvpkt) sndpkt = make_pkt(ack, chksum) notcorrupt(rcvpkt) && has_seq0(rcvpkt) sndpkt = make_pkt(ack, chksum) 0 from 1 from notcorrupt(rcvpkt) && has_seq1(rcvpkt) sndpkt = make_pkt(ack, chksum) (corrupt(rcvpkt) sndpkt = make_pkt(nak, chksum) not corrupt(rcvpkt) && has_seq0(rcvpkt) sndpkt = make_pkt(ack, chksum) Don t deliver the data: It is retransmission. 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 current pkt has 0 or 1 seq. # Receiver: must check if received packet is duplicate state indicates whether 0 or 1 is expected pkt seq # note: can not know if its last ACK/NAK received OK at rdt2.2: a NAK-free protocol rdt2.2:, fragments same functionality as rdt2.1, using ACKs only instead of NAK, sends ACK for last pkt received OK must explicitly include seq # of pkt being ACKed duplicate ACK at results in same action as NAK: retransmit current pkt (corrupt(rcvpkt) has_seq1(rcvpkt)) sndpkt = make_pkt(0, data, checksum) call 0 from 0 from ACK 0 FSM fragment FSM fragment notcorrupt(rcvpkt) && has_seq1(rcvpkt) sndpkt = make_pkt(ack1, chksum) isack(rcvpkt,1) ) && isack(rcvpkt,0) rdt3.0: channels with errors and loss New assumption: underlying channel can also lose packets (data or ACKs) checksum, seq. #, ACKs, retransmissions will be of help, but not enough Approach: waits reasonable amount of for ACK retransmits if no ACK received in this if pkt (or ACK) just delayed (not lost): retransmission will be duplicate, but use of seq. # s already handles this must specify seq # of pkt being ACKed requires countdown r rdt3.0 call 0from && isack(rcvpkt,1) stop_r isack(rcvpkt,0) ) sndpkt = make_pkt(0, data, checksum) Wait for ACK1 Wait for ACK0 call 1 from sndpkt = make_pkt(1, data, checksum) isack(rcvpkt,1) ) && isack(rcvpkt,0) stop_r All the burden of detecting lost packets and recovering is on the : rdt2.2 still works fine. 3

4 rdt3.0 in action rdt3.0 in action Performance of rdt3.0 rdt3.0 works, but performance stinks ex: 1 Gbps link, 15 ms prop. delay, 8000 bit packet: d trans U : utilization fraction of busy sending U = L 8000bits = = R 10 bps 9 = L / R RTT + L / R = 8microseconds = KB pkt every 30 msec -> 33kB/sec thruput over 1 Gbps link network protocol limits use of physical resources! rdt3.0: stop-and-wait operation first packet bit transmitted, t = 0 last packet bit transmitted, t = L / R RTT ACK arrives, send next packet, t = RTT + L / R U = L / R RTT + L / R = first packet bit arrives last packet bit arrives, send ACK = Pipelined protocols Pipelining: allows multiple, in-flight, yet-tobe-acknowledged pkts range of sequence numbers must be increased buffering at and/or Pipelining: increased utilization first packet bit transmitted, t = 0 last bit transmitted, t = L / R RTT ACK arrives, send next packet, t = RTT + L / R first packet bit arrives last packet bit arrives, send ACK last bit of 2 nd packet arrives, send ACK last bit of 3 rd packet arrives, send ACK Two generic forms of pipelined protocols: go-back-n, selective repeat U = 3 * L / R RTT + L / R = = Increase utilization by a factor of 3! 4

5 Go-Back-N Sender: k-bit seq # in pkt header window of up to N, consecutive unack ed pkts allowed ACK(n): ACKs all pkts up to, including seq # n - cumulative ACK may receive duplicate ACKs (see ) r for each in-flight pkt (n): retransmit pkt n and all higher seq # pkts in window GBN: extended FSM base=1 nextseqnum=1 && corrupt(rcvpkt) if (nextseqnum < base+n) { sndpkt[nextseqnum] = make_pkt(nextseqnum,data,chksum) udt_send(sndpkt[nextseqnum]) if (base == nextseqnum) nextseqnum++ } else refuse_data(data) Wait notcorrupt(rcvpkt) base = getacknum(rcvpkt)+1 If (base == nextseqnum) stop_r else udt_send(sndpkt[base]) udt_send(sndpkt[base+1]) udt_send(sndpkt[nextseqnum-1]) Cumulative ack: Think that some acks may get lost. GBN: extended FSM default expectedseqnum=1 sndpkt = make_pkt(0,ack,chksum) Wait && notcurrupt(rcvpkt) && hasseqnum(rcvpkt,expectedseqnum) sndpkt = make_pkt(expectedseqnum,ack,chksum) expectedseqnum++ GBN in action ACK-only: always send ACK for correctly-received pkt with highest in-order seq # may generate duplicate ACKs need only remember expectedseqnum out-of-order pkt: discard (don t buffer) -> no buffering! Re-ACK pkt with highest in-order seq # Selective Repeat Selective repeat:, windows individually acknowledges all correctly received pkts buffers pkts, as needed, for eventual in-order delivery to upper layer only resends pkts for which ACK not received r for each unacked pkt window N consecutive seq # s again limits seq #s of sent, unacked pkts 5

6 Selective repeat Selective repeat in action data from : if next available seq # in window, send pkt (n): resend pkt n, restart r ACK(n) in [sendbase,sendbase+n]: mark pkt n as received if n smallest unacked pkt, advance window base to next unacked seq # pkt n in [rcvbase, rcvbase+n-1] send ACK(n) out-of-order: buffer in-order: deliver (also deliver buffered, in-order pkts), advance window to next not-yet-received pkt pkt n in [rcvbase-n,rcvbase-1] ACK(n) otherwise: ignore Think that the original ack may have got lost. Selective repeat: dilemma Example: seq # s: 0, 1, 2, 3 window size=3 sees no difference in two scenarios! incorrectly passes duplicate data as new in (a) Q: what relationship between seq # size and window size? socket door TCP: Overview RFCs: 793, 1122, 1323, 2018, 2581 point-to-point: one, one reliable, in-order byte steam: no message boundaries pipelined: TCP congestion and flow control set window size send & receive buffers application writes data TCP send buffer segment application reads data TCP receive buffer full duplex data: bi-directional data flow in same connection MSS: maximum segment size connection-oriented: handshaking (exchange of control msgs) init s, state before data exchange flow controlled: will not overwhelm socket door TCP segment structure URG: urgent data (generally not used) ACK: ACK # valid PSH: push data now (generally not used) RST, SYN, FIN: connection estab (setup, teardown commands) Internet checksum (as in UDP) 32 bits source port # dest port # sequence number acknowledgement number head not UAP R SF Receive window len used checksum Urg data pnter Options (variable length) application data (variable length) counting by bytes of data (not segments!) # bytes rcvr willing to accept TCP seq. # s and ACKs Seq. # s: byte stream number of first byte in segment s data ACKs: seq # of next byte expected from other side cumulative ACK Q: how handles out-of-order segments A: TCP spec doesn t say, - up to implementor User types C host ACKs receipt of echoed C This does not change if out-of-order segments arrive. simple telnet scenario host ACKs receipt of C, echoes back C 6

7 TCP Round Trip Time and Timeout Q: how to set TCP value? longer than RTT but RTT varies too short: premature unnecessary retransmissions too long: slow reaction to segment loss Q: how to estimate RTT? SampleRTT: measured from segment transmission until ACK receipt ignore retransmissions SampleRTT will vary, want estimated RTT smoother average several recent measurements, not just current SampleRTT TCP Round Trip Time and Timeout EstimatedRTT = (1- α)*estimatedrtt + α*samplertt Exponential weighted moving average influence of past sample decreases exponentially fast typical value: α = RTT (milliseconds) RTT: gaia.cs.umass.edu to fantasia.eurecom.fr (seconnds) SampleRTT Estimated RTT TCP Round Trip Time and Timeout Setting the EstimtedRTT plus safety margin large variation in EstimatedRTT -> larger safety margin first estimate of how much SampleRTT deviates from EstimatedRTT: DevRTT = (1-β)*DevRTT + β* SampleRTT-EstimatedRTT (typically, β = 0.25) Then set interval: TCP reliable data transfer TCP creates rdt service on top of IP s unreliable service Pipelined segments Cumulative acks TCP uses single retransmission r Retransmissions are triggered by: events duplicate acks Initially consider simplified TCP : ignore duplicate acks ignore flow control, congestion control TimeoutInterval = EstimatedRTT + 4*DevRTT TCP events: data rcvd from app: Create segment with seq # seq # is byte-stream number of first data byte in segment start r if not already running (think of r as for oldest unacked segment) expiration interval: TimeOutInterval : retransmit segment that caused restart r Ack rcvd: If acknowledges previously unacked segments update what is known to be acked start r if there are outstanding segments NextSeqNum = InitialSeqNum SendBase = InitialSeqNum loop (forever) { switch(event) event: data received from application create TCP segment with sequence number NextSeqNum if (r currently not running) start r (with estimated TimeOutInterval) pass segment to IP NextSeqNum = NextSeqNum + length(data) event: r retransmit not-yet-acknowledged segment with smallest sequence number (i.e. sendbase) start r (with double the previous TimeOutInterval) event: ACK received, with ACK field value of y if (y > SendBase) { SendBase = y if (there are currently not-yet-acknowledged segments) start r (with estimated TimeOutInterval) } } /* end of loop forever */ TCP (simplified) Comment: SendBase-1: last cumulatively ack ed byte Example: SendBase-1 = 71; y= 73, so the rcvr wants 73+ ; y > SendBase, so that new data is acked 7

8 TCP: retransmission scenarios TCP retransmission scenarios (more) X loss Seq=92 X loss SendBase = 100 Needed!!! lost ACK scenario Sendbase = 100 SendBase = 120 SendBase = 120 Seq=92 No needed, but unavoidable. Seq=100 no retransmitted. premature SendBase = 120 Cumulative ACK scenario TCP ACK generation [RFC 1122, RFC 2581] Fast Retransmit Event at Receiver Arrival of in-order segment with expected seq #. All data up to expected seq # already ACKed Arrival of in-order segment with expected seq #. One other segment has ACK pending Arrival of out-of-order segment higher-than-expect seq. #. Gap detected Arrival of segment that partially or completely fills gap TCP Receiver action Delayed ACK. Wait up to 500ms for next segment. If no next segment, send ACK Immediately send single cumulative ACK, ACKing both in-order segments Immediately send duplicate ACK, indicating seq. # of next expected byte Immediate send ACK, provided that segment starts at lower end of gap Time-out period often relatively long: long delay before resending lost packet Detect lost segments via duplicate ACKs. Sender often sends many segments back-toback If segment is lost, there will likely be many duplicate ACKs. If receives 3 ACKs for the same data, it supposes that segment after ACKed data was lost: fast retransmit: resend segment before r expires Arrival of segment with smaller-than-expected seq# Repeat latest ACK Fast retransmit algorithm: X event: ACK received, with ACK field value of y if (y > SendBase) { SendBase = y if (there are currently not-yet-acknowledged segments) start r } else { increment count of dup ACKs received for y if (count of dup ACKs received for y = 3) { resend segment with sequence number y } Figure 3.37 Resending a segment after triple duplicate ACK a duplicate ACK for already ACKed segment fast retransmit (no waiting for ) 8