Is only as strong as the weakest link on the network.

If there is one device that doesn't support it, or an old device that is on the way, that is going to be the weak point or the problem in the network.

• IP packet delivery is on a 'best effort' basis
• Routers can/will drop IP datagrams
• Congestion occurs when queues/buffers fill
• Many applications require better service
• Convergenve of communication services to IP
• Low latency requirements (e.g. VoIP)
• Bandwidth guarantees, e.g. video streaming
• Need methods to deliver these sevices at good 'quality' on IP networks

• Throughput - e.g. in Mbits/s or Gbits/s
• One way delay (OWD) - in milliseconds
• Round trip time (RTT)
• Paths may be asymetric to and form sender
• Jitter - variation in delay
• Packet loss - as percentage
• Allows ISPs to offer Service Level Agreements (quality) based on these metrics

• Need to offer application an assurance of service
• So routers must apply special processing to packets
• Based on some property/classification of packet
• Usually requires support from all routers on path
• Where full end-to-end guarantees are required
• That path may traverse a number of ISPs
• Inter-ISP policy agreement can be the hardest
• Implies enough bandwith to offer service
• Prioritising traffic may impact normal "best effort" traffic

• Overprovisioning
• Applying QoS policies on individual routers
• May include traffic shaping per application/device
• Integrated services
• End-to-end pre-negotiated QoS
• Requires signaling and flow state held in each router on path
• Differentiated services
• Pre-configured priorities applied by each router on path

• An ISP can procure bandwith such taht congesiton is very rare, and typical usage well below capacity
• Costs money
• Sometimes the simplest approach
• This is how JANET academic core is delivered
• Problem is that congestion is pushed to the edge
• Where congestion is only at the edge, local QoS configuration at the edge router may suffice

• Often the main problem lies at the access router
• e.g. Many nodes using TCP but one handles crucial data - he would suffer more
• Could configure the access router on the local home network to offer some QoS support
• Treat different packets or flows differently with queuing algorithms/methods

• IP source address/network
• IP destination address/network
• TCP/UDP source port
• TCP/UDP destination port
• Protocol used

• QoS support is variable on commodity ASDL routers
• Might have some option via web config screen
• May be able to:
• Reserve bandwith based on flow properties
• Prioritise traffic based on flow properties
• Rate-limit (Traffic shape) based on flow propert.
• But usually quite limited capabilities as these are cheap devices

• Integrated services (Intserv)
• Presignal QoS requirement & reserve capability
• Differenciated services (Difserv)
• Pre-configure router to prioritise packets based on the observed value of the 8-bit type of service (ToS) IP header field (IPv4) or Traffic Class Field (IPv6)
• Implies the fileld is set to the desired value by sender

• (RSVP) Application (data sender) sets the QoS path
• PATH message sent by sender to destination
• Routers forward PATH message to receiver
• At each hop routers note IP of previous hop
• Receiver requests the reservation
• RESV message sent back hop by hop to sender
• RESV messsage contains flow/filter spec
• Routers reserve appropriate parameters for QoS
• If sender receives RESV message back, it knows QoS reservation is made

What are the pros of IntServ?

• Allows fine granularity (Density of components in the system) of QoS behaviours
• Multiple types/classes between multiple senders and receivers

• Requires signalling per flow - May be a significant overhead
• Requires per flow state to be held in each router, so that flows can be identified (classified) and prioritised accordingly
• Reservation needs to be refreshed periodically, typically every 30 secs, due to possible routing changes
• All routers along traffic path must support it

• Traffic (packets) are prioritised by routers depending on the value of the 8-bit ToS (Type of Service) field in the IP header
• Value may be set by sender
• Value may be (re)written by a router (typically a site border router for the sender) - classifying and marking the packet
• Routers are preconfigured to apply policy/prioritisation based on the value they see
• Can define common behaviour for well-known values
• QoS is thus applied hop by hop (router by router)
• No signalling or per-flow state required

• Allows operator to provide assurance of delivery as long as the traffic does not exceed some subscribed rate.
• Traffic that exceeds the subscription rate faces a higher probability if congestion occurs.
• The AF behaviour defines four separate AF classes, with class 4 having the highest priority

• A 6-bit field within the IPv4 and IPv6 type of service (ToS) 8-bit header field
• Common semantics of DSCP values can be agreed for end-to-end Diffserv traffic handling eg.
• Premium IP (High priority) - DSCP 46
• Best effort (Normal) = DSCP 0
• Less than Best Effort (Low priority - discarded first when congestion occurs) - DSCP 8

• Offers reserved bandwidth
• Packets with DSCP 46 placed in the highest PQ
• Portion of router capacity dedicated to DSCP 46
• Capacity dedicated to premium IP reduces capacity available for regular Best Effort traffic
• BE traffic is served from a different queue
• Premium IP requires support by all routers on a path

• Need to agree between networks how much Premium IP traffic is allowed
• Police volume of Premium IP entering network
• Agree how excess Premium traffic is handled
• Usually dropped
• Need to cater/provision for the worst case
• One option is to overprovision Premium IP capacity
• But this reduces the bandwidth available to normal traffic

• New idea - Similar to the Unix 'nice' command
• Marks packets voluntarilly (usually in application)
• Market packets are dropped first when congestion occurs
• Can thus fill a link with LBE traffic and best effort (BE) should not be affected
• LBE marked by sender, e.g. by an ftp server
• Does't have to have end-to-end support
• LBE can eb deployed incrementally at points of congestion
• Deprioritise 'junk' rather than prioritise important traffic

• Bulk transfer
• Transfer many terabytes over a week
• Peer to peer background traffic
• Remote backups
• Real time delivery not important
• Deprioritising student dormitory traffic
• (De)prioritising certain traffic on low bandwidth academic sites