Chapter3-2-TransportLayer.pptx lecture note

lecture note

1. Transport Layer Chapter 6 Transport Service Elements of Transport Protocols Barkley socket Congestion Control Internet Protocols – UDP Internet Protocols – TCP 1 CN5E by Tanenbaum & Wetherall, © Pearson Education-Prentice Hall and D. Wetherall, 2011

2. The Transport Layer Responsible for delivering data across networks with the desired reliability or quality Application Transport Network Link Physical 2 CN5E by Tanenbaum & Wetherall, © Pearson Education-Prentice Hall and D. Wetherall, 2011

3. Transport Service Services Provided to the Upper Layer » Transport Service Primitives » Berkeley Sockets » Socket Example : client and server » 3 CN5E by Tanenbaum & Wetherall, © Pearson Education-Prentice Hall and D. Wetherall, 2011

4. Services Provided to the Upper Layers (1) Transport layer adds reliability to the network layer Offers connectionless (e.g., UDP) and connection- oriented (e.g, TCP) service to applications 4 CN5E by Tanenbaum & Wetherall, © Pearson Education-Prentice Hall and D. Wetherall, 2011

5. Services Provided to the Upper Layers (2) Transport layer sends segments in packets (in frames) Seg m ent Seg m ent 5 CN5E by Tanenbaum & Wetherall, © Pearson Education-Prentice Hall and D. Wetherall, 2011

6. Transport Service Primitives (1) Primitives that applications might call to transport data for a simple connection-oriented service: Client calls CONNECT , SEND , RECEIVE , DISCONNECT Server calls LISTEN , RECEIVE , SEND , DISCONNECT Segment 6 CN5E by Tanenbaum & Wetherall, © Pearson Education-Prentice Hall and D. Wetherall, 2011

7. Transport Service Primitives (2) State diagram for a simple connection-oriented service Solid lines (right) show client state sequence Dashed lines (left) show server state sequence Transitions in italics are due to segment arrivals. 7 CN5E by Tanenbaum & Wetherall, © Pearson Education-Prentice Hall and D. Wetherall, 2011

8. Berkeley Sockets Very widely used primitives started with TCP on UNIX Notion of “sockets” as transport endpoints Like simple set plus SOCKET , BIND , and ACCEPT 8 CN5E by Tanenbaum & Wetherall, © Pearson Education-Prentice Hall and D. Wetherall, 2011

9. Socket Example – Client-Server (1) Get server’s IP address Make a socket Try to connect Client code // initialize socket and input output streams private Socket socket = null; private DataInputStream input = null; private DataOutputStream out = null; // constructor to put ip address and port public ClientProgram (String address, int port) { // establish a connection try { socket = new Socket(address, port); System.out.println ("Connected"); // takes input from terminal input = new DataInputStream (System.in); // sends output to the socket out = new DataOutputStream ( socket.getOutputStream ()); } 9 CN5E by Tanenbaum & Wetherall, © Pearson Education-Prentice Hall and D. Wetherall, 2011

10. Socket Example – Client-Server(2) Client code (cont.) Write data (equivalent to send) catch( UnknownHostException u) { System.out.println (u); } catch( IOException i ) { System.out.println ( i ); }// string to read message from input String line = ""; // keep reading until "Over" is input while (! line.equals ("Over")) { try { line = input.readLine (); out.writeUTF (line); } catch( IOException i ) { System.out.println ( i ); } } Loop reading (equivalent to receive) until no more data; exit implicitly calls close 10 CN5E by Tanenbaum & Wetherall, © Pearson Education-Prentice Hall and D. Wetherall, 2011

11. Socket Example – Client-Server(3) // close the connection try { input.close (); out.close (); socket.close (); } catch( IOException i ) { System.out.println ( i ); } } public static void main(String args []) { ClientProgram client = new ClientProgram ("127.0.0.1", 5000); } } Client code (cont.) 11 CN5E by Tanenbaum & Wetherall, © Pearson Education-Prentice Hall and D. Wetherall, 2011

12. Socket Example – Client-Server ( 4 ) . . . Server code . . . Make a socket Assign address //initialize socket and input stream private Socket socket = null; private ServerSocket server = null; private DataInputStream in = null; // constructor with port public ServerSide ( int port) { // starts server and waits for a connection try { server = new ServerSocket (port); System.out.println ("Server started"); System.out.println ("Waiting for a client ..."); socket = server.accept (); System.out.println ("Client accepted");// takes input from the client socket in = new DataInputStream ( new BufferedInputStream ( socket.getInputStream () )); String line = "";// reads message from client until "Over" is sent Prepare for incoming connections 12 CN5E by Tanenbaum & Wetherall, © Pearson Education-Prentice Hall and D. Wetherall, 2011

