Tutorial 9 : TCP and congestion control part I

Transcription

1 Lund University ETSN01 Advanced Telecommunication Tutorial 9 : TCP and congestion control part I Author: Antonio Franco Course Teacher: Emma Fitzgerald January 27, 2015

2 Contents I Before you start 3 II Exercises 3 1 TCP and congestion control III Solutions 4 2 TCP and congestion control

3 Part I Before you start This tutorial is given to prepare you to the exam. Since time is limited, it is highly advised that you first try to solve the exercises (Part II) at home, then have a look at the solutions (Part III), and, finally, ask questions during the exercises sessions. Part II Exercises 1 TCP and congestion control 1.1 Briefly explain the following terms: Kleinrock s conservation law 2. Priority Queuin 3. Fair Queuing 4. Weighted Fair queuing The IETF has standardised two main architectures for QoS management in IP networks, IntServ and DiffServ Explain how the two differ, name their main advantage/drawback. 2. The RSVP signalling protocol can be used in both architectures, why is this protocol receiver based instead of sender based? 3. RSVP implements PATH and RESV messages. Why are they used and what do they achieve? 4. Why is RSVP implementing soft states on routers? What is the global synchronisation problem in TCP (Transport Control Protocol) congestion control and why does it occur? How does RED (Random Early Detection) avoid this problem while still controlling congestion? 3

4 In RED, what is the reason for the conversion from P a to P b? That is, why is the packet drop probability not simply linear as a function of the queue length? Part III Solutions 2 TCP and congestion control 2.1 Kleinrock s conservation law (sum of the utilisation x delay for each node is constant) simply states that for a work conserving system, id delay is lowered for a node (flow) then the delay for other nodes (flows) must increase. Priority Queuing is a simple system with n queues in order of priority where a queue of a higher priority that holds a packet is emptied before any queue of lower priority. The system provides traffic separation but no fairness and low priority queues can be starved. Fair Queueing is a system with one queue per flow served in a round robin fashion. FQ provides load balancing among flows (no point in being greedy) but flows with smaller packets are being penalised since they get to send lower number of bytes per round. Weighted Fair Queuing is a system that first achieves equal bit rate per flow (as in bit round fair queueing) but then also has the capability to achieve service differentiation among flows so that higher priority flows receive more expedited forwarding. WFQ achieves this by calculating a finishing time for each packet and then serving the packets from different flow in order of finishing time. 2.2 IntServ is a scheme that emulates the behaviour and function of the ATM system with virtual curcuits. In IntServ, each flow is classified and states are maintained for each flow in accordance with a flow specification at each router along a path. This achieves great granularity and predictability for the performance of each flow. DiffServ on the other hand classifies each flow as belonging to a small set of traffic classes where each class receives separate treatment along a path. In DiffServ, most of the heavy lifting is done at the edge which results in lower overheads for the core routers. INtserv provides great granularity but suffers from scalability problems whereas DiffServ scales well but only provides statistical guarantees. RSVP is receiver based in order to support varying reservation levels among flows in a multicast scenario, to enable differentiated cost levels to be controlled by the receivers etc. PATH messages are used to detect the forwarding path from sender to receiver so that the receiver can make reservations along the correct path. The RESV 4

5 messages are used to make reservation requests along the path discovered by the PATH messages. RSVP uses soft states because routing paths may change during a session. When this happens, routers must detect that a flow has terminated and thus remove reservations and free resources. 2.3 The global synchronisation problem occurs when there is congestion in the network. Many TCP connections will detect the congestion at once (by losing packets as queue buffers fill up) and will then simultaneously lower their transmission rates. This results in an under-utilisation of the network. The connections will then see eased congestion and increase their transmission rate again, resulting in congestion again. RED uses probabilistic packet dropping before the queue becomes full. This means that only some TCP connections will lose packets and thus enter backoff. Since some connections back off, congestion will be eased, but global synchronisation is avoided as not all connections are affected at the same time. The packet drop probability increases as the queue length increases, so that congestion can be controlled effectively at different offered loads. The conversion causes the packet drop probability to begin low and then increase as the count of packets arriving since the last packet drop increases. This results in a uniform distribution of the number of packets allowed to join the queue between discards. This is done to prevent unfairly penalising bursty traffic. 5