1. Chapter 6 The Transport Layer

2. SERVICES PROVIDED TO THE UPPER LAYERS
The ultimate goal of the transport layer is to provide efficient, reliable, and cost effective service to its processes in the application layer.
The hardware/software within the transport layer that does the work is called the transport entity.
Figure 6-1. The network, transport, and application layers.

3. SERVICES PROVIDED TO THE UPPER LAYERS
Just as there are two types of network service, connection-oriented and connectionless, there are also the same two types of transport service.
If the transport layer is so similar to the network layer service, why are there two distinct layers?
The network layer is part of communication subnet. What happens if the network layer offers connection-oriented service but is unreliable? Suppose that it frequently loses packets, what happens if routers crash from time to time?
The users have no control over the subnet, so they cannot solve the problem of poor service by using better routers or putting more error handling in the data link layer. The only possibility is to put another layer on the top of the network layer that improves the quality of service.

4. SERVICES PROVIDED TO THE UPPER LAYERS
If a transport layer is informed through a long transmission that its network connection has been abruptly terminated, it can set up a new connection to the remote transport entity. Then it can send a query to its peer asking which data arrived and which did not, and then pick up from where it left off.
The existence of the transport layer makes it possible for the transport service to be more reliable than the underlying network service.
The transport service primitives can be designed to be independent of the network service primitives which may vary from network to network.
Because of the transport layer, it is possible for the application programs to be written using a standard set of primitives, and to have these programs work on a wide variety of networks.

5. Transport Service Primitives
The transport service primitives allow transport users (e.g., application programs) to access the transport service. Each transport service has its own access primitives.
The purpose of the transport layer is to provide a reliable service on the top of an unreliable network. Therefore, it hides the imperfections of the network service so the user processes can just assume the existence of an error-free bit stream.
The following transport service primitives allow application programs to establish, use, and release connection.
Figure 6-2. The primitives for a simple transport service.

6. Transport Service Primitives
A message, sent from transport entity to transport entity, is called Transport Protocol Data Unit (TPDU).
When a frame arrives, the data link layer processes the frame header and passes the contents of the frame payload field up to the network entity. The network entity processes the packet header and passes the contents of the packet payload up to the transport entity.
Figure 6-3. Nesting of TPDUs, packets, and frames.

7. Transport Service Primitives
Consider an application with a server and a number of remote clients.
The server executes a LISTEN primitive to block the server (i.e., is interested in handling requests) until a client turns up.
When a client wants to talk to a server, it executes a CONNECT primitive. This causes to block the client and to send a CONNECTION REQUEST TPDU to the server.
When it arrives, the transport entity checks to see that server is blocked on a LISTEN. It then unblock the server and sends a CONNECTION ACCEPTED TPDU back to the client. When this TPDU arrives, the client is unblocked and the connection is established.
When connection is no longer needed, it must be released by issuing a DISCONNECT primitive.

8. Transport Service Primitives
Figure 6-4. 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.

9. Elements of Transport Protocols
The transport service is implemented by a transport protocol used between the two transport entities.
Both transport protocols and data link protocols have to deal with error control, sequencing, and flow control.
However, significant differences between the two also exist. At data link layer, two routers communicate directly, via a physical channel, whereas at the transport layer, this physical channel is replaced by the entire subnet
Figure 6-7. (a) Environment of the data link layer. (b) Environment of the transport layer.

10. Elements of Transport Protocols
Differences between the Data Link Layer and Transport Layer:
First: In data link layer, each outgoing line uniquely specifies a particular router. However, in the transport layer, explicit addressing of destinations is required.
Second: The process of establishing a connection over a wire is simple. However, in transport layer, initial connection establishment is more complicated.
Third: The existence of storage capacity in the subnet. In data link layer, the frame may arrive or be lost, but it cannot bounce around for a while. However, in transport layer, there is a nonnegligible probability that a packet may be stored for a number of seconds and then delivered later.
Fourth: Buffering and flow control are needed in both layers, but in the transport layer may require a different approach than we used in the data link layer.

11. Figure 6-8. TSAPs, NSAPs, and transport connections.
ADDRESSING
When an application process wishes to set up a connection to a remote application process, it must specify which one to connect to.
The method is to define transport addresses to which processes can listen for connection request. These are called Transport Service Access Point (TSAP). In the Internet, these points are (IP address, local port) pairs. Similarly, the end points in the network layer are called Network Service Access Point (NSAP).
Figure 6-8. TSAPs, NSAPs, and transport connections.

