Chapter 3 Transport Layer

Transcription

1 Chapter 3 Transport Layer

2 Chapter 3: Transport Layer our goals: understand principles behind transport layer services: multiplexing, demultiplexing reliable data transfer flow control congestion control learn about Internet transport layer protocols: UDP: connectionless transport TCP: connection-oriented reliable transport TCP congestion control Transport Layer 3-2

3 Chapter 3 outline 3.1 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 Transport Layer 3-3

4 Transport services and protocols provide logical communication between app processes running on different hosts transport protocols run in end systems send side: breaks app messages into segments, passes to network layer rcv side: reassembles segments into messages, passes to app layer more than one transport protocol available to apps Internet: TCP and UDP application transport network data link physical application transport network data link physical Transport Layer 3-4

5 Transport vs. network layer network layer: logical communication between hosts transport layer: logical communication between processes relies on, enhances, network layer services household analogy: 12 kids in Ann s house sending letters to 12 kids in Bill s house: hosts = houses processes = kids app messages = letters in envelopes transport protocol = Ann and Bill who demux to inhouse siblings network-layer protocol = postal service Transport Layer 3-5

6 Internet transport-layer protocols reliable, in-order delivery (TCP) congestion control flow control connection setup unreliable, unordered delivery: UDP no-frills extension of best-effort IP services not available: delay guarantees bandwidth guarantees application transport network data link physical network data link physical network data link physical network data link physical network data link physical network data link physical network data link physical network data link physical application transport network data link physical Transport Layer 3-6

7 Transport Layer Session multiplexing Segmentation Flow control (when required) Connection-oriented (when required) Reliability (when required)

8 End-to-End Protocols Underlying best-effort network drop messages re-orders messages delivers duplicate copies of a given message limits messages to some finite size delivers messages after an arbitrarily long delay Common end-to-end services guarantee message delivery deliver messages in the same order they are sent deliver at most one copy of each message support arbitrarily large messages support synchronization allow the receiver to flow control the sender support multiple application processes on each host

9 Position of TCP and UDP in TCP/IP protocol suite

10 Chapter 3 outline 3.1 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 Transport Layer 3-10

11 Multiplexing/demultiplexing multiplexing at sender: handle data from multiple sockets, add transport header (later used for demultiplexing) demultiplexing at receiver: use header info to deliver received segments to correct socket application application P3 transport network link P1 P2 transport network link physical application P4 transport network link socket process physical physical Transport Layer 3-11

12 How demultiplexing works host receives IP datagrams each datagram has source IP address, destination IP address each datagram carries one transport-layer segment each segment has source, destination port number host uses IP addresses & port numbers to direct segment to appropriate socket 32 bits source port # dest port # other header fields application data (payload) TCP/UDP segment format Transport Layer 3-12

13 Connectionless demultiplexing recall: created socket has host-local port #: DatagramSocket mysocket1 = new DatagramSocket(12534); recall: when creating datagram to send into UDP socket, must specify destination IP address destination port # when host receives UDP segment: checks destination port # in segment directs UDP segment to socket with that port # IP datagrams with same dest. port #, but different source IP addresses and/or source port numbers will be directed to same socket at dest Transport Layer 3-13

14 Connectionless demux: example DatagramSocket mysocket2 = new DatagramSocket (9157); application P3 transport network link physical DatagramSocket serversocket = new DatagramSocket (6428); application P1 transport network link physical DatagramSocket mysocket1 = new DatagramSocket (5775); application P4 transport network link physical source port: 6428 dest port: 9157 source port:? dest port:? source port: 9157 dest port: 6428 source port:? dest port:? Transport Layer 3-14

15 Connection-oriented demux TCP socket identified by 4-tuple: source IP address source port number dest IP address dest port number demux: receiver uses all four values to direct segment to appropriate socket server host may support many simultaneous TCP sockets: each socket identified by its own 4-tuple web servers have different sockets for each connecting client non-persistent HTTP will have different socket for each request Transport Layer 3-15

16 Connection-oriented demux: example application application P3 transport network link physical P4 P5 transport network link physical P6 server: IP address B application P2 P3 transport network link physical host: IP address A source IP,port: B,80 dest IP,port: A,9157 source IP,port: C,5775 dest IP,port: B,80 host: IP address C source IP,port: A,9157 dest IP, port: B,80 three segments, all destined to IP address: B, dest port: 80 are demultiplexed to different sockets source IP,port: C,9157 dest IP,port: B,80 Transport Layer 3-16

17 Connection-oriented demux: example threaded server application application P3 transport network link physical P4 transport network link physical server: IP address B application P2 P3 transport network link physical host: IP address A source IP,port: B,80 dest IP,port: A,9157 source IP,port: C,5775 dest IP,port: B,80 host: IP address C source IP,port: A,9157 dest IP, port: B,80 source IP,port: C,9157 dest IP,port: B,80 Transport Layer 3-17

18 Reminder Layered architecture Transport Layer 3-18

19 Transport Layer 3-19

20 Chapter 3 outline 3.1 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 Transport Layer 3-20

21 UDP: User Datagram Protocol [RFC 768] no frills, bare bones Internet transport 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 UDP use: streaming multimedia apps (loss tolerant, rate sensitive) DNS SNMP reliable transfer over UDP: add reliability at application layer application-specific error recovery! Transport Layer 3-21

