Chapter 6: The Transport Layer

1. Chapter 6: The Transport Layer CS455/555

2. The Transport Service • Provide efficient, reliable, cost-effective service to upper layers (application layer) • Transport entity---the HW/SW that does the work to offer this service • Connection-oriented and connectionless service • Flow-control is an issue • Transport layer adds additional reliability/flexibility to the services offered by the network layer • True end-to-end protocol • QoS parameters: Specified by a user to the transport layer • (See Fig 6.2)

3. The Transport Service (Cont.) • We concentrate on the connection-oriented service only in this chapter • Transport layer primitives: LISTEN (executed by a server), CONNECT (by a client, SEND, RECEIVE, DISCONNECT • TPDU: Transport protocol data units (similar to packets at NWL and frames at DLL) • Figure 6-5: establish/disconnect a connection

4. Elements of Transport protocols • TL is similar to DLL: error-control, sequencing, flow-control, etc. • How is TL different from DLL? Environments are different---single link vs. subnet(s) between the two entities. Subnet acts as a storage unit; this implies that a message may float around and not reach the destination in a given time. No addressing needed at DLL; TL needs addresses

5. Elements of Transport protocols Cont.) • Addressing: Transport service access points, TSAP: (IP+local port) or AAL-SAP • Example of setting up a connection between a user process and a time-server on another machine (Page 289-490) • Concept of name server to match the users (clients) with servers • TSAP address is generally hierarchical indicating the machine and port

6. Establishing a Connection How can a transport entity establish a connection with another transport entity? Problems can arise since a network can: store, lose, and duplicate packets. Example problem: If a user has requested for a connection, sent a transaction, and requested for a disconnection. While the original 3 messages were executed correctly, later on duplicates of the three may once again at the destination. This is a problem. Delayed duplicates is a problem. Solution 1. Assign a connection ID for each connection. It is assigned by the requesting user. If a server receives an old ID, it recognizes it as a duplicate and ignores it. Problem: Server has to keep a list of all of the earlier connection Ids. What happens if a machine crashes and this table is lost?

7. Elements of Transport protocols (Contd.) • Restricting the life of a packet in a network: three ways proposed in the text • Tomlinson’s solution to memory loss: Each host should have a clock that does not lose memory when system crashes. The clock is a counter that is incremented at uniform intervals. The number of bits that hold the counter are larger than the bits used for a sequence number. • Procedure: When a connection is set up, the initiating host uses the low-order k bits of its clock as the initial sequence number (of k bits)----so each connection does not start numbering their TPDUs from 0; instead they start from the number the chosen k-bit sequence number.

8. Time Elements of Transport protocols (Contd.) While the clock was used to determine the initial seq. #, after that the seq # is incremented sequentially. For example, if it started with seq # 1789, then subsequent TPDUs are given numbers 1790, 1791, and so on. What happens if a host crashes during a session? Does it remember the last sequence # already allocated to the last TPDU prior to failure? NO. Initial Seq #

9. Elements of Transport protocols (Contd.) • Why do we want to know the last seq# assigned? Suppose when the system recovers, the clock is 1801. But the last seq# assigned was 1870. If for a newsession we start with 1801, then the old TPDUs with numbers 1801-1870 may coexist with the new 1801-1870 in the network. This causes confusion. How do we solve this problem?

10. Elements of Transport protocols (Contd.) • Note that the rate at which a clock may advance may be smaller than the rate of generating TPDUs. • Each TPDU has both the connection # and a sequence number. • Example: Assume that the clock advances at the rate of 1 tick a second. At t=30, a host crashed, and the last TPDU sent on connection #5 was with seq # 80. After recovering, at time t=70, it reopens connection #5. The clock is now 70. So it starts the new connection with seq #70. Subsequenetly it sends TPDUs 70-85. The new 80 may clash with the old 80 at the destination which treats as them duplicates. • One solution is for the recovered host to wait for T (time-to-live) units of time prior to starting a new session. This way all the old TPDUs may have exited the network by now. But this may be too long time to wait.

11. Elements of Transport protocols (Contd.) • Two-hand shake to set up a connection may not work? Suppose A sends a connection set up request with an initial seq number. B accepts the request and sends a connection acceptance. But is lost on the way. Now a duplicate of the original request arrives later. B thinks it is a new request and sends Acceptance for the new connection also. When A receives it, it thinks it is for the 1st one. So there is a confusion. Solution: Three-way handshake.