12. ADDRESSING
Example:
A possible connection scenario for a transport connection over a connection oriented a network layer is as follows.
1. A time-of-day server on host 2 attaches itself to TSAP 122 to wait for an incoming call. A call such as LISTEN might me used.
2. An application process on host 1 wants to find out the time-of-day, so it issues a CONNECT request specifying TSAP 6 as the source and TSAP 122 as the destination.
3. The transport entity on host 1 selects a network address on its machine (if it has more than one) and sets up a network connection to make host 1's transport entity to talk to the transport entity on host 2.
4. The first thing the transport entity on 1 says to its peer on 2 is: "Good morning. I would like to establish a transport connection between my TSAP 6 and your TSAP 122. What do you say?"
5. The transport entity on 2 then asks the time-of-day server at TSAP 122 if it is willing to accept a new connection.

13. ADDRESSING
How does the user process on host 1 know that the time-of-day server is attached to TSAP 122?
One possibility is stable TSAP addresses, i.e., the time-of-day server has been attaching itself to TSAP 122 for years, and gradually all the network users have learned this.
Stable TSAP addresses might work for a small number of key services. However, in general, user processes often talk to other user processes for a short time and do not have a TSAP address that is known in advance. Furthermore, if there are many server processes, most of which are rarely used, it is wasteful to have each of them active and listening to a stable TSAP address all day long. Therefore, a better scheme is needed.

14. ADDRESSING
One scheme, used by UNIX on the Internet, is known as the initial connection protocol, which is as follows.
Each machine that wishes to offer service to remote users has a special process server, which listens to a set of ports at the same time, waiting for a TCP connection request, specifying a TCP address (TCP port) of the service they want. If no server is waiting for them, they get a connection to the process server.
After it gets the incoming request, the process server produces the requested server, which then does the requested work, while the process server goes back to listening for new requests.

15. Example for Initial Connection Protocol:
Figure 6-9. How a user process in host 1 establishes a connection with a time-of-day server in host 2.

16. For a file server, it needs to run a special hardware (a machine with a disk).
There exists a special process called a name server or sometimes a directory server.
To find the TSAP address corresponding to a given service name, such as "time-of-day", a user sets up a connection to the name server. The user then sends a message specifying the service name. The name server sends back the TSAP address. Then the user releases the connection with the name server and establishes a new one with the desired service.
TSAP addresses can be either hierarchical addresses or flat addresses.
Hierarchical Address = <galaxy><star><planet><country><network><host><port>.

17. Establishing a Connection
Establishing a connection sounds easy. It would seem sufficient for one entity to just send a CONNECTION REQUEST TPDU to the destination and wait for a CONNECTION ACCEPTED reply. The problem occurs when the network can lose, store, and duplicate packets.
To solve this problem, one way is to use throw away transport addresses. Each time a transport address is needed, a new one is generated. When a connection is released, the address is discarded.
Another possibility is to give each connection identifier (i.e., a sequence number incremented for each connection established), chosen by the initiating party, and put in each TPDU, including the one requesting the connection. After each connection is released, each transport entity could update a table listing obsolete connections as (peer transport entity, connection identifier) pairs. Whenever a connection request came in, it could be checked against the table to see if it belong to previously released connection.

18. Establishing a Connection
The drawback of this scheme is that when a machine crashes and loses its history, it will no longer know which connection identifiers have already been used.
Therefore, we have to devise a mechanism to kill of the aged packets using one of the following techniques:
1. Restricted subnet design: It prevents packet from looping.
2. Putting a hop limit in each packet.
3. Timestamping each packet: The router clocks need to be synchronized.
In practice, we will need to guarantee not only that packet is dead, but also that all acknowledgements to it are also dead. If we wait a time T after a packet has been sent, we can sure that all traces of it are now gone and that neither it nor its acknowledgements will suddenly appear.

19. Establishing a Connection
Figure (a) TPDUs may not enter the forbidden region. (b) The resynchronization problem.