22 UDP: segment header source port # dest port # length 32 bits application data (payload) checksum UDP segment format length, in bytes of UDP segment, including header why is there a UDP? no connection establishment (which can add delay) simple: no connection state at sender, receiver small header size no congestion control: UDP can blast away as fast as desired Transport Layer 3-22

23 UDP checksum Goal: detect errors (e.g., flipped bits) in transmitted segment sender: treat segment contents, including header fields, as sequence of 16-bit integers checksum: addition (one s complement sum) of segment contents sender puts checksum value into UDP 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 3-23

24 Internet checksum: example example: add two 16-bit integers wraparound sum checksum Note: when adding numbers, a carryout from the most significant bit needs to be added to the result * Check out the online interactive exercises for more examples: Transport Layer 3-24

25 Chapter 3 outline 3.1 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 Transport Layer 3-25

26 Principles of reliable data transfer important in application, transport, link layers top-10 list of important networking topics! characteristics of unreliable channel will determine complexity of reliable data transfer protocol (rdt) Transport Layer 3-26

27 Principles of reliable data transfer important in application, transport, link layers top-10 list of important networking topics! characteristics of unreliable channel will determine complexity of reliable data transfer protocol (rdt) Transport Layer 3-27

28 Principles of reliable data transfer important in application, transport, link layers top-10 list of important networking topics! characteristics of unreliable channel will determine complexity of reliable data transfer protocol (rdt) Transport Layer 3-28

29 Chapter 3 outline 3.1 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 Transport Layer 3-29

30 TCP: Overview RFCs: 793,1122,1323, 2018, 2581 point-to-point: one sender, one receiver reliable, in-order byte steam: no message boundaries pipelined: TCP congestion and flow control set window size full duplex data: bi-directional data flow in same connection MSS: maximum segment size connection-oriented: handshaking (exchange of control msgs) inits sender, receiver state before data exchange flow controlled: sender will not overwhelm receiver Transport Layer 3-30

31 TCP segment structure

32 TCP segment structure - Control field

33 TCP seq. numbers, ACKs sequence numbers: byte stream number of first byte in segment s data acknowledgements: seq # of next byte expected from other side cumulative ACK Q: how receiver handles out-of-order segments A: TCP spec doesn t say, outgoing segment from sender source port # dest port # sequence number acknowledgement number rwnd checksum sent ACKed urg pointer window size N sender sequence number space sent, notyet usable not ACKed but not usable ( inflight ) yet sent incoming segment to sender - up to implementor source port # dest port # sequence number acknowledgement number rwnd A checksum urg pointer Transport Layer 3-34

34 TCP seq. numbers, ACKs Host A Host B User types C host ACKs receipt of echoed C Seq=42, ACK=79, data = C Seq=79, ACK=43, data = C Seq=43, ACK=80 host ACKs receipt of C, echoes back C simple telnet scenario Transport Layer 3-35

35 TCP round trip time, timeout Q: how to set TCP timeout value? longer than RTT but RTT varies too short: premature timeout, unnecessary retransmissions too long: slow reaction to segment loss Q: how to estimate RTT? SampleRTT: measured time from segment transmission until ACK receipt ignore retransmissions SampleRTT will vary, want estimated RTT smoother average several recent measurements, not just current SampleRTT Transport Layer 3-36

36 TCP round trip time, timeout EstimatedRTT = (1- α)*estimatedrtt + α*samplertt exponential weighted moving average influence of past sample decreases exponentially fast typical value: α = RTT: gaia.cs.umass.edu to fantasia.eurecom.fr 350 RTT: gaia.cs.umass.edu to fantasia.eurecom.fr RTT (milliseconds) RTT (milliseconds) samplertt EstimatedRTT time (seconnds) time (seconds) SampleRTT Estimated RTT Transport Layer 3-37

37 TCP round trip time, timeout timeout interval: EstimatedRTT plus safety margin large variation in EstimatedRTT -> larger safety margin estimate SampleRTT deviation from EstimatedRTT: DevRTT = (1-β)*DevRTT + β* SampleRTT-EstimatedRTT (typically, β = 0.25) TimeoutInterval = EstimatedRTT + 4*DevRTT estimated RTT safety margin * Check out the online interactive exercises for more examples: Transport Layer 3-38

38 Chapter 3 outline 3.1 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 Transport Layer 3-39

39 TCP reliable data transfer TCP creates rdt service on top of IP s unreliable service pipelined segments cumulative acks single retransmission timer retransmissions triggered by: timeout events duplicate acks let s initially consider simplified TCP sender: ignore duplicate acks ignore flow control, congestion control Transport Layer 3-40

40 TCP sender events: data rcvd from app: create segment with seq # seq # is byte-stream number of first data byte in segment start timer if not already running think of timer as for oldest unacked segment expiration interval: TimeOutInterval timeout: retransmit segment that caused timeout restart timer ack rcvd: if ack acknowledges previously unacked segments update what is known to be ACKed start timer if there are still unacked segments Transport Layer 3-41

41 TCP sender (simplified) Λ NextSeqNum = InitialSeqNum SendBase = InitialSeqNum wait for event ACK received, with ACK field value y data received from application above create segment, seq. #: NextSeqNum pass segment to IP (i.e., send ) NextSeqNum = NextSeqNum + length(data) if (timer currently not running) start timer timeout retransmit not-yet-acked segment with smallest seq. # start timer if (y > SendBase) { SendBase = y /* SendBase 1: last cumulatively ACKed byte */ if (there are currently not-yet-acked segments) start timer else stop timer } Transport Layer 3-42

