Transport Layer (TCP/UDP)
|
|
- Bertina Doyle
- 5 years ago
- Views:
Transcription
1 Transport Layer (TCP/UDP)
2 Recall the protocol stack Application Transport Network Link Physical Programs that use network service Provides end-to-end data delivery Send packets over multiple networks Send frames over one or more links Send bits using signals Computer Networks 2
3 Transport layer Provides end-to-end connectivity to applications Client Transport Network Server Transport Network Host Host CSE 461 University of Washington 3
4 Transport layer protocols Provide different kinds of data delivery across the network to applications Messages Bytestream Unreliable Datagrams (UDP) Reliable Streams (TCP) CSE 461 University of Washington 4
5 Comparison of Internet transports TCP is full-featured, UDP is a glorified packet TCP (Streams) Connections Bytes are delivered once, reliably, and in order Arbitrary length content Flow control matches sender to receiver Congestion control matches sender to network UDP (Datagrams) Datagrams Messages may be lost, reordered, duplicated Limited message size Can send regardless of receiver state Can send regardless of network state CSE 461 University of Washington 5
6 Socket API Simple abstraction to use the network The network API (really Transport service) used to write all Internet apps Part of all major OSes and languages; originally Berkeley (Unix) ~1983 Supports both Internet transport services (Streams and Datagrams) CSE 461 University of Washington 6
7 Socket API (2) Sockets let apps attach to the local network at different ports Socket, Port #1 Socket, Port #2 CSE 461 University of Washington 7
8 Socket API (3) Same API used for Streams and Datagrams Only needed for Streams To/From for Datagrams Primitive Meaning SOCKET Create a new communication endpoint BIND Associate a local address (port) with a socket LISTEN Announce willingness to accept connections ACCEPT Passively establish an incoming connection CONNECT Actively attempt to establish a connection SEND(TO) Send some data over the socket RECEIVE(FROM) Receive some data over the socket CLOSE Release the socket CSE 461 University of Washington 8
9 Ports Application process is identified by the tuple IP address, transport protocol, and port Ports are 16-bit integers representing local mailboxes that a process leases Servers often bind to well-known ports <1024, require administrative privileges Clients often assigned ephemeral ports Chosen by OS, used temporarily CSE 461 University of Washington 9
10 Some Well-Known Ports Port Protocol Use 20, 21 FTP File transfer 22 SSH Remote login, replacement for Telnet 25 SMTP 80 HTTP World Wide Web 110 POP-3 Remote access 143 IMAP Remote access 443 HTTPS Secure Web (HTTP over SSL/TLS) 543 RTSP Media player control 631 IPP Printer sharing CSE 461 University of Washington 10
11 Topics Service models Socket API and ports Datagrams, Streams User Datagram Protocol (UDP) Connections (TCP) Sliding Window (TCP) Flow control (TCP) Retransmission timers (TCP) Congestion control (TCP) CSE 461 University of Washington 11
12 UDP
13 User Datagram Protocol (UDP) Used by apps that don t want reliability or bytestreams Like what? CSE 461 University of Washington 13
14 User Datagram Protocol (UDP) Used by apps that don t want reliability or bytestreams Voice-over-IP DNS DHCP (If application wants reliability and messages then it has work to do!) CSE 461 University of Washington 14
15 Datagram Sockets Client (host 1) Time Server (host 2) request reply CSE 461 University of Washington 15
16 Datagram Sockets (2) Client (host 1) Time Server (host 2) 1: socket 4: sendto request 1: socket 2: bind 3: recvfrom* 5: recvfrom* reply 6: sendto 7: close 7: close *= call blocks CSE 461 University of Washington 16
17 UDP Buffering Application App App App Ports Transport (UDP) Message queues Network (IP) Port Mux/Demux packet CSE 461 University of Washington 17
18 UDP Header Uses ports to identify sending and receiving application processes Datagram length up to 64K Checksum (16 bits) for reliability CSE 461 University of Washington 18
19 UDP Header (2) Optional checksum covers UDP segment and IP pseudoheader Checks key IP fields (addresses) Value of zero means no checksum CSE 461 University of Washington 19
20 TCP
21 TCP TCP Consists of 3 primary phases: Connection Establishment (Setup) Sliding Windows/Flow Control Connection Release (Teardown)
22 Connection Establishment Both sender and receiver must be ready before we start the transfer of data Need to agree on a set of parameters e.g., the Maximum Segment Size (MSS) This is signaling It sets up state at the endpoints Like dialing for a telephone call CSE 461 University of Washington 22
23 Three-Way Handshake Used in TCP; opens connection for data in both directions Each side probes the other with a fresh Initial Sequence Number (ISN) Sends on a SYNchronize segment Echo on an ACKnowledge segment Chosen to be robust even against delayed duplicates Active party (client) Passive party (server) CSE 461 University of Washington 23
24 Three-Way Handshake (2) Three steps: Client sends SYN(x) Server replies with SYN(y)ACK(x+1) Client replies with ACK(y+1) SYNs are retransmitted if lost Sequence and ack numbers carried on further segments Active party (client) 1 SYN (SEQ=x) 2 SYN (SEQ=y, ACK=x+1) Time 3 (SEQ=x+1, ACK=y+1) Passive party (server) CSE 461 University of Washington 24
25 Three-Way Handshake (3) Suppose delayed, duplicate copies of the SYN and ACK arrive at the server! Improbable, but anyhow Active party (client) SYN (SEQ=x) Passive party (server) (SEQ=x+1, ACK=z+1) CSE 461 University of Washington 25
26 Three-Way Handshake (4) Suppose delayed, duplicate copies of the SYN and ACK arrive at the server! Improbable, but anyhow Connection will be cleanly rejected on both sides J Active party (client) X REJECT SYN (SEQ=x) SYN (SEQ=y, ACK=x+1) (SEQ=x+1, ACK=z+1) Passive party (server) X REJECT CSE 461 University of Washington 26
27 TCP Connection State Machine Captures the states ([]) and transitions (->) A/B means event A triggers the transition, with action B Both parties run instances of this state machine
28 TCP Connections (2) Follow the path of the client:
29 TCP Connections (3) And the path of the server:
30 TCP Connections (4) Again, with states Active party (client) CLOSED SYN_SENT 1 SYN (SEQ=x) Passive party (server) CLOSED LISTEN ESTABLISHED 2 SYN (SEQ=y, ACK=x+1) 3 (SEQ=x+1, ACK=y+1) SYN_RCVD Time ESTABLISHED CSE 461 University of Washington 30
31 TCP Connections (5) Finite state machines are a useful tool to specify and check the handling of all cases that may occur TCP allows for simultaneous open i.e., both sides open instead of the client-server pattern Try at home to confirm it works J CSE 461 University of Washington 31
32 Connection Release Orderly release by both parties when done Delivers all pending data and hangs up Cleans up state in sender and receiver Key problem is to provide reliability while releasing TCP uses a symmetric close in which both sides shutdown independently CSE 461 University of Washington 32
33 TCP Connection Release Two steps: Active sends FIN(x), passive ACKs Passive sends FIN(y), active ACKs FINs are retransmitted if lost Active party Passive party Each FIN/ACK closes one direction of data transfer CSE 461 University of Washington 33
34 TCP Connection Release (2) Two steps: Active sends FIN(x), passive ACKs Passive sends FIN(y), active ACKs FINs are retransmitted if lost Each FIN/ACK closes one direction of data transfer Active party FIN (SEQ=x) 1 (SEQ=y, ACK=x+1) FIN (SEQ=y, ACK=x+1) 2 (SEQ=x+1, ACK=y+1) Passive party CSE 461 University of Washington 34
35 TCP Connection State Machine Both parties run instances of this state machine CSE 461 University of Washington 35
36 TCP Release Follow the active party CSE 461 University of Washington 36
37 TCP Release (2) Follow the passive party CSE 461 University of Washington 37
38 TCP Release (3) Again, with states Active party ESTABLISHED FIN_WAIT_1 FIN_WAIT_2 FIN (SEQ=x) TIME_WAIT (timeout) CLOSED CLOSED 1 (SEQ=y, ACK=x+1) FIN (SEQ=y, ACK=x+1) 2 (SEQ=x+1, ACK=y+1) Passive party ESTABLISHED CLOSE_WAIT LAST_ACK CSE 461 University of Washington 38
39 TIME_WAIT State Wait a long time after sending all segments and before completing the close Two times the maximum segment lifetime of 60 seconds Why? CSE 461 University of Washington 39
40 TIME_WAIT State Wait a long time after sending all segments and before completing the close Two times the maximum segment lifetime of 60 seconds Why? ACK might have been lost, in which case FIN will be resent for an orderly close Could otherwise interfere with a subsequent connection CSE 461 University of Washington 40
41 Flow Control
42 Flow control goal Match transmission speed to reception capacity Otherwise data will be lost
43 ARQ: Automatic repeat query ARQ with one message at a time is Stop-and-Wait Timeout Sender Receiver Frame 0 ACK 0 Time Frame 1 ACK 1 CSE 461 University of Washington 43
44 Limitation of Stop-and-Wait It allows only a single message to be outstanding from the sender: Fine for LAN (only one frame fits in network anyhow) Not efficient for network paths with longer delays CSE 461 University of Washington 44
45 Limitation of Stop-and-Wait (2) Example: B=1 Mbps, D = 50 ms, 10kb packets RTT (Round Trip Time) = 2D = 100 ms How many packets/sec? 10 Usage efficiency if packet is 10kb? (10,000 x 10) / (1 x 10 6 ) = 10% What is the efficient B=10 Mbps? 1% CSE 461 University of Washington 45
46 Sliding Window Generalization of stop-and-wait Allows W packets to be outstanding Can send W packets per RTT (=2D) Pipelining improves performance Need W=2BD to fill network path CSE 461 University of Washington 46
47 Sliding Window (2) What W will use the network capacity with 10kb packets? Ex: B=1 Mbps, D = 50 ms 2BD = 2 x 10 6 x 50/1000 = 100 Kb W = 100 kb/10 = 10 packets Ex: What if B=10 Mbps? W = 100 packets CSE 461 University of Washington 47
48 Sliding Window Protocol Many variations, depending on how buffers, acknowledgements, and retransmissions are handled Go-Back-N Simplest version, can be inefficient Selective Repeat More complex, better performance CSE 461 University of Washington 48
49 Sender Sliding Window Sender buffers up to W segments until they are acknowledged LFS=LAST FRAME SENT, LAR=LAST ACK REC D Sends while LFS LAR W Sliding Window W=5 Available.. 5Acked Unacked Unavailable LAR LFS seq. number CSE 461 University of Washington 49
50 Sender Sliding Window (2) Transport accepts another segment of data from the Application... Transport sends it (LFS LAR à 5) Sliding Window W=5 Sent.. 5Acked Unacked Unavailable LAR LFS seq. number CSE 461 University of Washington 50
51 Sender Sliding Window (3) Next higher ACK arrives from peer Window advances, buffer is freed LFS LAR à 4 (can send one more) Sliding Window W=5 Available.. 5Acked Unacked Unavailable LAR LFS seq. number CSE 461 University of Washington 51
52 Receiver Sliding Window Go-Back-N Receiver keeps only a single packet buffer for the next segment State variable, LAS = LAST ACK SENT On receive: If seq. number is LAS+1, accept and pass it to app, update LAS, send ACK Otherwise discard (as out of order) CSE 461 University of Washington 52
53 Receiver Sliding Window Selective Repeat Receiver passes data to app in order, and buffers out-oforder segments to reduce retransmissions ACK conveys highest in-order segment, plus hints about outof-order segments Ex: I got everything up to 42 (LAS), and got 44, 45 TCP uses a selective repeat design; we ll see the details later CSE 461 University of Washington 53
54 Receiver Sliding Window Selective Repeat (2) Buffers W segments, keeps state variable LAS = LAST ACK SENT On receive: Buffer segments [LAS+1, LAS+W] Send app in-order segments from LAS+1, and update LAS Send ACK for LAS regardless CSE 461 University of Washington 54
55 Sender Sliding Window Selective Repeat Keep normal sliding window If out-of-order ACK arrives Send LAR again! Sliding Window W=5 Ack Arrives Out of Order!.. 5Acked Unacked Unavailable LAR again LFS seq. number CSE 461 University of Washington 55
56 Sender Sliding Window Selective Repeat (2) Keep normal sliding window If in-order ACK arrives Move window and LAR, send more messages Sliding Window W=5 In-order ack arrives Now Available.. 5Acked Unacked LAR LFS seq. number CSE 461 University of Washington 56
57 Sliding Window Retransmissions Go-Back-N uses a single timer to detect losses On timeout, resends buffered packets starting at LAR+1 Selective Repeat uses a timer per unacked segment to detect losses On timeout for segment, resend it Hope to resend fewer segments CSE 461 University of Washington 57
58 Sequence Numbers Need more than 0/1 for Stop-and-Wait but how many? For Selective Repeat: 2W seq numbers W for packets, plus W for earlier acks For Go-Back-N: W+1 sequence numbers Typically implement seq. number with an N-bit counter that wraps around at 2 N 1 E.g., N=8:, 253, 254, 255, 0, 1, 2, 3, CSE 461 University of Washington 58
59 Sequence Time Plot Seq. Number Transmissions (at Sender) Delay (=RTT/2) Acks (at Receiver) Time CSE 461 University of Washington 59
60 Sequence Time Plot (2) Go-Back-N scenario Seq. Number Time CSE 461 University of Washington 60
61 Sequence Time Plot (3) Retransmissions Seq. Number Loss Timeout Time CSE 461 University of Washington 61
62 ACK Clocking
63 Sliding Window ACK Clock Typically, the sender does not know B or D Each in-order ACK advances the sliding window and lets a new segment enter the network ACKs clock data segments Data Ack CSE 461 University of Washington 63
64 Benefit of ACK Clocking Consider what happens when sender injects a burst of segments into the network Queue Fast link Slow (bottleneck) link Fast link CSE 461 University of Washington 64
65 Benefit of ACK Clocking (2) Segments are buffered and spread out on slow link Segments spread out Fast link Slow (bottleneck) link Fast link CSE 461 University of Washington 65
66 Benefit of ACK Clocking (3) ACKs maintain the spread back to the original sender Slow link Acks maintain spread CSE 461 University of Washington 66
67 Benefit of ACK Clocking (4) Sender clocks new segments with the spread Now sending at the bottleneck link without queuing! Segments spread Queue no longer builds Slow link CSE 461 University of Washington 67
68 Benefit of ACK Clocking (4) Helps run with low levels of loss and delay! The network smooths out the burst of data segments ACK clock transfers this smooth timing back to sender Subsequent data segments are not sent in bursts so do not queue up in the network CSE 461 University of Washington 68
69 TCP Uses ACK Clocking TCP uses a sliding window because of the value of ACK clocking Sliding window controls how many segments are inside the network TCP only sends small bursts of segments to let the network keep the traffic smooth CSE 461 University of Washington 69
70 Problem Sliding window has pipelining to keep network busy What if the receiver is overloaded? Arg Big Iron Streaming video Wee Mobile CSE 461 University of Washington 70
71 Receiver Sliding Window Consider receiver with W buffers LAS=LAST ACK SENT app pulls in-order data from buffer with recv() call Sliding Window W=5.. 5Finished Acceptable Too 3 high LAS seq. number CSE 461 University of Washington 71
72 Receiver Sliding Window (2) Suppose the next two segments arrive but app does not call recv() W=5.. 5Finished Acceptable Too 3 high LAS seq. number CSE 461 University of Washington 72
73 Receiver Sliding Window (3) Suppose the next two segments arrive but app does not call recv() LAS rises, but we can t slide window! W=5.. 5Finished 6 7 Acked Too 3 high LAS seq. number CSE 461 University of Washington 73
74 Receiver Sliding Window (4) Further segments arrive (in order) we fill buffer Must drop segments until app recvs! W=5 Nothing Acceptable!.. 5Finished 6 7 Acked Too 3 high LAS seq. number CSE 461 University of Washington 74
75 Receiver Sliding Window (5) App recv() takes two segments Window slides (phew) W=5 Acceptable.. 5Finished Acked LAS seq. number CSE 461 University of Washington 75
76 Flow Control Avoid loss at receiver by telling sender the available buffer space WIN=#Acceptable, not W (from LAS) W=5 Acceptable.. 5Finished Acked LAS seq. number CSE 461 University of Washington 76
77 Flow Control (2) Sender uses lower of the sliding window and flow control window (WIN) as the effective window size W=3 Acceptable.. 5Finished 6 7 Acked Too 3 high LAS seq. number CSE 461 University of Washington 77
78 Flow Control (3) TCP-style example SEQ/ACK sliding window Flow control with WIN SEQ + length < ACK+WIN 4KB buffer at receiver Circular buffer of bytes CSE 461 University of Washington 78
79 Topic How to set the timeout for sending a retransmission Adapting to the network path Lost? Network CSE 461 University of Washington 79
80 Retransmissions With sliding window, detecting loss with timeout Set timer when a segment is sent Cancel timer when ack is received If timer fires, retransmit data as lost Retransmit! CSE 461 University of Washington 80
81 Timeout Problem Timeout should be just right Too long à inefficient network capacity use Too short à spurious resends waste network capacity But what is just right? Easy to set on a LAN (Link) Short, fixed, predictable RTT Hard on the Internet (Transport) Wide range, variable RTT CSE 461 University of Washington 81
82 Example of RTTs BCNàSEAàBCN Round Trip Time (ms) Seconds CSE 461 University of Washington 82
83 Example of RTTs (2) Round Trip Time (ms) BCNàSEAàBCN Variation due to queuing at routers, changes in network paths, etc. Propagation (+transmission) delay 2D Seconds CSE 461 University of Washington 83
84 Example of RTTs (3) Round Trip Time (ms) Timer too high! Need to adapt to the network conditions Timer too low! Seconds CSE 461 University of Washington 84
85 Adaptive Timeout Smoothed estimates of the RTT (1) and variance in RTT (2) Update estimates with a moving average 1. SRTT N+1 = 0.9*SRTT N + 0.1*RTT N+1 2. Svar N+1 = 0.9*Svar N + 0.1* RTT N+1 SRTT N+1 Set timeout to a multiple of estimates To estimate the upper RTT in practice TCP Timeout N = SRTT N + 4*Svar N CSE 461 University of Washington 85
86 Example of Adaptive Timeout RTT (ms) SRTT Svar Seconds CSE 461 University of Washington 86
87 Example of Adaptive Timeout (2) Early timeout Timeout (SRTT + 4*Svar) RTT (ms) Seconds CSE 461 University of Washington 87
88 Adaptive Timeout (2) Simple to compute, does a good job of tracking actual RTT Little headroom to lower Yet very few early timeouts Turns out to be important for good performance and robustness CSE 461 University of Washington 88
89 Congestion
90 TCP to date: We can set up and tear connections Connection establishment and release handshakes Keep the sending and receiving buffers from overflowing (flow control) What s missing?
91 Network Congestion A traffic jam in the network Later we will learn how to control it What s the hold up? Network CSE 461 University of Washington 91
92 Congestion Collapse in the 1980s Early TCP used fixed size window (e.g., 8 packets) Initially fine for reliability But something happened as the network grew Links stayed busy but transfer rates fell by orders of magnitude! CSE 461 University of Washington 92
93 Nature of Congestion Routers/switches have internal buffering Input Output Input Buffer Fabric Output Buffer CSE 461 University of Washington 93
94 Nature of Congestion (2) Simplified view of per port output queues Typically FIFO (First In First Out), discard when full Router Router = (FIFO) Queue Queued Packets CSE 461 University of Washington 94
95 Nature of Congestion (3) Queues help by absorbing bursts when input > output rate But if input > output rate persistently, queue will overflow This is congestion Congestion is a function of the traffic patterns can occur even if every link has the same capacity CSE 461 University of Washington 95
96 Effects of Congestion What happens to performance as we increase load?
97 Effects of Congestion (2) What happens to performance as we increase load?
98 Effects of Congestion (3) As offered load rises, congestion occurs as queues begin to fill: Delay and loss rise sharply with load Throughput < load (due to loss) Goodput << throughput (due to spurious retransmissions) None of the above is good! Want network performance just before congestion CSE 461 University of Washington 98
99 TCP Tahoe/Reno TCP extensions and features we will study: AIMD Fair Queuing Slow-start Fast Retransmission Fast Recovery CSE 461 University of Washington 100
100 TCP Timeline 3-way handshake (Tomlinson, 75) Origins of TCP (Cerf & Kahn, 74) TCP/IP flag day (BSD Unix 4.2, 83) TCP and IP (RFC 791/793, 81) Congestion collapse Observed, TCP Reno (Jacobson, 90) TCP Tahoe (Jacobson, 88) Pre-history Congestion control CSE 461 University of Washington 101
101 TCP Timeline (2) Delay based TCP Reno (Jacobson, 90) ECN (Floyd, 94) TCP Vegas (Brakmo, 93) Router support TCP with SACK (Floyd, 96) TCP New Reno (Hoe, 95) FAST TCP (Low et al., 04) Background TCP BIC (Linux, 04 TCP LEDBAT (IETF 08) Compound TCP (Windows, 07) TCP CUBIC (Linux, 06) Classic congestion control Diversification CSE 461 University of Washington 102
102 Bandwidth Allocation Important task for network is to allocate its capacity to senders Good allocation is both efficient and fair Efficient: most capacity is used but there is no congestion Fair: every sender gets a reasonable share of the network CSE 461 University of Washington 103
103 Efficiency vs. Fairness Cannot always have both! Example network with traffic: AàB, BàC and AàC How much traffic can we carry? A B C 1 1 CSE 461 University of Washington 104
104 Efficiency vs. Fairness (2) If we care about fairness: Give equal bandwidth to each flow AàB: ½ unit, BàC: ½, and AàC, ½ Total traffic carried is 1 ½ units A B C 1 1 CSE 461 University of Washington 105
105 Efficiency vs. Fairness (3) If we care about efficiency: Maximize total traffic in network AàB: 1 unit, BàC: 1, and AàC, 0 Total traffic rises to 2 units! A B C 1 1 CSE 461 University of Washington 106
106 Fairness What s a fair bandwidth allocation? The max-min fair allocation CSE 461 University of Washington 107
107 The Slippery Notion of Fairness Why is equal per flow fair anyway? AàC uses more network resources than AàB or BàC Host A sends two flows, B sends one Not productive to seek exact fairness More important to avoid starvation A node that cannot use any bandwidth Equal per flow is good enough CSE 461 University of Washington 108
108 Generalizing Equal per Flow Bottleneck for a flow of traffic is the link that limits its bandwidth Where congestion occurs for the flow For AàC, link A B is the bottleneck A B C 1 10 Bottleneck CSE 461 University of Washington 109
109 Generalizing Equal per Flow (2) Flows may have different bottlenecks For AàC, link A B is the bottleneck For BàC, link B C is the bottleneck Can no longer divide links equally A B C 1 10 CSE 461 University of Washington 110
110 Max-Min Fairness Intuitively, flows bottlenecked on a link get an equal share of that link Max-min fair allocation is one that: Increasing the rate of one flow will decrease the rate of a smaller flow This maximizes the minimum flow CSE 461 University of Washington 111
111 Max-Min Fairness (2) To find it given a network, imagine pouring water into the network 1. Start with all flows at rate 0 2. Increase the flows until there is a new bottleneck in the network 3. Hold fixed the rate of the flows that are bottlenecked 4. Go to step 2 for any remaining flows CSE 461 University of Washington 112
112 Max-Min Example Example: network with 4 flows, link bandwidth = 1 What is the max-min fair allocation? CSE 461 University of Washington 113
113 Max-Min Example (2) When rate=1/3, flows B, C, and D bottleneck R4 R5 Fix B, C, and D, continue to increase A Bottleneck Bottleneck CSE 461 University of Washington 114
114 Max-Min Example (3) When rate=2/3, flow A bottlenecks R2 R3. Done. Bottleneck Bottleneck CSE 461 University of Washington 115
115 Max-Min Example (4) End with A=2/3, B, C, D=1/3, and R2 R3, R4 R5 full Other links have extra capacity that can t be used, linksxample: network with 4 flows, links equal bandwidth What is the max-min fair allocation? CSE 461 University of Washington 116
116 Adapting over Time Allocation changes as flows start and stop Time CSE 461 University of Washington 117
117 Adapting over Time (2) Flow 1 slows when Flow 2 starts Flow 1 speeds up when Flow 2 stops Flow 3 limit is elsewhere Time CSE 461 University of Washington 118
118 Recall the goals of bandwidth allocation Want to allocate capacity to senders Network layer provides feedback Transport layer adjusts offered load A good allocation is efficient and fair CSE 461 University of Washington 119
119 Why is Bandwidth Allocation hard? Number of senders and their offered load changes Senders may be limited in other ways Other parts of network or by applications Network is distributed; no single party has an overall picture of its state CSE 461 University of Washington 120
120 Bandwidth Allocation Models Open loop versus closed loop Open: reserve bandwidth before use Closed: use feedback to adjust rates Host versus Network support Who is sets/enforces allocations? Window versus Rate based How is allocation expressed? TCP is a closed loop, host-driven, and window-based CSE 461 University of Washington 123
121 Bandwidth Allocation Models (2) We ll study closed-loop, host-driven, and windowbased too Network layer returns feedback on current allocation to senders At least tells if there is congestion Transport layer adjusts sender s behavior via window in response How senders adapt is a control law CSE 461 University of Washington 124
122 Additive Increase Multiplicative Decrease AIMD is a control law hosts can use to reach a good allocation Hosts additively increase rate while network not congested Hosts multiplicatively decrease rate when congested Used by TCP Let s explore the AIMD game CSE 461 University of Washington 125
123 AIMD Game Hosts 1 and 2 share a bottleneck But do not talk to each other directly Router provides binary feedback Tells hosts if network is congested Host 1 Host Router Bottleneck 1 Rest of Network CSE 461 University of Washington 126
124 AIMD Game (2) Each point is a possible allocation Host 1 1 Congested Fair Optimal Allocation Efficient 0 1 Host 2 CSE 461 University of Washington 127
125 AIMD Game (3) AI and MD move the allocation Host 1 1 Congested Additive Increase Multiplicative Decrease Fair, y=x Optimal Allocation Efficient, x+y=1 0 1 Host 2 CSE 461 University of Washington 128
126 AIMD Game (4) Play the game! Host 1 1 Congested A starting point Fair Efficient 0 1 Host 2 CSE 461 University of Washington 129
127 AIMD Game (5) Always converge to good allocation! Host 1 1 Congested A starting point Fair Efficient 0 1 Host 2 CSE 461 University of Washington 130
128 AIMD Sawtooth Produces a sawtooth pattern over time for rate of each host This is the TCP sawtooth (later) Host 1 or 2 s Rate Multiplicative Decrease Additive Increase Time CSE 461 University of Washington 131
129 AIMD Properties Converges to an allocation that is efficient and fair when hosts run it Holds for more general topologies Other increase/decrease control laws do not! (Try MIAD, MIMD, MIAD) Requires only binary feedback from the network CSE 461 University of Washington 132
130 Feedback Signals Several possible signals, with different pros/cons We ll look at classic TCP that uses packet loss as a signal Signal Example Protocol Pros / Cons Packet loss Packet delay Router indication TCP NewReno Cubic TCP (Linux) Compound TCP (Windows) TCPs with Explicit Congestion Notification Hard to get wrong Hear about congestion late Other events can cause loss Hear about congestion early Need to infer congestion Hear about congestion early Require router support CSE 461 University of Washington 133
131 Slow Start (TCP Additive Increase)
132 What we know about TCP so far Connection establishment 3-way handshake Connection release FIN/ACK for each direction Flow control Sliding windows Congestion control basics Max-min fairness, AIMD This lecture: TCP congestion control in practice
133 TCP congestion control overview Follows AIMD control law for a good allocation Sender uses a congestion window or cwnd to set its rate ( cwnd/rtt) Sender uses loss as network congestion signal Designed to work across a very large range of rates and RTTs CSE 461 University of Washington 136
134 TCP Slow Start Problem We want to quickly near the right rate, cwnd IDEAL, but it varies greatly Fixed sliding window doesn t adapt and is rough on the network (loss!) Additive Increase with small bursts adapts cwnd gently, but might take a long time to become efficient CSE 461 University of Washington 137
135 Slow-Start Solution Start by doubling cwnd every RTT Exponential growth (1, 2, 4, 8, 16, ) Start slow, quickly reach large values Window (cwnd) Fixed Slow-start AI Time 138
136 Slow-Start Solution (2) Eventually packet loss will occur when the network is congested Loss timeout tells us cwnd is too large Next time, switch to AI beforehand Slowly adapt cwnd near right value In terms of cwnd: Expect loss for cwnd C 2BD+queue Use ssthresh = cwnd C /2 to switch to AI CSE 461 University of Washington 139
137 Slow-Start Solution (3) Combined behavior, after first time Most time spent near right value Window cwnd C cwnd IDEAL ssthresh Fixed Slow-start AI phase AI Time 140
138 Slow-Start (Doubling) Timeline Increment cwnd by 1 packet for each ACK CSE 461 University of Washington 141
139 Additive Increase Timeline Increment cwnd by 1 packet every cwnd ACKs (or 1 RTT) CSE 461 University of Washington 142
140 TCP Tahoe (Implementation) Initial slow-start (doubling) phase Start with cwnd = 1 (or small value) cwnd += 1 packet per ACK Later Additive Increase phase cwnd += 1/cwnd packets per ACK Roughly adds 1 packet per RTT Switching threshold (initially infinity) Switch to AI when cwnd > ssthresh Set ssthresh = cwnd/2 after loss Begin with slow-start after timeout CSE 461 University of Washington 143
141 Timeout Misfortunes Why do a slow-start after timeout? Instead of MD cwnd (for AIMD) Timeouts are sufficiently long that the ACK clock will have run down Slow-start ramps up the ACK clock We need to detect loss before a timeout to get to full AIMD CSE 461 University of Washington 144
142 Fast Recovery (TCP Multiplicative Decrease)
143 Inferring Loss from ACKs TCP uses a cumulative ACK Carries highest in-order seq. number Normally a steady advance Duplicate ACKs give us hints about what data hasn t arrived Tell us some new data did arrive, but it was not next segment Thus the next segment may be lost CSE 461 University of Washington 146
144 Fast Retransmit Treat three duplicate ACKs as a loss Retransmit next expected segment Some repetition allows for reordering, but still detects loss quickly Ack CSE 461 University of Washington 147
145 Fast Retransmit (2) Third duplicate ACK, so send 14 ACK jumps after loss is repaired Ack 10 Ack 11 Ack 12 Ack 13 Ack 13 Ack 13 Ack 13 Ack Ack Data 20 Data 14 Data 14 was lost earlier, but got 15 to 20 Retransmission fills in the hole at 14 CSE 461 University of Washington 148
146 Fast Retransmit (3) It can repair single segment loss quickly, typically before a timeout However, we have quiet time at the sender/receiver while waiting for the ACK to jump And we still need to MD cwnd CSE 461 University of Washington 149
147 Inferring Non-Loss from ACKs Duplicate ACKs also give us hints about what data has arrived Each new duplicate ACK means that some new segment has arrived It will be the segments after the loss Thus advancing the sliding window will not increase the number of segments stored in the network CSE 461 University of Washington 150
148 Fast Recovery First fast retransmit, and MD cwnd Then pretend further duplicate ACKs are the expected ACKs Lets new segments be sent for ACKs Reconcile views when the ACK jumps Ack CSE 461 University of Washington 151
149 Fast Recovery (2) Third duplicate ACK, so send 14 Set ssthresh, cwnd = cwnd/2 More ACKs advance window; may send segments before jump Ack 12 Ack 13 Ack 13 Ack 13 Ack 13 Ack 13 Ack 13 Ack Exit Fast Recovery Data 20 Data 14 Data 21 Data 22 Data 14 was lost earlier, but got 15 to 20 Retransmission fills in the hole at 14 CSE 461 University of Washington 152
150 Fast Recovery (3) With fast retransmit, it repairs a single segment loss quickly and keeps the ACK clock running This allows us to realize AIMD No timeouts or slow-start after loss, just continue with a smaller cwnd TCP Reno combines slow-start, fast retransmit and fast recovery Multiplicative Decrease is ½ CSE 461 University of Washington 153
151 TCP Reno TCP sawtooth MD of ½, no slow-start ACK clock running CSE 461 University of Washington 154
152 TCP Reno, NewReno, and SACK Reno can repair one loss per RTT Multiple losses cause a timeout NewReno further refines ACK heuristics Repairs multiple losses without timeout Selective ACK (SACK) is a better idea Receiver sends ACK ranges so sender can retransmit without guesswork CSE 461 University of Washington 155
153 Network-Assisted Congestion Control
154 Congestion Avoidance vs. Control Classic TCP drives the network into congestion and then recovers Needs to see loss to slow down Would be better to use the network but avoid congestion altogether! Reduces loss and delay But how can we do this? CSE 461 University of Washington 157
155 Feedback Signals Delay and router signals can let us avoid congestion Signal Example Protocol Pros / Cons Packet loss Packet delay Router indication Classic TCP Cubic TCP (Linux) Compound TCP (Windows) TCPs with Explicit Congestion Notification Hard to get wrong Hear about congestion late Other events can cause loss Hear about congestion early Need to infer congestion Hear about congestion early Require router support CSE 461 University of Washington 158
156 ECN (Explicit Congestion Notification) Router detects the onset of congestion via its queue When congested, it marks affected packets (IP header) CSE 461 University of Washington 159
157 ECN (2) Marked packets arrive at receiver TCP receiver informs TCP sender of the congestion CSE 461 University of Washington 160
158 ECN (3) Advantages: Routers deliver clear signal to hosts Congestion is detected early, no loss No extra packets need to be sent Disadvantages: Routers and hosts must be upgraded CSE 461 University of Washington 161
159 Recent transport layer developments (1) QUIC
160 Recent transport layer developments (2) Multipath TCP (MPTCP) By Aclarembeau - Own work, CC BY-SA 4.0,
Operating Systems and Networks. Network Lecture 8: Transport Layer. Adrian Perrig Network Security Group ETH Zürich
Operating Systems and Networks Network Lecture 8: Transport Layer Adrian Perrig Network Security Group ETH Zürich I was going to tell you a joke about UDP, but I wasn t sure if you were going to get it
More informationOperating Systems and Networks. Network Lecture 8: Transport Layer. Where we are in the Course. Recall. Transport Layer Services.
Operating Systems and s Lecture 8: Transport Layer I was going to tell you a joke about UDP, but I wasn t sure if you were going to get it Adrian Perrig Security Group ETH Zürich 2 Where we are in the
More informationOperating Systems and Networks. Network Lecture 10: Congestion Control. Adrian Perrig Network Security Group ETH Zürich
Operating Systems and Networks Network Lecture 10: Congestion Control Adrian Perrig Network Security Group ETH Zürich Where we are in the Course More fun in the Transport Layer! The mystery of congestion
More informationWhere we are in the Course. Topic. Nature of Congestion. Nature of Congestion (3) Nature of Congestion (2) Operating Systems and Networks
Operating Systems and Networks Network Lecture 0: Congestion Control Adrian Perrig Network Security Group ETH Zürich Where we are in the Course More fun in the Transport Layer! The mystery of congestion
More informationTransport Layer (TCP/UDP)
Transport Layer (TCP/UDP) Where we are in the Course Moving on up to the Transport Layer! Application Transport Network Link Physical CSE 461 University of Washington 2 Three-Way Handshake (3) Suppose
More informationTransport Layer (TCP/UDP)
Transport Layer (TCP/UDP) Where we are in the Course Moving on up to the Transport Layer! Application Transport Network Link Physical CSE 461 University of Washington 2 Recall Transport layer provides
More informationTransport Layer (TCP/UDP)
Transport Layer (TCP/UDP) Where we are in the Course Moving on up to the Transport Layer! Application Transport Network Link Physical CSE 461 University of Washington 2 Recall Transport layer provides
More informationTransport Layer (Congestion Control)
Transport Layer (Congestion Control) Where we are in the Course Moving on up to the Transport Layer! Application Transport Network Link Physical CSE 461 University of Washington 2 Congestion Collapse Congestion
More informationCongestion Collapse in the 1980s
Congestion Collapse Congestion Collapse in the 1980s Early TCP used fixed size window (e.g., 8 packets) Initially fine for reliability But something happened as the ARPANET grew Links stayed busy but transfer
More informationTransport Layer (TCP/UDP)
Transport Layer (TCP/UDP) Where we are in the Course Moving on up to the Transport Layer! Application Transport Network Link Physical CSE 461 University of Washington 2 Recall Transport layer provides
More informationComputer Networks (Honor Track)
04832250 Computer Networks (Honor Track) A Data Communication and Device Networking Perspective Module 5: End-to-End Transport Prof. Chenren Xu Center for Energy-efficient Computing and Applications Computer
More informationRecap. TCP connection setup/teardown Sliding window, flow control Retransmission timeouts Fairness, max-min fairness AIMD achieves max-min fairness
Recap TCP connection setup/teardown Sliding window, flow control Retransmission timeouts Fairness, max-min fairness AIMD achieves max-min fairness 81 Feedback Signals Several possible signals, with different
More informationTransport Layer (Congestion Control)
Transport Layer (Congestion Control) Where we are in the Course Moving on up to the Transport Layer! Application Transport Network Link Physical CSE 461 University of Washington 2 TCP to date: We can set
More informationComputer Networks. Course Reference Model. Topic. Congestion What s the hold up? Nature of Congestion. Nature of Congestion 1/5/2015.
Course Reference Model Computer Networks 7 Application Provides functions needed by users Zhang, Xinyu Fall 204 4 Transport Provides end-to-end delivery 3 Network Sends packets over multiple links School
More informationOpera&ng Systems and Networks. Network Lecture 8: Transport Layer. Adrian Perrig Network Security Group ETH Zürich
Opera&ng Systems and Networks Network Lecture 8: Transport Layer Adrian Perrig Network Security Group ETH Zürich Where we are in the Course Star&ng the Transport Layer! Builds on the network layer to deliver
More informationWhere we are in the Course
Where we are in the Course Star9ng the Transport Layer! Builds on the network layer to deliver data across networks for applica9ons with the desired reliability or quality Applica9on Transport Network
More informationOpera&ng Systems and Networks. Network Lecture 10: Conges&on Control. Adrian Perrig Network Security Group ETH Zürich
Opera&ng Systems and Networks Network Lecture 10: Conges&on Control Adrian Perrig Network Security Group ETH Zürich Thursday Announcements 15:15 16:00 assignment 9 16:15 17:00 project 2 presenta=on + Q&A
More informationCSEP 561 Connections. David Wetherall
CSEP 561 Connections David Wetherall djw@cs.washington.edu Connections Focus How do we (reliably) connect processes? This is the transport layer Topics Naming processes Connection setup / teardown Sliding
More informationCSEP 561 Connections. David Wetherall
CSEP 561 Connections David Wetherall djw@cs.washington.edu Connections Focus How do we (reliably) connect processes? This is the transport layer Topics Naming processes TCP / UDP Connection setup / teardown
More informationConnections. Topics. Focus. Presentation Session. Application. Data Link. Transport. Physical. Network
Connections Focus How do we connect processes? This is the transport layer Topics Naming processes Connection setup / teardown Flow control Application Presentation Session Transport Network Data Link
More informationAnnouncements Computer Networking. Outline. Transport Protocols. Transport introduction. Error recovery & flow control. Mid-semester grades
Announcements 15-441 Computer Networking Lecture 16 Transport Protocols Mid-semester grades Based on project1 + midterm + HW1 + HW2 42.5% of class If you got a D+,D, D- or F! must meet with Dave or me
More informationCSE 461 Connections. David Wetherall
CSE 461 Connections David Wetherall djw@cs.washington.edu Connections Focus How do we (reliably) connect processes? This is the transport layer Topics Naming processes TCP / UDP Connection setup / teardown
More informationOutline Computer Networking. Functionality Split. Transport Protocols
Outline 15-441 15 441 Computer Networking 15-641 Lecture 10: Transport Protocols Justine Sherry Peter Steenkiste Fall 2017 www.cs.cmu.edu/~prs/15 441 F17 Transport introduction TCP connection establishment
More informationSome slides courtesy David Wetherall. Communications Software. Lecture 4: Connections and Flow Control. CSE 123b. Spring 2003.
CSE 123b Communications Software Spring 2003 Lecture 4: Connections and Flow Control Stefan Savage Some slides courtesy David Wetherall Administrativa Computer accounts have been setup You can use the
More informationLast Class. CSE 123b Communications Software. Today. Naming Processes/Services. Transmission Control Protocol (TCP) Picking Port Numbers.
CSE 123b Communications Software Spring 2002 Lecture 4: Connections and Flow Control Stefan Savage Last Class We talked about how to implement a reliable channel in the transport layer Approaches ARQ (Automatic
More informationCSE 461 The Transport Layer
CSE 461 The Transport Layer The Transport Layer Focus How do we (reliably) connect processes? This is the transport layer Topics Naming end points UDP: unreliable transport TCP: reliable transport Connection
More informationTransport Layer Chapter 6
Transport Service Transport Layer Chapter 6 Elements of Transport Protocols Congestion Control Internet Protocols UDP Internet Protocols TCP Performance Issues Delay-Tolerant Networking Revised: August
More informationAnnouncements Computer Networking. What was hard. Midterm. Lecture 16 Transport Protocols. Avg: 62 Med: 67 STD: 13.
Announcements 15-441 Computer Networking Lecture 16 Transport Protocols Mid-semester grades Based on (ckpt 1 & ckpt2) + midterm + HW1 + HW2 NOTE: GRADES DO NOT REFLECT LATE PENALTIES! 25.4% of class If
More informationTCP Review. Carey Williamson Department of Computer Science University of Calgary Winter 2018
TCP Review Carey Williamson Department of Computer Science University of Calgary Winter 2018 Credit: Much of this content came courtesy of Erich Nahum (IBM Research) The TCP Protocol Connection-oriented,
More informationCongestion Control End Hosts. CSE 561 Lecture 7, Spring David Wetherall. How fast should the sender transmit data?
Congestion Control End Hosts CSE 51 Lecture 7, Spring. David Wetherall Today s question How fast should the sender transmit data? Not tooslow Not toofast Just right Should not be faster than the receiver
More informationCMSC 417. Computer Networks Prof. Ashok K Agrawala Ashok Agrawala. October 25, 2018
CMSC 417 Computer Networks Prof. Ashok K Agrawala 2018 Ashok Agrawala Message, Segment, Packet, and Frame host host HTTP HTTP message HTTP TCP TCP segment TCP router router IP IP packet IP IP packet IP
More informationCMSC 417. Computer Networks Prof. Ashok K Agrawala Ashok Agrawala. October 11, 2018
CMSC 417 Computer Networks Prof. Ashok K Agrawala 2018 Ashok Agrawala Message, Segment, Packet, and Frame host host HTTP HTTP message HTTP TCP TCP segment TCP router router IP IP packet IP IP packet IP
More informationTransport layer. UDP: User Datagram Protocol [RFC 768] Review principles: Instantiation in the Internet UDP TCP
Transport layer Review principles: Reliable data transfer Flow control Congestion control Instantiation in the Internet UDP TCP 1 UDP: User Datagram Protocol [RFC 768] No frills, bare bones Internet transport
More informationTransport layer. Review principles: Instantiation in the Internet UDP TCP. Reliable data transfer Flow control Congestion control
Transport layer Review principles: Reliable data transfer Flow control Congestion control Instantiation in the Internet UDP TCP 1 UDP: User Datagram Protocol [RFC 768] No frills, bare bones Internet transport
More informationTransmission Control Protocol. ITS 413 Internet Technologies and Applications
Transmission Control Protocol ITS 413 Internet Technologies and Applications Contents Overview of TCP (Review) TCP and Congestion Control The Causes of Congestion Approaches to Congestion Control TCP Congestion
More informationCE693 Advanced Computer Networks
CE693 Advanced Computer Networks Review 2 Transport Protocols Acknowledgments: Lecture slides are from the graduate level Computer Networks course thought by Srinivasan Seshan at CMU. When slides are obtained
More informationTCP reliable data transfer. Chapter 3 outline. TCP sender events: TCP sender (simplified) TCP: retransmission scenarios. TCP: retransmission scenarios
Chapter 3 outline TCP reliable 3.2 principles of reliable 3.3 connection-oriented flow 3.4 principles of congestion 3.5 TCP congestion TCP creates rdt service on top of IP s unreliable service pipelined
More informationChapter 3 outline. 3.5 Connection-oriented transport: TCP. 3.6 Principles of congestion control 3.7 TCP congestion control
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
More informationCommunication Networks
Communication Networks Spring 2018 Laurent Vanbever nsg.ee.ethz.ch ETH Zürich (D-ITET) April 30 2018 Materials inspired from Scott Shenker & Jennifer Rexford Last week on Communication Networks We started
More informationPage 1. Review: Internet Protocol Stack. Transport Layer Services EEC173B/ECS152C. Review: TCP. Transport Layer: Connectionless Service
EEC7B/ECS5C Review: Internet Protocol Stack Review: TCP Application Telnet FTP HTTP Transport Network Link Physical bits on wire TCP LAN IP UDP Packet radio Do you remember the various mechanisms we have
More informationCSE/EE 461 Lecture 14. Connections. Last Time. This Time. We began on the Transport layer. Focus How do we send information reliably?
CSE/EE 461 Lecture 14 Connections Last Time We began on the Transport layer Focus How do we send information reliably? Topics ARQ and sliding windows Application Presentation Session Transport Network
More informationTCP/IP Networking. Part 4: Network and Transport Layer Protocols
TCP/IP Networking Part 4: Network and Transport Layer Protocols Orientation Application Application protocol Application TCP TCP protocol TCP IP IP protocol IP IP protocol IP IP protocol IP Network Access
More informationChapter 3- parte B outline
Chapter 3- parte B 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:
More informationFast Retransmit. Problem: coarsegrain. timeouts lead to idle periods Fast retransmit: use duplicate ACKs to trigger retransmission
Fast Retransmit Problem: coarsegrain TCP timeouts lead to idle periods Fast retransmit: use duplicate ACKs to trigger retransmission Packet 1 Packet 2 Packet 3 Packet 4 Packet 5 Packet 6 Sender Receiver
More informationCSE/EE 461 Lecture 12 TCP. A brief Internet history...
CSE/EE 461 Lecture 12 TCP Tom Anderson tom@cs.washington.edu Peterson, Chapter 5.2, 6 A brief Internet history... 1991 WWW/HTTP 1969 ARPANET created 1972 TELNET RFC 318 1973 FTP RFC 454 1977 MAIL RFC 733
More informationTransport Layer Marcos Vieira
Transport Layer 2014 Marcos Vieira Transport Layer Transport protocols sit on top of network layer and provide Application-level multiplexing ( ports ) Error detection, reliability, etc. UDP User Datagram
More informationTransport Layer. Application / Transport Interface. Transport Layer Services. Transport Layer Connections
Application / Transport Interface Application requests service from transport layer Transport Layer Application Layer Prepare Transport service requirements Data for transport Local endpoint node address
More informationTCP Basics : Computer Networking. Overview. What s Different From Link Layers? Introduction to TCP. TCP reliability Assigned reading
TCP Basics 15-744: Computer Networking TCP reliability Assigned reading [FF96] Simulation-based Comparisons of Tahoe, Reno, and SACK TCP L-9 TCP Basics 2 Key Things You Should Know Already Port numbers
More informationGood Ideas So Far Computer Networking. Outline. Sequence Numbers (reminder) TCP flow control. Congestion sources and collapse
Good Ideas So Far 15-441 Computer Networking Lecture 17 TCP & Congestion Control Flow control Stop & wait Parallel stop & wait Sliding window Loss recovery Timeouts Acknowledgement-driven recovery (selective
More informationCSE 461 Module 11. Connections
CSE 461 Module 11 Connections This Time More on the Transport Layer Focus How do we connect processes? Topics Naming processes Connection setup / teardown Flow control Application Presentation Session
More informationLecture 21: Congestion Control" CSE 123: Computer Networks Alex C. Snoeren
Lecture 21: Congestion Control" CSE 123: Computer Networks Alex C. Snoeren Lecture 21 Overview" How fast should a sending host transmit data? Not to fast, not to slow, just right Should not be faster than
More informationCOMP/ELEC 429/556 Introduction to Computer Networks
COMP/ELEC 429/556 Introduction to Computer Networks The TCP Protocol Some slides used with permissions from Edward W. Knightly, T. S. Eugene Ng, Ion Stoica, Hui Zhang T. S. Eugene Ng eugeneng at cs.rice.edu
More informationLecture 22: TCP & NAT. CSE 123: Computer Networks Alex C. Snoeren
Lecture 22: TCP & NAT CSE 123: Computer Networks Alex C. Snoeren Lecture 22 Overview TCP Connection Management TCP Slow Start Allow TCP to adjust to links of any speed Fast Retransmit & Recovery Avoid
More informationUser Datagram Protocol
Topics Transport Layer TCP s three-way handshake TCP s connection termination sequence TCP s TIME_WAIT state TCP and UDP buffering by the socket layer 2 Introduction UDP is a simple, unreliable datagram
More informationComputer Networking Introduction
Computer Networking Introduction Halgurd S. Maghdid Software Engineering Department Koya University-Koya, Kurdistan-Iraq Lecture No.11 Chapter 3 outline 3.1 transport-layer services 3.2 multiplexing and
More informationFlow and Congestion Control (Hosts)
Flow and Congestion Control (Hosts) 14-740: Fundamentals of Computer Networks Bill Nace Material from Computer Networking: A Top Down Approach, 6 th edition. J.F. Kurose and K.W. Ross traceroute Flow Control
More informationMultiple unconnected networks
TCP/IP Life in the Early 1970s Multiple unconnected networks ARPAnet Data-over-cable Packet satellite (Aloha) Packet radio ARPAnet satellite net Differences Across Packet-Switched Networks Addressing Maximum
More informationLecture 4: Congestion Control
Lecture 4: Congestion Control Overview Internet is a network of networks Narrow waist of IP: unreliable, best-effort datagram delivery Packet forwarding: input port to output port Routing protocols: computing
More informationPage 1. Review: Internet Protocol Stack. Transport Layer Services. Design Issue EEC173B/ECS152C. Review: TCP
EEC7B/ECS5C Review: Internet Protocol Stack Review: TCP Application Telnet FTP HTTP Transport Network Link Physical bits on wire TCP LAN IP UDP Packet radio Transport Layer Services Design Issue Underlying
More informationCongestion Control. Daniel Zappala. CS 460 Computer Networking Brigham Young University
Congestion Control Daniel Zappala CS 460 Computer Networking Brigham Young University 2/25 Congestion Control how do you send as fast as possible, without overwhelming the network? challenges the fastest
More informationLecture 20 Overview. Last Lecture. This Lecture. Next Lecture. Transport Control Protocol (1) Transport Control Protocol (2) Source: chapters 23, 24
Lecture 20 Overview Last Lecture Transport Control Protocol (1) This Lecture Transport Control Protocol (2) Source: chapters 23, 24 Next Lecture Internet Applications Source: chapter 26 COSC244 & TELE202
More informationBandwidth Allocation & TCP
Bandwidth Allocation & TCP The Transport Layer Focus Application Presentation How do we share bandwidth? Session Topics Transport Network Congestion control & fairness Data Link TCP Additive Increase/Multiplicative
More informationCS321: Computer Networks Congestion Control in TCP
CS321: Computer Networks Congestion Control in TCP Dr. Manas Khatua Assistant Professor Dept. of CSE IIT Jodhpur E-mail: manaskhatua@iitj.ac.in Causes and Cost of Congestion Scenario-1: Two Senders, a
More informationFall 2012: FCM 708 Bridge Foundation I
Fall 2012: FCM 708 Bridge Foundation I Prof. Shamik Sengupta Instructor s Website: http://jjcweb.jjay.cuny.edu/ssengupta/ Blackboard Website: https://bbhosted.cuny.edu/ Intro to Computer Networking Transport
More informationArhitecturi și Protocoale de Comunicații (APC) Protocoale de nivel Transport
Arhitecturi și Protocoale de Comunicații (APC) Protocoale de nivel Transport End-to-end data transport Web apps HTTP File transfer FTP Other apps E-mail SMTP, POP, IMAP Other apps E-mail SMTP, POP, IMAP
More informationCongestion / Flow Control in TCP
Congestion and Flow Control in 1 Flow Control and Congestion Control Flow control Sender avoids overflow of receiver buffer Congestion control All senders avoid overflow of intermediate network buffers
More informationLecture 11. Transport Layer (cont d) Transport Layer 1
Lecture 11 Transport Layer (cont d) Transport Layer 1 Agenda The Transport Layer (continue) Connection-oriented Transport (TCP) Flow Control Connection Management Congestion Control Introduction to the
More informationOverview. TCP congestion control Computer Networking. TCP modern loss recovery. TCP modeling. TCP Congestion Control AIMD
Overview 15-441 Computer Networking Lecture 9 More TCP & Congestion Control TCP congestion control TCP modern loss recovery TCP modeling Lecture 9: 09-25-2002 2 TCP Congestion Control Changes to TCP motivated
More informationCS 356: Introduction to Computer Networks. Lecture 16: Transmission Control Protocol (TCP) Chap. 5.2, 6.3. Xiaowei Yang
CS 356: Introduction to Computer Networks Lecture 16: Transmission Control Protocol (TCP) Chap. 5.2, 6.3 Xiaowei Yang xwy@cs.duke.edu Overview TCP Connection management Flow control When to transmit a
More informationLecture 14: Congestion Control"
Lecture 14: Congestion Control" CSE 222A: Computer Communication Networks George Porter Thanks: Amin Vahdat, Dina Katabi and Alex C. Snoeren Lecture 14 Overview" TCP congestion control review Dukkipati
More information6.1 Internet Transport Layer Architecture 6.2 UDP (User Datagram Protocol) 6.3 TCP (Transmission Control Protocol) 6. Transport Layer 6-1
6. Transport Layer 6.1 Internet Transport Layer Architecture 6.2 UDP (User Datagram Protocol) 6.3 TCP (Transmission Control Protocol) 6. Transport Layer 6-1 6.1 Internet Transport Layer Architecture The
More informationCS457 Transport Protocols. CS 457 Fall 2014
CS457 Transport Protocols CS 457 Fall 2014 Topics Principles underlying transport-layer services Demultiplexing Detecting corruption Reliable delivery Flow control Transport-layer protocols User Datagram
More informationimage 3.8 KB Figure 1.6: Example Web Page
image. KB image 1 KB Figure 1.: Example Web Page and is buffered at a router, it must wait for all previously queued packets to be transmitted first. The longer the queue (i.e., the more packets in the
More informationCS419: Computer Networks. Lecture 10, Part 2: Apr 11, 2005 Transport: TCP mechanics (RFCs: 793, 1122, 1323, 2018, 2581)
: Computer Networks Lecture 10, Part 2: Apr 11, 2005 Transport: TCP mechanics (RFCs: 793, 1122, 1323, 2018, 2581) TCP as seen from above the socket The TCP socket interface consists of: Commands to start
More informationECE 435 Network Engineering Lecture 10
ECE 435 Network Engineering Lecture 10 Vince Weaver http://web.eece.maine.edu/~vweaver vincent.weaver@maine.edu 28 September 2017 Announcements HW#4 was due HW#5 will be posted. midterm/fall break You
More informationCS 43: Computer Networks. 19: TCP Flow and Congestion Control October 31, Nov 2, 2018
CS 43: Computer Networks 19: TCP Flow and Congestion Control October 31, Nov 2, 2018 Five-layer Internet Model Application: the application (e.g., the Web, Email) Transport: end-to-end connections, reliability
More informationCSE 123A Computer Networks
CSE 123A Computer Networks Winter 2005 Lecture 14 Congestion Control Some images courtesy David Wetherall Animations by Nick McKeown and Guido Appenzeller The bad news and the good news The bad news: new
More informationTransport Protocols Reading: Sections 2.5, 5.1, and 5.2. Goals for Todayʼs Lecture. Role of Transport Layer
Transport Protocols Reading: Sections 2.5, 5.1, and 5.2 CS 375: Computer Networks Thomas C. Bressoud 1 Goals for Todayʼs Lecture Principles underlying transport-layer services (De)multiplexing Detecting
More informationTCP. CSU CS557, Spring 2018 Instructor: Lorenzo De Carli (Slides by Christos Papadopoulos, remixed by Lorenzo De Carli)
TCP CSU CS557, Spring 2018 Instructor: Lorenzo De Carli (Slides by Christos Papadopoulos, remixed by Lorenzo De Carli) 1 Sources Fall and Stevens, TCP/IP Illustrated Vol. 1, 2nd edition Congestion Avoidance
More informationFunctionality Split Computer Networking. Transport Protocols. Overview. Multiplexing & Demultiplexing
Functionality Split 15-441 Computer Networking Transport Layer Network provides best-effort delivery End-systems implement many functions Reliability In-order delivery Demultiplexing Message boundaries
More informationNWEN 243. Networked Applications. Layer 4 TCP and UDP
NWEN 243 Networked Applications Layer 4 TCP and UDP 1 About the second lecturer Aaron Chen Office: AM405 Phone: 463 5114 Email: aaron.chen@ecs.vuw.ac.nz Transport layer and application layer protocols
More informationTransport Protocols Reading: Sections 2.5, 5.1, and 5.2
Transport Protocols Reading: Sections 2.5, 5.1, and 5.2 CE443 - Fall 1390 Acknowledgments: Lecture slides are from Computer networks course thought by Jennifer Rexford at Princeton University. When slides
More informationCNT 6885 Network Review on Transport Layer
CNT 6885 Network Review on Transport Layer Jonathan Kavalan, Ph.D. Department of Computer, Information Science and Engineering (CISE), University of Florida User Datagram Protocol [RFC 768] no frills,
More informationReliable Transport II: TCP and Congestion Control
Reliable Transport II: TCP and Congestion Control Stefano Vissicchio UCL Computer Science COMP0023 Recap: Last Lecture Transport Concepts Layering context Transport goals Transport mechanisms and design
More informationCS 5520/ECE 5590NA: Network Architecture I Spring Lecture 13: UDP and TCP
CS 5520/ECE 5590NA: Network Architecture I Spring 2008 Lecture 13: UDP and TCP Most recent lectures discussed mechanisms to make better use of the IP address space, Internet control messages, and layering
More informationOutline. TCP: Overview RFCs: 793, 1122, 1323, 2018, steam: r Development of reliable protocol r Sliding window protocols
Outline r Development of reliable protocol r Sliding window protocols m Go-Back-N, Selective Repeat r Protocol performance r Sockets, UDP, TCP, and IP r UDP operation r TCP operation m connection management
More informationcs/ee 143 Communication Networks
cs/ee 143 Communication Networks Chapter 4 Transport Text: Walrand & Parakh, 2010 Steven Low CMS, EE, Caltech Recap: Internet overview Some basic mechanisms n Packet switching n Addressing n Routing o
More informationUDP and TCP. Introduction. So far we have studied some data link layer protocols such as PPP which are responsible for getting data
ELEX 4550 : Wide Area Networks 2015 Winter Session UDP and TCP is lecture describes the two most common transport-layer protocols used by IP networks: the User Datagram Protocol (UDP) and the Transmission
More informationCSCI-1680 Transport Layer II Data over TCP Rodrigo Fonseca
CSCI-1680 Transport Layer II Data over TCP Rodrigo Fonseca Based partly on lecture notes by David Mazières, Phil Levis, John Janno< Last Class CLOSED Passive open Close Close LISTEN Introduction to TCP
More informationTransport Protocols and TCP
Transport Protocols and TCP Functions Connection establishment and termination Breaking message into packets Error recovery ARQ Flow control Multiplexing, de-multiplexing Transport service is end to end
More informationCS4700/CS5700 Fundamentals of Computer Networks
CS4700/CS5700 Fundamentals of Computer Networks Lecture 14: TCP Slides used with permissions from Edward W. Knightly, T. S. Eugene Ng, Ion Stoica, Hui Zhang Alan Mislove amislove at ccs.neu.edu Northeastern
More informationCMPE 150/L : Introduction to Computer Networks. Chen Qian Computer Engineering UCSC Baskin Engineering Lecture 10
CMPE 150/L : Introduction to Computer Networks Chen Qian Computer Engineering UCSC Baskin Engineering Lecture 10 1 Midterm exam Midterm next Thursday Close book but one-side 8.5"x11" note is allowed (must
More information15-744: Computer Networking TCP
15-744: Computer Networking TCP Congestion Control Congestion Control Assigned Reading [Jacobson and Karels] Congestion Avoidance and Control [TFRC] Equation-Based Congestion Control for Unicast Applications
More informationUNIT IV -- TRANSPORT LAYER
UNIT IV -- TRANSPORT LAYER TABLE OF CONTENTS 4.1. Transport layer. 02 4.2. Reliable delivery service. 03 4.3. Congestion control. 05 4.4. Connection establishment.. 07 4.5. Flow control 09 4.6. Transmission
More informationLecture 5: Flow Control. CSE 123: Computer Networks Alex C. Snoeren
Lecture 5: Flow Control CSE 123: Computer Networks Alex C. Snoeren Pipelined Transmission Sender Receiver Sender Receiver Ignored! Keep multiple packets in flight Allows sender to make efficient use of
More informationCS Networks and Distributed Systems. Lecture 10: Congestion Control
CS 3700 Networks and Distributed Systems Lecture 10: Congestion Control Revised 2/9/2014 Transport Layer 2 Application Presentation Session Transport Network Data Link Physical Function:! Demultiplexing
More informationCongestion control in TCP
Congestion control in TCP If the transport entities on many machines send too many packets into the network too quickly, the network will become congested, with performance degraded as packets are delayed
More informationDepartment of Computer and IT Engineering University of Kurdistan. Transport Layer. By: Dr. Alireza Abdollahpouri
Department of Computer and IT Engineering University of Kurdistan Transport Layer By: Dr. Alireza Abdollahpouri TCP/IP protocol suite 2 Transport Layer The transport layer is responsible for process-to-process
More informationOverview. TCP & router queuing Computer Networking. TCP details. Workloads. TCP Performance. TCP Performance. Lecture 10 TCP & Routers
Overview 15-441 Computer Networking TCP & router queuing Lecture 10 TCP & Routers TCP details Workloads Lecture 10: 09-30-2002 2 TCP Performance TCP Performance Can TCP saturate a link? Congestion control
More informationCS519: Computer Networks. Lecture 5, Part 4: Mar 29, 2004 Transport: TCP congestion control
: Computer Networks Lecture 5, Part 4: Mar 29, 2004 Transport: TCP congestion control TCP performance We ve seen how TCP the protocol works Sequencing, receive window, connection setup and teardown And
More information