20. Establishing a Connection
To get around a machine losing all memory, Tomlinson proposed to equip each host with a time-of-day clock. The clocks at different hosts need not to be synchronized. Furthermore, the number of bits in the counter must equal or exceed the number of bits in the sequence number. Also, the clock is assumed to continue running even if the host goes down.
The basic idea is to ensure that two identically numbered TDPU are never outstanding at the same time. When a connection is set up, the low-order k bits of the clock are used as the initial sequence number. Therefore, each connection starts numbering its TDPUs with a different sequence number.
The sequence space should be so large that by the time sequence number wrap around, old TPDUs with the same sequence number are long gone.

21. Establishing a Connection
To establish a connection, there is a potential problem in getting both sides to agree on the initial sequence number.
For example, host 1 establishes a connection by sending a CONNECT REQUEST TPDU containing the proposed initial sequence number and destination port number to a remote peer, host 2. The receiver, host 2, then acknowledges this request by sending a CONNECTION ACCEPT TPDU back.
If the CONNECTION REQUEST TPDU is lost but a delayed duplicate CONNECTION REQUEST suddenly shows up at host 2, the connection will be established incorrectly.
To solve this problem, Tomlison introduced the three-way handshake.

22. Establishing a Connection
The three-way handshake protocol does not require both sides to begin sending with the same sequence number.
Host 1 chooses a sequence number, x, and sends a CONNECTION REQUEST TPDU containing x to host 2. Host 2 replies with a CONNECTION ACCEPTED TDPU acknowledging x and announcing its own initial sequence number, y. Finally, host 1 acknowledges host 2 in the first data TPDU that it sends.
The three-way handshake works in the presence of delayed duplicate control TPDUs.

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

24. Releasing a Connection
There are two styles of terminating a connection: asymmetric release and symmetric release.
Asymmetric release is the way the telephone works: when one party hangs up, the connection is broken.
Asymmetric release may result in a data loss. If a connection is established, host 1 sends a TDPU to host 2. Then host 1 sends another TPDU. However, host 2 issues a DISCONNECT before the second TPDU arrives. The result is that the connection is released and the data are lost.
Figure Abrupt disconnection with loss of data

25. Releasing a Connection
Symmetric release treats the connection as two separate unidirectional connections and requires each one to be released separately.
Although symmetric release is more sophisticated protocol that avoids data loss, it does not always work. There is a famous problem that deals with this issue. It is called the two-army problem.
Figure The two-army problem.

26. Releasing a Connection
Figure Four protocol scenarios for releasing a connection. (a) Normal case of three-way handshake. (b) Final ACK lost.

27. Releasing a Connection
Figure Four protocol scenarios for releasing a connection. Final ACK lost. (c) Response lost. (d) Response lost and subsequent DRs lost.

28. Flow Control and Buffering
Flow Control scheme is needed on each connection to keep a fast transmitter from overrunning a slow receiver.
If the subnet provides a datagram service, the sending transport entity must buffer outgoing frames because they might be retransmitted.
If the receiver knows that the sender buffers all TPDUs until they are acknowledged, the receiver may or may not dedicate specific buffers to specific connections. The receiver may maintain a single buffer pool shared by all connections.
When a TPDU comes in, an attempt is made to acquire a new buffer. If one is available, the TPDU is accepted, otherwise, it is discarded. Since the sender is prepared to retransmit TPDUs lost by the subnet, no harm is done by having the receiver drop TPDUs. The sender just keeps trying until it gets an acknowledgement.

29. Flow Control and Buffering
In summary, If the network service is unreliable, the sender must buffer all TPDUs sent. However, with reliable network service, if the sender knows that the receiver always has a buffer space, it need not retain copies of the TPDUs it sends. However, if the receiver cannot guarantee that every incoming TPDU will be accepted, the sender will have to buffer anyway.

30. Flow Control and Buffering
Buffer Size
If most TPDUs are nearly the same size, we can organize the buffers as a pool of identical size buffers, with one TPDU per buffer.
If there is a wide variation in TPDU size, from a few characters typed at a terminal to thousands of characters from file transfers, a pool of fixed-sized buffers presents problems.
If the buffer size is chosen equal to the largest possible TPDU, space will be wasted whenever a short TPDU arrives. If the buffer size is chosen less than the maximum TPDU size, multiple buffers will be needed for long TPDUs.
Another approach to the buffer size problem is to use variable-size buffers. The advantage is better memory utilization, at the price of more complicated buffer management.
A third possibility is to dedicate a single large circular buffer per connection. This is good approach when all connections are heavily loaded, but is poor if some connections are lightly loaded.

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