42 TCP: retransmission scenarios Host A Host B Host A Host B Seq=92, 8 bytes of data SendBase=92 Seq=92, 8 bytes of data timeout X ACK=100 timeout Seq=100, 20 bytes of data ACK=100 ACK=120 Seq=92, 8 bytes of data ACK=100 lost ACK scenario SendBase=100 SendBase=120 SendBase=120 Seq=92, 8 bytes of data ACK=120 premature timeout Transport Layer 3-43

43 TCP: retransmission scenarios Host A Host B Seq=92, 8 bytes of data Seq=100, 20 bytes of data timeout X ACK=100 ACK=120 Seq=120, 15 bytes of data cumulative ACK Transport Layer 3-44

44 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 immediate send ACK, provided that segment starts at lower end of gap Transport Layer 3-45

45 TCP fast retransmit time-out period often relatively long: long delay before resending lost packet detect lost segments via duplicate ACKs. sender often sends many segments backto-back if segment is lost, there will likely be many duplicate ACKs. TCP fast retransmit if sender receives 3 ACKs for same data ( triple duplicate ACKs ), resend unacked segment with smallest seq # likely that unacked segment lost, so don t wait for timeout Transport Layer 3-46

46 TCP fast retransmit Host A Host B Seq=92, 8 bytes of data Seq=100, 20 bytes of data X timeout ACK=100 ACK=100 ACK=100 ACK=100 Seq=100, 20 bytes of data fast retransmit after sender receipt of triple duplicate ACK Transport Layer 3-47

47 Chapter 3 outline 3.1 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 Transport Layer 3-48

48 TCP Flow control: Example In TCP, the sender window size is totally controlled by the receiver window value. However, the actual window size can be smaller if there is congestion in the network. Some more points about TCP s Sliding Windows: 1. The source does not have to send a full window s worth of data. 2. The size of the window can be increased or decreased by the destination.

49 TCP flow control application may remove data from TCP socket buffers. slower than TCP receiver is delivering (sender is sending) application process TCP socket receiver buffers TCP code application OS flow control receiver controls sender, so sender won t overflow receiver s buffer by transmitting too much, too fast from sender IP code receiver protocol stack Transport Layer 3-50

50 TCP flow control receiver advertises free buffer space by including rwnd value in TCP header of receiver-to-sender segments RcvBuffer size set via socket options (typical default is 4096 bytes) many operating systems autoadjust RcvBuffer sender limits amount of unacked ( in-flight ) data to receiver s rwnd value guarantees receive buffer will not overflow RcvBuffer rwnd to application process buffered data free buffer space TCP segment payloads receiver-side buffering Transport Layer 3-51

51 Flow Control

52 AP- application program SB- Send Buffer RB receive Buffer SN Sequence number MSS Message Segment Size W Receive Window (S- Sender, R- Receiver) Transport Layer 3-53

53 Transport Layer 3-54

54 Transport Layer 3-55

55 TCP Flow control: Example Sender buffer Receiver buffer

56 TCP Flow control: Example Sender buffer and sender window

57 TCP Flow control: Example Sliding the sender window

58 TCP Flow control: Example Expanding the sender window Shrinking the sender window

59 Keeping the Pipe Full D B dictates how big the Advertised Window should be. Window should be opened enough to allow D B data to be transmitted. Bandwidth & Time Until Wrap Around Wrap Around: 32-bit SequenceNum Bandwidth T1 (1.5Mbps) Ethernet (10Mbps) T3 (45Mbps) FDDI (100Mbps) STS-3 (155Mbps) STS-12 (622Mbps) STS-24 (1.2Gbps) Time Until Wrap Around 6.4 hours 57 minutes 13 minutes 6 minutes 4 minutes 55 seconds 28 seconds

60 Delay-Bandwidth product Bytes in Transit: 16-bit AdvertisedWindow 64kB max) Bandwidth & Delay x Bandwidth Product for 100ms RTT Bandwidth T1 (1.5Mbps) Ethernet (10Mbps) T3 (45Mbps) FDDI (100Mbps) STS-3 (155Mbps) STS-12 (622Mbps) STS-24 (1.2Gbps) Delay x Bandwidth Product 18KB 122KB 549KB 1.2MB 1.8MB 7.4MB 14.8MB

61 Nagle s Algorithm How long does sender delay sending data? too long: hurts interactive applications too short: poor network utilization strategies: timer-based vs self-clocking When application generates additional data if fills a max segment (and window open): send it else if there is unack ed data in transit: buffer it until ACK arrives else: send it

62 Ivan Marsic, Computer Networks Book website: Go to congestion slide Transport Layer 3-63

63 Chapter 3 outline 3.1 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 Transport Layer 3-64

64 Connection Management before exchanging data, sender/receiver handshake : agree to establish connection (each knowing the other willing to establish connection) agree on connection parameters application connection state: ESTAB connection variables: seq # client-to-server server-to-client rcvbuffer size at server,client network application connection state: ESTAB connection Variables: seq # client-to-server server-to-client rcvbuffer size at server,client network Socket clientsocket = newsocket("hostname","port number"); Socket connectionsocket = welcomesocket.accept(); Transport Layer 3-65

