Multiplexing/demultiplexing

Transcription

1 Transport services and protocols Transport-layer protocols provide logical communication between app processes running on different hosts protocols run in end systems vs layer services: layer: transfer between end systems layer: transfer between processes relies on, enhances, layer services logical end-end Internet services: reliable, in-order unicast delivery (TCP) congestion flow control connection setup unreliable ( best-effort ), unordered unicast or multicast delivery: UDP services not available: real-time bandwidth guarantees reliable multicast logical end-end 2: Application Layer 1 2: Application Layer 2 Multiplexing/demultiplexing Multiplexing/demultiplexing ecall: segment -unit of exchanged between layer entities aka TPDU: protocol unit -layer segment P1 header M segment Ht M Hn segment P3 Demultiplexing: delivering received segments to correct app layer processes receiver M M P4 M P2 Multiplexing: gathering from multiple app processes, enveloping with header (later used for demultiplexing) multiplexing/demultiplexing: based on sender, receiver port numbers, IP addresses source, dest port #s in each segment recall: well-known port numbers for specific s 32 bits source port # dest port # other header fields (message) TCP/UDP segment format 2: Application Layer 3 2: Application Layer 4 Multiplexing/demultiplexing: examples UDP: User Datagram Protocol [FC 768] host A source port: x dest. port: 23 source port:23 dest. port: x server B port use: simple telnet app Web client host A Source IP: A Dest IP: B source port: x dest. port: 80 Source IP: C Dest IP: B source port: y dest. port: 80 Web client host C Source IP: C Dest IP: B source port: x dest. port: 80 Web server B port use: Web server no frills, bare bones Internet protocol best effort service, UDP segments may be: lost delivered out of order to app connectionless: no handshaking between UDP sender, receiver each UDP segment handled independently of others Why is there a UDP? no connection establishment (which can add delay) simple: no connection state at sender, receiver small segment header no congestion control: UDP can blast away as fast as desired 2: Application Layer 5 2: Application Layer 6

2 UDP: more often used for streaming multimedia apps loss tolerant rate sensitive other UDP uses (why?): DNS SNMP reliable transfer over UDP: add reliability at layer -specific error recover! Length, in bytes of UDP segment, including header 32 bits source port # dest port # length Application (message) checksum UDP segment format UDP checksum Goal: detect errors (e.g., flipped bits) in transmitted segment Sender: treat segment contents as sequence of 16-bit integers checksum: addition (1 s complement sum) of segment contents sender puts checksum value into UDP checksum field eceiver: compute checksum of received segment check if computed checksum equals checksum field value: NO - error detected YES - no error detected. But maybe errors nonethless? More later. 2: Application Layer 7 2: Application Layer 8 Principles of eliable transfer eliable transfer: getting started important in app.,, link layers top-10 list of important ing topics! rdt_send(): called from above, (e.g., by app.). Passed to deliver to receiver upper layer deliver_(): called by rdt to deliver to upper send side receive side characteristics of unreliable channel will determine complexity of reliable transfer protocol (rdt) 2: Application Layer 9 udt_send(): called by rdt, to transfer packet over unreliable channel to receiver rdt_rcv(): called when packet arrives on rcv-side of channel 2: Application Layer 10 eliable transfer: getting started Pipelined protocols We ll: incrementally develop sender, receiver sides of reliable transfer protocol (rdt) consider only unidirectional transfer but control info will flow on both directions! use finite state machines (FSM) to specify sender, receiver 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 Pipelining: sender allows multiple, in-flight, yet-tobe-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 2: Application Layer 11 2: Application Layer 12

3 Go-Back-N Sender: k-bit seq # in pkt header window of up to N, consecutive unack ed pkts allowed GBN in action ACK(n): ACKs all pkts up to, including seq # n - cumulative ACK may deceive duplicate ACKs (see receiver) timer for each in-flight pkt timeout(n): retransmit pkt n and all higher seq # pkts in window 2: Application Layer 13 2: Application Layer 14 Selective epeat Selective repeat: sender, receiver windows receiver individually acknowledges all correctly received pkts buffers pkts, as needed, for eventual in-order delivery to upper layer sender only resends pkts for which ACK not received sender timer for each unacked pkt sender window N consecutive seq # s again limits seq #s of sent, unacked pkts 2: Application Layer 15 2: Application Layer 16 Selective repeat sender from above : if next available seq # in window, send pkt timeout(n): resend pkt n, restart timer ACK(n) in [sendbase,sendbase+n]: 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 (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 Selective repeat in action 2: Application Layer 17 2: Application Layer 18

