1. Transport Layer

2. Context of various layers upto Network layer NL : present in LAN and subnet MAC sublayer : not present in Subnets, only in LANs DLL : present in LAN and subnet

3. Context of various layers Transport Layer : Peer (a transport entity, a process in TL, in a host H1) to Peer (a transport entity, a process in TL, in a host H2). Network Layer: End (IP address of H1) to End (IP address of H2). DLL: Local, (DLL address of) router to (DLL address of) router in subnet or host to router on a LAN.

4. Context of various layers contd DLL : node to node and not source to destination MAC address also : node to node and not source to destination NL : Though addressing is source to destination but responsibilities are node to node

5. DLL revisited Services offered by the DLL may be CO or CL Implementation of CO in DLL is done with the help of frame sequence numbers DLL handles errors due to transmission only I.e. due to the physical errors..bits damaged etc

6. Services offered by the DLL may or may not be reliable When the medium is reliable or the system is real time where fast response is more important than correct data for eg. Voice DLL should be kept light and reliability if required must be added in higher layers When the medium is unreliable and it is more important that data is never lost than the response time, it may be worth adding reliable services(ACKs) in the DLL

7. NL revisted CL service : Internet community : They say that subnet is inherently unreliable and hence reliability, error control, flow control must be done by the destination host anyway, and hence there is no need of doing that in the NL (and hence at every router). CO service : Telephone Companies

8. Implementation of CO in NL Is done with Virtual Circuit Numbers between H1 and H2. Now suppose there are two processes (transport entity) on H1 wanting to establish connection with one or two processes on H2. NL may establish separate connections or use a common connection between H1 and H2 for the two applications.

9. Contd.. Now consider the following scenario: Suppose a network entity is informed halfway halfway through a long transmission that its network connection has been abruptly terminated (router crash or link down etc). TL entity can set up a new connection to the remote TL entity and ask upto what point it received and start from thereon. This cannot be done at the NL since the NL cannot distinguish between the two TL connections because it was using the same virtual circuit for both.

10. The Transport Layer Truly Peer to peer layer. Services provided in TL are similar to those provided in the NL and DLL together.

11. Why do we need the Transport Layer To take care of the issues which were not taken care of, by the lower layers. Or, one could say, a final check.

12. Why Transport Layer? Since the protocols are developed independent of the protocols in the lower layers, It handles all the things CO Reliability by adding Acks, even if Acks were added at the DLL we still need them here as at DLL only frames damaged due to transmission errors are resent. However, packets may be dropped for other reasons such as congestion etc. If this is not taken care of at the NL, which is most often the case, then it must be done at the transport layer. Error-control Flow-control Congestion-control

13. Elements of Transport Protocols Addressing Connection Establishment Connection Release Flow Control and Buffering Multiplexing Crash Recovery

14. Differences between NL and TL Real Networks can loose packets and NL may not make an attempt to recover or retransmit the lost packets. Whereas TL services are meant to be reliable. One of the main objective of TL: provide a reliable service on top of unreliable network. Users: Users of NL services are TL entities and not an end user whereas the users of TL services are the programmers writing applications, hence TL entity must be convenient and easy to use.

15. Similarities between NL and TL Both provide services CO/CL to the higher layer. Both perform congestion control

16. Similarities between DLL and TL TL services resemble more with that of the DLL: Error Control Flow Control Sequencing etc

17. Differences between DLL and TL Due to the dissimilarities between the environment they operate in:In DLL, two routers communicate directly through a physical link. In TL, the two transport entities communicate through the entire subnet. Thus the life is greatly simplified in case of DLL as compared to that in TL.

18. Differences contd.. In DLL, each outgoing line uniquely identifies the destination router, no explicit addressing is required whereas in TL explicit addressing of the destination is required. Initial connection establishment is more complicated in TL. In DLL, a packet is either delivered or lost. But at TL, a packet may go around in the subnet, be stored in some router for some time and emerge later.

19. Differences contd.. Buffering and Flow Control: In DLL, buffer space is allocated with each line. The number of lines a router is connected is small and constant. Having dedicating buffers with each VC at the TL is not feasible as the number of VCs is too large.