65 Agreeing to establish a connection 2-way handshake: Let s talk ESTAB OK choose x req_conn(x) ESTAB acc_conn(x) ESTAB ESTAB Q: will 2-way handshake always work in network? variable delays retransmitted messages (e.g. req_conn(x)) due to message loss message reordering can t see other side Transport Layer 3-66

66 Agreeing to establish a connection 2-way handshake failure scenarios: choose x retransmit req_conn(x) req_conn(x) acc_conn(x) ESTAB choose x retransmit req_conn(x) req_conn(x) acc_conn(x) ESTAB ESTAB client terminates req_conn(x) connection x completes server forgets x ESTAB retransmit data(x+1) client terminates data(x+1) connection x completes req_conn(x) accept data(x+1) server forgets x half open connection! (no client!) ESTAB data(x+1) ESTAB accept data(x+1) Transport Layer 3-67

67 TCP 3-way handshake client state LISTEN SYNSENT ESTAB choose init seq num, x send TCP SYN msg received SYNACK(x) indicates server is live; send ACK for SYNACK; this segment may contain client-to-server data SYNbit=1, Seq=x SYNbit=1, Seq=y ACKbit=1; ACKnum=x+1 ACKbit=1, ACKnum=y+1 choose init seq num, y send TCP SYNACK msg, acking SYN received ACK(y) indicates client is live server state LISTEN SYN RCVD ESTAB Transport Layer 3-68

68 TCP 3-way handshake: FSM closed Socket connectionsocket = welcomesocket.accept(); SYN(x) SYNACK(seq=y,ACKnum=x+1) create new socket for communication back to client Λ listen Socket clientsocket = newsocket("hostname","port number"); SYN(seq=x) SYN rcvd SYN sent ACK(ACKnum=y+1) Λ ESTAB SYNACK(seq=y,ACKnum=x+1) ACK(ACKnum=y+1) Transport Layer 3-69

69 TCP: closing a connection client, server each close their side of connection send TCP segment with FIN bit = 1 respond to received FIN with ACK on receiving FIN, ACK can be combined with own FIN simultaneous FIN exchanges can be handled Transport Layer 3-70

70 TCP: closing a connection client state server state ESTAB ESTAB clientsocket.close() FIN_WAIT_1 FIN_WAIT_2 can no longer send but can receive data wait for server close FINbit=1, seq=x ACKbit=1; ACKnum=x+1 can still send data CLOSE_WAIT TIMED_WAIT timed wait for 2*max segment lifetime FINbit=1, seq=y ACKbit=1; ACKnum=y+1 can no longer send data LAST_ACK CLOSED CLOSED Transport Layer 3-71

71 Chapter 3 outline 3.1 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 Transport Layer 3-72

72 Principles of Congestion Control Congestion: informally: too many sources sending too much data too fast for network to handle Formally: Congestion occurs when number of packets transmitted approaches network capacity Objective of congestion control: keep number of packets below level at which performance drops off dramatically different from flow control! manifestations: lost packets (buffer overflow at routers) long delays (queueing in router buffers)

73 Principles of Congestion Control Data network is a network of queues If arrival rate > transmission rate then queue size grows without bound and packet delay goes to infinity Discard any incoming packet if no buffer available Saturated node exercises flow control over neighbors May cause congestion to propagate throughout network

74 Ideal Performance Infinite buffers, no overhead for packet transmission or congestion control Throughput increases with offered load until full capacity Packet delay increases with offered load approaching infinity at full capacity Power = throughput / delay Higher throughput results in higher delay

75 Figure 10.3

76 Causes/costs of congestion: scenario 1 two senders, two receivers one router, infinite buffers output link capacity: R no retransmission original data: λ in Host A unlimited shared output link buffers throughput: λ out Host B R/2 λ out delay λ in R/2 λ in R/2 maximum per-connection throughput: R/2 large delays as arrival rate, λ in, approaches capacity Transport Layer 3-77

77 Practical Performance Finite buffers, non-zero packet processing overhead With no congestion control, increased load eventually causes moderate congestion: throughput increases at slower rate than load Further increased load causes packet delays to increase and eventually throughput to drop to zero

78 Figure 10.4

79 Causes/costs of congestion: scenario 1 two senders, two receivers one router, infinite buffers no retransmission large delays when congested maximum achievable throughput

80 Causes/costs of congestion: scenario 2 one router, finite buffers sender retransmission of timed-out packet application-layer input = application-layer output: λ in = λ out transport-layer input includes retransmissions : λ in λ in λ in : original data λ' in : original data, plus retransmitted data λ out Host A Host B finite shared output link buffers Transport Layer 3-81

81 Causes/costs of congestion: scenario 2 idealization: perfect knowledge sender sends only when router buffers available R/2 λ out λ in R/2 copy λ in : original data λ' in : original data, plus retransmitted data λ out A free buffer space! Host B finite shared output link buffers Transport Layer 3-82

82 Causes/costs of congestion: scenario 2 Idealization: known loss packets can be lost, dropped at router due to full buffers sender only resends if packet known to be lost copy λ in : original data λ' in : original data, plus retransmitted data λ out A no buffer space! Host B Transport Layer 3-83

