The University of Adelaide, School of Computer Science

The University of Adelaide, School of Computer Science
17 April 2017 Chapter 6 Congestion Control and Resource Allocation Copyright © 2010, Elsevier Inc. All rights Reserved Chapter 2 — Instructions: Language of the Computer

Problem 17 April 2017 We have seen enough layers of protocol hierarchy to understand how data can be transferred among processes across heterogeneous networks Problem How to effectively and fairly allocate resources among a collection of competing users? Chapter 2 — Instructions: Language of the Computer

Congestion Control and Resource Allocation
Resources Bandwidth of the links Buffers at the routers and switches What is congestion? “too many sources sending too much data too fast for network to handle” Higher rate of inputs to a router than outputs Packets compete at a router for the use of a link Each competing packet is placed in a queue waiting for its turn to be transmitted over the link

When too many packets are contending for the same link Queuing/Buffering at routers Long Delays The buffer overflows at routers Dropped packets Result in lost packets Network should provide a congestion control mechanism to deal with such a situation

Congestion Control vs Flow Control
The University of Adelaide, School of Computer Science Congestion Control vs Flow Control 17 April 2017 Congestion control is a global issue involves every router and host within the subnet Flow control – scope is point-to-point involves just sender and receiver How did TCP implement this? Flow control: Make sure fast sender does not overwhelm a slow receiver(advertised window). Congestion control: Not overwhelm network by putting too much data at too much speed Chapter 2 — Instructions: Language of the Computer

Two sides of the same coin If the network takes active role in allocating resources The congestion may be avoided No need for congestion control

Allocating resources with any precision is difficult Resources are distributed throughout the network On the other hand, we can always let the sources send as much data as they want Then recover from the congestion when it occurs Easier approach But it can be disruptive because many packets may be discarded by the network before congestions can be controlled

Question Congestion control and resource allocations involve both hosts and network elements such as routers What can a host do to control congestion? What can a router do to control congestion?

Answer Congestion control and resource allocations involve both hosts and network elements such as routers In network elements (Routers) Various queuing disciplines can be used to control: the order in which packets get transmitted and which packets get dropped At the hosts’ end The congestion control mechanism paces how fast sources are allowed to send packets

Issues in Resource Allocation
The University of Adelaide, School of Computer Science Issues in Resource Allocation 17 April 2017 Packet Switched Network (internet) Resource allocation consists of multiple links and switches/routers. Congested intermediate link. In such an environment, a given source may have more than enough capacity on the immediate outgoing link to send a packet. Bottleneck router: But somewhere in the middle of a network, its packets encounter a link that is being used by many different traffic sources Chapter 2 — Instructions: Language of the Computer

Question What are the causes of a bottleneck router?

Aswer 17 April 2017 1. Amount of incoming data is too large AND 2. Speed of data arrival at router too high - Why? Even if router has a size 1 packet buffer, receiving large number of packets is not a problem as long as they are sent slowly. Why not arrival rate = forwarding rate? Processing time (only up to network layer) Mismatch of speed in heterogeneous networks (most important) Chapter 2 — Instructions: Language of the Computer

The University of Adelaide, School of Computer Science Issues in Resource Allocation 17 April 2017 Network Model Packet Switched Network Ethernet and T1 are two terms that are commonly heard in close proximity to each other. Although these technologies can be used together in some cases, they are not one and the same. The main difference between Ethernet and T1 is where they are being used. Ethernet is a networking technology that is used to interconnect multiple digital devices like computers in order to facilitate the transfer of information across them. In contrast, T1 is a telecommunications technology that is used to carry information across long distances. T1 is capable of carrying both voice and data information, unlike Ethernet, which is only capable of carrying data. But in our world today, voice can be transformed into data and allowed to pass through Ethernets via VoIP technologies. Although they may no longer be any difference to the end user, how the results are achieved are still very different. Read more: Difference Between Ethernet and T1 | Difference Between | Ethernet vs T1 One of the reasons why Ethernet and T1 are often used together is because of range. Ethernet has a very limited range, in contrast to T1. Because of this, T1 is often used by companies to expand their Ethernet far beyond its range. For example, if you have two Ethernets that are two far from each other, you can use T1 channels to bridge that gap. The signals need to be converted from one to the other and vice versa but the data will still remain intact. Read more: Difference Between Ethernet and T1 | Difference Between | Ethernet vs T1 A potential bottleneck router. Chapter 2 — Instructions: Language of the Computer

The University of Adelaide, School of Computer Science Issues in Resource Allocation 17 April 2017 Connectionless Flows For much of our discussion, we assume that the network is essentially connectionless Any connection-oriented service needed is implemented in the transport protocol that is running on the end hosts. Why this assumption? Chapter 2 — Instructions: Language of the Computer

Why this assumption? Because, our original assumptions were too restrictive/strong: Connection-less vs connection-oriented networks There IS a grey area in between Datagrams are completely independent in connectionless network Yes, datagrams ARE certainly switched independently But usually, stream of datagrams between a particular pair of hosts flows through a particular set of routers

The University of Adelaide, School of Computer Science Issues in Resource Allocation 17 April 2017 Network Model Connectionless Flows Multiple flows passing through a set of routers Chapter 2 — Instructions: Language of the Computer

The University of Adelaide, School of Computer Science Issues in Resource Allocation 17 April 2017 Multiple related packets flow through each router Routers maintain soft state (some state of information) for each flow that goes through it Soft state is refreshed by periodic messages or is otherwise expired. Soft State (e.g. PIM)Vs Hard State Information (e.g RIP) Soft state of a flow can be used to make resource allocation decisions about the packets that belong to the flow. [Ref: Book]: Networking 2005 Networking Technologies, Services, And Protocols State maintained by the network is categorized into: Hard state Installed in nodes upon receipt of a setup message Removed only upon receipt of a explicit removal message Several routing protocols(BGP, OSPF, RIP) and early Internet signallig protocol (ST-II) use hard-state Soft state Refer to some non-permanent state in network nodes Expires unless refreshed Therefore does not need explicit removal mechanism like tat needed for hard state Used in many protocols(RTCP, PIM, SIP) By the use of the state (hard or soft), inside the network, protocols can provide enhanced services for end-to-end communcations. E.g. QoS reservation setup, flow-coupled firewall configuration Both hard or soft state can be installed either in intermediate nodes, end hosts only or both Due to the nature of the state, unlike other types of protocols, state management protocol often require extremely complex and powerful mechanisms to ensure that the state is perfectly synchronized and up-to-date. Chapter 2 — Instructions: Language of the Computer

The University of Adelaide, School of Computer Science Issues in Resource Allocation 17 April 2017 Soft state represents a middle ground between : a purely connectionless network that maintains no state at the routers and a purely connection-oriented network that maintains hard state at the routers. In general, the correct operation of the network does not depend on soft state being present Each packet is still routed correctly without regard to this state But, when a packet happens to belong to a flow for which the router is currently maintaining soft state, then the router is better able to handle the packet. Chapter 2 — Instructions: Language of the Computer