32. Flow Control and Buffering
Dynamic Buffer Allocation:
The sender requests a certain number of buffers. The receiver then grants as many of these as it can afford. Every time the sender transmits a TPDU, it must decrements its allocation, and stops when the allocation reaches zero. The receiver then separately piggybacks both acknowledgements and buffer allocations onto the reverse traffic.

33. Dynamic Buffer Allocation
Figure Dynamic buffer allocation. The arrows show the direction of transmission. An ellipsis (...) indicates a lost TPDU.

34. Multiplexing
Plays a role in several layers of the Network architecture
Several Transport connections at a time possible
Also if only one Network address is available on a Host
Upward Multiplexing
Downward Multiplexing

35. Figure 6-17. (a) Upward multiplexing. (b) Downward multiplexing

36. Crash recovery
In case of a Host or Router crash, and:
If the Network provides Datagram service:
TPDU may be lost. It should be then retransmitted.
If the Network provides Connection Oriented Service:
New Circuit will be build up
Last TPDU, if lost should be retransmitted

37. Crash Recovery
For failures occurring in Layer N, Recovery is only possible in Layer N+1
The Transport layer can therefore recover
failures of the Network Layer
But with the condition, enough status information are saved

38. Figure 6-18. Different combinations of client and server strategy
Crash recovery
Figure Different combinations of client and server strategy

39. A Simple Transport Protocol
The Example Service Primitives
The Example Transport Entity
The Example as a Finite State Machine

40. The Example Service Primitives
It is an example of a connection oriented establishment.
The primitives used are:
Listen
Connect
Send
Receive
Disconnect

41. The Example Transport Entity
Figure The network layer packets used in our example.

42. The Example Transport Entity (2)
Each connection is in one of seven states:
Idle – Connection not established yet.
Waiting – CONNECT has been executed, CALL REQUEST sent.
Queued – A CALL REQUEST has arrived; no LISTEN yet.
Established – The connection has been established.
Sending – The user is waiting for permission to send a packet.
Receiving – A RECEIVE has been done.
DISCONNECTING – a DISCONNECT has been done locally.

43. The Example as a Finite State Machine
The example protocol as a finite state machine. Each entry has an optional predicate, an optional action, and the new state. The tilde indicates that no major action is taken. An overbar above a predicate indicate the negation of the predicate. Blank entries correspond to impossible or invalid events.
Figure The example protocol as a finite state machine. Each entry has an optional predicate, an optional action, and the new state. The tilde indicates that no major action is taken. An overbar above a predicate indicates the negation of the predicate. Blank entries correspond to impossible or invalid events.

44. The Example as a Finite State Machine (2)
Figure The example protocol in graphical form. Transitions that leave the connection state unchanged have been omitted for simplicity

45. The Internet Transport Protocols: UDP
Introduction to UDP
Remote Procedure Call
The Real-Time Transport Protocol

46. Introduction to UDP
The UDP header.

47. Introduction to UDP
The User Datagram Protocol is a connectionless transport protocol
Usually used for short messages
Transmits 8 bytes Segment header followed by the payload
The ports identifies the End points of the source and destination Hosts
The source port is primarily needed when a reply must be sent back to the source

48. Introduction to UDP-2-
UDP length field includes the 8 bytes header and the data
Checksum is optional and is 0 if not used
UDP does NOT do:
Flow control
Error control
Retransmission
The User process is responsible for that.

49. Introduction to UDP-3- All what UDP do:
Provide an interface for demultiplexing multiple processes using the ports
Is useful for Server/Client applications
Client send a short request (ex: DNS)
Server send a short reply back
If Request or Replay is lost, it will timeout.Client can try again.

50. Steps in making a remote procedure call. The stubs are shaded.
Figure Steps in making a remote procedure call. The stubs are shaded

51. Remote Call Procedure
Consist of sending a msg to a remote host, and getting reply back
Used for Request/Replay interactions on Networks, based on UDP.
The client program must be bound with a small library procedure called CLIENT STUB
Similarly the server is bound with a SERVER STUB
The fact that the procedure call from client to the server is not local is HIDDEN (transparent) for the user.

52. The Real-Time Transport Protocol
Figure (a) The position of RTP in the protocol stack. (b) Packet nesting