83 Causes/costs of congestion: scenario 2 Idealization: known loss packets can be lost, dropped at router due to full buffers sender only resends if packet known to be lost R/2 λ out λ in R/2 when sending at R/2, some packets are retransmissions but asymptotic goodput is still R/2 (why?) λ in : original data λ' in : original data, plus retransmitted data λ out A free buffer space! Host B Transport Layer 3-84

84 Causes/costs of congestion: scenario 2 Realistic: duplicates packets can be lost, dropped at router due to full buffers sender times out prematurely, sending two copies, both of which are delivered R/2 λ out λ in R/2 when sending at R/2, some packets are retransmissions including duplicated that are delivered! copy timeout λ in λ' in λ out A free buffer space! Host B Transport Layer 3-85

85 Causes/costs of congestion: scenario 2 Realistic: duplicates packets can be lost, dropped at router due to full buffers sender times out prematurely, sending two copies, both of which are delivered λ out R/2 λ in R/2 when sending at R/2, some packets are retransmissions including duplicated that are delivered! costs of congestion: more work (retrans) for given goodput unneeded retransmissions: link carries multiple copies of pkt decreasing goodput Transport Layer 3-86

86 Causes/costs of congestion: scenario 2 a. always: λ = λ (goodput) in out b. perfect retransmission only when loss: λ > λ in out c. retransmission of delayed (not lost) packet makes larger (than λ perfect case) for same λ in out R/2 R/2 R/2 R/3 λ out λ out λ out R/4 λ in R/2 λ in R/2 λ in R/2 a. costs of congestion: b. c. more work (retrans) for given goodput unneeded retransmissions: link carries multiple copies of pkt

87 Causes/costs of congestion: scenario 3 four senders multihop paths timeout/retransmit Host A Q: what happens as λ in and λ in increase? A: as red λ in increases, all arriving blue pkts at upper queue are dropped, blue throughput 0 λ in : original data λ' in : original data, plus retransmitted data finite shared output link buffers λ out Host B Host D Host C Transport Layer 3-88

88 Causes/costs of congestion: scenario 3 C/2 λ out λ in C/2 another cost of congestion: when packet dropped, any upstream transmission capacity used for that packet was wasted! Transport Layer 3-89

89 Chapter 3 outline 3.1 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 Transport Layer 3-90

90 TCP congestion control: bandwidth probing probing for bandwidth : increase transmission rate on receipt of ACK, until eventually loss occurs, then decrease transmission rate continue to increase on ACK/decrease on loss (since available bandwidth is changing, depending on other connections in network) [dynamically adapts to network state] sending rate ACKs being received, so increase rate X X X X X loss, so decrease rate TCP s sawtooth behavior time Q: how fast to increase/decrease? What is the (average/useful throughput)? details to follow Transport Layer 3-91

91 TCP congestion control: additive increase multiplicative decrease approach: sender increases transmission rate (window size), probing for usable bandwidth, until loss occurs additive increase: increase cwnd by 1 MSS every RTT until loss detected multiplicative decrease: cut cwnd in half after loss AIMD saw tooth behavior: probing for bandwidth cwnd: TCP sender congestion window size additively increase window size. until loss occurs (then cut window in half) time Transport Layer 3-92

92 TCP congestion control: bandwidth probing probing for bandwidth : increase transmission rate on receipt of ACK, until eventually loss occurs, then decrease transmission rate continue to increase on ACK/decrease on loss (since available bandwidth is changing, depending on other connections in network) [dynamically adapts to network state] sending rate ACKs being received, so increase rate X X X X X loss, so decrease rate TCP s sawtooth behavior time Q: how fast to increase/decrease? What is the (average/useful throughput)? details to follow Transport Layer 3-93

93 TCP Congestion Control: details sender sequence number space cwnd last byte ACKed last byte sent sender limits transmission: sent, notyet ACKed ( inflight ) LastByteSent- LastByteAcked < cwnd TCP sending rate: roughly: send cwnd bytes, wait RTT for ACKS, then send more bytes rate ~ cwnd RTT bytes/sec cwnd is dynamic, function of perceived network congestion Transport Layer 3-94

94 TCP Slow Start when connection begins, increase rate exponentially until first loss event: initially cwnd = 1 MSS double cwnd every RTT done by incrementing cwnd for every ACK received summary: initial rate is slow but ramps up exponentially fast Host A RTT Host B time Transport Layer 3-95

95 TCP: detecting, reacting to loss loss indicated by timeout: cwnd set to 1 MSS; window then grows exponentially (as in slow start) to threshold, then grows linearly loss indicated by 3 duplicate ACKs: TCP RENO dup ACKs indicate network capable of delivering some segments cwnd is cut in half window then grows linearly TCP Tahoe always sets cwnd to 1 (timeout or 3 duplicate acks) Transport Layer 3-96

96 TCP: switching from slow start to CA Q: when should the exponential increase switch to linear? A: when cwnd gets to 1/2 of its value before timeout. Implementation: variable ssthresh on loss event, ssthresh is set to 1/2 of cwnd just before loss event * Check out the online interactive exercises for more examples: Transport Layer 3-97

97 What happens here? Window stopped growing or shrinking!!! No loss or dup-ack event?!!! Anything to do with flow control? Transport Layer 3-98

98 Transport Layer 3-99

99 Transport Layer 3-100