Taxonomy There are countless ways in which resource allocation mechanisms differ We will discuss 3 dimensions along which resource allocation mechanisms can be characterized: Router-centric vs Host-centric Reservation based vs Feedback based Window based vs Rate based

The University of Adelaide, School of Computer Science Issues in Resource Allocation 17 April 2017 Router-centric vs. Host-centric Router-centric design: Each router takes responsibility for : deciding when packets are forwarded and selecting which packets are to dropped, as well as informing the hosts that are generating the network traffic how many packets hosts are allowed to send. Host-centric design: End hosts: observe the network conditions e.g. observe how many packets they are successfully getting through the network Adjust their behavior accordingly Note that these two groups are not mutually exclusive. Chapter 2 — Instructions: Language of the Computer

The University of Adelaide, School of Computer Science Issues in Resource Allocation 17 April 2017 Reservation-based vs. Feedback-based Reservation-based system : some entity (e.g., the end host) asks the network for a certain amount of capacity to be allocated for a flow. Each router then allocates enough resources (buffers and/or percentage of the link’s bandwidth) to satisfy this request. If the request cannot be satisfied at some router, because doing so would overcommit its resources, then the router rejects the reservation. Feedback-based approach: the end hosts begin sending data without first reserving any capacity and End hosts then adjust their sending rate according to the feedback they receive. EXPLICIT feedback - Router sends message ’slow down’ IMPLICIT feedback - end host adjusts sending rate subject to network conditions e.g. packet loss Chapter 2 — Instructions: Language of the Computer

The University of Adelaide, School of Computer Science Issues in Resource Allocation 17 April 2017 Window-based versus Rate-based Window-based: Receiver advertises a window to the sender (window advertisement) Rate-based Receiver control sender’s behavior using a rate: how many bit per second the receiver or network is able to absorb. E.g. multimedia streaming application Chapter 2 — Instructions: Language of the Computer

Evaluating Resource Allocation Schemes
Resource allocation schemes can be evaluated based on: Effectiveness Fairness

Evaluate Effectiveness of Resource Allocation
The University of Adelaide, School of Computer Science Evaluate Effectiveness of Resource Allocation 17 April 2017 Consider the two principal metrics of networking: throughput and delay. Clearly, we want as much throughput and as little delay as possible. Unfortunately, these goals are often somewhat at odds with each other. Increased throughput: fill links with data > congestion > increased delay Low delay > less congestion > reduced throughput Chapter 2 — Instructions: Language of the Computer

Increase throughput: Idle link hurts throughput. So, allow as many packets into the network as possible, Goal: drive the utilization of all the links up to 100%. Problem with this strategy: increasing the number of packets in the network also increases the length of the queues at each router. Longer queues, in turn, mean packets are delayed longer in the network

The University of Adelaide, School of Computer Science Evaluate Effectiveness of Resource Allocation 17 April 2017 Throughput and Delay Relationship: Described using the throughput to delay ratio. Used as a metric for evaluating the effectiveness of a resource allocation scheme. This ratio is sometimes referred to as the power of the network. Power = Throughput/Delay Chapter 2 — Instructions: Language of the Computer

The University of Adelaide, School of Computer Science Evaluate Effectiveness of Resource Allocation 17 April 2017 Ratio of throughput to delay as a function of load Chapter 2 — Instructions: Language of the Computer

Fair Resource Allocation
The University of Adelaide, School of Computer Science Fair Resource Allocation 17 April 2017 What exactly constitutes fair resource allocation? For example, a reservation-based resource allocation scheme provides an explicit way to create controlled unfairness. With such a scheme, we might use reservations to enable a video stream to receive 1 Mbps across some link while a file transfer receives only 10 Kbps over the same link. Chapter 2 — Instructions: Language of the Computer

The University of Adelaide, School of Computer Science Fair Resource Allocation 17 April 2017 When several flows share a particular link, we would like for each flow to receive an equal share of the bandwidth. This definition presumes that a fair share of bandwidth means an equal share of bandwidth. But equal shares may not equate to fair shares. Why? Chapter 2 — Instructions: Language of the Computer

The University of Adelaide, School of Computer Science Fair Resource Allocation 17 April 2017 Should we also consider the length of the paths being compared? Consider the figure: What does “Fair” mean? Equal share of resources for all flows? Proportional to how much you pay for service? Should we take route length into account? One four-hop flow competing with three one-hop flows Chapter 2 — Instructions: Language of the Computer

The University of Adelaide, School of Computer Science Fair Resource Allocation 17 April 2017 Raj Jain’s fairness index: Metric to quantify the fairness of a congestion-control mechanism. Assume: fair implies equal, all paths are of equal length Definition: Given a set of flow throughputs (x1, x2, , xn), the following function assigns a fairness index to the flows: The fairness index always results in a number between 0 and 1, with 1 representing greatest fairness. X1 = 2bits/s X2=2bits/s, X3 = 2bits/s f(x1,x2,x3) = ((2+2+2)^2)/(3*(2^2+2^2+2^2)) = 6^2 / 3*12 = 36/36 = 1 X1 = 2bits/s X2=10bits/s, X3 = 2bits/s f(x1,x2,x3) = ((2+10+2)^2)/(3*(2^2+10^2+2^2)) = 14^2 / 3*108 = 0.60 Chapter 2 — Instructions: Language of the Computer

Queuing Disciplines Each router must implement some queuing discipline
4/17/2017 Each router must implement some queuing discipline Scheduling policy Drop policy Queuing allocate bandwidth and buffer space: Bandwidth: which packet to serve (transmit) next Buffer space: which packet to drop next (when required) Queuing also affects latency

Queuing Disciplines FIFO Queuing Priority Queuing Fair Queuing

FIFO Queuing FIFO queuing: Tail drop: Scheduling disciplines
First-Come-First-Served (FCFS) queuing The first packet that arrives at a router transmitted first Tail drop: Drop policy If a packet arrives and the queue (buffer space) is full, then the router discards that packet regardless of flow or importance

Queuing Disciplines (a) FIFO queuing (b) tail drop at a FIFO queue

Question What are the problems of FIFO scheduling?
How suitable is FIFO queuing for sending both Voice over IP and s?

Answer FIFO: First-in first-out scheduling Voice over IP and Email:
Simple, but restrictive Voice over IP and Two kinds of traffic (different flows) Their transmission requirements differ: Voice over IP needs low delay can tolerate delay FIFO queue treats all packets the same: If voice traffic comes after traffic, VOIP traffic waits behind in FIFO queue (not acceptable!) FIFO Queue

FIFO + Drop-tail Problems
4/17/2017 Lock-out problem Few flows can monopolize the queue space A flow sends more Fill most of FIFO queue Full queues Occurs if routers’ queues are often full. TCP detects congestion from loss Forces network to have long standing queues in steady-state Queuing delays – bad for time sensitive traffic