4 Selective repeat: dilemma TCP: Overview FCs: 793, 1122, 1323, 2018, 2581 Example: seq # s: 0, 1, 2, 3 window size=3 receiver sees no difference in two scenarios! incorrectly passes duplicate as new in (a) Q: what relationship between seq # size and window size? 2: Application Layer 19 socket door point-to-point: one sender, one receiver reliable, in-order byte steam: no message boundaries pipelined: TCP congestion and flow control set window size send & receive buffers writes TCP send buffer segment reads TCP receive buffer full duplex : bi-directional flow in same connection MSS: maximum segment size connection-oriented: handshaking (exchange of control msgs) init s sender, receiver state before exchange flow controlled: sender will not overwhelm receiver socket door 2: Application Layer 20 TCP segment structure UG: urgent (generally not used) ACK: ACK # valid PSH: push now (generally not used) ST, SYN, FIN: connection estab (setup, teardown commands) Internet checksum (as in UDP) 32 bits source port # dest port # sequence number acknowledgement number head not UA P S len used F rcvr window size checksum ptr urgent Options (variable length) (variable length) counting by bytes of (not segments!) # bytes rcvr willing to accept TCP seq. # s and ACKs Seq. # s: byte stream number of first byte in segment s ACKs: seq # of next byte expected from other side cumulative ACK Q: how receiver handles out-of-order segments A: TCP spec doesn t say, - up to implementor User types C host ACKs receipt of echoed C Host A Host B Seq=42, ACK=79, = C Seq=79, ACK=43, = C Seq=43, ACK=80 simple telnet scenario host ACKs receipt of C, echoes back C time 2: Application Layer 21 2: Application Layer 22 TCP: reliable transfer event: received from above create, send segment wait for event event: ACK received, with ACK # y ACK processing event: timer timeout for segment with seq # y retransmit segment simplified sender, assuming one way transfer no flow, congestion control 2: Application Layer 23 TCP: reliable transfer Simplified TCP sender 00 sendbase = initial_sequence number 01 nextseqnum = initial_sequence number loop (forever) { 04 switch(event) 05 event: received from above 06 create TCP segment with sequence number nextseqnum 07 start timer for segment nextseqnum 08 pass segment to IP 09 nextseqnum = nextseqnum + length() 10 event: timer timeout for segment with sequence number y 11 retransmit segment with sequence number y 12 compue new timeout interval for segment y 13 restart timer for sequence number y 14 event: ACK received, with ACK field value of y 15 if (y > sendbase) { /* cumulative ACK of all up to y */ 16 cancel all timers for segments with sequence numbers < y 17 sendbase = y 18 } 19 else { /* a duplicate ACK for already ACKed segment */ 20 increment number of duplicate ACKs received for y 21 if (number of duplicate ACKS received for y == 3) { 22 /* TCP fast retransmit */ 23 resend segment with sequence number y 24 restart timer for segment y 25 } 26 } /* end of loop forever */ 2: Application Layer 24