100 Summary: TCP Congestion Control Λ cwnd = 1 MSS ssthresh = 64 KB dupackcount = 0 timeout ssthresh = cwnd/2 cwnd = 1 MSS dupackcount = 0 retransmit missing segment dupackcount == 3 ssthresh= cwnd/2 cwnd = ssthresh + 3 retransmit missing segment duplicate ACK dupackcount++ slow start New ACK! new ACK cwnd = cwnd+mss dupackcount = 0 transmit new segment(s), as allowed cwnd > ssthresh Λ timeout ssthresh = cwnd/2 cwnd = 1 MSS dupackcount = 0 retransmit missing segment timeout ssthresh = cwnd/2 cwnd = 1 dupackcount = 0 retransmit missing segment fast recovery duplicate ACK new ACK cwnd = cwnd + MSS (MSS/cwnd) dupackcount = 0 transmit new segment(s), as allowed cwnd = ssthresh dupackcount = 0 congestion avoidance New ACK! New ACK cwnd = cwnd + MSS transmit new segment(s), as allowed. New ACK! duplicate ACK dupackcount++ dupackcount == 3 ssthresh= cwnd/2 cwnd = ssthresh + 3 retransmit missing segment Transport Layer 3-101

101 TCP throughput avg. TCP thruput as function of window size, RTT? ignore slow start, assume always data to send W: window size (measured in bytes) where loss occurs avg. window size (# in-flight bytes) is ¾ W avg. thruput is 3/4W per RTT avg TCP thruput = 3 4 W RTT bytes/sec W W/2 Transport Layer 3-102

102 TCP Futures: TCP over long, fat pipes example: 1500 byte segments, 100ms RTT, want 10 Gbps throughput requires W = 83,333 in-flight segments throughput in terms of segment loss probability, L [Mathis 1997]: TCP throughput = MSS RTT L to achieve 10 Gbps throughput, need a loss rate of L = a very small loss rate! new versions of TCP for high-speed Transport Layer 3-103

103 TCP Fairness fairness goal: if K TCP sessions share same bottleneck link of bandwidth R, each should have average rate of R/K TCP connection 1 TCP connection 2 bottleneck router capacity R Transport Layer 3-104

104 Why is TCP fair? two competing sessions: additive increase gives slope of 1, as throughout increases multiplicative decrease decreases throughput proportionally R 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 Connection 1 throughput R Transport Layer 3-105

105 Fairness (more) Fairness and UDP multimedia apps often do not use TCP do not want rate throttled by congestion control instead use UDP: send audio/video at constant rate, tolerate packet loss Fairness, parallel TCP connections application can open multiple parallel connections between two hosts web browsers do this e.g., link of rate R with 9 existing connections: new app asks for 1 TCP, gets rate R/10 new app asks for 11 TCPs, gets R/2 Transport Layer 3-106

106 TCP Synchronization If losses are synchronized TCP flows sharing bottleneck receive loss indications at around the same time decrease rates at around the same time periods where link bandwidth significantly underutilized Transport Layer 3-107

107 Stopping Synchronization Observation: if rate synchronization can be prevented, then bandwidth will be used more efficiently Q: how can the network prevent rate synchronization? Transport Layer 3-108

108 Approaches towards congestion control Implicit end-end congestion control: no explicit feedback from network congestion inferred from endsystem 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 backpressure

109 Explicit congestion signaling Direction Backward Forward Categories Binary Credit-based rate-based

110 Explicit Congestion Notification (ECN) network-assisted congestion control: two bits in IP header (ToS field) marked by network router to indicate congestion congestion indication carried to receiving host receiver (seeing congestion indication in IP datagram) ) sets ECE bit on receiver-to-sender ACK segment to notify sender of congestion source application transport network link physical ECE=1 TCP ACK segment destination application transport network link physical ECN=00 ECN=11 IP datagram Transport Layer 3-111

111 Congestion Avoidance with Explicit Signaling 2 strategies Congestion always occurred slowly, almost always at egress nodes forward explicit congestion avoidance Congestion grew very quickly in internal nodes and required quick action backward explicit congestion avoidance

112 2 Bits for Explicit Signaling Forward Explicit Congestion Notification For traffic in same direction as received frame This frame has encountered congestion Backward Explicit Congestion Notification For traffic in opposite direction of received frame Frames transmitted may encounter congestion

113 Congestion Control strategies Two strategies pre-allocate resources so at to avoid congestion send data and control congestion if (and when) it occurs Two points of implementation hosts at the edges of the network (transport protocol) routers inside the network (queuing discipline)

114 Taxonomy router-centric versus host-centric Attempt to simplify routers reservation-based versus Feedback-based RSVP requires API and application changes window-based versus rate-based ATM has rate based algorithms to specify acceptable rates for each flow. Alternatives include congestion indication where hosts shrink their window.

115 Congestion Avoidance TCP s strategy control congestion once it happens repeatedly increase load in an effort to find the point at which congestion occurs, and then back off Alternative strategy predict when congestion is about to happen reduce rate before packets start being discarded call this congestion avoidance, instead of congestion control Two possibilities

116 DECbit Add binary congestion bit to each packet header Router Queue length monitors average queue length over last busy+idle cycle Current time Previous cycle Averaging interval Current cycle Time

117 End Hosts Destination echoes bit back to source Source records how many packets resulted in set bit If less than 50% of last window s worth had bit set increase CongestionWindow by 1 packet If 50% or more of last window s worth had bit set decrease CongestionWindow by times