Priority Queuing A simple variation on basic FIFO queuing.
Mark each packet with a priority The routers implement multiple FIFO queues, one per priority class. Always transmit high-priority traffic when present Possible starvation Priority 1 Queue Priority 2 Queue Priority 3 Queue Strict Priority Queuing Process: priority1 else priority 2 priority 3 Priority Assignment Methods: Weighted Fair Queuing E.g. Flow1  Queue1 processing probability = 0.1 Flow2  Queue2 processing probability = 0.2 Flow3  Queue3 processing probability = 0.7 Research queuing strategies 39

Fair Queuing Solves the main problem with FIFO queuing:
FIFO queuing does not discriminate between different traffic sources/ flows Fair queuing (FQ) algorithm address this problem. Maintain a separate queue for each flow currently being handled by the router. The router then services these queues in a round-robin fashion

Fair Queuing Round-robin service of four flows at a router
Why round robin? Round-robin (RR) is one of the algorithms employed by process and network schedulers in computing.[1] As the term is generally used, time slices are assigned to each process in equal portions and in circular order, handling all processes without priority (also known as cyclic executive). Round-robin scheduling is simple, easy to implement, and starvation-free. Packet scheduling use packets rather than time slices Round-robin scheduling can also be applied to other scheduling problems, such as data packet scheduling in computer networks. It is an Operating System concept. The name of the algorithm comes from the round-robin principle known from other fields, where each person takes an equal share of something in turn. In best-effort packet switching and other statistical multiplexing, round-robin scheduling can be used as an alternative to first-come first-served queuing. A multiplexer, switch, or router that provides round-robin scheduling has a separate queue for every data flow, where a data flow may be identified by its source and destination address. The algorithm lets every active data flow that has data packets in the queue to take turns in transferring packets on a shared channel in a periodically repeated order. The scheduling is work-conserving, meaning that if one flow is out of packets, the next data flow will take its place. Hence, the scheduling tries to prevent link resources from going unused. Round-robin scheduling results in max-min fairness if the data packets are equally sized, since the data flow that has waited the longest time is given scheduling priority. It may not be desirable if the size of the data packets varies widely from one job to another. A user that produces large packets would be favored over other users. In that case fair queuing would be preferable. If guaranteed or differentiated quality of service is offered, and not only best-effort communication, deficit round-robin (DRR) scheduling, weighted round-robin (WRR) scheduling, or weighted fair queuing (WFQ) may be considered. Round-robin service of four flows at a router

Question 17 April 2017 Does fair queuing actually do a fair queuing? Fair if all packets ave same length: Previous example: Flow1-4: packet size = 250bytes Flow i (-1-4)share = 250/(250*4) = ¼ fair Unfair if all packets have different lengths: Flow1: packet size = 500bytes ½ share Flow1: packet size = 100bytes 1/10 share Flow1: packet size = 100bytes 1/10 share Flow1: packet size = 300bytes 3/10 share Chapter 2 — Instructions: Language of the Computer

Answer The main complication with Fair Queuing:
Packets lengths vary: packets being processed at a router are not necessarily the same length. To truly allocate the bandwidth of the outgoing link in a fair manner, it is necessary to take packet length into consideration. E.g. A router is managing two flows one with 1000-byte packets and the other with 500-byte packets If you use round-robin for processing of packets: the first flow 2/3 of the link’s bandwidth and the second flow only 1/3 of its bandwidth. Unfair!

Bit-by-bit round-robin
What we really want is bit-by-bit round-robin Bit-by-bit round-robin: Router transmits: a bit from flow 1, then a bit from flow 2, and so on. Clearly, it is not feasible to interleave the bits from different packets. The FQ mechanism therefore simulates this behavior: Determine finishing-time of transmitting a packet if it used bit-by-bit round-robin Use this finishing time to sequence the packets for transmission.

Queuing Disciplines Fi = Si + Pi Bit-by-bit round robin:
To understand the algorithm for approximating bit-by-bit round robin, consider the behavior of a single flow For this flow, let Pi : packet length: denote the length of packet i Si: start time: time when the router starts to transmit packet i Fi: finish time: time when router finishes transmitting packet I Fi = Si + Pi Assume Pi is expressed in time to transmit packet (1bit  1 second)

Queuing Disciplines When do we start transmitting packet i?
Depends on whether packet i arrived before or after the router finishes transmitting packet i-1 for the flow If packet i arrived before router finished transmitting packet i-1: First bit of packet i transmitted immediately after last bit of packet i-1 If packet i arrived after router finished transmitting packet i-1: i.e. router finished sending packet i-1 long before packet i arrived i.e. for sometime the queue for this packet is empty

Queuing Disciplines Let Ai denote the time that packet i arrives at the router Then Si = max(Fi-1, Ai) Fi = max(Fi-1, Ai) + Pi Now for every flow, we calculate Fi for each packet that arrives using our formula We then treat all the Fi as timestamps Next packet to transmit is always the packet that has the lowest timestamp The packet that should finish transmission before all others i.e. a shorter packet arriving can be inserted in front of a longer packet already in queue

Queuing Disciplines E.g. Fair Queuing
(a) packets with earlier finishing times are sent first (b) sending of a packet already in progress is completed Both packets in flow1 have earlier finishing times than packet in flow2 Router already begun sending packet from flow2 when a packet from flow 1 comes Implementation does not preempt already processing packet (So, not exactly bit-by-bit fair queuing)

TCP Congestion Control
TCP congestion control was introduced into the Internet in the late 1980s by Van Jacobson, roughly eight years after the TCP/IP protocol stack had become operational. Immediately preceding this time, the Internet was suffering from congestion collapse— hosts send their packets into the Internet as fast as the advertised window would allow congestion would occur at some router (causing packets to be dropped), hosts would time out and retransmit their packets, resulting in even more congestion

The idea of TCP congestion control: 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. Once a given source has this many packets in transit, it uses the arrival of an ACK as a signal that one of its packets has left the network, and that it is therefore safe to insert a new packet into the network without adding to the level of congestion. By using ACKs to pace the transmission of packets, TCP is said to be self-clocking.

There a quite a few TCP congestion control variants in use today: Additive Increase/ Multiplicative Decrease (AIMD) Slow Start Fast retransmit and Fast Recovery

Additive Increase Multiplicative Decrease (AIMD)
Congestion Window: TCP maintains a new variable called congestion window per connection Source use this to limit amount of allowed data in transit at a given time. The congestion window is congestion control’s counterpart to flow control’s advertised window. The maximum number of bytes of unacknowledged data allowed = Minimum( congestion Window, advertised Window)