5 TCP ACK generation [FC 1122, FC 2581] TCP: retransmission scenarios Event in-order segment arrival, no gaps, everything else already ACKed in-order segment arrival, no gaps, one delayed ACK pending TCP eceiver action delayed ACK. Wait up to 500ms for next segment. If no next segment, send ACK immediately send single cumulative ACK timeout Host A Host B Seq=92, 8 bytes X loss ACK=100 Seq=92, 8 bytes Seq=100 timeout Seq=92 timeout Host A Host B Seq=92, 8 bytes Seq=100, 20 bytes ACK=100 ACK=120 Seq=92, 8 bytes out-of-order segment arrival higher-than-expect seq. # gap detected send duplicate ACK, indicating seq. # of next expected byte ACK=100 ACK=120 arrival of segment that partially or completely fills gap immediate ACK if segment starts at lower end of gap time lost ACK scenario time premature timeout, cumulative ACKs 2: Application Layer 25 2: Application Layer 26 TCP Flow Control TCP ound Trip Time and Timeout flow control sender won t overrun receiver s buffers by transmitting too much, too fast cvbuffer = size or TCP eceive Buffer cvwindow = amount of spare room in Buffer receiver: explicitly informs sender of (dynamically changing) amount of free buffer space cvwindow field in TCP segment sender: keeps the amount of transmitted, unacked less than most recently received cvwindow Q: how to set TCP timeout value? longer than TT note: TT will vary too short: premature timeout unnecessary retransmissions too long: slow reaction to segment loss Q: how to estimate TT? SampleTT: measured time from segment transmission until ACK receipt ignore retransmissions, cumulatively ACKed segments SampleTT will vary, want estimated TT smoother use several recent measurements, not just current SampleTT receiver buffering 2: Application Layer 27 2: Application Layer 28 TCP ound Trip Time and Timeout TCP Connection Management EstimatedTT = (1-x)*EstimatedTT + x*samplett Exponential weighted moving average influence of given sample decreases exponentially fast typical value of x: 0.1 Setting the timeout EstimtedTT plus safety margin large variation in EstimatedTT -> larger safety margin Timeout = EstimatedTT + 4*Deviation Deviation = (1-x)*Deviation + x* SampleTT-EstimatedTT ecall: TCP sender, receiver establish connection before exchanging segments initialize TCP variables: seq. #s buffers, flow control info (e.g. cvwindow) client: connection initiator Socket clientsocket = new Socket("hostname","port number"); server: contacted by client Socket connectionsocket = welcomesocket.accept(); Three way handshake: Step 1: client end system sends TCP SYN control segment to server specifies initial seq # Step 2: server end system receives SYN, replies with SYNACK control segment ACKs received SYN allocates buffers specifies server-> receiver initial seq. # 2: Application Layer 29 2: Application Layer 30

6 TCP Connection Management (cont.) TCP Connection Management (cont.) Closing a connection: client closes socket: clientsocket.close(); Step 1: client end system sends TCP FIN control segment to server close client FIN ACK FIN server close Step 3: client receives FIN, replies with ACK. Enters timed wait - will respond with ACK to received FINs Step 4: server, receives ACK. Connection closed. closing client FIN ACK FIN server closing Step 2: server receives FIN, replies with ACK. Closes connection, sends FIN. timed wait ACK Note: with small modification, can handly simultaneous FINs. timed wait ACK closed closed closed 2: Application Layer 31 2: Application Layer 32 TCP Connection Management (cont) Principles of Congestion Control TCP client lifecycle TCP server lifecycle Congestion: informally: too many sources sending too much too fast for to handle different from flow control! manifestations: lost packets (buffer overflow at routers) long delays (queueing in router buffers) a top-10 problem! 2: Application Layer 33 2: Application Layer 34 Causes/costs of congestion: scenario 1 two senders, two receivers one router, infinite buffers no retransmission Causes/costs of congestion: scenario 2 one router, finite buffers sender retransmission of lost packet large delays when congested maximum achievable throughput 2: Application Layer 35 2: Application Layer 36

7 Causes/costs of congestion: scenario 2 Causes/costs of congestion: scenario 3 always: = (goodput) in out perfect retransmission only when loss: > in out retransmission of delayed (not lost) packet makes larger in (than perfect case) for same out four senders multihop paths timeout/retransmit Q: what happens as in and increase? in costs of congestion: more work (retrans) for given goodput unneeded retransmissions: link carries multiple copies of pkt 2: Application Layer 37 2: Application Layer 38 Causes/costs of congestion: scenario 3 Approaches towards congestion control Two broad approaches towards congestion control: Another cost of congestion: when packet dropped, any upstream transmission capacity used for that packet was wasted! End-end congestion control: no explicit feedback from congestion inferred from end-system observed loss, delay approach taken by TCP Network-assisted congestion control: routers provide feedback to end systems single bit indicating congestion (SNA, DECbit, TCP/IP ECN, ATM) explicit rate sender should send at 2: Application Layer 39 2: Application Layer 40 TCP Congestion Control TCP congestion control: end-end control (no assistance) transmission rate limited by congestion window size, Congwin, over segments: Congwin w segments, each with MSS bytes sent in one TT: throughput = w * MSS TT Bytes/sec probing for usable bandwidth: ideally: transmit as fast as possible (Congwin as large as possible) without loss increase Congwin until loss (congestion) loss: decrease Congwin, then begin probing (increasing) again two phases slow start congestion avoidance important variables: Congwin threshold: defines threshold between two slow start phase, congestion control phase 2: Application Layer 41 2: Application Layer 42

