Computer Networks. 3.Transport Layer. Transport Layer - 1

Transcription

1 Computer Networks 3.Transport Layer Transport Layer - 1

2 Transport services and protocols End-to-end protocol Logical communication between app processes Segmentation of messages Send side: breaks app messages into segments; Passes to network layer Receive side: reassembles segments into messages; Passes to application layer Multiplexing application transport network data link physical network data link physical Usual transport protocols Internet: TCP and UDP (restricted functionality) network data link physical network data link physical network data link physical network data link physical application transport network data link physical Transport Layer - 2

3 Internet transport-layer protocols Transport layer provides communication between application processes Network layer: between hosts Reliable, in-order delivery (TCP) connection setup flow control (receiver may slowdown sender) congestion control (against overall overload) Unreliable, unordered delivery (UDP) no-frills extension of best-effort IP Services not available in any of them Quality of Service (QoS) such as delay and bandwidth guarantees Real-time Transport Protocol (RTP) Application process Write bytes Origins at the vat audio conferencing tool s application protocol RTP is a transport protocol, running over the usual transport protocols, typically over UDP TCP Send buffer Segment Segment Segment Transmit segments Application process TCP Receive buffer Read bytes Transport Layer - 3

4 Multiplexing/demultiplexing Multiplexing at send host: Gathering data from multiple sender processes, enveloping data with header (needed for demultiplexing) Demultiplexing at rcv host: Delivering received segments to correct receiver process A channel of level i used by multiple sub-channels of level i+1 The multiplexed messages must be marked ( colored ) At demultiplexing the marks denote the sub-channel 3 sub-channels in 1 message with header (black) Transport Layer - 4

5 How demultiplexing works Host receives IP datagrams Each datagram has source and destination IP address Each datagram carries 1 TL-segment Each segment has source and destination port number Host uses IP address & port number to direct segment to appropriate socket Connection-oriented (TCP) demultipl. Own socket for each sub-channel, denoted by destination and source IP address and port number (4-tupel) Connectionless (UDP) demultiplexing Uses only the destination IP and port: Demux must be done by application 32 bits source port # dest port # other header fields application data (message) TCP/UDP segment format Transport Layer - 5

6 Connection-oriented (TCP) demux Server host may support many simultaneous TCP sockets: Sockets identified by own 4-tuple (source-ip, dest-ip, source-port, dest-port) E.g. Web servers have different sockets for each connecting client Non-persistent HTTP has different socket for each request P2 P3 P4 P1P1 SP: 80 DP: 9157 SP: 80 DP: 5775 SP: 9157 SP: 5775 client IP: A DP: 80 server IP: C DP: 80 Client IP:B Transport Layer - 6

7 Connectionless (UDP) demultiplexing IP datagrams with different source IP addresses and/or source port numbers are directed to the same socket Demultiplexing must be done by the application DatagramSocket serversock = new DatagramSocket(6428); P2 P3 P1P1 SP: 6428 DP: 9157 SP: 6428 DP: 5775 client IP: A SP: 9157 DP: 6428 SP provides return address server IP: C SP: 5775 DP: 6428 Client IP:B Transport Layer - 7

8 Principles of Reliable data transfer Important in application, transport and link layers Top-10 list of important networking topics! Task of reliable data transfer protocol (rdt): unreliable reliable Complexity depends on the characteristics of the unreliable channel Transport Layer - 8

9 Reliable transfer over a reliable channel Underlying channel perfectly reliable No bit errors No loss of packets Separate FSMs for sender, receiver: Just send/receive data into/from underlying channel FSM (Finite State Machine) Usual tool for specification of protocol states Causing event Wait for call from above rdt_send(data) packet = make_pkt(data) udt_send(packet) Wait for call from below rdt_rcv(data) extract (packet,data) deliver_data(data) sender Actions taken To higher level receiver Transport Layer - 9