Additive Increase Multiplicative Decrease
TCP’s effective window is revised as follows: MaxWindow = MIN(CongestionWindow, AdvertisedWindow) EffectiveWindow = MaxWindow − (LastByteSent − LastByteAcked). Remember from previous: LastByteSent – LastByteAcked <= AdvertisedWindow That is, MaxWindow replaces AdvertisedWindow in the calculation of EffectiveWindow. Thus, a TCP source is allowed to send no faster than the slowest component—the network or the destination host—can accommodate. MaxWindow: ======== It is the sender who needs to know the amount of packets it can send at a time. It does not matter if receiver can accept 100 packets (advertised window = 100) at a time when the path is congested and can only carry 50 packets a time. (Congestion window size = 50) Similarly, it does not matter if the path is not so congested (Congestion window size = 100) when the receiver can accept only 50 packets (advertised window = 50) at a time Therefore take the minimum of the two as what sender can send at a time. EffectiveWindow: =========== LastByteSent – LastByteAcked is amount f unacked bytes So amount of unacked bytes < maxWindow E.g. max window = 100 bytes last byte sent = 130 last byte acknowledged: 100 i.e. you sent only 30 bytes where as u could have sent 100 bytes max.

How does TCP comes to learn an appropriate value for CongestionWindow? Sender needs to know both congestion window and advertised window. AdvertisedWindow is sent by the receiver There is no one to send a suitable CongestionWindow to sender!

Answer: TCP sender sets the CongestionWindow based on the level of congestion it perceives to exist in the network. Sender decrease the congestion window when the level of congestion goes up Sender increase the congestion window when the level of congestion goes down. Taken together, the mechanism is commonly called additive increase/multiplicative decrease (AIMD)

How does the source determine that the network is congested and that it should decrease the congestion window?

Answer: Multiplicative Decrease The main reason for un-delivered packets, and timeout occurrences, is that a packet was dropped due to congestion. Therefore, TCP interprets timeouts as a sign of congestion and reduces it’s current transmission rate. Specifically, each time a timeout occurs, the source sets CongestionWindow to half of its previous value. Repetition of this cycle gives the classic sawtooth pattern

Although CongestionWindow is defined in terms of bytes, it is easiest to understand multiplicative decrease if we think in terms of whole packets. E.g. suppose current CongestionWindow = 16 packets. If a loss is detected, CongestionWindow is set to 8. Additional losses cause CongestionWindow to be reduced to 4, then 2, and finally to 1 packet. CongestionWindow is not allowed to fall below the MSS: i.e. size of a single packet.

Every time the source successfully sends a CongestionWindow’s worth of packets—that is, each packet sent out during the last RTT has been ACKed—it adds the equivalent of 1 packet to CongestionWindow. i.e. Increment CongestionWindow by one packet per RTT (until a packet loss occur, in which case AIMD enters MD mode) Packet gets ack. That is your initial assumption of the congestion window was accurate. Then why increase it by 1? Because network might have more capacity to send more packets without being conggested. i.e. the actual congestion window could be larger than what sender knows. It needs to find out b/s it likes to send max bytes without congesting. So it will incrementally increase bytes sent to discover this.

Packets in transit during additive increase, with one packet being added each RTT.

The University of Adelaide, School of Computer Science Additive Increase Multiplicative Decrease 17 April 2017 Each time an ACK arrives, the congestion window is incremented as follows : Increment = MSS × (MSS/CongestionWindow) Congestion Window+= Increment CongestionWindow>=MSS i.e, rather than incrementing CongestionWindow by an entire MSS bytes each RTT, we increment it by a fraction of MSS every time an ACK is received. Increment : A fraction / multiple of MSS Fraction = (MSS/CW) If CW=MSS  increment = MSS If CW<MSS  increment>1 MSS  aggressive increase If CW>MSS  increment<MSS  conservative increase Chapter 2 — Instructions: Language of the Computer

Question Why does TCP decrease congestion window aggressively and increase it conservatively?

Answer 17 April 2017 One intuitive reason is that the consequences of having too large a window are much worse than those of it being too small. For example, when the window is too large, packets that are dropped will be retransmitted, resulting in congestion Thus, it is important to get out of this state quickly. Suppose node sends 10 bytes. Got acks So node set cw to 11 and sent 11 bytes but actual cw of network is only 10 bytes. So last byte was dropped from ruter’ So sender gets no ack and time out. It therefore reset its cs to 11/2 = 5 rather than 10. Additive increase more than make up for it by allowing it to rediscover correct cw again. Chapter 2 — Instructions: Language of the Computer

The University of Adelaide, School of Computer Science Additive Increase Multiplicative Decrease 17 April 2017 Problem: AIMD is good for channels operating close to network capacity But AIMD takes a long time to ramp up to full capacity when it has to start from scratch Why? AIMD increase congestion window linearly. Solution: Use Slow Start to increase window rapidly from a cold start Ironic to call it slow start isnt it? Chapter 2 — Instructions: Language of the Computer

Slow Start Another congestion control mechanism
Increase the congestion window rapidly from a cold start. Effectively increases the congestion window exponentially, rather than linearly.

Slow Start Start: Upon receipt of ACK: Upon receipt of 2 ACKs:
Set Congestion window = 1 packet Send 1 packet Upon receipt of ACK: Set Congestion window = 1+1 = 2 packets Send 2 packets Upon receipt of 2 ACKs: Set Congestion window = 2+2 = 4 packets Send 4 packets The end result is that TCP effectively doubles the number of packets it has in transit every RTT.

Slow start Additive increase
exponential increase in sender window Additive increase linear increase in sender window

Slow Start There are two situations in which slow start runs:
At the very beginning of a connection (Cold Start) When the connection goes dead while waiting for a timeout to occur. Note that you want slow start only when AI in AIMD does not do well (i.e. Start from scratch) So you don’t have to replace all AIs by SS, only a few.

Slow Start At the very beginning of a connection (Cold Start):
Source doesn’t know how many packets it is going to have in transit at a given time. TCP runs over everything from 9600bps link to 2.4Gbps link Slow start continues to double CongestionWindow each RTT until there is a loss When a loss is detected, timeout causes multiplicative decrease to divide CongestionWindow by 2.

Slow Start When the connection goes dead while waiting for a timeout to occur. Original TCP Sliding Window: Sender sent advertised window of data already a packet gets lost Source waits for ACK and eventually, a timeouts and retransmit lost packet. Source gets a single cumulative ACK that reopens an entire advertised window Slow Start: The source then uses slow start to restart the flow of data rather than dumping a whole window’s worth of data on the network all at once.

Slow Start Target congestion window: After detecting packet loss:
Update congestion window = CongestionWindow prior to the last packet loss/2 This is called target congestion widow compared to current congestion window (actual congestion window) Why? Packet loss mean congestion. This means the sender’s initial assumption about congestion window was an overestimation So to be on the safer side sender aggressively decrease it by half. (as consequences are worse if congestion occurs)

Slow Start Now we need to remember both: “target” congestion window:
resulting from multiplicative decrease Called Congestion Threshold (or simply threshold) “actual” congestion window: used by slow start. Simply called Congestion Window (CW).

How to update current/actual CW?
Upon packet loss calculate threshold= CW/2 Reset actual CW = 1 Use Slow start to rapidly increase the sending rate up to target CW, and then use additive increase beyond this point. Target congestion window is where Slow start ends and AIMD begins.