8 TCP Slowstart Slowstart algorithm initialize: Congwin = 1 for (each segment ACKed) Congwin++ until (loss event O CongWin > threshold) exponential increase (per TT) in window size (not so slow!) loss event: timeout (Tahoe TCP) and/or or three duplicate ACKs (eno TCP) TT Host A Host B one segment two segments four segments time 2: Application Layer 43 TCP Congestion Avoidance Congestion avoidance /* slowstart is over */ /* Congwin > threshold */ Until (loss event) { every w segments ACKed: Congwin++ } threshold = Congwin/2 Congwin = 1 1 perform slowstart 1: TCP eno skips slowstart (fast recovery) after three duplicate ACKs 2: Application Layer 44 AIMD TCP congestion avoidance: AIMD: additive increase, multiplicative decrease increase window by 1 per TT decrease window by factor of 2 on loss event TCP Fairness Fairness goal: if N TCP sessions share same bottleneck link, each should get 1/N of link capacity TCP connection 1 TCP connection 2 bottleneck router capacity 2: Application Layer 45 Why is TCP fair? Two competing sessions: Additive increase gives slope of 1, as throughout increases multiplicative decrease decreases throughput proportionally Connection 2 throughput Connection 1 throughput equal bandwidth share loss: decrease window by factor of 2 congestion avoidance: additive increase loss: decrease window by factor of 2 congestion avoidance: additive increase 2: Application Layer 46 TCP latency modeling TCP latency Modeling K:= O/WS Q: How long does it take to receive an object from a Web server after sending a request? TCP connection establishment transfer delay Notation, assumptions: Two cases to consider: Assume one link between client and server of rate Assume: fixed congestion window, W segments S: MSS (bits) O: object size (bits) no retransmissions (no loss, no corruption) WS/ > TT + S/: ACK for first segment in Case 1: latency = 2TT + O/ Case 2: latency = 2TT + O/ window returns before window s worth of + (K-1)[S/ + TT - WS/] sent WS/ < TT + S/: wait for ACK after sending window s worth of sent 2: Application Layer 47 2: Application Layer 48

9 TCP Latency Modeling: Slow Start Now suppose window grows according to slow start. Will show that the latency of one object of size O is: O S P S Latency 2TT P TT (2 1) where P is the number of times TCP stalls at server: P min{ Q, K 1} - where Q is the number of times the server would stall if the object were of infinite size. TCP Latency Modeling: Slow Start (cont.) Example: O/S = 15 segments K = 4 windows Q = 2 P = min{k-1,q} = 2 Server stalls P=2 times. initiate TCP connection request object first window = S/ TT second window = 2S/ third window = 4S/ fourth window = 8S/ - and K is the number of windows that cover the object. object delivered complete transmission time at client time at server 2: Application Layer 49 2: Application Layer 50 TCP Latency Modeling: Slow Start (cont.) S TT timefrom when server starts to send segment until server receives acknowledgement k S 2 1 time to transmit the kth window S k S 2 1 TT stall time after the kth window O latency 2TT P p1 stalltime P O S k 1 S 2TT [ TT 2 ] k 1 O S P S 2TT P[ TT ] (2 1) p initiate TCP connection request object object delivered TT time at client first window = S/ second window = 2S/ third window = 4S/ fourth window = 8S/ complete transmission time at server 2: Application Layer 51 Summary principles behind layer services: multiplexing/demultiplexing reliable transfer flow control congestion control instantiation and implementation in the Internet UDP TCP Next: leaving the edge ( layer) into the core 2: Application Layer 52