10 Channels with errors and loss Underlying channel can have errors Corrupt packets (flip or loose bits) Lose packets But: no reordering for the first! Checksum, sequence numbers (seq #), acknowledgments (ACKs), retransmissions will be of help, but not enough Alternating-bit protocol After sending a packet, sender sets a time limit and waits until either an ACK arrives or a time out interrupt happens The receiver sends positive acknowledgments (ACK) for all packets Sender retransmits packets, if ACK does not arrives in time We enumerate the packets (0 and 1), to enable the receiver to distinct duplicates from originals Transport Layer - 10

11 Alternating-bit protocol sender rdt_rcv(rcvpkt) Λ rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isack(rcvpkt,1) stop_timer timeout udt_send(sndpkt) start_timer rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) isack(rcvpkt,0) ) Λ Wait for call 0 from above Wait for ACK1 rdt_send(data) sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt) start_timer Wait for ACK0 Wait for call 1 from above rdt_send(data) sndpkt = make_pkt(1, data, checksum) udt_send(sndpkt) start_timer rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) isack(rcvpkt,1) ) Λ timeout udt_send(sndpkt) start_timer rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isack(rcvpkt,0) stop_timer rdt_rcv(rcvpkt) Λ No-action Transport Layer - 11

12 Alternating-bit protocol in action (1) time Transport Layer - 12

13 Alternating-bit protocol in action (2) Transport Layer - 13

14 Performance of Alternating-bit protocol Alternating-bit protocol works, but performance is poor Example: 1 Gbps link, 15 ms e-e prop. delay, 1KB packet: T transmit = L (packet length in bits) R (transmission rate, bps) = 8*10 3 b 10 9 b/sec = 8 microsec U sender = L / R RTT + L / R =.008 ms ms = U sender : utilization fraction of time sender busy sending 1KB packet every 30 msec 270 Kbps throughput over 1 Gbps link Network protocol limits use of physical resources! Transport Layer - 14

15 Alt.-bit protocol: stop-and-wait operation first packet bit transmitted, t = 0 last packet bit transmitted, t = L / R sender receiver RTT first packet bit arrives last packet bit arrives, send ACK ACK arrives, send next packet, t = RTT + L / R U sender = L / R RTT + L / R = = Transport Layer - 15

16 Pipelined protocols Sender allows multiple, in-flight, yet-to-be-acknowledged packets Range of sequence numbers must be increased Buffering at sender and/or receiver Two generic forms of pipelined protocols go-back-n, selective repeat Transport Layer - 16

17 Pipelining: increased utilization first packet bit transmitted, t = 0 last bit transmitted, t = L / R sender receiver 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 Increase utilization by a factor of 3! U sender = 3 * L / R RTT + L / R = = Transport Layer - 17