13. Socket Example – Client-Server(5) Server code . . . while (! line.equals ("Over")) { try { line = in.readUTF (); System.out.println (line); input = new DataInputStream (System.in); // sends output to the socket out = new DataOutputStream ( socket.getOutputStream ()); } catch ( IOException e) { e.printStackTrace (); } } catch ( IOException i ) { System.out.println ( i ); } } R ead (receive) request and treat as file name 13 CN5E by Tanenbaum & Wetherall, © Pearson Education-Prentice Hall and D. Wetherall, 2011

14. System.out.println ("Closing connection"); // close connection socket.close (); in.close (); } catch ( IOException i ) { System.out.println ( i ); }} public static void main(String args []){ ServerSide server = new ServerSide (5000); }} Socket Example – Client-Server(6) 14 CN5E by Tanenbaum & Wetherall, © Pearson Education-Prentice Hall and D. Wetherall, 2011

15. Instruction Socket Example – Client-Server(6) First you have to run the server code followed by the client code 1. When you run the server side script, it will start and wait for the client to get started. 2. Next, the client will get connected and inputs the request in the form of a string. 3. When the client sends the request, the server will respond back. 15 CN5E by Tanenbaum & Wetherall, © Pearson Education-Prentice Hall and D. Wetherall, 2011

16. Elements of Transport Protocols Addressing » Connection establishment » Connection release » Error control and flow control » Multiplexing » Crash recovery » 16 CN5E by Tanenbaum & Wetherall, © Pearson Education-Prentice Hall and D. Wetherall, 2011

17. Instructor’s Slide Addition: Addressing https://www.ietf.org/assignments/service-names-port-numbers/service-names- port-numbers.xml Three types of Ports Well-known Ports: ports 0 – 1023 Registered Ports: ports 1024 – 49151 » Ports through 49151 are formally registered worldwide through IANA (see above URL for current registration results) Dynamic Ports: Ports 49152 – 65535 » These ports are not registered thru IANA but rather use a locally scoped port ID system such as portmapper (see textbook page 510) Example is Sun Microsystems’ ONC RPC protocol system, which is a popular approach for RPCs (see pages 543-546) 17 CN5E by Tanenbaum & Wetherall, © Pearson Education-Prentice Hall and D. Wetherall, 2011

18. Addressing Transport layer adds TSAPs Multiple clients and servers can run on a host with a single network (IP) address TSAPs are ports for TCP/UDP 18 CN5E by Tanenbaum & Wetherall, © Pearson Education-Prentice Hall and D. Wetherall, 2011

19. Connection Establishment (1) Key problem is to ensure reliability even though packets may be lost, corrupted, delayed , and duplicated Don’t treat an old or duplicate packet as new (Use ARQ and checksums for loss/corruption) Approach: Don’t reuse sequence numbers within twice the MSL (Maximum Segment Lifetime) of 2T=240 secs Three-way handshake for establishing connection 19 CN5E by Tanenbaum & Wetherall, © Pearson Education-Prentice Hall and D. Wetherall, 2011

20. Connection Establishment (2) Use a sequence number space large enough that it will not wrap, even when sending at full rate Clock (high bits) advances & keeps state over crash Need seq. number not to wrap within T seconds Need seq. number not to climb too slowly for too long 20 CN5E by Tanenbaum & Wetherall, © Pearson Education-Prentice Hall and D. Wetherall, 2011

21. Connection Establishment (3) Three-way handshake used for initial packet Since no state from previous connection Both hosts contribute fresh seq. numbers CR = Connect Request 21 CN5E by Tanenbaum & Wetherall, © Pearson Education-Prentice Hall and D. Wetherall, 2011

22. Connection Establishment (4) Three-way handshake protects against odd cases: Duplicate CR. Spurious ACK does not connect Duplicate CR and DATA. Same plus DATA will be rejected (wrong ACK). a) b) X X X 22 CN5E by Tanenbaum & Wetherall, © Pearson Education-Prentice Hall and D. Wetherall, 2011

23. Connection Release (1) Key problem is to ensure reliability while releasing Asymmetric release (when one side breaks connection) is abrupt and may lose data X 23 CN5E by Tanenbaum & Wetherall, © Pearson Education-Prentice Hall and D. Wetherall, 2011

