TCP continued Discussion TCP Throughput TCP will most

TCP continued

Discussion – TCP Throughput • TCP will most likely generate the saw tooth type of traffic. – A rough estimate is that the congestion window will go from w/2 to w, where w is the cwnd value causing congestion. • Does it mean that TCP can achieve only 75% of the throughput that the network can support?

Discussion – TCP Throughput • Recall that the routers have buffers. Buffer size is usually large. • What happens is that from the time the router drops a packet (when TCP will start to backoff), till the time TCP climbs back to a large window size, the router keeps on working to get rid of the buffered packets.

Discussion – TCP on Wireless • How will TCP perform when the path goes through a wireless link of loss ratio 0. 1? (Randomly drops 10% of the packets? )

Discussion – TCP on Wireless • TCP will most likely perform not ideally. • A wireless loss is a loss. The TCP sender will have to, according to the protocol, backoff, either start fast retransmit or perform slow start, in both cases the congestion window is reduced. • Is this the correct response? Actually no. Because the loss is not due to congestion. • TCP should send packets as fast as possible to recover from the loss.

Discussion – TCP in a Global Sense • We usually assume a router drops packets at the end of the queue. • What will this lead to in a global sense? – Many TCP connections share the same router, the same input/output ports.

Discussion – TCP in a Global Sense • What will likely happen is that all TCP flows will hold back at the same time, i. e. , when the router starts to drop packets. Then they will start in increase at the same time. • Global synchronization is not good because it puts more pressure on the router buffers. – If not synchronized, the buffer size needs to prepare for the average case. If synchronized, needs to prepare for the worst case. • Solution?

Discussion – TCP in a Global Sense • Use Random Early Detection (RED). • Idea is to drop even when the queue is not full. Drop with larger probability if the queue length is longer. • It will more likely drop a packet from a larger flow than from a smaller flow.

TCP Timeout • In our project, each packet contains the sender timestamp. If the packet is received correctly, the receiver will send an ACK which will echo this timestamp. – The ACK may not be for this packet but for an earlier packet. – The advantage of this is that we always have unambiguous samples of RTT: the sender simply compares the timestamp in the ACK and its local time. – The disadvantage is that we send the timestamps every time. • So how does TCP do it?

TCP Timeout • TCP does not want to send the timestamp in every segment. – This is overhead we don’t like and is not in the TCP header. • So the problem is that when we get an ACK for segment A at T 1, and suppose we remember we sent segment A at T 0, can we use T 1 – T 0 as a sample of RTT? • We cannot because we may have retransmitted segment A and the ACK is actually for the earlier transmission.

TCP Timeout • The TCP sender will get a RTT sample only for a segment that has not been retransmitted. – Delayed ACK is not a problem because we will receive only one ACK for the later segment and we will have one RTT sample. – Duplicate ACK will cause an over estimation of RTT but should still be reasonably close.

TCP Timeout • What will happen if congestion really happened and a stream of packets are lost? • Every packet will timeout suppose the current timeout is TIMEOUT 0. We will retransmit every packet. We will not get RTT samples for a long time, and we will be stuck with TIMEOUT 0. But TIMEOUT 0 was calculated before the congestion so it is small, so every packet will timeout and we will retransmit every packet again. This is disastrous. • When designing a system, we are sometimes okay with non-optimal solutions, but we do not like disasters.

TCP Timeout • So, the fix in most TCP implementations is to double the timeout value upon a timeout event. – That is basically saying that if we do not know the actual RTT, we will just probe and if we fail, we take a more conservative estimate. A theme recurring over and over again in networks.

Misc – TCP Deadlock • The receiver window is full because the application is not reading the data fast enough. • The receiver sends ACK back advertising window size 0. • The sender will not send anything. • The receiver finally frees up some space, but the sender does not know, because the receiver does not send ACK when no data is received. • Solution: TCP provide option for the sender to send a 1 -byte segment to probe the receiver.

Misc – TCP sender • TCP sender does not have to send the data immediately. The implementation typically waits until get some more data to send. Remember TCP regards the data as a byte stream. – This is the reason why the template code took some measures to make sure that always a complete packet is delivered.

Misc – Silly Window Syndrome • The receiver may advertise small windows. • The sender then sends small segments – not very efficient. • TCP requires the receiver only advertise window of one MSS or half of its buffer, whichever is smaller.

ECN • Explicit Congestion Notification. RFC 3168. • “An ECN-aware router may set a bit in the IP header instead of dropping a packet in order to signal the beginning of congestion. The receiver of the packet echoes the congestion indication to the sender, which must react as though a packet drop were detected. “ – from wiki

Exercise • Consider a, 802. 11 g LAN, and assume there is only one node called A running at 54 Mbps. Assume A is downloading a file with FTP which runs over TCP. Assume each IP packet is either 1500 bytes or 40 bytes, and assume the TCP header and the IP header are always both 20 bytes. Assume for every TCP data segment received, A sends a TCP ACK immediately. Assume SIFS is 10 us and DIFS is 28 us. In this problem, for simplicity, assume there is no back-off and there is no frame loss. Assume the duration of each 802. 11 data frame is 20 us plus data transmission time of the IP packet. The duration of the 802. 11 ACK frame is 30 us. Assume the Access Point always has data to send to A. What is the maximum downloading speed of A measured in megabits per second?

Exercise • • • Consider a, 802. 11 g LAN, and assume there is only one node called A running at 54 Mbps. Assume A is downloading a file with FTP which runs over TCP. Assume each IP packet is either 1500 bytes or 40 bytes, and assume the TCP header and the IP header are always both 20 bytes. Assume for every TCP data segment received, A sends a TCP ACK immediately. Assume SIFS is 10 us and DIFS is 28 us. In this problem, for simplicity, assume there is no back-off and there is no frame loss. Assume the duration of each 802. 11 data frame is 20 us plus data transmission time of the IP packet. The duration of the 802. 11 ACK frame is 30 us. Assume the Access Point always has data to send to A. What is the maximum downloading speed of A measured in megabits per second? TCP Data frame: 20+222=242 us TCP ACK frame: 20+6 = 26 us Each transaction is 28+242+10+30+28+26+10+30 = 404 us And the transferred 1460 * 8 = bits So, 28. 9 Mbps

Beyond TCP – Data Center TCP • The problem is to support BOTH high throughput and low latency. • When there are large flows, the queues in the switches will build up. TCP will not respond until the queue size is really large, at which point the delay is already too large for many applications!

Beyond TCP – DCCP • Sometimes you don’t need reliability, but need to exercise some congestion control! • For applications with timing constraints, data may be useless if outdated. • http: //read. cs. ucla. edu/dccp/

Useful Linux Network Commands • • • ifconfig route tracert netstat ping tcpdump