UNIT IV : INTREGRATED AND DIFFERENTIATED SERVICES TOPIC I: INTEGRATED SERVICES ARCHITECTURE:

REVIEW: Demands on IP-based internets are rising IP-based internets were designed for elastic applications that tolerate variations in throughput and loss Now, they are used to support high volumes and various traffic mix including real-time and non real-time pplications These are sensitive to delay and throughput variations and requires high quality of service (QoS) Thus, they now need to provide service differentiations for different applications like ATM networks. INTRODUCTION: New additions to Internet increasing traffic High volume client/server application Web Real time voice and video Need to manage traffic and control congestion Two complementary IETF standards: 1. Integrated services (IntServ) 2. Provides collective service to set of traffic demands placed in a domain 3. Limit demand per capacity & reserve resources to meet QoS Differentiated services (DiffServ) 1. Classify traffic in groups 2. Different group traffic handled differently INTERNET TRAFFIC: Elastic Can adjust to changes in delay and throughput E.g. common TCP and UDP application like email,FTP, web

 Inelastic Does not easily adapt to changes in delay and throughput real time traffic such as web streaming, voice over IP (VoIP) Requires minimum throughput, bounded delay and jitter (i.e. variation of delay) INTSERV ARCHITECTURE: IPv4 header fields for precedence/priority and type of service usually ignored ATM is only network designed to support TCP, UDP and realtime traffic from inception not available everywhere, costly reconfiguration Need to support Quality of Service (QoS) within TCP/IP architecture Requires adding functionality to routers Means of requesting QoS INTSERV APPROACH: Enable provision of QoS over IP (RFC2211,2212) Enables sharing available capacity when congested Currently, routers have these mechanisms: Dynamic Routing Algorithms Select to minimise delay to balance load Active Queue Management (AQM) Causes TCP sender to back off and reduce load These are not sufficient, and are enhanced by IntServ INTSERV COMPONENTS & BACKGROUND FUNCTIONS Reservation Protocol Reserve resources for new flows Admission control Determines whether current resources enough tosupport new request Management agent Can use agent to modify traffic control database and direct

admission control Routing protocol Directs next hop for each address and flow INTSERV COMPONENTS FORWARDING: Classifier and route selection Incoming packets mapped to classes Single flow or set of flows with same QoS E.g. all video flows Based on IP header fields Determines next hop Packet scheduler Manages one or more queues for each output Order in which queued packets sent Based on class, traffic control database, current and past activity on outgoing port Policing Determine whether flow exceed its requested capacity INTSERV SERVICES: Service defined on two levels General categories of service: Guaranteed Controlled load Best effort (default) Particular flow within category Service for a flow is specified by certainparameters known as traffic specification(TSpec) TSpec is part of the traffic contract INTSERV SERVICES GUARANTEED SERVICE Most demanding service Provides assured data rate Has specific upper bound on queuing delay through network Must be added to propagation delay to get total delay

 May be wise to set high to accommodate rare long queue delays Has no queuing losses i.e. no buffer overflow QUEUING DISCIPLINE: Traditionally FIFO or FCFS at each router port No special treatment to high priority packets(flows) Small packets held up by large packets ahead of them in queue Larger average delay for smaller packets Flows of larger packets get better service Greedy TCP connection can crowd out altruistic (i.e. unselfish) connections If one connection does not back off, others may back off more FAIR QUEUING (FQ): Multiple queues for each port One for each source or flow Queues serviced in round robin Each busy queue gets exactly one packet percycle Achieves load balancing among flows No advantage to being greedy Your queue gets longer, increasing your delay Drawback: Short packets penalized as each queue sends one packet per cycle

FIFO and FQ

PROCESSOR SHARING (PS): Not practical but same principle adopted in another scheme Multiple queues as in FQ Send one bit from each queue per round Longer packets no longer get an advantage Work out virtual start and finish time for a given packet (of queue ) However, we wish to send packets, not bits in Reality BIT-ROUND FAIR QUEUING (BRFQ) : Based on PS Each flow gets 1/nth of bandwidth (n flows) Compute virtual start and finish time as in PS When a packet finished, the next packet sent is the one with the earliest virtual finish time Good approximation to performance of PS Throughput and delay of queues converge as time increases

COMPARISON OF FIFO, FQ AND BRFQ

GENERALISED PROCESSOR SHARING (GPS): BRFQ cant provide different capacities to different flows Enhancement called weighted fair queuing (WFQ),based on generalised PS From PS, allocate weighting to each flow that determines how many bits are sent during each round If weighted 5, then 5 bits are sent per round

 Gives means of responding to different service levels => The concept of service differentiation! Can provide guarantees that delays do not exceed certain bounds WEIGHTED FAIR QUEUING: Emulates GPS Same strategy as BRFQ Enables a router to assign weight to each flow and guarantee bound on delay Max buffer size needed proportional to defined max delay

DIFFERENTIATED SERVICES (DIFFSERV): IntServ is complex to deploy! May not scale well for large volumes of traffic Amount of control signals ( overhead) Maintenance of state information at routers Intserv has only two classes DiffServ (RFC2475) designed to providesimple, easy to implement, low overhead tool simple functions in network core, relatively complex functions at edge routers (or hosts) Doesnt define service classes, provide functional components to build service classes CHARACTERISTICS OF DIFFSERV: Use IPv4 header Type of Service or IPv6 Traffic Class field (called DS field) So, no change to IP! Service level agreement (SLA) established between provider and customer prior to use of DiffServ All traffic with same DS field treated same E.g. multiple voice connections DIFFSERV ARCHITECTURE: Edge/Boundary router: - per-flow traffic management - marks packets as in-profile and out-profile Core/Interior router: - per class traffic management - buffering and scheduling based on marking at edge - preference given to in-profilepackets

RANDOM EARLY DETECTION:

Random early detection (RED), also known as random early discard or random early drop is an active queue management algorithm. It is also a congestion avoidance algorithm. In the traditional tail drop algorithm, a router or other network component buffers as many packets as it can, and simply drops the ones it cannot buffer. If buffers are constantly full, the network is

congested. Tail drop distributes buffer space unfairly among traffic flows (as the number of packets lost is proportional to the number sent - irrespective of their size). Tail drop can also lead to TCP global synchronization as all TCP connections "hold back" simultaneously, and then step forward simultaneously. Networks become under-utilized and flooded by turns. RED addresses these issues. It monitors the average queue size and drops (or marks when used in conjunction with ECN) packets based on statistical probabilities. If the buffer is almost empty, all incoming packets are accepted. As the queue grows, the probability for dropping an incoming packet grows too. When the buffer is full, the probability has reached 1 and all incoming packets are dropped. RED is more fair than tail drop, in the sense that it does not possess a bias against bursty traffic that uses only a small portion of the bandwidth. The more a host transmits, the more likely it is that its packets are dropped as the probability of a host's packet being dropped is proportional to the amount of data it has in a queue. Early detection helps avoid TCP global synchronization. Pure RED does not accommodate quality of service (QoS) differentiation. Weighted RED (WRED) and RED In/Out (RIO) provide early detection with QoS considerations.