53. The Real-Time Transport Protocol (RTP)
UDP is widely used on Real Time multimedia Applications
RTP is a transport protocol implemented in the application layer
Its basic function: multiplex several real time data streams onto a single stream of UDP packets, sent to:
A single destination: Unicasting or
Multiple destinations: Multicasting

54. The Real-Time Transport Protocol (2)
Figure The RTP header.

55. The Real-Time Transport Protocol (RTP) –2-
RTP runs over UDP, that means it just uses UDP
RTP has, as UDP, no flow control, no error control, no ack, and no mechanism to request retransmissions
UDP packets are imbedded in IP packets
If the host is on Ethernet, the IP packets are then put in Ethernet frames for transmission

56. The Internet Transport Protocols: TCP
Introduction to TCP
The TCP Service Model
The TCP Protocol
The TCP Segment Header
TCP Connection Establishment
TCP Connection Release
TCP Connection Management Modeling
TCP Transmission Policy
TCP Congestion Control
TCP Timer Management
Wireless TCP and UDP
Transactional TCP

57. The Internet Transport Protocols (TCP and UDP)
The Internet has two main protocols in the transport layer, a connection-oriented protocol (TCP) and a connectionless protocol (UDP).
TCP (Transmission Control Protocol) was designed to provide a reliable end-to end connection over an unreliable internetwork.
TCP was designed to dynamically adapt to the properties of the internetwork.
A TCP entity accepts user data streams from local processes, breaks them up into pieces not exceeding 64K bytes (in practice, usually 1500 bytes), and sends each piece as a separate IP datagram. When IP datagrams containing TCP data arrive at a machine, they are given to the TCP entity, which reconstruct the original byte streams.
The IP layer gives no guarantee that datagram will be delivered properly, so it is up to TCP to time out and retransmit them. Also, it is up to TCP to reassemble the datagrams into messages in the proper sequence. Therefore, TCP provides the reliability the most users want and that IP does not provide

58. The TCP Service Model
TCP service is obtained by having both the sender and receiver create end points, called sockets. Each socket has a socket number (address) consisting of the IP address of the host and a 16-bit port. A port is the TCP name for a TSAP.
To obtain TCP service, a connection must be explicitly established between a socket on the sending machine and a socket on the receiving machine using the socket calls.
Port numbers below 256 are called well-known ports and are reserved for standard services. For example, port 21 is for FTP, port 23 for TELNET, port 79 for finger, and port 119 for USENET news.
All TCP connections are full-duplex and point-to-point.

59. The TCP Service Model
A TCP connection is a byte stream, not a message stream. Message boundaries are not preserved end to end. For example if the sending process does four 512-byte write to a TCP stream, these data may delivered to the receiving processes as four 512-byte pieces, two 1024-byte pieces, one 2048-byte piece, or some other way.
When an application passes data to TCP, TCP may send it immediately or buffer it (in order to collect a larger amount to send at once). However, sometimes, the application really wants the data to be sent immediately. For example, suppose a user is logged into a remote machine. After a command line has been finished and the carriage return typed, it is essential that the line be shipped off to the remote machine immediately and not buffered until the next line comes in.
Figure (a) Four 512-byte segments sent as separate IP datagrams. (b) The 2048 bytes of data delivered to the application in a single READ call.

60. The TCP Protocol
A sending and receiving TCP entities exchange data in form of segments.
A segment consists of a 20-byte header (plus an optional part) followed by zero or more data bytes.
Two limits restrict the segment size. First, each segment, including the TCP header, must fit in the 65,535-byte IP payload. Second, each network has a maximum transfer unit (MTU). If a segment passes through sequence of networks without being fragmented and then hits one whose MTU is smaller than the segment, the router at the boundary fragments the segment into two or more smaller segments. Each new segment gets its own TCP and IP headers, so fragmentation by routers increases the total overhead.

61. The TCP Protocol
The basic protocol used by TCP entities is the sliding window protocol. When a sender transmits a segment, it also starts a timer. When a segment arrives at the destination, the receiving TCP entity sends back a segment (with data if any exists, otherwise without data) bearing an acknowledgement number equal to the next sequence number it expects to receive. If a sender's timer goes off before the acknowledgement is received, the sender transmits the segment again.
Challenges:
Segments can be fragmented, it is possible that part of the transmitted segment arrives and acknowledged by the receiving TSP entity, but the rest is lost.
Segments can arrive out of order.
Segments can also be delayed and the sender times out and retransmits them.
If a retransmitted segment takes a different route than the original, and is fragmented differently.
It is possible that a segment may occasionally hit a congested (or broken) network along its path.