Behavior of TCP congestion control.
Slow Start Behavior of TCP congestion control. Colored line = value of CongestionWindow over time; solid bullets at top of graph = timeouts; hash marks at top of graph = time when each packet is transmitted; vertical bars = time when a packet that was eventually retransmitted was first transmitted.

Behavior of TCP congestion control.
Slow Start Additive increase Slow starts Behavior of TCP congestion control. Colored line = value of CongestionWindow over time; solid bullets at top of graph = timeouts; hash marks at top of graph = time when each packet is transmitted; vertical bars = time when a packet that was eventually retransmitted was first transmitted.

Slow Start Initial slow start:
Rapid increase due to exponential increase in sender window

Slow Start Why? TCP attempts to learn network bandwidth
Packets lost Why? TCP attempts to learn network bandwidth It uses exponential growth of congestion window to do this. Source runs the risk of having ½ window worth packets dropped by network. E.g. network capacity = 16 packets Source sends 1, 2,4,8,16 successfully so then bumps up congestion window to 32 32-16 = 16 packets are dropped (worst case – some packets might be buffered at some router) TCP Sender cannot afford to use linear growth of congestion window to find out network bandwidth. Why? - linear – not aggressive in sending data (too slow) - It might take long time for it to discover network bandwidth - has a dramatic impact in throughput

Slow Start Why? No new packets are sent (notice no hash marks)
Congestion window flattens Why? No new packets are sent (notice no hash marks) Because several packets were lost. So no ACKs arrive at sender You sent entire 32 packets. Sender cant open/free some window until ack arrives. No acks arrive as network is congested. Some packets dropped. So sender send no data. Sender receive no data. So no change in cw.

Slow Start Timeout occurs.
~34 ~34/2  17 Timeout occurs. Congestion window is divided by 2 : ~34KB  ~17KB Set CongestionThreshold = ~17KB Reset CongestionWindow=1KB Use exponential increase in CongestionWindow to arrive at CongestionThreshold Use Additive increase afterwards (no apparent in figure) Why not apperant? Probably b/s net capacity has gone down from previous. Note until 1.0s congestion window = 30 kb however, s: cw is much lower. So even before additive increase, during slow start phase itself network got saturated and congested again. However, slow start ecponential increae followed by AI is apperent in cw increaese phae 5.5s-7.0s and 7.8s-8.0s

Slow Start Congestion window is reset to 1 packet
Packets lost Timeout occurs Congestion window reset to 1 packet Slow start runs Additive increase runs Congestion window is reset to 1 packet It starts ramping up from there using slow start. Then use Additive increase afterwards

Fast Retransmit and Fast Recovery
Coarse-grained implementation of TCP timeouts led to long periods of time during which the connection went dead while waiting for a timer to expire. To solve this, a new mechanism called fast retransmit was added to TCP. Fast retransmit is a heuristic that sometimes triggers the retransmission of a dropped packet sooner than the regular timeout mechanism. no packets sent no packets sent Network aggressively send packets(exponential increase)  often leading to congestion nothing sent/received(float congestion window)  need to wait until timeout expire to resend Does sender need to wait until timeout expire to send data? Not always. The dead state (flat CW) is not necessary. Sender should be able to quickly adjust sending rate (reduce) right after detection of packet loss(timeout)

Receiver sends a duplicate ACK: Receiver gets data Receiver responds with an acknowledgment, even if this sequence number has already been acknowledged (duplicate ACK). Routers dropped packets.

Out of order packet receipt:
TCP cannot yet acknowledge the data the packet contains because earlier data has not yet arrived TCP resends the same acknowledgment (duplicate ACK) it sent the last time. Sender receives a duplicate ACK So, sender interprets this as receiver got a packet out of order

Question What are the reasons for receiving packets out-of-order?

The University of Adelaide, School of Computer Science Fast Retransmit and Fast Recovery 17 April 2017 Answer: Earlier packet might have been lost or delayed Question: How does the sender make sure it is actually a lost packet, not a delayed packet? Lost packet : no ack Delayed packet: delayed ack But doesn’t work as sender might timeout before delayed ack comes. So cant distingish loss vs delay Chapter 2 — Instructions: Language of the Computer

Sender waits until it sees some number of duplicate ACKs (to make sure it is not a delayed packet but a lost packet) Why does receiver send multiple duplicate ACKs?

For every single packet sent after the missing packet, receiver will send a duplicate ACK Sender then retransmits the missing packet. In practice, TCP waits until it has seen three duplicate ACKs before retransmitting the packet.

The University of Adelaide, School of Computer Science Fast Retransmit and Fast Recovery 17 April 2017 Figure illustrates how duplicate ACKs lead to a fast retransmit: the destination receives packets 1 and 2, but packet 3 is lost in the network. destination will send a duplicate ACK for packet 2 when packet 4 arrives, again when packet 5 arrives, and so on Sender sees the 3rd duplicate ACK for packet2, and retransmit packet 3 To simplify this example, we think in terms of packets 1, 2, 3, and so on, rather than worrying about the sequence numbers for each byte. the destination receives packets 1 and 2, but packet 3 is lost in the network. Thus, the destination will send a duplicate ACK for packet 2 when packet 4 arrives, again when packet 5 arrives, and so on. (To simplify this example, we think in terms of packets 1, 2, 3, and so on, rather) Sender sends a cumulative ACK for everything up to and including packet 6 Chapter 2 — Instructions: Language of the Computer

Trace of TCP with fast retransmit. Colored line = CongestionWindow; solid bullet = timeout; hash marks = time when each packet is transmitted; vertical bars = time when a packet that was eventually retransmitted was first transmitted.

No fast retransmit no packets sent no packets sent

This improves throughput by ~20% However this does not completely eliminate all coarse-grained timeouts. Why?

The University of Adelaide, School of Computer Science Fast Retransmit and Fast Recovery 17 April 2017 Fast retransmit strategy does not eliminate all coarse-grained timeouts. This is because for a small window size there will not be enough packets in transit to cause enough duplicate ACKs to be delivered. If sender waits for 3 duplicate acks to enter FR, and sender window size<3  u never get 3 duplicate /acks  no fR Window size fluctuate with time (nased on congestion window, and advertised window) Chapter 2 — Instructions: Language of the Computer

Fast Retransmission signals congestion. due to lost packets With fast recovery: The sender, instead of returning to Slow Start uses a pure AIMD. Why? Slow start reset CW =1 and rapidly increase to threshold. Unnecessary. i.e. sender simply reduces the congestion window by half and resumes additive increase. Thus, recovery is faster -- this is called Fast Recovery.

TCP Reno The version of TCP wherein fast retransmit and fast recovery are added in addition to previous congestion control mechanisms is called TCP Reno. Has other features: header compression (if ACKs are being received regularly,omit some fields of TCP header). delayed ACKs -- ACK only every other segment.

Where are we ? We are done with Section 6.3. We now move on to looking at more sophisticated congestion avoidance mechanisms.