24. Connection Release (2) Symmetric release (both sides agree to release) can’t be handled solely by the transport layer Two-army problem shows pitfall of agreement At t ack? At t ack? 24 CN5E by Tanenbaum & Wetherall, © Pearson Education-Prentice Hall and D. Wetherall, 2011

25. Connection Release (3) Normal release sequence, initiated by transport user on Host 1 DR=Disconnect Request Both DRs are ACKed by the other side 25 CN5E by Tanenbaum & Wetherall, © Pearson Education-Prentice Hall and D. Wetherall, 2011

26. Connection Release (4) Error cases are handled with timer and retransmission Final ACK lost, Host 2 times out Lost DR causes retra n smiss i o n s Extreme: Many lost DRs cause both hosts to timeout 26 CN5E by Tanenbaum & Wetherall, © Pearson Education-Prentice Hall and D. Wetherall, 2011

27. Crash Recovery Application needs to help recovering from a crash Transport can fail since A(ck) / W(rite) not atomic 27 CN5E by Tanenbaum & Wetherall, © Pearson Education-Prentice Hall and D. Wetherall, 2011

28. Congestion Control Two layers are responsible for congestion control: Transport layer, controls the offered load [here] Network layer, experiences congestion [previous] Desirable bandwidth allocation » Regulating the sending rate » Wireless issues » 28 CN5E by Tanenbaum & Wetherall, © Pearson Education-Prentice Hall and D. Wetherall, 2011

29. Desirable Bandwidth Allocation (1) Efficient use of bandwidth gives high goodput, low delay Delay begins to rise sharply when congestion sets in Goodput rises more slowly than load when congestion sets in 29 CN5E by Tanenbaum & Wetherall, © Pearson Education-Prentice Hall and D. Wetherall, 2011

30. Desirable Bandwidth Allocation (2) Fair use gives bandwidth to all flows (no starvation) Max-min fairness gives equal shares of bottleneck Bottleneck link 30 CN5E by Tanenbaum & Wetherall, © Pearson Education-Prentice Hall and D. Wetherall, 2011

31. Desirable Bandwidth Allocation (3) We want bandwidth levels to converge quickly when traffic patterns change Flow 1 slows quickly when Flow 2 starts Flow 1 speeds up quickly when Flow 2 stops 31 CN5E by Tanenbaum & Wetherall, © Pearson Education-Prentice Hall and D. Wetherall, 2011

32. Regulating the Sending Rate (1) Sender may need to slow down for different reasons: Flow control, when the receiver is not fast enough [right] Congestion, when the network is not fast enough [over] A fast network feeding a low-capacity receiver  flow control is needed 32 CN5E by Tanenbaum & Wetherall, © Pearson Education-Prentice Hall and D. Wetherall, 2011

33. Regulating the Sending Rate (2) Our focus is dealing with this problem – congestion A slow network feeding a high-capacity receiver  congestion control is needed 33 CN5E by Tanenbaum & Wetherall, © Pearson Education-Prentice Hall and D. Wetherall, 2011

34. Regulating the Sending Rate (3) Different congestion signals the network may use to tell the transport endpoint to slow down (or speed up) 34 CN5E by Tanenbaum & Wetherall, © Pearson Education-Prentice Hall and D. Wetherall, 2011

35. Regulating the Sending Rate ( 4 ) +/– percentage If two flows increase/decrease their bandwidth in the same way when the network signals free/busy they will not converge to a fair allocation + /– constant 35 CN5E by Tanenbaum & Wetherall, © Pearson Education-Prentice Hall and D. Wetherall, 2011

36. Regulating the Sending Rate ( 5 ) The AIMD (Additive Increase Multiplicative Decrease) control law does converge to a fair and efficient point! TCP uses AIMD for this reason User 1’s bandwidth User 2’s bandwidth 36 CN5E by Tanenbaum & Wetherall, © Pearson Education-Prentice Hall and D. Wetherall, 2011

37. Wireless Issues Wireless links lose packets due to transmission errors Do not want to confuse this loss with congestion Or connection will run slowly over wireless links! Strategy: Wireless links use ARQ, which masks errors 37 CN5E by Tanenbaum & Wetherall, © Pearson Education-Prentice Hall and D. Wetherall, 2011

38. Internet Protocols – UDP Introduction to UDP » Remote Procedure Call » Real-Time Transport » 38 CN5E by Tanenbaum & Wetherall, © Pearson Education-Prentice Hall and D. Wetherall, 2011

39. Introduction to UDP (1) UDP (User Datagram Protocol) is a shim over IP Header has ports (TSAPs), length and checksum. 39 CN5E by Tanenbaum & Wetherall, © Pearson Education-Prentice Hall and D. Wetherall, 2011