18 Go-Back-N Sender k-bit sequence number (seq #) in packet header (modulo 2 k arithmetic) Sliding window of up to N ( 2 k ), consecutive unack ed pkts allowed ACK(i) ACKs all packets up to, including sequence number i: cumulative ACK Timer for each in-flight packet Maybe implemented by a single timer for the oldest sent but unack ed pkt Timeout(i) Retransmit packets in the range [i.. nextseqnum-1] (i = base, if only 1 timer) Laszlo Böszörmenyi Computer Networks Transport Layer - 18

19 GBN: sender extended FSM rdt_send(data) Initialization Λ base=0 nextseqnum=0 rdt_rcv(rcvpkt) && (corrupt(rcvpkt) base > getacknum(rcvpkt)) Λ if (nextseqnum < base+n) { // inside window? sndpkt[nextseqnum] = make_pkt(nextseqnum,data,chksum) udt_send(sndpkt[nextseqnum]) if (base == nextseqnum) { // Use a single timer start_timer // at the low edge of the window } nextseqnum++ } else // outside window refuse_data(data) // Let us assume a greedy app. Wait timeout start_timer udt_send(sndpkt[base]) udt_send(sndpkt[base+1]) udt_send(sndpkt[nextseqnum-1]) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && base <= getacknum(rcvpkt) // ACK is received base = getacknum(rcvpkt)+1 // Window slides If (base == nextseqnum) stop_timer // No unack ed pkt else start_timer // Still unack ed Transport Layer - 19

20 GBN: receiver extended FSM Λ expectedseqnum=0 Wait sndpkt = make_pkt(expectedseqnum,ack,chksum) No correctly received packet // resend ACK udt_send(sndpkt) rdt_rcv(rcvpkt) // Packet correctly received && notcurrupt(rcvpkt) && hasseqnum(rcvpkt, expectedseqnum) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(expectedseqnum, ACK, chksum) udt_send(sndpkt) expectedseqnum++ Send ACK for each correct pkt with highest in-order seq # may generate duplicate ACKs need only remember expectedseqnum Out-of-order pkt: discard (don t buffer) -> no receiver buffering! Re-ACK packet with highest in-order seq # Transport Layer - 20

21 GBN in action GBN in action Window size = 4 Transport Layer - 21

22 Selective Repeat Receiver individually acknowledges all correctly received packets Buffers packets, as needed, for eventual in-order delivery to upper layer Sender only resends packets for which ACK not received Sender timer for each unacked packet Sender window N consecutive seq # s Again limits seq #s of sent, unacked packets Transport Layer - 22

23 Selective repeat: sender, receiver windows Window can move at consecutive greens Window can move at consecutive reds Transport Layer - 23

24 Selective repeat sender data from above : if next available seq # in window, send pkt timeout(n): resend pkt n, restart timer ACK(n) in [sendbase,sendbase+n-1]: mark pkt n as received if n smallest unacked pkt, advance window base to next unacked seq # receiver pkt n in [rcvbase, rcvbase+n-1] send ACK(n) out-of-order: buffer in-order: deliver consec. in-order pkts advance window to next not-yet-received pkt pkt n in [rcvbase-n,rcvbase-1] ACK(n) otherwise: ignore Transport Layer - 24

25 Selective repeat in action Transport Layer - 25

26 Selective repeat dilemma Example: Seq # space: 4 (0, 1, 2, 3) 2 bits, modulo 4 arithmetic Window size = 3 Receiver window is forwareded premature Incorrectly passes duplicate data as new in (a) When the 2. ACK0 arrives, sender slides w. + sends pkt3 The same seq.# at the receiver could belong to 2 consecutive sender windows What relationship between seq # space and window size? window size < seq#space/2! Laszlo Böszörmenyi Transport Layer - 26 Computer Networks

27 UDP: User Datagram Protocol [RFC 768] Best effort service, segments may be Lost and delivered out of order Connectionless No handshaking Each segment is independent Rationales (why UDP?) Application may add reliability No connection establishment No connection state Small segment header No congestion control Used by Video streaming, DNS, SNMP Length, in bytes of segment, including header 32 bits source port # dest port # length Application data (message) checksum UDP segment format Transport Layer - 27

28 UDP checksum Goal: detect errors (e.g. flipped bits) in transmitted segment Sender: Treat segment contents as 16-bit integers Includes the 12-byte pseudo-header of the NW Layer (IP addresses) Checksum: addition (1 s complement sum) of segment contents Sender puts checksum into checksum field Receiver: Compute checksum of received segment Check if computed checksum equals checksum field value: NO - error detected YES - no error detected. But maybe errors nonetheless? More later. Transport Layer - 28

29 TCP: Overview RFCs: 793, 1122, 1323, 2018, 2581 socket door Point-to-point: one sender, one receiver Reliable, in-order byte stream: 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 (Max. Segment Size): may avoid IP fragmentation Connection-oriented: handshaking (exchange of control msgs) init s sender, receiver state before data exchange Flow controlled: socket door sender will not overwhelm receiver Transport Layer - 29

30 URG: urgent data (generally not used) ACK: ACK # valid PSH: push data now (suppress buffering; generally not used) RST, SYN, FIN: connection estab. (reset,setup,teardown commands) Head length (total head < 64 KB) Internet checksum: Includes IP addr.+ total length ( nasty ) TCP segment structure 32 bits source port # dest port # head len sequence number acknowledgement number not used U A P checksum R S F Receive window application data (variable length) Urg data pnter Options (variable length) counting by bytes of data (not segments!) # bytes rcvr willing to accept (flow-contr.) e.g. MSS negotiation, or time- Stamping MSS = MTU (Max. Segm. Size = Max. Transf. Unit) Transport Layer - 30

31 Seq. # s: TCP seq. # s and ACKs Byte number of first byte in segment s data Starts with random#: avoid delayed strangers from previous connections ACKs: Seqence# of next byte expected from other side Cumulative ACK Should receiver buffer out-of-order segments? TCP spec doesn t say - up to implementer Simple dev. may drop them User types C host ACKs receipt of echoed C Host A no data Host B simple telnet scenario host ACKs receipt of C, echoes back C Transport Layer - 31 time

32 TCP Round Trip Time and Timeouts RTT must be estimated well protocol based on time outs Exponential weighted moving average (EWMA) EstimatedRTT = (1- α)*estimatedrtt + α*samplertt Influence of past sample decreases exponentially fast (recomm.: α=0.125) RTT (milliseconds) time (seconnds) SampleRTT Estimated RTT Transport Layer - 32

33 TCP, Setting the timeout Estimated-RTT plus safety margin large variation in EstimatedRTT larger safety margin Estimate how sample-rtt deviates from estimated-rtt DevRTT = (1-β)*DevRTT + β* SampleRTT-EstimatedRTT (recommended, β = 0.25) Then set timeout interval TimeoutInterval = EstimatedRTT + 4*DevRTT TCP creates rdt service on top of IP s unreliable service Pipelined segments, cumulative acknowledgments, single retransmission timer Transport Layer - 33

34 TCP, Retransmission strategies At retransmission, the timeout is doubled Helps to avoid premature timeouts A simple way of congestion control Simulated Negative Acknowledgments (NAK) If the receiver notices a gap in the sequence numbers, it may send a duplicate ACK for the in-order part (as NAK) Why simulated? no NAK for historical reasons Retransmissions are triggered by Timeout events 3 duplicate acknowledgment: Allows fast retransmission of the missing bytes, before the timeout is elapsed Transport Layer - 34

35 NextSeqNum SendBase = InitialSeqNum = InitialSeqNum loop (forever) { switch(event) event: data received from application above create TCP segment with sequence number NextSeqNum if (timer currently not running) start timer pass segment to IP // assume here that length(data) MTU NextSeqNum = NextSeqNum + length(data) event: timer timeout retransmit not-yet-acknowledged segment with smallest sequence number start timer event: ACK received, with ACK field value of y if (y > SendBase) { SendBase = y // move send window edge if (there are currently not-yet-acknowledged segments) start timer } } /* end of loop forever */ TCP sender (simplified) Comment: SendBase: first unack ed byte 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 Transport Layer - 35

36 TCP: retransmission scenarios Host A Host B Host A Host B timeout X loss Seq=92 timeout SendBase = 100 time lost ACK scenario discard, but ack Sendbase = 100 SendBase = 120 SendBase = 120 time premature timeout Transport Layer - 36 Seq=92 timeout

37 TCP retransmission scenarios (more) Host A Host B timeout X loss SendBase = 120 No resend time Cumulative ACK scenario Transport Layer - 37

38 TCP ACK generation [RFC 1122, RFC 2581] 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 (May enforce fast retransmit) Immediate send ACK, provided that segment starts at lower end of gap Transport Layer - 38

39 TCP Flow control LBRcvd LBRead flow control sender won t overflow receiver s buffer by transmitting too much, too fast Spare room in buffer (Let receiver discard out-of-order data) LastByteRead: Number of the last byte read by the application LastByteRcvd: Number of the last byte arrived from the network RcvWindow = RcvBuffer- [LastByteRcvd-LastByteRead] Rcvr advertises spare room by including value of RcvWindow Sender limits unacked data to RcvWindow: LastByteSent-LastByteAcked RcvWin Receive buffer never overflows RcvWindow 0 holds If RcvWindow = 0, sender sends 1 byte messages to enforce ACK with RcvWindow Transport Layer - 39

40 TCP Connection Management Sender, receiver establish connection before exchanging data segments Initialize TCP variables: seq. #s, buffers, flow control info (e.g. RcvWindow) Server: contacted by client Socket connectionsocket = welcomesocket.accept(); Client: connection initiator Socket clientsocket = Socket ("hostname","port number ); Three way handshake: 1. Client host sends TCP SYN segment to server specifies initial seq # no data 2. Server host receives SYN, replies with SYN&ACK segment server allocates buffers specifies server initial seq. # 3. Client receives SYN&ACK, replies with ACK segment may contain data Termination can be initiated both by client and server Transport Layer - 40

41 TCP Connection Management (cont) TCP server lifecycle TCP client lifecycle Grace termination With abrupt termination we might loose segments on way 2 army problem Last ACK may be lost Transport Layer - 41

42 Principles of Congestion Control Congestion: Informally: Too many sources sending too much data too fast for the network to handle Different from flow control! Manifestations: lost packets (buffer overflow at routers) long delays (queuing in router buffers) A top-10 problem! Transport Layer - 42

43 Causes/costs of congestion: scenario 1 2 senders, 2 receivers C: link capacity (bps) λ: data rate (bps or bytes/sec or packets/sec) one router, infinite buffers no retransmission λ in Host B Host A λ in : rate for application data unlimited shared output link buffers λ out Max. throughput / connection Operating over the link capacity Infinite delays Operating near the link capacity Large delays (although link usage is maximal) Transport Layer - 43

44 Causes/costs of congestion: scenario 2 One router, finite buffers Packets arriving at full buffer must be discarded Sender retransmission of lost packet λ (offered load): the rate at which the transport layer sends data Host A λ in : application data rate λ' in : original data, plus retransmitted data λ out Host B finite shared output link buffers Transport Layer - 44

45 Performance of scenario 2 a) λ = λ (no retransmission: goodput ) in out b) Perfect retransmission, only when loss: λ > λ in out c) Retransmission of delayed (not lost) packet makes λ larger than in perfect case for the same λ out More work (retransmission) for given goodput Unneeded retransmissions: link carries multiple copies of packets Transport Layer - 45