Why Congestion Avoidance?
The University of Adelaide, School of Computer Science Why Congestion Avoidance? 17 April 2017 TCP does congestion control: Reactive approach: Let congestion occur, then control TCP need to create losses to determine available bandwidth: TCP increases load to determine when congestion occurs and then backs off. Packet losses used to determine congestion. This is costly : Causes packet losses Remember why we did this in first place: -sender sends min of network bandwidth(cw) or receiver advertised window -determine network bandwidth  intentionally create losses. Chapter 2 — Instructions: Language of the Computer

Congestion Avoidance Mechanism
Can we do better? Avoid congestion ? Prevent losses? Need a proactive approach! Can we predict the onset of congestion ? If so, we can reduce the sending rate just before packets dropped.

Congestion Avoidance Mechanism
We introduce 3 congestion avoidance mechanisms: DECbit Random Early Detection (RED) Source based Congestion Avoidance

Router Based Congestion Avoidance:
DECbit , RED Put additional functionality into router to assist end nodes determine congestion Host Based Congestion Avoidance: Source Based Congestion Avoidance Avoid congestion purely from end nodes.

DECbit Evenly splits the responsibility of congestion control between end hosts and routers. At Router: Router monitors congestion It explicitly notifies end-host when congestion is about to occur How to notify? Each packet has a “Congestion Notification” bit called the DECbit in its header. If router is congested, it set the DECbit of packets that flow through it.

DECbit At Destination end-host: At Source end-host:
The notification reaches the destination Destination copies the bit in the ACK that it sends the source. At Source end-host: In response, the source adjusts transmit rate.

Question How does a router monitor congestion?
When does router sets DECbit of packets flowing through it?

DECbit Router sets DECbit of packets if its average queue length is > = 1 at the time the packet arrives Therefore, Criterion for congestion: average queue length of router  1 packet Why average queue length of router  1 denote congestion? This is a trade-off between significant queuing (and hence higher throughput) and increased idle time (and hence lower delay). (maximize throughput/dealy power) In other words, a queue length of 1 seems to optimize the power function.

DECbit How to measure average queue length?
Queue length is averaged over a time interval that spans the last busy+idle cycle, plus the current busy cycle. Busy: router send data Idle: router not send data busy idle last busy+idle cycle Current busy cycle The reason for using an average queue length rather than an instantaneous one is that it more accurately captures the notion of congestion.

DECbit Source adjusts rate to avoid congestion.
Counts fraction of DECbits set in each congestion window. If <50% set, increase rate additively (increase by 1). If >=50% set, decrease rate multiplicatively (decrease by 0.875th). The value 50% was chosen as the threshold based on analysis that showed it to correspond to the peak of the power curve. The “increase by 1, decrease by 0.875” rule was selected because additive increase/multiplicative decrease makes the mechanism stable.

Random Early Detection (RED)
RED is based on DECbit: Each router monitors its queue length When a router detects that congestion is about to happen, it notify the source to adjust its congestion window. RED implicitly notifies sender by dropping packets Source notification: timeout/duplicateACK So, it works well with TCP

Router drops few packets before queue is full. Notify source to slow down sooner than it would normally have. So , router does not have to drop lots of packets later on. GOALS: Avoid bias against bursty traffic Keep power (throughput/delay) high keep average queue size low

When to drop a packet? What packets to drop? Answer: Early Random Drop: Drop each arriving packet with some drop probability whenever the queue length exceeds some drop level. Drop probability is increased as the average queue length increases.

Computing average queue length: Using a weighted running average: AvgLen = (1 − ) × AvgLen + × SampleLen  : a Weight between 0 and 1 SampleLen: queue length when a sample measurement is made.

Average queue length captures notion of congestion (long-lived congestion) better than an instantaneous measure. Bursty traffic (queues become full fast/ get empty fast. ) Using this value for query length In deciding congestion is bad! (it is only a small burst of traffic. Queue is not so full other times.) Short term changes are filtered out

RED has two queue length thresholds that trigger certain activity: MinThreshold MaxThreshold When a packet arrives at the router, RED compares the current AvgLen with these two thresholds, according to the following rules: if AvgLen  MinThreshold  queue the packet if MinThreshold < AvgLen < MaxThreshold  calculate probability P  drop the arriving packet with probability P (random drop) if MaxThreshold  AvgLen  drop the arriving packet

Drop probability P : A function of both AvgLen and how long it has been since the last packet was dropped. P is computed as follows: TempP = MaxP × (AvgLen − MinThreshold)/(MaxThreshold − MinThreshold) P = TempP/(1 − count × TempP) Note: Above calculation assumes queue size is measured in packets. Denote time elapsed since last packet dropped

if MinThreshold < AvgLen < MaxThreshold: TempP = MaxP × (AvgLen − MinThreshold)/(MaxThreshold − MinThreshold) P = TempP/(1 − count × TempP) Extra step : P helps space out drops Number of queued packets since last drop. count  P Drop probability function for RED TempP RED thresholds on a FIFO queue If AvgLen is closer to MinThreshold than MaxThreshold  (AvgLen − MinThreshold) < < < (MaxThreshold − MinThreshold) i.e. (AvgLen − MinThreshold) / (MaxThreshold − MinThreshold) <<< 1 TempP = MaxP * very small value  closer to 0 If AvgLen is closer to MaxThreshold than MainThreshold  (AvgLen − MinThreshold) < (MaxThreshold − MinThreshold) i.e. (AvgLen − MinThreshold) / (MaxThreshold − MinThreshold) < 1 TempP = MaxP * value close to 1  closer to MaxP If count is large: - it has been long since you dropped a packet - 1-(count*tempP) is smaller - TempP/smaller value  P>>TempP for larger count Maximum drop probability

Question Why spacing out packet drops necessary?

Answer If you take TempP as dropping probability, packet drops were not well distributed in time (occur in clusters) Why dropping clusters of packets bad? Packet arrivals from a certain connection are likely to arrive in bursts (clusters) Clustering of drops can cause multiple drops in a single connection. TempP Packet burst in a connection can cause AvgLen of queue to be in this range Most packets dropped will belong to connection

Properties of RED Drops packets before queue is full
In the hope of reducing the rates of some flows Drops packet in proportion to each flow’s rate High-rate flows have more packets Hence, a higher chance of being selected for dropping Drops are spaced out in time Which should help desynchronize the TCP senders Tolerant of burstiness in the traffic By basing the decisions on average queue length

Problems With RED Hard to get tunable parameters just right
How early to start dropping packets? What slope for increase in drop probability? What time scale for averaging queue length? RED has mixed adoption in practice If parameters aren’t set right, RED doesn’t help Hard to know how to set the parameters

Source-based Congestion Avoidance
Host watch for some sign from the network that: some router’s queue is building up and congestion will happen soon if nothing is done about it. How does an end host know router’s queue is building up? Host notice : a measurable increase in the RTT for each successive packet it sends. Sending rate flattens