62. The TCP Segment Header
Figure The TCP header.

63. The TCP Segment Header
Source Port and Destination Port Fields (16 bits each):
The source port and destination port identify the local end points of the connection. A port plus its host's IP address forms a 48-bit unique TSAP.
Sequence Number and Acknowledgement Number Fields (32 bits each):
The sequence number and acknowledgement number fields perform their usual function. The acknowledgement number field specifies the next byte expected. Both are 32 bits long because every byte of data is numbered in a TCP stream.
TCP Header Length Field (4 bits):
The TCP header length field tells the number of 32-bit words in the TCP header
Reserved Field (6-bit):
The reserved field is reserved for future use

64. The TCP Segment Header URG Bit:
The URG bit is set to 1 to indicate that the urgent pointer is valid. The urgent pointer indicates amount of urgent (expedited) data in the segment.
ACK Bit:
The ACK bit set to 1 to indicate that the acknowledgement number is valid. If ACK is 0, the segment does not contain an acknowledgement so the acknowledgement number field is ignored.
PSH Bit:
If the PSH bit is set, the receiver is requested to deliver the data to the application upon arrival and not buffered until a full buffer has been received.
RST Bit:
The RST bit is used to reset a connection that has become confused due to host crash or some other reason. It is also used to reject an invalid segment or to refuse an attempt to open a connection.

65. The TCP Segment Header SYN Bit:
The SYN bit is used to establish connections. The connection request has SYN=1 and ACK=0 to indicate that the piggyback acknowledgement field is not in use. The connection reply does bear an acknowledgement, so it has SYN=1 and ACK=1. Therefore, the SYN bit is used to denote CONNECTION REQUESTED and CONNECTION ACCEPTED, with ACK bit used to distinguish between those two possibilities.
FIN Bit:
The FIN bit is used to release connection. It specifies that the sender has no more data to transmit.
Window Size Field (16 bits):
The window size field relates to the sliding window flow control scheme. It indicates the number of bytes may be sent starting at the byte acknowledged.

66. Figure 6-30. The pseudoheader included in the TCP checksum
The TCP Segment Header
Checksum Field (16 bit):
A checksum is provided for extreme reliability. It checksums the header, the data, and the conceptual pseudoheader. The checksum is the 1's complement of the sum of all the 16-bit words in the segment added together using 1's complement arithmetic. As consequence, when the receiver performs the calculation on the entire segment including the checksum field, the result should be zero.
The pseudoheader contains the 32-bit IP addresses if the source and destination machines, the protocol number for TCP (6), and the byte count for the TCP segment (including the header).
Figure The pseudoheader included in the TCP checksum

67. The TCP Segment Header Urgent Pointer Field (16 bits):
The urgent pointer indicates the amount of urgent (expedited) data in the segment. Normally this is delivered by the receiving TCP entity immediately it is received.
Option Field:
The option field was designed to provide a way to add extra facilities not covered by the regular header. The most important option is the one that allows each host to specify the maximum TCP payload it is willing to accept. During connection setup, each side can announce its maximum, and the smaller of the two numbers wins. If a host does not use this option, it defaults to a 536-byte payload.

68. The TCP Segment Header
For lines with high bandwidth, high delay, or both, the 64 KByte window is often a problem.
On a T3 line ( Mbps), it take only 12 msec to output a full 64 KByte window. If the round trip propagation delay is 50 msec (typical for transcontinental fiber), the sender will be idle 3/4 of the time waiting for acknowledgement.
On a satellite connection, the situation is even worse. A larger window size would allow the sender to keep pumping data out, but using 16-bit window size field, there is no way to express such a size. Therefore, a window scale option is proposed, allowing the sender and receiver to negotiate a window scale option. This number allows both sides to shift the window size field up to 16 bits to the left, allowing windows up to 232 bytes.
Another option proposed is the use of the selective repeat instead of go back n protocol.