46 Causes/costs of congestion: scenario 3 4 senders / receivers Multihop paths Timeout/retransmit When packet dropped, previous transmission efforts used for that packet were wasted! At the end, no useful work is done any more! λ in : original data λ' in : original data, plus retransmitted data λ out Host A Host B Transport Layer - 46

47 TCP Congestion Control End-to-end control (no network assistance): hard task! Congestion window enables sender limits transmission: LastByteSent-LastByteAcked min{congwin, RcvWin} Rate is usually roughly: rate = CongWin RTT Bytes/sec CongWin is dynamic, function of perceived network congestion How does sender perceive congestion? Loss event = timeout or 3 duplicate acks TCP sender reduces rate (CongWin) after loss event 3 mechanisms AIMD (Additive-Increase, Multiplicative-Decrease) slow start conservative after timeout events Transport Layer - 47

48 TCP AIMD Multiplicative Decrease Cut CongWin in half after loss event congestion window Additive Increase Increase CongWin by 1 MSS every RTT in the absence of loss events (probing) 24 Kbytes 16 Kbytes 8 Kbytes Long-lived TCP connection ( sawtooth pattern) Transport Layer - 48 time

49 TCP Slow Start When TCP connection begins: CongWin = 1 MSS Rate = 1 MSS / RTT low! After begin, increase rate exponentially until first loss event: Double CongWin every RTT RTT Host A Host B Done by incrementing CongWin for every ACK received Initial rate is slow but ramps up exponentially fast could be also called fast start time Transport Layer - 49