20. TL addresses : TSAP (Transport Service Access Point) A server 1(say Time of Day) on host 2 attaches itself to TSAP 1522 to continuously listen for an incoming request. This attachment is done by a system call by the OS. An application process on Host 1 attaches itself to an available TSAP say 1208 and issues a CONNECT request specifying source TSAP as 1208 and destination TSAP as 1522. When Server 1 receives this request, connection is established eventually (we’ll discuss later). AP asks for the Time-of the Day Server responds with the TOD Connection is released.

21. Addressing. TSAPs, NSAPs and transport connections

22. TSAP There may be other servers on Host 2 attached to a different TSAP waiting for an incoming request.

23. Issues in Addressing How does the client know the TSAP (Transport Service access point) I.e. the port used by the server Well known servers use well known ports : defined in /etc/services file on UNIX for eg.wel Initial Connection Protocol : Process Server (attached to a well known TSAP) Initial Connection Protocol Name Server (attached to a well known TSAP) : Provides TSAP of the required service/server.

24. Some well known assigned ports PortProtocol Use 21 FTP File transfer 23 Telnet Remote login 25 SMTP E-mail 69 TFTP Trivial File Transfer Protocol 79 FingerLookup info about a user 80 HTTP World Wide Web 110 POP-3 Remote e-mail access 119 NNTP USENET news BacBack

25. Issues contd.. Stable and Standardized TSAPs are used for some frequently used servers. How about the servers which are rarely used? Letting a server listen whole day to a fixed TSAP is wasteful. Solution: proxy server listening to multiple TSAPs at the same time.

26. Proxy Server A client sends a request specifying the TSAP of the required service. But finds no one waiting at that TSAP, the request is handed over to the proxy server. The proxy server spawns the requested server inheriting all the properties of the connection. Problem: TSAP of the service required is still required to be known and works fine only for those services which can be created as and when required …like TOD server. Solution: Name Server

27. Initial Connection Protocol How a user process in host 1 establishes a connection with a time-of-day server in host 2.

28. Name Server Client connects itself to a name server on host 2. Name Server works on a well known TSAP. It requests the name server to provide the TSAP of the required service. NS responds back. Connection with the NS is released and a new connection with the required server is set up. Needless to say, when a new service comes up it must register itself with the NS together with its TSAP.

29. Connection Establishment Establish connection Transfer Data Release Connection

30. Issues in Connection Establishment Packets may be lost or may be duplicated or may roam around and emerge later Consider the following scenario: Connection Request Transfer data (say banking, say some amount to some account) Connection Release Suppose all the packets duplicate, roam around and emerge again after the connection is released… the connection will be re-established, data transferred again and again released.

31. How to handle Use connection identifier (a sequence number) and keep a list of obsolete connections after they are released….Not good to keep the history for infinite amount of time, also what happens when a router crashes.. All history will be lost. Kill off ageing packets : Keep a packet life time. Hop count or, Time Stamp: requires global synchronization of clock Unfortunately, none of them is fool proof.

32. Packet Lifetime To make sure that not only data packets but even their acknowledgements are lost, a multiple of true lifetime is used instead.

33. Tomlinson’s method Each host is equipped with a TOD clock which is assumed to be running even when the router crashes. No problem in this assumption, a battery-operated clock which gets charged up when powered. Clocks at different hosts need not be synchronized.

34. Tomlinson’s Method contd.. The clock is actually a binary counter which is incremented at uniform intervals. The number of bits in the binary counter must be greater or equal than the number of bits in the sequence number. When a connection is established, the low-order k bits of the clock are used as the initial sequence number and put into the TPDU (connection request). Once the initial sequence number is fixed any sliding window protocol can be used to control the flow of data. The sequence numbers are incremented and put into subsequent TPDUs (for the same connection) independent of the clock.

35. TM contd.. Now we want to ensure that two TPDUs numbered identically are not outstanding at the same time. If the sequence space is large enough that by the time seq no.s wrap around, old TPDUs with the same seq. no. are long gone, problem occurs only due to crashes.