Example Algoritm1: Increase congestion window normally (like TCP) For every two RTT delays: If current RTT> Average( min RTT seen so far, max RTT seen so far) : decreases the congestion window by 1/8

Example Algoritm2 (similar): Updating current window size is based on: Changes to RTT AND Changes to the window size. For every two RTT delays: Calculate (CurrentWindow − OldWindow)×(CurrentRTT − OldRTT) If the result is positive: the source decreases the window size by 1/8 If the result is negative or 0: the source increases the window by one maximum packet size. Result ==0 (network handled packet it sent without congestion, so increase cw) CurrentRTT = OldRTT OR CurrentWindow = OldWindow Result = negative (network handled packet it sent without congestion, so increase cw) CurrentRTT < OldRTT CurrentWindow < OldWindow Result is positive (we have increased cw but it took longer RTT denote congestion) CurrentRTT > OldRTT AND CurrentWindow > OldWindow

Quality of Service (QoS)
What is QoS? Providing guarantees/bounds on various network properties: Available bandwidth for flows Delay bounds Jitter (variation in delay) Packet loss

Internet currently provides one single class of “best-effort” service No assurances about delivery Most existing applications : E.g. mutimedia applications Tolerate delays and losses Can adapt to congestion Can use retransmissions to make sure data arrive correctly.

Some “real-time” applications: E.g. teleconferencing Need assurance from network data arrive on time Using retransmissions are not OK: adds latency Both end hosts and routers are responsible for timeliness of data delivery Therefore, best-effort delivery is not sufficient for real-time applications

What we need is a new service model: Applications can request higher assurance from network Network treat some packets differently from others A network that can provide these different levels of service is often said to support quality of service (QoS).

Question: Doesn’t the Internet already support real-time applications? So why a new service model? Answer: Yes. E.g. Skype (Voice/video over Internet) Seem to work OK Why? Best-effort service is often quite good. However, if you want a reliable service for real-time applications, best-effort isn’t good enough.

Application Requirements
What are the different needs of applications? Applications are of two types: Non real-time/ Elastic Applications Real-time/ nonElastic Applications

Application Requirements
Non real-time/ Elastic Applications: Traditional data applications E.g. telnet, FTP, , web browsing etc. Can work without guarantees of timely delivery of data. Can gracefully tolerate delay and losses: They do not become unusable as delay increases Nice if data arrives on time, if not, it is still usable. Delay requirements vary by application: telnet (very interactive : low delay required) FTP (interactive bulk transfer) (least interactive: delay tolerable)

E.g. Audio application Real-time Applications:
If a data packet is delayed, it is unusable. E.g. Audio application: Audio samples are played back at some appropriate rate Analogdigital conversion Data: audio samples Digital samples are placed in packets and transferred over the network Digital samples are received at other end and converted to analog signals

E.g. Audio application Audio Application:
Each audio sample has a particular playback time: Played back rate = voice samples collection rate E.g. Sample collection rate at receiver= 1 sample per 125 s Playback time of a sample = 125 s later than the preceding sample What happens if data arrives after appropriate playback time (delayed/retransmitted) ? Packet is useless

E.g. Audio application How to make sure packets arrive in time?
Obviously, different packets in an audio stream may experience different delays Why? Packets queued in switches and routers Queue lengths vary over time So, they may not arrive at expected time. Solution: Introduce a playback buffer

E.g. Audio application 17 April 2017 Playback buffer: Receiver buffer up some incoming data in reserve Store of packets waiting to be played at right time Playback point: Add a constant delay offset to playback time Short packet delay: OK Packet goes on buffer until playback time arrives Long packet delay: OK Packet goes in buffer (assuming a non empty queue). Played soon. Extreme Long packet delay: NOT OK Packet arrives after playback time E.g. suppose you always maintain 3 packets in buffer all times i.e if each packet arrives 100th microsecond, you add a delay offset of 200microsec to each packet. So if packet 4 arrive at 400th microsec, it will be played back in 600th microsec Chapter 2 — Instructions: Language of the Computer

E.g. Audio application Operation of a playback buffer From: YouTube
Playback point Already played at client/receiver Playback buffer From: YouTube

Operation of a playback buffer
data Client/receiver Server/sender Receiving time Playback time Sending time

E.g. Audio application How far can we delay playback of data?
For audio applications it is 300 ms. i.e. maximum time delay between when you speak and a listener hears to carry on a conversation. Application want the network to guarantee that all its data arrives within 300ms.

E.g. Audio application If audio application set playback point 100ms or less, 3 out of every 100 packets will arrive too late 97% of packets have a Latency of 100ms or less Long tail. We need to set playback point over 200ms to ensure that all packets arrived in time Delay measured over certain paths of the Internet

Taxonomy of Real-Time Applications
Let us look at different classes of applications that serve to motivate our service model

Classification1: Based on Tolerance of occasional loss of data Tolerant Applications: (E.g. Audio Applications) A packet loss: normal packet loss in network AND Packet arriving too late to be played back Small fix (occasional loss): Interpolate the lost sample by surrounding samples (little effect on audio quality) If more and more samples lost: Voice quality declines  speech is incomprehensible

Intolerant Applications: (E.g. Robot Control Program) Command sent to robot arm to reach it before it crashes into something Losing a packet is unacceptable Note that many real time applications are more tolerant of occasional loss than many non-real-time Applications E.g. Audio VS FTP (loss of 1 bit file completely useless)

Classification2: Based on adaptability to delay Delay-adaptive Applications: (E.g. Audio Applications) Application can adapt to amount of delay packets experience in traversing the network E.g. Application notices that packets are almost always arriving within 300ms of being sent It therefore set playback point accordingly, buffering any packets that arrive in less than 300 ms. Adjusting playback point: Easily done if application is audio application.  simply shorten silence  barely perceptible to user

Suppose that application subsequently observe that all packets are arriving within 100 ms of being sent. If application adjust playback point to 100 ms: users of the application would probably perceive an improvement. require us to play samples at an increased rate for some period We should advance playback point only when: We have a perceptible advantage AND We have some evidence that no. of lost packets are acceptably small

Rate Adaptive Applications: Another class of adaptive applications E.g. many video coding algorithms can trade off bit rate versus quality. A video is a finite sequence of correlated images. A higher bit rate accommodate higher image quality in the video Video coding = image compression + temporal component. If the network can support a certain bandwidth, we can set our coding parameters accordingly. If more bandwidth becomes available later, we can change parameters to increase the quality. Video Coding: ======== What is the bitrate? It’s important to understand how the bitrate control corresponds to video quality and the file size. In general, a higher bitrate will accommodate higher image quality in the video output. The bitrate for an HD Blu-ray video is typically in the range of 20 mbps, standard-definition DVD is usually 6 mbps, high-quality web video often runs at about 2 mbps, and video for phones is typically given in the kilobits (kbps). What is the video coding? Of all the different modalities of data, video is the one that produces the largest amount of data. A video is a finite sequence of correlated images. Video coding can be viewed as image compression with a temporal component. Video coding = Image coding + Strategy to take advantage of temporal correlation  In most video sequences there is little change in the contents of the image from one frame to the next. Even in sequences that depict a great deal of activity, there are significant portions of the image that do not change from frame to frame.  Most video compression schemes take advantage of this redundancy by using the previous frame to generate a prediction for the current frame.  In order to use a previous frame to predict the pixel values in the frame being encoded, we have to take the motion of objects in images into account.  Although a number of approaches have been investigated, the method that has worked best is the approach called: block-based motion compensation.  In this approach, the frame being encoded is divided into blocks of size MxM. For each block, we search the previous reconstructed frame for the block of size MxM that most closely matched the block being encoded. Ref:

Approaches to QoS Support
We need a richer service model than best-effort that meets the needs of any application This leads us to a service model with several classes, each available to meet the needs of some set of applications. Approaches have been developed to provide a range of qualities of service Two categories: Fine-grained approaches Coarse-grained approaches

Approaches to QoS Support
Fine-grained approaches: Provide QoS to individual applications or flows Integrated Services: Often associated with the Resource Reservation Protocol (RSVP) Coarse-grained approaches: Provide QoS to large classes of data or aggregated traffic Differentiated Services: Probably the most widely deployed QoS mechanism

Integrated Services (RSVP)
Integrated services (Intserv): A body of work IETF produced around Defines: A number of service classes that meet needs of some application types. How RSVP could be used to make reservations using service classes.

Service Classes Guaranteed Service: Designed for intolerant applications. Applications require packets never arrive late. The network should guarantee that the maximum delay that any packet will experience has some specified value Controlled Load Service: Designed for tolerant, adaptive applications Applications run quite well on lightly loaded networks Service should emulate a lightly loaded network for those applications that request the service, even though the network may in fact be heavily loaded

Overview of Mechanisms (Steps): Real-time application provide Flowspecs to network: Flowspecs specify the type of service required Network perform admission control: Network decide if it can provide that service. Admission Control: process of deciding when to say no. Network users/components perform resource reservation: Users and components of the network exchange information: requests for service, flowspecs, admission control decisions. Done using RSVP Switches/Router perform packet scheduling: Network switches and routers meet the requirements of the flows by managing the way packets are queued and scheduled for transmission.

Real-time application provide flowspecs to network Flowspec has 2 parts: TSpec: The part that describes the flow’s traffic characteristics E.g. bandwidth used by the flow not always a single number per application A video application generate more bits per second when the scene is changing rapidly than when it is still Sending average bandwidth is insufficient Rspec: The part that describes the service requested from the network. E.g. target delay bound (guaranteed service), No additional parameter (controlled load service)

Network perform admission control: Admission control looks at the TSpec and RSpec of the flow. Then it tries to decide if the desired service can be provided to that amount of traffic requested, given the currently available resources, without causing any previously admitted flow to receive worse service than it had requested. If it can provide the service, the flow is admitted. if not, then it is denied.

Network users/components perform resource reservation (RSVP): Connectionless networks like the Internet have had no setup protocols. However real-time applications need to provide a lot more setup information to network. Resource Reservation Protocol (RSVP) is one of the most popular setup protocols.

Connectionless nature of Internet is robust. Why? Because connectionless networks rely on little or no state being stored in the network Routers can crash/reboot and links can go up/down while end-to-end connectivity is still maintained. RSVP tries to maintain this robustness by using the idea of soft state in the routers. RSVP also support multicast flows just as effectively as unicast flows.

E.g. Unicast. One sender and one receiver trying to get a reservation for traffic flowing between them Making reservations on a multicast tree

Sender sends a path message TSpec to receiver This informs receiver the type of traffic and path used by sender This help receiver making appropriate resource reservation at each router on the path Each router on path looks at PATH message and figures out the reverse path that will be used to send reservations from the receiver back to the sender Sender Tspec PATH Making reservations on a multicast tree

receiver sends a reservation back “up” the multicast tree in a RESV message Each router on the path looks at the reservation request and tries to allocate the necessary resources to satisfy it. If the reservation can be made, the RESV request is passed on to the next router. If not, an error message is returned to the receiver who made the request. Sender Tspec Receiver RSpec RESV If all goes well, the correct reservation is installed at every router between the sender and the receiver. As long as the receiver wants to retain the reservation, it sends the same RESV message about once every 30 seconds

Switches/Router perform packet scheduling: Finally, routers deliver the requested service to the data packets. There are two things that need to be done: Classify packets: Associate each packet with the appropriate reservation so that it can be handled correctly. Schedule Packets: Manage the packets in the queues so that they receive the service that has been requested Manage packets in queues: - process based on delay bounds

Fine-grained approaches
Approaches have been developed to provide a range of qualities of service Two categories: Fine-grained approaches Integrated Approaches(RSVP) Coarse-grained approaches Differentiated services

Differentiated Services (DiffServ)
Integrated Services architecture: allocates resources to individual flows Differentiated Services model: Allocates resources to a small number of classes of traffic.

E.g. Add one new class, “premium.” How to identify packets as premium or not? Use a bit in the packet header: bit=1  premium packet bit=0  best effort packet

Who sets the premium bit, and under what circumstances?

Answer: Many possible answers A common approach is to set the bit at an administrative boundary. E.g. the router at the edge of an ISP’s network might set the bit for packets arriving on an interface that connects to a particular company’s network. Why? The Internet service provider might do this because that company has paid for a higher level of service than best effort.

What does a router do differently when it sees a packet with the bit set?

Answer: IETF standardized the behavior of routers. Called “per-hop behaviors” (PHBs) The Expedited Forwarding (EF) PHB: One of the simplest PHBs If a packets is marked for EF treatment, it should be forwarded by the router with minimal delay and loss. How to guarantee this? Router makes sure arrival rate of EF packets at the router < rate at which the router can forward EF packets.

Question True or False? Suppose host A is sending a large file to host B over a TCP connection. The number of unacknowledged bytes that A sends cannot exceed the size of the advertised receiver buffer.

Answer TRUE. TCP is not permitted to overflow the allocated receiver buffer. Hence when the sender can not send any more data ReceiverWindow would be 0 So, all the buffer would have unacknowledged data.

Question TCP waits until it has received three duplicate ACKs before performing a fast retransmit. Why do you think the TCP designers chose not to perform a fast retransmit after the first duplicate ACK for a segment is received?

Answer Packets can arrive out of order from the IP layer.
So whenever an out of order packet would be received it would generate a duplicate ACK if we perform retransmission after the first duplicate ACK it would lead the sender to introduce too many redundant packets in the network.

Quiz This Friday (10/24)!

The University of Adelaide, School of Computer Science

Similar presentations

Presentation on theme: "The University of Adelaide, School of Computer Science"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

The University of Adelaide, School of Computer Science

Similar presentations

Presentation on theme: "The University of Adelaide, School of Computer Science"— Presentation transcript:

Similar presentations

About project

Feedback