12. Three-way handshake protocol • Each side can start with a different sequenec number • Host 1 chooses a seq. # and sends a CR to host 2. • Host 2 sends an ACK with its own seq # as well as the seq# that it received in host 1’s request. On receiving the ACK, host 1 starts sending data along with a piggy backed ACK for host 2’s message. • Duplicate request: Suppose a duplicate (delayed) CR reaches host 2. It sends an ACK. But when Host 1receives the duplicate ACK, it rejects it and instead sends a REJECT message. Host 2 then abandons the connection. • Duplicate CR and delayed DATA+ACK from Host 1: On receiving the duplicate CR, host 2 will send an ACK for the old CR. When Host 1 receives it, it will send a REJECT. • Claim: No combination of CR, CA, or other TPDUs can cause the protocol to fail.

13. Releasing a Connection • Asymmetric release (any one releasing breaks a connection) vs. symmetric release (treats the connection as two separate unidirectional connections) • Asymmetric: When a host disconnects and stops sending, it should still be ready to receive TPDUs until the host gets the disconnect message • Symmetric: Both should agree to disconnect? No such algorithm exists to reach consensus in a faulty environment. • Example: The two-army problem

14. Releasing a connection (Cont.) • Three-way handshake to solve the problem in most cases: • Host 1 sends DR; Host 2 sends DR in return; host 1 sends an ACK and releases the connection; when host 2 gets ACK, it too releases the connection. • In case the ACK is lost, host2 timesout and releases the connection. • In case the original DR from host 1 to host 2 is lost, host 1 times-out and retransmits. • Sometimes host 1 may have to several DRs and finally just disconnect after several attempts.

15. Flow-control and buffering • Flow-control is between the two hosts • At the data link layer, the flow-control is only between a DL at one node and all its neighbors. Generally, there are only a few of them. • At the transport layers, a host may be running several programs needing several transport connections. Thus, buffer allocation is an issue. • A network layer ACK does not imply transport layer ACK. • The sender should buffer a TPDU until it is assured that it has reached the destination host. • Variable length TPDU’s (unlike fixed length data frames)

16. Flow-control and buffering • Source buffering vs. destination buffering: • Low-BW bursty output: Source buffering • File transfer and other high-bandwidth traffic: Destination buffering • Buffers could be allocated per connection or collectively for all connections running between two hosts • Necessary to deal with dynamic buffer allocation---unlike DLL • Separate buffer space from ACK (this unlike DLL) See Fig 6-16

17. Flow-control and buffering • Each host should send control TPDU’s with ACK and buffer allocation periodically to prevent deadlocks (in case earlier allocations are lost) • Another constraint is link capacity---we will discuss it later. • Upward multiplexing and downward multiplexing

18. Crash Recovery • Lost datagrams, disconnected VCs • Host (e.g. server) crashes---cannot be made transparent to higher layers • Truly End-to-end ACK???

19. A SIMPLE TRANSPORT PROTOCOL • TL Primitives: connum=LISTEN(local) connum = CONNECT(local,remote) status=SEND(connum, buffer, bytes) status=RECEIVE(connum, buffer, bytes) status=DISCONNECT(connum) • Interaction with the network layer: to_net, and from_net calls • Packet types: CALL REUQUEST, CALL ACCEPTED, CLEAR REQUEST, CLEAR CONFIRMATION, DATA, CREDIT

20. INTERNET TRANSPORT PROTOCOLS • TCP---Connection-oriented • UDP---connectionless • The chapter’s focus is on TCP • TCP---Transmission Control Protocol Reliable end-to-end byte stream over an unreliable internetwork

21. TCP Service Model • End points: Sockets • Socket number: host IP + 16-bit port number local to host • Connections are identified by the socket pairs at both ends • All TCP connections are full-duplex and point-to-point • Byte stream and not message stream • If an application wants TCP to send data immediately (I.e., not wait for other data to come), it can use a PUSH flag • URGENT data flag

22. A SIMPLE TRANSPORT PROTOCOL • Each transport connection is always in one of seven states: • IDLE • WAITING • QUEUED • ESTABLISHED • SENDING • RECEIVING • DISCONNECTING • State transitions occur when: a primitive is executed, a packet arrives, or the timer expires • State transition table: Fig 6-21 • See Figure 6-21