69. TCP Connection Management
Connections are established using the three-way handshake
To establish a connection, one side, say the server, passively waits for an incoming connection by executing the LISTEN and ACCEPT primitives
The other side, say the client, executes a CONNECT primitive, specifying the IP address and port to which it wants to connect and the maximum TCP segment size it is willing to accept. The CONNECT primitive sends a TCP segment with the SYN bit on and ACK bit off and waits for response.
When the segment arrives at the destination (server ) , the TCP entity checks to see if there is a process that has done a LISTEN on the port given in the Destination port field. If not, it sends a reply with the RST bit on to reject the connection.

70. TCP Connection Management
If some process is listening to the port, that process is given the incoming TCP segment. It can either accept or reject the connection. If it accepts, an acknowledgment segment is sent back. The sequence of TCP segments sent in the normal case. Note that a SYN segment consumes 1 byte of sequence space so it can be acknowledged unambiguously.
If two hosts simultaneously attempt to establish a connection between the same two sockets, only one connection is established.

71. TCP Connection Management
(a) TCP connection establishment in the normal case.
(b) Call collision.

72. TCP Connection Management
Although TCP connections are full duplex, connections are released as pair of simplex connections. Each simplex party can send a TCP segment with the FIN bit set, which means that it has no more data to transmit. When a FIN is acknowledged, the direction is shut down. Data may continue to flow in the other direction. When both directions have been shut down, the connection is released.
Normally, four TCP segments are needed to release a connection, one FIN and one ACK for each direction. However, it is possible for the first ACK and the second FIN to be contained in the same segment, reducing the total count to three.

73. TCP Connection Management
To avoid the two-army problem, timers are used. If a response to a FIN is not forthcoming within two maximum packet lifetimes, the sender of the FIN releases the connection. The other side will eventually notice that nobody seems to be listening to it anymore , and times out as well.
The steps required to establish and release and release a connection can be represented in a finite state machine with 11 states.

74. TCP Connection Management
TCP connection management finite state machine. The heavy solid line is the normal path for a client. The heavy dashed line is the normal path for a server. The light lines are unusual events

75. TCP Connection Management
The states used in the TCP connection management finite state machine.

76. TCP Connection Release
TCP connections are full duplex
They are as 2 simplex connections
Either party can release a connection
By sending TCP segment with FIN bit set
When Fin acknowlgd, direction shut down
Connection released when both direction shutdown
Timers are used to manage no response cases

77. TCP Connection management Modeling
Finite state machine shows steps to establish and release connections. (Host point of view)
Each connection starts with CLOSED state
It will leave it bei either passive open(LISTEN) or an active open(CONNECT)
If the other side does the opposite one, a connection is ESTABLISHED.
Connection RELEASE by either party
When RELEASE complete, the state returns to CLOSED

78. TCP Connection management Modeling -2-
Connection management (Server point of view)
The server does a LISTEN and wait
When SYN received, it is acknowledged
Server goes to SYN RCVD state
When the server’s SYN Ack is Acknowlgd, three ways handshake is complete, and the server goes to ESTABLISHED state.
DATA TRANSFER CAN THEN START

79. TCP Connection management Modeling -3-
When a client is done, it does a CLOSE.
This cause a FIN to arrive to the server
When the server has finished too, it sends a CLOSE too.
A FIN is sent to the client.
Once the client Acknowledge the FIN, the server releases the connection, and deletes the connection record

81. TCP Transmission Policy -1-
Example: Case the receiver has 4k buffer:
If the sender transmits a 2k segment:
The receiver will acknowledge the segment and advertise a window of 4-2=2K
Now the sender transmits another 2k, which will be acknowledged and the window will be 2-2=0
The sender must stop sending until it is informed that some data is removed from the windows buffer, with 2 exceptions:

82. TCP Transmission Policy -2-
The 2 exceptions:
Urgent data may be sent.
Ex:to allow the user to kill a remote process
The sender may send a 1 byte segment to make the receiver reannounce the next byte expected and the new window size

83. Nagle’s Algotithm
When data comes into the sender one byte at a time, then:
Just send the first byte and:
Buffer all the rest until the outstanding byte is acknowledged, then:
Send all buffered characters in one TCP, then
Start buffering again until the sent data is acknowledged