50 Refinement When should increase switch to linear? Controlled by the variable Threshold Initialized to a large value (65KB e.g.) When CongWin < Threshold Sender in slow-start phase, window grows exponentially When CongWin Threshold Sender in congestion-avoidance, window grows linearly When a triple duplicate ACK occurs Threshold = CongWin/2 and CongWin = Threshold (linear) When timeout occurs Threshold = CongWin/2 and CongWin = 1 MSS (slow start) Transport Layer - 50

51 TCP Fairness in AIMD mode If K TCP sessions share the same bottleneck link of bandwidth R, each should have average rate of R/K Example, 2 competing sessions (same MSS and RTT): Additive increase gives slope of 1, as throughput increases Multiplicative decrease decreases throughput proportionally R equal bandwidth share loss: decrease window by factor of 2 congestion avoidance: additive increase R = 11 CW CW CW Cw full bandwidth utilization Connection 1 throughput R Transport Layer - 51

52 Delay modeling How long does it take to receive an object e.g. from a Web server after sending a request? Ignoring congestion, delay is influenced by TCP connection establishment Data transmission delay Slow start Notation, assumptions: Assume one link between client and server of rate R S: Segment size = MSS (bits) O : Size of object to be transferred (bits) No retransmissions (no loss, no corruption) Window size (WS): Assume: fixed congestion window, W segments Dynamic window, modeling slow start is similar, but more complex Transport Layer - 52

53 Delay with big congestion window First case WS/R > RTT + S/R (WS > RTT*R + S): ACK for first segment in window returns before the first window is transmitted Delay = 2RTT + O/R Transport Layer - 53

54 Delay with small congestion window Second case WS/R < RTT + S/R Wait for ACK after sending window s worth of data sent K = #windows for O: K = O/WS Delay = 2RTT + O/R + (K-1)[S/R + RTT - WS/R] Transport Layer - 54