36. Recovery after a crash Consider the following scenario: At t = t0, a connection is established with connection identifier 5 and ISN = t0, more TPDUs are generated for this connection and, At t = 30 a sequence number say 80 is generated and put into a TPDU for the same connection, call this TPDU X. Then, the host crashes and comes up immediately again. At t=60, it starts establishing connections 0-4. At t= 70, it establishes a new connection 5, with ISN =70 and within next 15 sec, it sends TPDUs numbered 70-80. Thus a new TPDU with CI 5 and SN =80 has been created, call it Y. If X arrives at the receiver before Y, X may be accepted as original and Y may be rejected as duplicate…..problem

37. Solution We should not have assigned the sequence number 80 to X. We should have waited for an appropriate amount of time before assigning 80 to X. i.e. If we are about to assign a sequence number say 80 to a TPDU say x, when there are chances that in a near future (before the life time of x say T) 80 may be assigned as ISN, then we should wait. This wait period is called the forbidden region for a sequence number.

38. An example For example, let at t =30, host wants to send a TPDU x with CI = 5 and SN = 90. Suppose T= 60 then the TPDU with desired SN can be generated but if It was to be generated at t = 31, it cannot be, it will have to wait until t = 91. i.e. a sequences s should not be generated in the time period s-T to s.

39. Another Example Let at t =30, host wants to send a TPDU x with CI = 5 and SN = 31. It waits until t =32.

40. Connection Establishment (2) (a) TPDUs may not enter the forbidden region. (b) The resynchronization problem.

41. Note that if at t=20, host wants to send a TPDU with SN = 80. It can send.

42. What about the control packets? Once the two parties agree on the ISN, this method works fine? What if the control packets like CONNECTION REQUEST get delayed.

43. Possible Scenario a delayed duplicate packet of a CR by host1 proposing an ISN comes up. CA by host2 accepting the request. Connection will be setup incorrectly.

44. Three way handshake for Connection Establishment Three protocol scenarios for establishing a connection using a three-way handshake. CR denotes CONNECTION REQUEST. (a) Normal operation, (b) Old CONNECTION REQUEST appearing out of nowhere. (c) Duplicate CONNECTION REQUEST and duplicate ACK.

45. Connection Release Asymmetric: Telephone System, may result in loss of data. Symmetric: treats the connection as two unidirectional connections and each must be closed separately.

46. Connection Release Abrupt disconnection with loss of data.

47. Connection Release (2) The two-army problem.

48. Connection Release (3) Four protocol scenarios for releasing a connection. (a) Normal case of a three- way handshake. (b) final ACK lost. 6-14, a, b

49. Connection Release (4) (c) Response lost. (d) Response lost and subsequent DRs lost. 6-14, c,d

50. Flow control and buffering Difference between DLL and TL In TL, too many connections, dedicated buffers for each connection is not a very good idea. Buffers at sender vs at receiver If the network service is unreliable, sender must keep the unacked TPDUs in the buffer. If the network service is reliable(acked packets), several tradeoffs are possible.

51. An Important (side) Note In a reliable network, if the receiver guarantees enough buffer space to accept every incoming TPDU, sender need not buffer the unacked TPDUs (remember reliable network). Else, sender must. It cannot rely on the acked service of the network for that only means that packet arrived safely (and accepted) at the NL of the receiver but whether TL has enough space to buffer the TPDU or not is not guaranteed.

52. Tradeoffs in a reliable network (a) Chained fixed-size buffers. (b) Chained variable-sized buffers. (c) One large circular buffer per connection.

53. Tradeoffs in a reliable network Fixed size buffers – what should be the size? Variable size buffers – better memory utilization but complicated buffer management One large circular buffer per connection: good if all connections are heavily loaded but poor otherwise. In practice, a combination might be used depending upon the application.

54. Tradeoffs between buffering at sender and at receiver Low bandwidth bursty application like interactive terminal, having dedicated buffers is not a good idea, buffers must be acquired dynamically. Hence, buffer space at the receiver is not guaranteed, therefore sender must keep. High bandwidth traffic like file transfer Receiver must dedicate buffers to allow smooth and fast flow of data. Hence, sender need not keep.

