Editing Traffic shaping (section)

== Implementation ==
A traffic shaper works by delaying metered traffic such that each packet complies with the relevant [[traffic contract]].  Metering may be implemented with, for example, the [[leaky bucket]] or [[token bucket]] algorithms (the former typically in [[Asynchronous Transfer Mode|ATM]] and the latter in [[Internet Protocol|IP networks]]).  Metered packets or cells are then stored in a [[FIFO (computing and electronics)|FIFO buffer]], one for each separately shaped class, until they can be transmitted in compliance with the associated traffic contract.  Transmission may occur immediately (if the traffic arriving at the shaper is already compliant), after some delay (waiting in the buffer until its scheduled release time) or never (in case of [[packet loss]]).

===Overflow condition===
All traffic shaper implementations have a finite buffer, and must cope with the case where the buffer is full.  A simple and common approach is to drop traffic arriving while the buffer is full 
a strategy known as [[tail drop]] and which results in traffic policing as well as shaping.  A more [[sophisticated]] implementation could apply a dropping algorithm such as [[random early detection]].

===Traffic classification===
Simple traffic shaping schemes shape all traffic uniformly. More sophisticated shapers first [[traffic classification|classify]] traffic.  ''Traffic classification'' categorises traffic (for example, based on [[port number]] or [[Protocol (computing)|protocol]]).  Different ''classes'' can then be shaped separately to achieve a desired effect.

===Self-limiting sources===
A ''self-limiting source'' produces traffic which never exceeds some upper bound, for example media sources which cannot transmit faster than their encoded rate allows.<ref>{{citation |url=http://csr.bu.edu/icnp2005/Posters/Helzer.pdf |last1=Helzer |first1=Josh |first2=Lisong |last2=Xu |archive-url=https://web.archive.org/web/20090227044851/http://csr.bu.edu/icnp2005/Posters/Helzer.pdf |archive-date=2009-02-27 |date=2009-02-27 |title=Congestion Control for Multimedia Streaming with Self-Limiting Sources}}</ref> Self-limiting sources shape the traffic they generate to a greater or lesser degree. [[Congestion control]] mechanisms can also affect traffic shaping of sorts - for example [[Transmission Control Protocol|TCP's]] window mechanism implements a variable rate constraint related to [[bandwidth-delay product]].

TCP Nice, a modified version of TCP developed by researchers at the University of Texas at Austin, allows applications to request that certain TCP connections be managed by the operating system as near zero-cost background transfers, or ''[[nice (Unix)|nice]]'' flows. Such flows interfere only minimally with foreground (non-nice) flows, while reaping a large fraction of spare network bandwidth.<ref>{{cite web | citeseerx = 10.1.1.81.5905 | title = TCP Nice: Self-tuning Network Support for Background Applications | first1 = Arun | last1 = Venkataramani | first2 = Ravi | last2 = Kokku | first3 = Mike | last3 = Dahlin | url = https://dl.acm.org/doi/10.1145/844128.844159 |access-date = August 27, 2023}}</ref>

===Relationship to bandwidth management===
Traffic shaping is a specific technique and one of several which combined constitute [[bandwidth management]].<ref>[http://www.mfaforum.org/ftp/pub/approved-specs/af-tm-0056.000.pdf ATM Forum Traffic Management Specification, Version 4.0] Approved Specification 0056.00, Section 5.5, ''Traffic Shaping''</ref>