Classifications

• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L47/00—Traffic control in data switching networks
  • H04L47/10—Flow control; Congestion control
  • H04L47/20—Traffic policing
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L47/00—Traffic control in data switching networks
  • H04L47/10—Flow control; Congestion control
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L47/00—Traffic control in data switching networks
  • H04L47/10—Flow control; Congestion control
  • H04L47/11—Identifying congestion
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L47/00—Traffic control in data switching networks
  • H04L47/10—Flow control; Congestion control
  • H04L47/18—End to end
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L47/00—Traffic control in data switching networks
  • H04L47/10—Flow control; Congestion control
  • H04L47/22—Traffic shaping
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L47/00—Traffic control in data switching networks
  • H04L47/10—Flow control; Congestion control
  • H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
  • H04L47/2425—Traffic characterised by specific attributes, e.g. priority or QoS for supporting services specification, e.g. SLA
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L47/00—Traffic control in data switching networks
  • H04L47/10—Flow control; Congestion control
  • H04L47/28—Flow control; Congestion control in relation to timing considerations
  • H04L47/283—Flow control; Congestion control in relation to timing considerations in response to processing delays, e.g. caused by jitter or round trip time [RTT]
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L47/00—Traffic control in data switching networks
  • H04L47/10—Flow control; Congestion control
  • H04L47/31—Flow control; Congestion control by tagging of packets, e.g. using discard eligibility [DE] bits
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L47/00—Traffic control in data switching networks
  • H04L47/10—Flow control; Congestion control
  • H04L47/32—Flow control; Congestion control by discarding or delaying data units, e.g. packets or frames

Definitions