84. Clark’s Silly window syndrome
Here a problem that can degrade the TCP performance. Ex:
When data are passed to the TCP sending entity, in large blocks, and in the same time:
An interactive application on the receiving side reads data one byte at a time.
See next figure.
The solution is to prevent the receiver from sending a window update for 1 byte.
It is then forced to wait until it has a decent amount of space available and then advertise it.

86. TCP Congestion Control
Congestion is when the Network load is more than it ca handle
The Network layer deals with congestion
But TCP also, by slowing down the data rate
TCP manipulate dynamically the window size

88. TCP Congestion Control -2-
First, TCP try to detect congestion
It supposes that timeouts are due to congestion
TCP try also to prevent congestions
By connection setup, the receiver specify a window based buffer size
If no congestion, window overflow problem
will not occur

90. TCP Congestion Control -3-
The solution take 2 facts into account:
- Network capacity
- Receiver capacity
Each sender maintains two windows
- the window the receiver has granted
- the congestion window.
It takes into account a third parameter: the threshold

91. Slow Start algorithm
By connection setup, congestion window is set to the max segment size possible
If no timeout occurs, the congestion window size will be each time the double of the previous one.(2segments, 4.., 8…)
This continue exponentially until a timeout occurs.
Then the half of the last window size will be maintained as the congestion window.

92. The Internet Congestion Control Algorithm
The threshold has initially 64 KB size
Set to half of the current congestion window when a timeout occurs, and the congestion window is reset to one maximum segment
Slow start is then used to determine what it can handle
Exponential growth stops when the threshold is hit
Then the congestion window grows linearly by one segment at the f maximum for each burst

94. TCP Timer Management-1-
TCP uses multiple timers
The retransmission Timer is the most important
Problem: How to determine it!
It is more difficult to determine the one in the Internet Transport Layer than in the data link layer (Network versus point to point)
Should be slightly more then the RTT, and should take possible congestion into account

95. TCP Timer Management -2-
If timeout T1 is set too short,
unnecessary retransmissions will occur
More packets will be on the Network
Performance will suffer, especially when a packet is lost
Also, the mean and variance of the acknowledgement arrival distribution can change rapidly as congestion builds up and can be resolved very quickly
If timeout is set too large, unnecessary wait time will be spent for a packet which could be lost.
The solution: A highly dynamic algorithm that constantly adjusts the timeout interval is used.

96. TCP Timer Management -3-
For each connection, TCP maintains a variable, RTT (Round Trip Time)
When a segment is sent, a Timer is started, both to see:
How long the acknowledgement takes
And to start a retransmission if it takes too long.
If the ack gets back before the timer expires, then TCP measurers how long the acknowledgement took, say, M
It then updates RTT according to the formula:
RTT= aRTT + (1-a)M
Where a is a smoothing factors that determines how much weight is given to the old value. Typically a=7/8

98. Wireless TCP and UDP –1-
Unfortunately, wireless transmission links are highly unreliable
Packets are therefore often lost
This can lead to retransmission by TCP
And transmission will be slowed down
And mutters get worse
Usually on a link, only the last 1 km is wireless
Making the correct decision on a timeout is mutter of where a problem has occurred

99. Wireless TCP and UDP –2-
The Bakne and Badrinath solution is the INDIRECT TCP.
It splits TCP connection into 2 separate connections. –see figure-
One from sender to the base station
The other from base station to receiver
The base station simply copies packets between the connections in both directions
Pb1: it breaks the semantics of TCP
Pb2: Ack received from base station doesn’t mean that the receiver has got the message

100. Wireless TCP and UDP –3- A different solution, due to BALAKRISHNAN.
It doesn’t break TCP semantics
Several small modifications in Network Layer Code in the base station
Addition of a snooping agent at the base station
Disadvantage: if the wireless link is very lossy, the source may timeout, and congestion control algorithm may be invoked.

102. Transactional TCP –1-
Remote procedure calls are a way to implement client server systems.
UDP is used in case of Request and Replay are small, and fits in a single packet.
See the previous figure for normal sequence of packets for doing RPC over TCP.
The question is how to get both the efficiency of using UDP (just 2 msg) and the reliability of TCP.
The solution is to use T/TCP (transactional TCP)

103. T/TCP or Transactional TCP –2-
See previous figure, part (b).
The standard connection setup sequence slightly is modified
It allows the transfer of data during setup.
If the reply of the server fits in a packet, the connection will terminate after 3 msg
If not, the server will send multiple packets before closing down the connection.