118 Random Early Detection (RED) Notification is implicit just drop the packet (TCP will timeout) could make explicit by marking the packet Early random drop rather than wait for queue to become full, drop each arriving packet with some drop probability whenever the queue length exceeds some drop level

119 RED Details Compute average queue length AvgLen = (1 - Weight) * AvgLen + Weight * SampleLen 0 < Weight < 1 (usually 0.002) SampleLen is queue length each time a packet arrives MaxThreshold MinThreshold AvgLen

120 RED Details (cont) Two queue length thresholds if AvgLen <= MinThreshold then enqueue the packet if MinThreshold < AvgLen < MaxThreshold then calculate probability P drop arriving packet with probability P if ManThreshold <= AvgLen then drop arriving packet

121 RED Details (cont) Computing probability P TempP = MaxP * (AvgLen - MinThreshold)/ (MaxThreshold - MinThreshold) P = TempP/(1 - count * TempP) P(drop) Drop Probability Curve 1.0 MaxP AvgLen MinThresh MaxThresh

122 Tuning RED Probability of dropping a particular flow s packet(s) is roughly proportional to the share of the bandwidth that flow is currently getting MaxP is typically set to 0.02, meaning that when the average queue size is halfway between the two thresholds, the gateway drops roughly one out of 50 packets. If traffic id bursty, then MinThreshold should be sufficiently large to allow link utilization to be maintained at an acceptably high level Difference between two thresholds should be larger than the typical increase in the calculated average queue length in one RTT; setting MaxThreshold to twice MinThreshold is reasonable for traffic on today s Internet Penalty Box for Offenders

123 TCP Flavors TCP-Tahoe W=1 adaptation on congestion TCP-Reno W=W/2 adaptation on fast retransmit, W=1 on timeout TCP-newReno TCP-Reno + fast recovery TCP Vegas Uses round-trip time as an early-congestionfeedback mechanism Reduces losses TCP-SACK Selective Acknowledgements

124 TCP Tahoe Slow-start Congestion control upon time-out. Congestion window reduced to 1 and slowstart performed again Simple Congestion control too aggressive It takes a complete timeout interval to detect a packet loss and this empties the pipeline

125 TCP Reno Tahoe + Fast re-transmit Packet loss detected both through timeouts, and through DUP-ACKs On receiving 3 DUP-ACKs retransmit packet and reduce the ssthresh to half of current window and set cwnd to this value. For each DUP-ACK received increase cwnd by one. If cwnd larger than number of packets in transit send new data else wait. In this way the pipe is not emptied. Window cut-down to 1 (and subsequent slow-start) performed only on time-out

126 TCP New-Reno TCP-Reno with more intelligence during fast recovery In TCP-Reno, the first partial ACK will bring the sender out of the fast recovery phase Results in multiple reductions of the cwnd for packets lost in one RTT. In TCP New-Reno, partial ACK is taken as an indication of another lost packet (which is immediately retransmitted). Sender comes out of fast recovery only

127 TCP SACK TCP (Tahoe, Reno, and New-Reno) uses cumulative acknowledgements When there are multiple losses, TCP Reno and New-Reno can retransmit only one lost packet per round-trip time SACK enables receiver to give more information to sender about received packets allowing sender to recover from multiple-packet losses faster

128 TCP SACK (Example) Assume packets 5-25 are transmitted Let packets 5, 12, and 18 be lost Receiver sends back a CACK=5, and SACK=(6-11,13-17,19-25) Sender knows that packets 5, 12, and 18 are lost and retransmits them immediately

129 TCP Vegas Idea: source watches for some sign that some router's queue is building up and congestion will happen soon; e.g., RTT is growing sending rate flattens

130 Algorithm Let BaseRTT be the minimum of all measured RTTs (commonly the RTT of the first packet) if not overflowing the connection, then ExpectedRate = CongestionWindow / BaseRTT source calculates current sending rate (ActualRate) once per RTT source compares ActualRate with ExpectedRate Diff = ExpectedRate ActualRate if Diff < α -->increase CongestionWindow linearly else if Diff >β -->decrease CongestionWindow linearly else -->leave CongestionWindow unchanged

131 Algorithm (cont) Parameters α = 1 packet β = 3 packets Time (seconds) Even faster retransmit keep fine-grained timestamps for each packet check for timeout on first duplicate ACK Time (seconds)

132 Intuition KB Sending KBps Time (seconds) Congestion Window Queue size in router Time (seconds) Time (seconds) Driving on Ice Average send rate at source Average Q length in router

133 Vegas Details Value of throughput with no congestion is compared to current throughput If current difference is smaller, increase window size linearly If current difference is larger, decrease window size linearly The change in the Slow Start Mechanism consists of doubling the window every other RTT, rather than every RTT and of using a boundary in the difference between throughputs to exit the Slow Start phase, rather than a window size value.

134 TCP Performance 1 Utilization of a link with 5 TCP connections Link Utilization Link Capacity (Mbps) Cannot fully utilize the huge capacity of highspeed networks! NS-2 Simulation (100 sec) Link Capacity = 155Mbps, 622Mbps, 2.5Gbps, 5Gbps, 10Gbps, Drop-Tail Routers, 0.1BDP Buffer 5 TCP Connections, 100ms RTT, 1000-Byte Packet Size

