WO2006082443A1 - Policing networks - Google Patents
Policing networks Download PDFInfo
- Publication number
- WO2006082443A1 WO2006082443A1 PCT/GB2006/000417 GB2006000417W WO2006082443A1 WO 2006082443 A1 WO2006082443 A1 WO 2006082443A1 GB 2006000417 W GB2006000417 W GB 2006000417W WO 2006082443 A1 WO2006082443 A1 WO 2006082443A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- flow
- greediness
- messages
- measure
- path
- Prior art date
Links
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)
Abstract
Description
Claims
Priority Applications (5)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2007553706A JP4705115B2 (en) | 2005-02-07 | 2006-02-07 | Network monitoring |
EP06709661.0A EP1847081B1 (en) | 2005-02-07 | 2006-02-07 | Policing networks |
US11/795,949 US7948878B2 (en) | 2005-02-07 | 2006-02-07 | Policing networks |
KR1020077019177A KR101228288B1 (en) | 2005-02-07 | 2006-02-07 | Policing networks |
CN200680004192.7A CN101116292B (en) | 2005-02-07 | 2006-02-07 | Policing networks |
Applications Claiming Priority (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
GB0502483.1 | 2005-02-07 | ||
GB0502483A GB0502483D0 (en) | 2005-02-07 | 2005-02-07 | Policing networks |
EP05255164.5 | 2005-08-22 | ||
EP05255164A EP1758313A1 (en) | 2005-08-22 | 2005-08-22 | Policing networks |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2006082443A1 true WO2006082443A1 (en) | 2006-08-10 |
Family
ID=36103258
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/GB2006/000417 WO2006082443A1 (en) | 2005-02-07 | 2006-02-07 | Policing networks |
Country Status (6)
Country | Link |
---|---|
US (1) | US7948878B2 (en) |
EP (1) | EP1847081B1 (en) |
JP (1) | JP4705115B2 (en) |
KR (1) | KR101228288B1 (en) |
CN (1) | CN101116292B (en) |
WO (1) | WO2006082443A1 (en) |
Cited By (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP2234346A1 (en) | 2009-03-26 | 2010-09-29 | BRITISH TELECOMMUNICATIONS public limited company | Policing in data networks |
EP2398194A1 (en) | 2010-06-17 | 2011-12-21 | British Telecommunications Public Limited Company | Monitoring path characterisation information |
EP2541850A1 (en) | 2011-06-30 | 2013-01-02 | British Telecommunications Public Limited Company | Determining path congestion measures |
WO2013001271A1 (en) | 2011-06-30 | 2013-01-03 | British Telecommunications Public Limited Company | Determining path congestion measures |
EP2575303A1 (en) | 2011-09-30 | 2013-04-03 | British Telecommunications Public Limited Company | Determining congestion measures |
WO2013045878A1 (en) | 2011-09-30 | 2013-04-04 | British Telecommunications Plc | Attribution of congestion contributions |
Families Citing this family (52)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7965717B2 (en) * | 2003-01-17 | 2011-06-21 | Nortel Networks Limited | Multi-staged services policing |
EP2106068A1 (en) * | 2008-03-28 | 2009-09-30 | British Telecommunications Public Limited Company | Measuring data source-specific network metrics |
CN101557335B (en) * | 2008-04-11 | 2012-11-21 | 华为技术有限公司 | Method for controlling node to join peer-to-peer network and device thereof |
US8000235B2 (en) * | 2008-10-05 | 2011-08-16 | Contextream Ltd. | Bandwidth allocation method and apparatus |
US20110083175A1 (en) * | 2009-10-06 | 2011-04-07 | Sonus Networks, Inc. | Methods and Apparatuses for Policing and Prioritizing of Data Services |
US8340126B2 (en) | 2010-06-07 | 2012-12-25 | Lockheed Martin Corporation | Method and apparatus for congestion control |
US10284356B2 (en) | 2011-02-03 | 2019-05-07 | The Board Of Trustees Of The Leland Stanford Junior University | Self-interference cancellation |
US10230419B2 (en) * | 2011-02-03 | 2019-03-12 | The Board Of Trustees Of The Leland Stanford Junior University | Adaptive techniques for full duplex communications |
US10243719B2 (en) | 2011-11-09 | 2019-03-26 | The Board Of Trustees Of The Leland Stanford Junior University | Self-interference cancellation for MIMO radios |
CN102571570A (en) * | 2011-12-27 | 2012-07-11 | 广东电网公司电力科学研究院 | Network flow load balancing control method based on reinforcement learning |
TWI459768B (en) * | 2011-12-30 | 2014-11-01 | Ind Tech Res Inst | Communication system and method for assisting transmission of tcp packets |
US9325432B2 (en) | 2012-02-08 | 2016-04-26 | The Board Of Trustees Of The Leland Stanford Junior University | Systems and methods for full-duplex signal shaping |
KR101475935B1 (en) | 2013-06-20 | 2014-12-23 | 고려대학교 산학협력단 | Adaptive probabilistic packet filtering router and method thereof |
US11163050B2 (en) | 2013-08-09 | 2021-11-02 | The Board Of Trustees Of The Leland Stanford Junior University | Backscatter estimation using progressive self interference cancellation |
US9036749B2 (en) | 2013-08-09 | 2015-05-19 | Kumu Networks, Inc. | Systems and methods for frequency independent analog self-interference cancellation |
US9698860B2 (en) | 2013-08-09 | 2017-07-04 | Kumu Networks, Inc. | Systems and methods for self-interference canceller tuning |
US8976641B2 (en) | 2013-08-09 | 2015-03-10 | Kumu Networks, Inc. | Systems and methods for non-linear digital self-interference cancellation |
US9054795B2 (en) | 2013-08-14 | 2015-06-09 | Kumu Networks, Inc. | Systems and methods for phase noise mitigation |
US10673519B2 (en) | 2013-08-29 | 2020-06-02 | Kuma Networks, Inc. | Optically enhanced self-interference cancellation |
JP6183939B2 (en) | 2013-08-29 | 2017-08-23 | クム ネットワークス インコーポレイテッドKumu Networks,Inc. | Full duplex relay device |
US9520983B2 (en) | 2013-09-11 | 2016-12-13 | Kumu Networks, Inc. | Systems for delay-matched analog self-interference cancellation |
US9794210B1 (en) | 2013-11-14 | 2017-10-17 | The United States Of America, As Represented By The Secretary Of The Army | Priority assignment based on similarity |
US9774405B2 (en) | 2013-12-12 | 2017-09-26 | Kumu Networks, Inc. | Systems and methods for frequency-isolated self-interference cancellation |
US10230422B2 (en) | 2013-12-12 | 2019-03-12 | Kumu Networks, Inc. | Systems and methods for modified frequency-isolation self-interference cancellation |
US9712312B2 (en) | 2014-03-26 | 2017-07-18 | Kumu Networks, Inc. | Systems and methods for near band interference cancellation |
US11209536B2 (en) | 2014-05-02 | 2021-12-28 | The Board Of Trustees Of The Leland Stanford Junior University | Method and apparatus for tracking motion using radio frequency signals |
US10225195B2 (en) * | 2014-05-07 | 2019-03-05 | Adtran, Inc. | Telecommunication systems and methods using dynamic shaping for allocating network bandwidth |
WO2015179874A1 (en) | 2014-05-23 | 2015-11-26 | Kumu Networks, Inc. | Systems and methods for multi-rate digital self-interference cancellation |
US9521023B2 (en) | 2014-10-17 | 2016-12-13 | Kumu Networks, Inc. | Systems for analog phase shifting |
US9712313B2 (en) | 2014-11-03 | 2017-07-18 | Kumu Networks, Inc. | Systems for multi-peak-filter-based analog self-interference cancellation |
US9673854B2 (en) | 2015-01-29 | 2017-06-06 | Kumu Networks, Inc. | Method for pilot signal based self-inteference cancellation tuning |
US9537777B1 (en) * | 2015-03-30 | 2017-01-03 | EMC IP Holding Company LLC | Adjusting input/output operation arrival times to represent a token bucket that enforces maximum rate and burst size limits |
US9948561B2 (en) * | 2015-04-14 | 2018-04-17 | Cisco Technology, Inc. | Setting delay precedence on queues before a bottleneck link based on flow characteristics |
CN105119778B (en) * | 2015-09-09 | 2018-09-07 | 华为技术有限公司 | The method and apparatus for measuring time delay |
US9634823B1 (en) | 2015-10-13 | 2017-04-25 | Kumu Networks, Inc. | Systems for integrated self-interference cancellation |
US9742593B2 (en) | 2015-12-16 | 2017-08-22 | Kumu Networks, Inc. | Systems and methods for adaptively-tuned digital self-interference cancellation |
US9800275B2 (en) | 2015-12-16 | 2017-10-24 | Kumu Networks, Inc. | Systems and methods for out-of band-interference mitigation |
US10666305B2 (en) | 2015-12-16 | 2020-05-26 | Kumu Networks, Inc. | Systems and methods for linearized-mixer out-of-band interference mitigation |
CN108370082B (en) | 2015-12-16 | 2021-01-08 | 库姆网络公司 | Time delay filter |
US10153974B2 (en) * | 2016-04-13 | 2018-12-11 | Futurewei Technologies, Inc. | Software defined network traffic congestion control |
US9979374B2 (en) | 2016-04-25 | 2018-05-22 | Kumu Networks, Inc. | Integrated delay modules |
US10454444B2 (en) | 2016-04-25 | 2019-10-22 | Kumu Networks, Inc. | Integrated delay modules |
US10338205B2 (en) | 2016-08-12 | 2019-07-02 | The Board Of Trustees Of The Leland Stanford Junior University | Backscatter communication among commodity WiFi radios |
EP3477983B1 (en) * | 2016-09-21 | 2020-06-03 | Swisscom AG | Data-driven roll-out planning optimization method |
CN110100464A (en) | 2016-10-25 | 2019-08-06 | 小利兰·斯坦福大学托管委员会 | Backscattering environment ISM band signal |
WO2018183384A1 (en) | 2017-03-27 | 2018-10-04 | Kumu Networks, Inc. | Systems and methods for intelligently-tunded digital self-interference cancellation |
WO2018183352A1 (en) | 2017-03-27 | 2018-10-04 | Kumu Networks, Inc. | Enhanced linearity mixer |
US10236922B2 (en) | 2017-03-27 | 2019-03-19 | Kumu Networks, Inc. | Systems and methods for tunable out-of-band interference mitigation |
US10200076B1 (en) | 2017-08-01 | 2019-02-05 | Kumu Networks, Inc. | Analog self-interference cancellation systems for CMTS |
JP7096346B2 (en) | 2018-02-27 | 2022-07-05 | クム ネットワークス,インコーポレイテッド | Configurable hybrid self-interference cancellation system and method |
US10868661B2 (en) | 2019-03-14 | 2020-12-15 | Kumu Networks, Inc. | Systems and methods for efficiently-transformed digital self-interference cancellation |
US11888749B2 (en) | 2021-10-25 | 2024-01-30 | Hewlett Packard Enterprise Development Lp | Reverse loss detection for communication network bandwidth estimation with token buckets |
Family Cites Families (21)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6266327B1 (en) * | 1998-03-20 | 2001-07-24 | Lucent Technologies Inc. | Non-conformance indicator for the guaranteed frame rate service |
US6724721B1 (en) * | 1999-05-07 | 2004-04-20 | Cisco Technology, Inc. | Approximated per-flow rate limiting |
US6865185B1 (en) * | 2000-02-25 | 2005-03-08 | Cisco Technology, Inc. | Method and system for queuing traffic in a wireless communications network |
US6839321B1 (en) * | 2000-07-18 | 2005-01-04 | Alcatel | Domain based congestion management |
US6898182B1 (en) * | 2000-07-21 | 2005-05-24 | Arris International, Inc | Congestion control in a network device having a buffer circuit |
JP3788908B2 (en) * | 2000-12-28 | 2006-06-21 | 株式会社エヌ・ティ・ティ・ドコモ | Admission control device and new connection admission control method |
US7027393B1 (en) * | 2001-03-02 | 2006-04-11 | Cisco Technology, Inc. | TCP optimized single rate policer |
US6958998B2 (en) * | 2001-07-09 | 2005-10-25 | International Business Machines Corporation | Traffic management in packet-based networks |
CN1170444C (en) * | 2001-08-10 | 2004-10-06 | 华为技术有限公司 | Device and method for flow monitoring and managing every packet data protocol context |
US7006440B2 (en) * | 2001-10-26 | 2006-02-28 | Luminous Networks, Inc. | Aggregate fair queuing technique in a communications system using a class based queuing architecture |
US7092357B1 (en) * | 2001-11-13 | 2006-08-15 | Verizon Services Corp. | Anti-flooding flow-control methods and apparatus |
US7295516B1 (en) * | 2001-11-13 | 2007-11-13 | Verizon Services Corp. | Early traffic regulation techniques to protect against network flooding |
US7944839B2 (en) | 2001-11-30 | 2011-05-17 | British Telecommunications Public Limited Company | Method of resource control in a wireless network |
US7376159B1 (en) * | 2002-01-03 | 2008-05-20 | The Directv Group, Inc. | Exploitation of null packets in packetized digital television systems |
CN1319326C (en) * | 2003-04-01 | 2007-05-30 | 华为技术有限公司 | Band width statistical multiplex method based on acknowledged cut in speed |
GB0322770D0 (en) | 2003-09-29 | 2003-10-29 | British Telecomm | Bandwith allocation |
GB0407144D0 (en) | 2004-03-30 | 2004-05-05 | British Telecomm | Networks |
GB0410254D0 (en) | 2004-05-07 | 2004-06-09 | British Telecomm | Processing of data in networks |
US8248932B2 (en) * | 2004-05-26 | 2012-08-21 | West Lane Data Llc | Method and apparatus for fairly sharing excess bandwidth and packet dropping amongst subscribers of a data network |
US7782793B2 (en) * | 2005-09-15 | 2010-08-24 | Alcatel Lucent | Statistical trace-based methods for real-time traffic classification |
JP4722964B2 (en) * | 2008-05-30 | 2011-07-13 | 富士通株式会社 | Channel setting method in mobile communication system |
-
2006
- 2006-02-07 KR KR1020077019177A patent/KR101228288B1/en not_active IP Right Cessation
- 2006-02-07 WO PCT/GB2006/000417 patent/WO2006082443A1/en active Application Filing
- 2006-02-07 JP JP2007553706A patent/JP4705115B2/en active Active
- 2006-02-07 CN CN200680004192.7A patent/CN101116292B/en active Active
- 2006-02-07 US US11/795,949 patent/US7948878B2/en active Active
- 2006-02-07 EP EP06709661.0A patent/EP1847081B1/en active Active
Non-Patent Citations (1)
Title |
---|
NIKOLOUZOU E ET AL: "Network services definition and deployment in a differentiated services architecture", ICC 2002. 2002 IEEE INTERNATIONAL CONFERENCE ON COMMUNICATIONS. CONFERENCE PROCEEDINGS. NEW YORK, NY, APRIL 28 - MAY 2, 2002, IEEE INTERNATIONAL CONFERENCE ON COMMUNICATIONS, NEW YORK, NY : IEEE, US, vol. VOL. 1 OF 5, 28 April 2002 (2002-04-28), pages 1057 - 1062, XP010589653, ISBN: 0-7803-7400-2 * |
Cited By (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP2234346A1 (en) | 2009-03-26 | 2010-09-29 | BRITISH TELECOMMUNICATIONS public limited company | Policing in data networks |
WO2010109201A1 (en) | 2009-03-26 | 2010-09-30 | British Telecommunications Public Limited Company | Policing in data networks |
US9154422B2 (en) | 2009-03-26 | 2015-10-06 | British Telecommunications Plc | Policing in data networks |
EP2398194A1 (en) | 2010-06-17 | 2011-12-21 | British Telecommunications Public Limited Company | Monitoring path characterisation information |
WO2011157984A1 (en) | 2010-06-17 | 2011-12-22 | British Telecommunications Public Limited Company | Monitoring path characterisation information |
EP2541850A1 (en) | 2011-06-30 | 2013-01-02 | British Telecommunications Public Limited Company | Determining path congestion measures |
WO2013001271A1 (en) | 2011-06-30 | 2013-01-03 | British Telecommunications Public Limited Company | Determining path congestion measures |
EP2575303A1 (en) | 2011-09-30 | 2013-04-03 | British Telecommunications Public Limited Company | Determining congestion measures |
WO2013045878A1 (en) | 2011-09-30 | 2013-04-04 | British Telecommunications Plc | Attribution of congestion contributions |
US9998400B2 (en) | 2011-09-30 | 2018-06-12 | British Telecommunications Public Limited Company | Attribution of congestion contributions |
Also Published As
Publication number | Publication date |
---|---|
EP1847081A1 (en) | 2007-10-24 |
EP1847081B1 (en) | 2014-12-24 |
KR101228288B1 (en) | 2013-01-30 |
JP2008530841A (en) | 2008-08-07 |
US20080192636A1 (en) | 2008-08-14 |
CN101116292A (en) | 2008-01-30 |
CN101116292B (en) | 2014-11-05 |
JP4705115B2 (en) | 2011-06-22 |
KR20070100899A (en) | 2007-10-12 |
US7948878B2 (en) | 2011-05-24 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
EP1847081B1 (en) | Policing networks | |
Bedi et al. | Mitigating congestion based DoS attacks with an enhanced AQM technique | |
US8289851B2 (en) | Lightweight bandwidth-management scheme for elastic traffic | |
Chandrayana et al. | Uncooperative congestion control | |
Podlesny et al. | RD network services: differentiation through performance incentives | |
Seddigh et al. | Experimental study of assured services in a Diffserv IP QoS network | |
EP1758313A1 (en) | Policing networks | |
Joshi et al. | Design and analysis of multi-level active queue management mechanisms for emergency traffic | |
Muhammad et al. | Study on performance of AQM schemes over TCP variants in different network environments | |
Yamaguchi et al. | A queue management algorithm for fair bandwidth allocation | |
Mohammed et al. | Active queue management for congestion control: Performance evaluation, new approach, and comparative study | |
Mellia et al. | TCP-aware packet marking in networks with diffserv support | |
Chatranon et al. | Fairness of AQM schemes for TCP-friendly traffic | |
Haider et al. | Congestion control algorithms in high speed telecommunication networks | |
Hassayoun et al. | Loss synchronization, router buffer sizing and high-speed TCP versions: Adding RED to the mix | |
Akintola et al. | Modeling and Performance Analysis of Dynamic Random Early Detection (DRED) Gateway for Congestion Avoidance. | |
Habib et al. | Network tomography-based unresponsive flow detection and control | |
Prasad et al. | A stateless and light-weight bandwidth management mechanism for elastic traffic | |
Aweya et al. | WINTRAC: A TCP window adjustment scheme for bandwidth management | |
Zhu | A new class-based traffic queue management algorithm in the internet | |
Li et al. | Core‐stateless fair rate estimation fair queuing | |
Casetti et al. | A lightweight marker with partial state information for DiffServ networks | |
Liberatore | Local flow separation | |
Kinicki et al. | A Performance Studym of Explicit Congestion Notification (ECN) with Heterogeneous TCP Flows | |
Zheng et al. | Adaptive explicit congestion notification |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
121 | Ep: the epo has been informed by wipo that ep was designated in this application | ||
WWE | Wipo information: entry into national phase |
Ref document number: 2006709661 Country of ref document: EP |
|
WWE | Wipo information: entry into national phase |
Ref document number: 5747/DELNP/2007 Country of ref document: IN |
|
WWE | Wipo information: entry into national phase |
Ref document number: 11795949 Country of ref document: US |
|
WWE | Wipo information: entry into national phase |
Ref document number: 200680004192.7 Country of ref document: CN Ref document number: 2007553706 Country of ref document: JP |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
WWE | Wipo information: entry into national phase |
Ref document number: 1020077019177 Country of ref document: KR |
|
WWP | Wipo information: published in national office |
Ref document number: 2006709661 Country of ref document: EP |