40. Introduction to UDP (2) Checksum covers UDP segment and IP pseudoheader Fields that change in the network are zeroed out Provides an end-to-end delivery check 40 CN5E by Tanenbaum & Wetherall, © Pearson Education-Prentice Hall and D. Wetherall, 2011

41. RPC (Remote Procedure Call) RPC connects applications over the network with the familiar abstraction of procedure calls Stubs package parameters/results into a message UDP with retransmissions is a low-latency transport 43 41 CN5E by Tanenbaum & Wetherall, © Pearson Education-Prentice Hall and D. Wetherall, 2011

42. Real-Time Protocol (1) RTP (Real-time Transport Protocol) provides support for sending real-time media over UDP Often implemented as part of the application 42 CN5E by Tanenbaum & Wetherall, © Pearson Education-Prentice Hall and D. Wetherall, 2011

43. Real-Time Protocol (2) RTP header contains fields to describe the type of media and synchronize it across multiple streams RTCP sister protocol helps with management tasks 43 CN5E by Tanenbaum & Wetherall, © Pearson Education-Prentice Hall and D. Wetherall, 2011

44. Real-Time Protocol (3) Buffer at receiver is used to delay packets and absorb jitter so that streaming media is played out smoothly Packet 8’s network delay is too large for buffer to help Constant rate Variable rate Constant rate 44 CN5E by Tanenbaum & Wetherall, © Pearson Education-Prentice Hall and D. Wetherall, 2011

45. Real-Time Protocol (4) High jitter, or more variation in delay, requires a larger playout buffer to avoid playout misses Propagation delay does not affect buffer size B u f fer Miss e s 45 CN5E by Tanenbaum & Wetherall, © Pearson Education-Prentice Hall and D. Wetherall, 2011

46. Internet Protocols – TCP The TCP service model » The TCP segment header » TCP connection establishment » TCP connection state modeling » TCP sliding window » TCP timer management » TCP congestion control » 46 CN5E by Tanenbaum & Wetherall, © Pearson Education-Prentice Hall and D. Wetherall, 2011

47. The TCP Service Model (1) TCP provides applications with a reliable byte stream between processes; it is the workhorse of the Internet Popular servers run on well-known ports 47 CN5E by Tanenbaum & Wetherall, © Pearson Education-Prentice Hall and D. Wetherall, 2011

48. The TCP Service Model (2) Applications using TCP see only the byte stream [right] and not the segments [left] sent as separate IP packets Four segments, each with 512 bytes of data and carried in an IP packet 2048 bytes of data delivered to application in a single READ call 48 CN5E by Tanenbaum & Wetherall, © Pearson Education-Prentice Hall and D. Wetherall, 2011

49. The TCP Segment Header TCP header includes addressing (ports), sliding window (seq. / ack. number), flow control (window), error control (checksum) and more. 49 CN5E by Tanenbaum & Wetherall, © Pearson Education-Prentice Hall and D. Wetherall, 2011

50. TCP Connection Establishment TCP sets up connections with the three-way handshake Release is symmetric, also as described before Normal case Simultaneous connect 50 CN5E by Tanenbaum & Wetherall, © Pearson Education-Prentice Hall and D. Wetherall, 2011

51. TCP Connection State Modeling (1) The TCP connection finite state machine has more states than our simple example from earlier. 51 CN5E by Tanenbaum & Wetherall, © Pearson Education-Prentice Hall and D. Wetherall, 2011

52. TCP Connection State Modeling (2) Solid line is the normal path for a client. Dashed line is the normal path for a server. Light lines are unusual events. Transitions are labeled by the cause and action, separated by a slash. 52 CN5E by Tanenbaum & Wetherall, © Pearson Education-Prentice Hall and D. Wetherall, 2011

53. TCP Sliding Window (1) TCP adds flow control to the sliding window as before ACK + WIN is the sender’s limit 53 CN5E by Tanenbaum & Wetherall, © Pearson Education-Prentice Hall and D. Wetherall, 2011

54. TCP Sliding Window (2) Need to add special cases to avoid unwanted behavior E.g., silly window syndrome [below] Receiver application reads single bytes, so sender always sends one byte segments 54 CN5E by Tanenbaum & Wetherall, © Pearson Education-Prentice Hall and D. Wetherall, 2011

55. End 55 CN5E by Tanenbaum & Wetherall, © Pearson Education-Prentice Hall and D. Wetherall, 2011