• the present invention relates primarily to the control of data in a network, and to methods and systems for enabling the policing of use of networks such as the Internet for communicating data.
• Some applications need to be unresponsive (e.g. interactive voice, video and games). Others simply choose to be aggressive to give themselves premium service. Also, some users continuously fill their access link with more flows than others, whether deliberately (peer-to-peer file sharing) or unwittingly (worm infected zombie hosts). Even if each flow is responsive, in total more congestion results.
• the TCP rate control algorithm [7] was developed in the late 1980s in response to a major congestion collapse on the Internet. It was designed to ensure that the rate of every flow traversing the Internet rapidly adapted to the level of congestion it experienced in such a way that each flow would tend towards a rate that shared capacity of any congested router or link fairly.
• the TCP rate control algorithm runs within the operating system of the sending host.
• the programmer of an application can choose to use it or not.
• the TCP algorithm characterised the path being used across the Internet by detecting losses through missing acknowledgements and by measuring the round trip delay before those acknowledgements arrived.
• the TCP/IP standard was improved by the optional addition of Explicit Congestion Notification (ECN), so that a router experiencing early signs of congestion could mark packets before forwarding.
• ECN Explicit Congestion Notification
• the acknowledgement protocol was also changed to allow these marks to be conveyed back to the source.
• the standard for the TCP algorithm was altered to require the sending host to respond to these returned marks as if there had been a loss.
• x is the expectation of the throughput
• k is a constant of the order of V(3/2)
• s is the packet size for the flow
• T is its round-trip-time
• m is the end-to-end congestion metric (as represented by the proportion of marked and dropped packets within the flow).
• an Internet network element cannot currently know the relevant metrics about the path to verify that a sender is complying with the TCP protocol.
• Commercially available policers e.g. from Sandvine ( www.sandvine.com ), or Riverhead Networks ( www.riverhead.com ) ensure that no flow exceeds a maximum rate, irrespective of the condition of each path being used through the rest of the network. Some such policers can use their knowledge of any local congestion on the equipment itself, but not elsewhere.
• policers that reduce the amount of state required by these commercial policers [4,5,12,13,14,15,16] must be sited on relays that are congested themselves in order to work. All these policers, which we will refer to as “bottleneck policers", detect unusually high bit rates, but a high sending rate might be perfectly legitimate if the path is uncongested or the round-trip time is short. Similarly, other policers on the latest broadband remote access servers enforce monthly volume caps in an attempt to control high volume file-sharing. But they punish traffic that fills troughs as much as traffic that causes peaks in utilisation.
• RED random early detection
• CHOKe Another exploits the idea that a grossly misbehaving flow will appear far more in the data stream than a compliant TCP flow. Whenever a packet arrives, it is compared with another randomly picked from the queue. If the two are from the same flow, that flow is suspected of misbehaving. CHOKe shows very good results in forcing down unusually high rate traffic.
• Stabilized RED SRED [12] was published in parallel, while later improvements include CHOKe [5], RED with Preference Dropping (RED-PD [13]), Least Recently Used RED (LRU-RED [14]), XCHOKe [16], and Approx. Fair Dropping (AFD [15]).
• rate is policed with no respect to the specific characteristics of the path. For instance, let us consider two flows crossing a common bottleneck: flow A with a short round-trip time passes over an otherwise barely congested path while flow B has a round trip-time four times as long and experiences four times as much congestion on its path. In the long-term, flow B should get only 1/8 of the bandwidth flow A gets. Nevertheless, with all existing policers, if congestion is elsewhere than on the network element housing the policer itself, both packets will be considered equally responsible, and flow A will therefore be much more likely to be constrained than flow B.
• Raisinghani & lyer[18] discloses a mechanism whereby a receiver dynamically prioritises its flows by controlling the achievable congestion window they should aim for, assuming drops are all caused on the final wireless section of the path. It appears that this relates to the problem of inter-flow congestion control, and that the receiver tampers with the congestion signal in order to adjust priorities between its flow.
• This document includes a discussion of RED-DT, which is another single-bottleneck fairness optimisation on RED. The optimisation only relies on local information (i.e. local with respect to the node concerned), such as queue lengths, buffer size, and a number of per-flow variables all specific to the node.
• Nikolouzou et al [19] describes a generic Differentiated Services (DiffServ) arrangement, and addresses the definition and deployment of specific network services in a DiffServ environment.
• DiffServ Differentiated Services
• the source places a request in a protocol field.
• the request is in terms of how much data can be sent before any acknowledgement has been received (termed the amount of data in flight, or the congestion window).
• Quick-Start the field is in terms of sending rate. As a packet traverses the network, if the value of the metric that a router can tolerate is less than the request, it re-writes the field. However, the resulting field must still be returned to the sender, and the sender must ensure its future rate complies with the network's response to its request.
• connection-oriented networks such as ATM
• network elements send congestion backpressure messages [9] along each connection, duplicating any end-to-end feedback because they don't trust it. But it is inherently hard to use similar techniques in a connectionless datagram network without losing the benefits of low connection set-up latency and robustness of a packet network.
• re-feedback a novel feedback mechanism was proposed termed "re-feedback", this term being indicative of the idea of "Receiver-Normalised” feedback.
• the sender sets the initial value of any path characterisation field so that, by the time it has accumulated path information, it tends to arrive at the destination set to a commonly standardised value. Feedback from the destination to the source is then used to continuously correct any error in the destination value when future data is sent.
• a principal advantage is that data effectively carries with it a "prediction" of its own downstream path for use by in-line equipment along the transmission path.
• rate is policed with no respect to the specific characteristics of the path.
• existing policers deny themselves opportunities for optimising certain policing characteristics, including their responsiveness (i.e. ability to detect misbehaving flows quickly), their robustness (i.e. ability to identify as misbehaving as few compliant flows as possible, thus avoiding “false positives"), and in particular the trade-off between characteristics such as these.
• a method of policing flow in a data network said data network providing a network service having an associated reference rate adaptation policy, said method comprising steps of: determining a measure of greediness of a flow through a node; comparing said measure of greediness with a measure indicative of acceptable greediness; and designating the flow for possible sanction in the event that the greediness is not in accordance with the acceptable greediness; characterised in that said measure indicative of acceptable greediness is determined in dependence on the expected greediness of a flow conforming to the reference rate adaptation policy associated with said network service and experiencing substantially similar path conditions.
• apparatus for policing flow in a data network comprising means for carrying out the steps for implementing methods according to the first aspect above.
• Flow in a data network can in general be regarded as comprising a plurality of messages, these being the individual data-carrying items applicable to the network and/or protocol in question.
• a policing method is used in relation to current Internet Protocol (IP)
• IP Internet Protocol
• Host-based rate control algorithms maintain state about the recent condition of each flow's path, which determines the sending rate. For instance, TCP maintains a congestion window variable while TCP-friendly rate control and Kelly's algorithm maintain a variable holding the current sending rate.
• path characterisation arrives at a network element in each packet, the element can maintain its own path state for each flow. Then it can derive its own view of how fast the flow should transmit. It can use this to shape the rate of the flow by buffering packets, but it is preferred for it to merely check that the source is correctly adapting its rate in response to the changing path, termed policing.
• schemes that require per flow state to be held on network elements are less preferable. It would be less problematic, however, for an edge access router to hold per flow state as it already maintains state for each access customer (such as the customer's allowed maximum rate).
• Figure 1 outlines the difference between bottleneck policers (Hg 1 (a)) and the path- specific policer we propose (Fig 1 (b)).
• Hg 1 (a) bottleneck policers
• Fig 1 (b) path- specific policer we propose
• y mi, which means a policer is required on every potential bottleneck, that is every router on the path.
• misbehaving flow may be defined as a flow that uses significantly more bandwidth than would a compliant flow given the same path conditions.
• it is proposed to detect misbehaving flows by recording the flow description of packets in the stream, with a probability in inverse proportion to their expected throughput. Equation (1) (see above) is used as an example of how expected throughput may be determined, noting that is based on the specific path characterisation values obtained from the packet.
• the allowed rate adaptation algorithm may be the standard one of TCP, or alternatively some other algorithm agreed between the sender and the ingress network operator, such as those of MuITCP or Kelly. In these latter cases, the weight parameter ⁇ or willingness to pay parameter w may need to be part of the agreement between sender and ingress network.
• This parameter could be associated with a class of traffic, with certain flow identifiers, with a certain type of access interface, or with some field carried in some or all of the packets.
• This agreement might be signalled as and when a parameter is needed, or agreed contractually over long time periods.
• misbehaving flows are not characterised only because of their absolute throughput, but rather on their throughput relative to that a compliant flow would get with the same network conditions on the data path. This is much more accurate in selecting which flows to sanction.
• a further mechanism should preferably operate at the granularity of each sending user, rather than each flow.
• a "per user” counter should be maintained of the accumulated total of all the congestion values from packets probabilistically selected for the polling record. Then this counter can be used to weight the "per flow” algorithms more harshly against users who cause more congestion.
• rate policers such as those available from vendors such as Sandvine or Riverhead Networks (see above). It is certainly desirable to be able to limit the rate, and hence the value that lower-tier customers can derive from a network. But such limits represent the maximum under the best conditions. To maximize the value all customers derive from a network and to balance revenues and the costs of interconnect with other networks, the allowed rate should further depend on path conditions across the whole or any relevant part of the inter-network.
• a packet may label itself as TCP, but not behave in compliance with the TCP algorithm.
• a packet may label itself as UDP or Skype or whatever, but be sent using an algorithm friendly to TCP.
• a policer according to a preferred embodiment of the present invention, it is made possible to push back harder the more congestion people cause cumulatively over periods, measured in days for example. So use of the network for high-bandwidth activities such as p2p file-sharing can be pushed into the troughs and off the peaks at the network edge.
• edge network devices can police any desired congestion response, not just TCP, thereby enabling inter-provider QoS to be carried out by carrying out policing solely at the very edges of the Internet.
• Figure 1 outlines a fundamental difference between bottleneck policers (Fig 1 (a)) and a path-specific policer (Fig 1 (b)) operating according to the present invention
• Figure 2 shows graphs indicating potential differences in policing behaviour between a classic policer (Fig 2(a)) and a path-specific policer operating according to a preferred embodiment of the present invention (Fig 2(b));
• FIG. 3 is a diagram showing a policer according to a comparatively generic embodiment of the present invention.
• Figure 4 is a diagram showing a policer operating according to an embodiment of the present invention, using the model of a token bucket of fixed depth
• Figure 5 is a diagram showing a policer operating according to a preferred embodiment of the present invention, wherein greediness is monitored by sampling traffic in inverse proportion to its expected throughput;
• Figure 6 is a flow-chart showing steps taken by a policer operating according to an embodiment of the present invention wherein greediness is monitored without sampling traffic;
• Figure 7 is a flow-chart showing steps taken by a policer operating according to an embodiment of the present invention wherein greediness is monitored by sampling traffic;
• Figure 8 is a graph showing the expected throughput of a TCP flow through a policer operating in accordance with a preferred embodiment of the invention.
• Equation (1) which we repeat here as Equation (4).
• s, T, and m are respectively the average values over T for the packet size, the round-trip-time and the end-to-end congestion level, and .5.
• x # as a reference compliant rate for policing the traffic with respect to the conditions of the path they follow, where # denotes the rate adaptation policy used for that class of traffic.
• x TC p becomes a special case of x # .
• Figure 3 outlines the objective of the policer: it has to flag any flow whose apparent greediness q is higher than the ceiling ⁇ * for a period of time T*.
• Flow j arrives at the policer at a rate x app .
• the effect of the policer is to identify whether the flow is behaving (ct j ⁇ ⁇ *) or misbehaving ( ⁇ j > ⁇ * ) and to segregate their subsequent treatment based on that information.
• x TC p has to be maintained per flow and can be updated whenever a packet is received.
• x TG p may be obtained for each packet from the re-feedback fields thanks to Equation (4).
• Equation (4) We describe below several mechanisms to monitor q per flow, and segregate for sanction those flows with a greediness higher than the ceiling ⁇ * for a period of time T * .
• the exact definition of the flow is left open. Preferably, it would be the packets of an end-to-end connection, as identified by the source and destination addresses and ports. It may also be an aggregate of such connections: for instance, all connections incoming on a given interface of the policer and destined to an IP prefix.
• a classic policer will not categorise as misbehaving some flows with a throughput not so high in absolute terms, but already too high given the unfavourable path conditions, while a path-specific policer would catch it, in zone 4, a classic policer will categorise as misbehaving some flows with very high throughput in absolute terms, but perfectly acceptable given the very favourable path conditions, while a path-specific policer would let them through.
• Embodiments of the invention allow instead for the policing to be performed at the upstream edge of the network, therefore enabling a more efficient protection of the network.
• Figure 4 shows how this can be done by means of a token bucket. Whenever a packet arrives, ⁇ T cp-dt j ,j is added to the token bucket (where dt j j is the inter-arrival time since the last packet), while k-rcp-T j j.Vmy is taken out of it (where Ty and m ⁇ are obtained from the fields in the packet). If the bucket is not empty after the adjustment, the packet is served as requested. If on the other hand the bucket is empty, the flow is flagged for sanction and the packet is dealt with appropriately.
• Figure 6 describes the flow chart related to Figure 4.
• a packet arrives, it is associated with its flow id j, the downstream congestion metric m lt ⁇ , the round-trip time Ty and the time t new when it is received.
• the policer checks whether the flow is on the blacklist (no flow is on the blacklist at first).
• the final step is to check that the bucket is not empty at the end of this operation. If B j ⁇ 0 the flow id is blacklisted and the packet is treated for sanction, while if B j >0 the packet is processed normally.
• n TC p is not a very simple computational operation as it may require extracting a square root (or a cubic root, as explained in the section dealing with Obtaining the path metrics"). Therefore, if the implementation of the policer is required to minimise delay in forwarding packets, the order of operation may be different. First the number of tokens in the bucket would be checked. If Bj>0, the packet would be forwarded immediately. Updating the state of the token bucket would be done offline, but quickly enough so that the update occurs within a round-trip time. The delay minimisation in the packet processing may come at the expense of responsiveness, as it may take longer to detect misbehaving flows.
• the depth of the bucket follows from the objective of the policer.
• the policer should flag any flow whose apparent greediness ⁇ , is higher than the ceiling ⁇ * for a period of time T*.
• the bucket should be empty after T*, even if the bucket is full at the start:
• the advantage of the sampling version for the policer is that small compliant flows will not require the creation of a token bucket, which will reduce the state requirement (number of active token buckets) of the policer when compared to a non-sampling embodiment. This feature is important in protecting the policer against denial-of-service attacks.
• Figure 7 describes the flow chart related to Figure 5.
• a packet arrives, it is associated with its flow id j, the downstream congestion metric m j j , the round-trip time Ty and the time t n ⁇ W when it is received.
• the state of the token bucket Bj may still be updated at that point.
• One treatment may be applied when the flow has just been blacklisted, a harsher treatment may be applied if the number of tokens in the bucket remains negative, and the flow may be removed from the blacklist when the number of tokens in the bucket becomes positive again (as would happen if the flow drastically reduces its sending rate).
• three values may be extracted from the packet header: the flow id j, the re-feedback congestion field h j , and the re-feedback downstream delay D j .
• the policer should be located close to the ingress of the network. Indeed the re- feedback fields may only characterise the downstream path while end-to-end metrics are required for the compliance test. If the policer is located close to the network ingress, there are two options: either the discrepancy might be ignored because the upstream contribution to the end-to-end metrics can be shown to be negligible, or the upstream contribution could be monitored by the policing node and used together with the downstream metrics in order to obtain the end-to-end metrics. This may require the policing node to keep permanent state of its upstream paths, which may only be manageable at a network ingress where the number of upstream nodes is limited.
• nri j from the downstream metric extracted from hj, which is a standard re-feedback operation. This assumes that the upstream network between the ingress access element and the sending host doesn't experience significant congestion.
• the policing node a record of the upstream round-trip delay T 0 between each upstream source and itself using the minimum of a number of tests at uncongested periods.
• Other techniques might be used to retrieve the roundtrip: see for instance Jiang & Dovrolis [20].
• ⁇ * is the main control parameter of the policer. Its choice is key in setting the trade-off between responsiveness (detecting misbehaving flows quickly) and robustness (identifying as misbehaving as few compliant flows as possible) of the policer. We explain here how to set ⁇ * so that the proportion of compliant flows identified as misbehaving (that is, the proportion of false positives) remains smaller than ⁇ (we would expect ⁇ to take very small values, say 10 3 at most).
• ⁇ * should therefore be set so that the probability for the congestion window to exceed ⁇ * times the expected average cwnd avg is smaller than ⁇ , which is given by P(cwnd> ⁇ * .cwnd avg ) ⁇ ⁇ .
• ⁇ *.cwnd avg ⁇ 35 while cwnd a v g -12.7 the value of the average comes from analysis of the TCP congestion window as a Markov chain.
• the depth of the bucket should be set to a lower value.
• sampling version of the policer is to be dimensioned to minimise its state requirement (as defined by the number of buckets necessary to monitor the traffic flowing through), a shorter bucket will reduce the state requirement, as well as a smaller value for the sampling parameter ⁇ .
• Further embodiment adjusting the compliance test to each user's congestion history It is possible to address the above issue by keeping track of the amount of congestion caused by a user over a recent period. For instance, a record of the volume of the congestion m k resulting from the data sent could be maintained for each user, while the contracted usage over the period U k is known. Further, estimates of the aggregate usage over all users U and of the resulting congestion M would also be computed.
• Different classes of traffic may also be tested against different compliance formulas by using different classes.

Landscapes

• Engineering & Computer Science (AREA)
• Computer Networks & Wireless Communication (AREA)
• Signal Processing (AREA)
• Data Exchanges In Wide-Area Networks (AREA)

Priority Applications (5)

Applications Claiming Priority (4)

Publications (1)

Family

ID=36103258

Family Applications (1)

Country Status (6)

Cited By (6)

Families Citing this family (52)

Family Cites Families (21)

• 2006
  • 2006-02-07 WO PCT/GB2006/000417 patent/WO2006082443A1/en active Application Filing
  • 2006-02-07 EP EP06709661.0A patent/EP1847081B1/en active Active
  • 2006-02-07 CN CN200680004192.7A patent/CN101116292B/zh active Active
  • 2006-02-07 JP JP2007553706A patent/JP4705115B2/ja active Active
  • 2006-02-07 KR KR1020077019177A patent/KR101228288B1/ko not_active IP Right Cessation
  • 2006-02-07 US US11/795,949 patent/US7948878B2/en active Active

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events