End-to-end protocols

A transport protocol is usually expected to provide:

• Guaranteed message delivery.
• Delivers messages in the same order they were sent.
• Delivers at most one copy of each message.
• Supports arbitrarily large messages.
• Supports synchronization between the sender and the receiver.
• Allows the receiver to apply flow control to the sender.
• Supports multiple application processes on each host.

Typical limitations of the network service (like IP of Internet) on which transport protocol will operate:

• Drop messages.
• Reorder messages.
• Deliver duplicate copies of a given message.
• Limit messages to some finite size.
• Deliver messages after an arbitrarily long delay.

Challenge for Transport Protocols:

• Develop algorithms that turn the unreliable service of the underlying network into the service required by application programs.
• Unreliable service -> Unreliable service (UDP)
  .
• Unreliable service -> Reliable service (TCP).

Simple Demultiplexer protocol (UDP)

• Extends host-to-host delivery service of the underlying network into a process-to-process communication service.
• Adds a level of demultiplexing which allows multiple application processes on each host to share the network.
• Format for UDP header:

Reliable Byte Stream protocol (TCP)

In contrast to User Datagram Protocol (UDP), Transmission Control Protocol (TCP) offers the following services:

• Reliable
• Connection oriented
• Byte-stream service

Flow control VS Congestion control

• Flow control involves preventing senders from overrunning the capacity of the receivers.
• Congestion control involves preventing too much data from being injected into the network, thereby causing routers/switches or links to become overloaded.

End-to-end Issues

TCP runs over the Internet rather than a point-to-point link.

The TCP sliding window algorithm need to consider:

• TCP supports logical connections between processes that are running on two different computers in the Internet.
• TCP connections are likely to have widely different RTT times.
• Packets may get reordered in the Internet.
• TCP needs a mechanism(機制) using which each side of a connection will learn what resources the other side offers to the connection.
• TCP needs a mechanism using which the sending side will learn the capacity of the network.

TCP Segment

• TCP is a byte-oriented protocol.
• The sender writes bytes into a TCP connection and the receiver reads bytes out of the TCP connection.
• However, TCP does not transmit individual bytes over the Internet.
• The source TCP buffers enough bytes from the sending process to fill a reasonably sized packet and then sends this packet to its peer on the destination host.
• The destination TCP then puts the contents of the packet into a receive buffer, and the receiving process reads from this buffer.
• The packets exchanged between TCP peers are called segments.
• TCP Header Format:

• SYN/FIN: The SYN and FIN flags are used when establishing and terminating a TCP connection, respectively.
• ACK: The ACK flag is set any time the Acknowledgment field is valid(有效的), implying(說明) that the receiver should pay attention to it.
• URG: The URG flag signifies that this segment contains urgent(緊急) data. When this flag is set, the UrgPtr field indicates where the nonurgent data contained in this segment begins. (The urgent data is contained at the front of the segment body, up to and including a value of UrgPtr bytes into the segment.)
• PSH: The PSH flag signifies that the sender invoked the push operation, which indicates to the receiving side of TCP that it should notify the receiving process of this fact.
• RST: The RST flag signifies that the receiver has become confused, it received a segment it did not expect to receive——and so wants to abort the connection.

TCP Connection Management

Establish Connection

TCP sender, receiver establish “connection” before exchanging data segments.

initialize TCP variables:

• Sequence numbers
• Buffers, flow control info (e.g. RcvWindow)

Client: connection initiator

Socket clientSocket = new Socket("hostname","port number");

Server: contacted by client

Socket connectionSocket = welcomeSocket.accept();

Three-way handshake:

• Step 1: Client sends TCP SYN segment to server.
  • specifies initial seq.
  • no data.
• Step 2: Server receives SYN, replies with SYN/ACK segment.
  • server allocates buffers.
  • specifies server initial seq.
• Step 3: client receives SYN/ACK, replies with ACK segment, which may contain data.
• Timeline for three-way handshake algorithm:

Closing Connection

• Step 1: Client sends TCP FIN control segment to server.
• Step 2: Server receives FIN, replies with ACK. Closes connection, sends FIN.
• Step 3: Client receives FIN, replies with ACK.
  • Enters “timed wait” —— will respond with ACK to received FINs
• Step 4: Server receives ACK. Connection closed
• Timeline for closing a connection:

TCP client state diagram

TCP server state diagram

Timeout value for Retransmission

Original Algorithm

• Measure SampleRTT for each segment/ ACK pair.
• Compute weighted average of RTT:
  • EstRTT = a x EstRTT + (1 - a )x SampleRTT
  • a between 0.8 and 0.9
• Set timeout based on EstRTT.
  • TimeOut = 2 x EstRTT
• Problem of calculating the SampleRTT:
  • When a segment is retransmitted and then an ACK arrives at the sender, It is impossible to decide if this ACK should be associated with the first or the second transmission for calculating RTTs.

Karn/Partridge Algorithm

• Do not sample RTT when retransmitting.
• Double timeout after each retransmission.

Main problem with the original computation is that it does not take variance of SampleRTTs into consideration.

• For small variance among SampleRTTs.
  • Then the EstimatedRTT can be better trusted.
  • There is no need to multiply this by 2 to compute the timeout.
• For large variance among SampleRTTs.
  • The timeout value should not be tightly coupled to the Estimated RTT.

Jacobson/Karels Algorithm

EstimatedRTT = (1 - α)· EstimatedRTT + α·SampleRTT (α=0.125)

DevRTT = (1-β)· DevRTT + β·|SampleRTI - EstimatedRTT| (β=0.25)

TimeoutInterval = EstimatedRTT + 4·DevRTT

TCP Fast Retransmission

TCP waits until it has seen three duplicate ACKs before retransmitting the packet.

Fast Retransmission:

TCP Congestion Control

The idea of TCP congestion control is for each source to determine how much capacity is available in the network, so that it knows how many packets it can safely have in transit.

Additive Increase Multiplicative Decrease (AIMD)

• CongestionWindow: used by the source to limit how much data it is allowed to have in transit simultaneously(同時) for a connection.
• The congestion window is congestion control’s counterpart(對應部分) to flow control’s advertised window.
• The maximum number of bytes of unacknowledged data allowed is now the minimum of the congestion window and the advertised window.
• Transmission rate:
  • Rate = CongestionWindow/RTT (Bytes/sec)
• TCP’s effective window is revised as follows:
  • MaxWindow = MIN (CongestionWindow, AdvertisedWindow)
  • EffectiveWindow = MaxWindow − (LastByteSent − LastByteAcked).
• A TCP source is allowed to send no faster than the slowest component can accommodate:
  • the network or
  • the destination host

The AdvertisedWindow is sent by the receiver.

To determine the value for CongestionWindow:

• Each time a packet lose(3-duplicate ACK) occurs, the source sets CongestionWindow to half of its previous value.
• CongestionWindow is not allowed to fall below the size of a single packet, or in TCP terminology, the maximum segment size (MSS).
• Increase the congestion window when the newly capacity of network is available. (adds the equivalent of 1 packet(MMS bytes) when the last RTT have been ACKed)
• Improve: TCP does not wait for an entire window’s worth of ACKs to add 1 packet’s worth to the congestion window, but instead increments CongestionWindow by a little for each ACK.
  • Increment = MSS × (MSS/CongestionWindow)
  • CongestionWindow += Increment (Every Acked)

Slow Start: to increase the congestion window rapidly from a cold start. Slow start effectively increases the congestion window exponentially, rather than linearly.

• TCP effectively doubles the number of packets it has in transit every RTT.
• After 3 dup ACKs:
  • CongWin is cut in half;
  • window then grows linearly.
• But after timeout event:
  • CongWin instead set to 1
    MSS;
  • window then grows exponentially;
  • to a threshold, then grows linearly.

Summary :

• When CongWin is below Threshold, sender in slow-start phase, window grows exponentially.
• When CongWin is above Threshold, sender is in congestion-avoidance phase, window grows linearly.
• When a triple duplicate ACK occurs, Threshold set to CongWin/2 and CongWin set to Threshold.
• When timeout occurs, Threshold set to CongWin/2 and CongWin is set to 1 MSS.
• Round Trip Time:

TCP throughput

• Ignore slow start.
• When window is W, throughput is W/RTT.
• Just after loss, window drops to W/2, throughput to W/2RTT.
• Average throughout: 0.75 W/RTT.

想了解更多關於計算機網路架構與網路安全：計算機網路架構與網路安全專欄