135 TCP Congestion Control The instantaneous throughput of TCP is controlled by a variable cwnd, TCP transmits approximately a cwnd number of packets per RTT (Round-Trip Time). cwnd = cwnd + 1 cwnd = cwnd * (1-1/2) cwnd Packet loss Packet loss Packet loss Packet loss TCP Slow start Congestion avoidance Time (RTT)

136 TCP over High-Speed Networks A TCP connection with 1250-Byte packet size and 100ms RTT is running over a 10Gbps link (assuming no other connections, and no buffers at routers) cwnd Packet loss 1.4 hours 1.4 hours 1.4 hours slow increase Packet loss Packet loss Packet loss 100,000 10Gbps big decrease TCP 50,000 5Gbps Slow start Congestion avoidance Time (RTT)

137 STCP (Scalable TCP) STCP adaptively increases cwnd, and decreases cwnd by 1/8. cwnd = cwnd + 1 cwnd = cwnd *cwnd cwnd = cwnd * (1-1/2) cwnd = cwnd * (1-1/8) cwnd Packet loss Packet loss Packet loss Packet loss TCP Slow start Congestion avoidance Time (RTT)

138 HSTCP (High Speed TCP) HSTCP adaptively increases cwnd, and adaptively decreases cwnd. The larger the cwnd, the larger the increment, and the smaller the decrement. cwnd = cwnd + 1 cwnd = cwnd * (1-1/2) cwnd = cwnd + inc(cwnd) cwnd = cwnd * (1-dec(cwnd)) cwnd Packet loss Packet loss Packet loss Packet loss TCP Slow start Congestion avoidance Time (RTT)

139 Some Measurements of Throughput CERN -SARA Using the GÉANT Backup Link 1 GByte file transfers Blue Data Red TCP ACKs Standard TCP Average Throughput 167 Mbit/s Users see 5-50 Mbit/s! High-Speed TCP Average Throughput 345 Mbit/s I/f Rate Mbits/s I/f Rate Mbits/s Standard TCP txlen Jan03 Out Mbit/s 2 In Mbit/s Time Hispeed TCP txlen Jan Out Mbit/s In Mbit/s Time Recv. Rate Mbits/s Recv. Rate Mbits/s Scalable TCP Average Throughput 340 Mbit/s II/f Rate Mbits/s Scalable TCP txlen Jan Out Mbit/s Time In Mbit/s Recv. Rate Mbits/s

140 TCP FAST Packet Losses give binary feedback to the end user. Binary feedback induces oscillations. Need multi-bit feedback to improve performance. Like TCP Vegas FAST TCP uses delays to infer congestion. The window is updated as follows. w= w+ min[2 w, (1 γ) + γ( basertt w+ α)] RTT

141 SC2002 Network OC48 OC192 (Sylvain Ravot, caltech)

142 FAST throughput (averaged over 1hr) 2G 92% 48% Average utilization 1G 95% 19% 27% 16% txq=100 txq=10000 Linux TCP Linux TCP FAST Linux TCP Linux TCP FAST

143 The XCP Protocol Round Trip Round Time Trip Time Congestion Congestion Window Window Feedback Feedback = packet Congestion Header

144 How does XCP Work? Round Trip Time Congestion Window Feedback = packet

145 How does XCP Work? Congestion Window = Congestion Window + Feedback XCP extends ECN and CSFQ Routers compute feedback without any per-flow state

146 How Does an XCP Router Compute the Feedback? Congestion Controller Congestion Goal: Matches input traffic to link capacity & Controller drains the queue Fairness Controller Fairness Goal: Divides between flows to Controller converge to fairness Looks at aggregate traffic & queue MIMD Algorithm: Aggregate traffic changes by ~ Spare Bandwidth ~ - Queue Size So, = α d avg Spare - β Queue Looks at a flow s state in Congestion Header AIMD Algorithm: If > 0 Divide equally between flows If < 0 Divide between flows proportionally to their current rates

147 Getting the devil out of the details Congestion Controller = α d avg Spare - β Queue Theorem: System converges to optimal utilization (i.e., stable) for any link bandwidth, delay, number of sources if: Fairness Controller Algorithm: If > 0 Divide equally between flows If < 0 Divide between flows proportionally to their current rates Need to estimate number of flows N 0 π 2 < α < and β = α N = 1 T ( Cwnd pkt / RTT pkt ) pkts in T No Parameter Tuning (Proof based on Nyquist Criterion) No Per-Flow State RTT pkt : Round Trip Time in header Cwnd pkt : Congestion Window in header T: Counting Interval

148 XCP Remains Efficient as Bandwidth or Delay Increases Utilization as a function of Bandwidth Utilization as a function of Delay Bottleneck Bandwidth (Mb/s) Round Trip Delay (sec)

149 XCP Remains Efficient as Bandwidth or Delay Increases Utilization as a function of Bandwidth Utilization as a function of Delay Bottleneck Bandwidth (Mb/s) Round Trip Delay (sec)

150 The ACP protocol

151 Responses generated by ACP

152 Chapter 3: summary principles behind transport layer services: multiplexing, demultiplexing reliable data transfer flow control congestion control instantiation, implementation in the Internet UDP TCP next: leaving the network edge (application, transport layers) into the network core two network layer chapters: data plane control plane Transport Layer 3-153