55. Negotiating buffer space in CR As connections are opened and closed, and the traffic pattern changes, sender and receiver must be able to adjust their buffer allocation dynamically. TP should allow the sender to request for buffer space at the receiver in CR, And the receiver to inform the sender as to how much buffer space it has for the sender, say in CA.

57. COO service in TL : Transport Service Primitives The primitives for a simple transport service.

58. Server is continuously LISTENing. Client sends a CONNECT request. Server is unblocked and accepts the request. Exchange data using SEND and RECEIVE. DISCONNECT could be symmetric or asymmetric.

59. DISCONNECT Symmetric: Each side is closed separately. When one side issues a DISCONNECT, it means it has no more data to send but it can accept more data. The other side can continue to send data and issues a separate DISCONNECT when it is done. Asymmetric: Any side can issue a DISCONNECT and the connection is released when it arrives at the other end.

60. TPDU : Transport Protocol Data Unit The nesting of TPDUs, packets, and frames.

61. Transport Service Primitives (3) A state diagram for a simple connection management scheme. Transitions labeled in italics are caused by packet arrivals. The solid lines show the client's state sequence. The dashed lines show the server's state sequence.

62. Berkeley Sockets The socket primitives for TCP.

63. Socket Programming Example: Internet File Server Client code using sockets. 6-6-1

64. Socket Programming Example: Internet File Server (2) Client code using sockets.

65. Issues in Connection Release Asymmetric Release : One party disconnects as in telephone system and the connection is released …. May lead to data loss Symmetric Release : If fixed amount of data then fine else problem

66. Connection Release Abrupt disconnection with loss of data.

67. Connection Release Four protocol scenarios for releasing a connection. (a) Normal case of a three- way handshake. (b) final ACK lost. 6-14, a, b

68. Connection Release (c) Response lost. (d) Response lost and subsequent DRs lost. 6-14, c,d

69. Connection Release What if the initial DR and all subsequent tries are lost : sender releases the connection but receiver stays connected : results in half-open connection Use timer : If no TPDUs arrive for a certain amount of time then disconnect

70. Flow Control and Buffering In DLL, Sliding window (buffering) is kept at both the sender’s end as well as at the receiver’s end for each connection. However, in a router the number of lines is few whereas at TL, the number of connections is large. Thus keeping buffers with each connection may not be very memory efficient.

71. Flow Control and Buffering : If subnet provides datagram service Since subnet provides unreliable datagram, TL must acknowledge, hence sender has to keep the unacked TPDUs, I.e. has to buffer them. So buffering at the receiver need not be very efficient.. Say a common pool may be maintained for all the connections. When a TPDU arrives, if there is a room in the pool, it is accepted else discarded and retransmitted by the sender

72. Flow Control and Buffering : subnet is reliable Other optimizations are possible : receiver can agree to do the buffering. Assuming the receiver always have sufficient space, sender need not buffer and TPDUs are never discarded and hence retransmitted due to insufficient buffer space.

73. How to make sure that the receiver always has enough space? Case a : most TPDUs are of same size Case b : variable-sized TPDUs chained together : space efficient, buffer management is more complicated Case c : single large chunk per connection : works well if all connections are heavily loaded, but poor otherwise.

74. Flow Control and Buffering (a) Chained fixed-size buffers. (b) Chained variable-sized buffers. (c) One large circular buffer per connection.

75. Source buffering Vs Destination buffering Low-bandwidth bursty traffic : eg. Bursty traffic.. Buffer at sender’s end High-bandwidth smooth traffic: eq. file transfer : buffer at receiver’s end to allow the data to flow at maximum speed

76. Dynamic allocation of buffers As the traffic pattern changes, buffer allocation strategies must change. The TL Protocol thus should allow the sender to request buffer space at the receiver’s end.

77. Flow Control and Buffering.

78. Multiplexing Upward Multiplexing : to reduce cost by multiplexing several TL connections on a single NL VC. Cost of NL VC is high as resources are reserved. Downward Multiplexing: Improve throughput by multiplexing single TL connection on multiple NL throughput. There is a tradeoff between cost and throughput

79. Crash Recovery