EP2979407A1 - Re-marking of packets for queue control - Google Patents
Re-marking of packets for queue controlInfo
- Publication number
- EP2979407A1 EP2979407A1 EP14716368.7A EP14716368A EP2979407A1 EP 2979407 A1 EP2979407 A1 EP 2979407A1 EP 14716368 A EP14716368 A EP 14716368A EP 2979407 A1 EP2979407 A1 EP 2979407A1
- Authority
- EP
- European Patent Office
- Prior art keywords
- queue
- packet
- packets
- node
- status
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000000034 method Methods 0.000 claims abstract description 58
- 238000004590 computer program Methods 0.000 claims description 9
- 230000005540 biological transmission Effects 0.000 claims description 6
- 230000008859 change Effects 0.000 claims description 5
- 239000000872 buffer Substances 0.000 abstract description 46
- 230000008569 process Effects 0.000 description 32
- 230000006870 function Effects 0.000 description 17
- 238000010586 diagram Methods 0.000 description 11
- 238000012360 testing method Methods 0.000 description 8
- 230000032258 transport Effects 0.000 description 8
- 238000013459 approach Methods 0.000 description 7
- 230000006399 behavior Effects 0.000 description 4
- 230000008901 benefit Effects 0.000 description 3
- 238000005259 measurement Methods 0.000 description 3
- 230000011664 signaling Effects 0.000 description 3
- 208000003443 Unconsciousness Diseases 0.000 description 2
- 230000007246 mechanism Effects 0.000 description 2
- 238000012544 monitoring process Methods 0.000 description 2
- 239000000523 sample Substances 0.000 description 2
- 238000007493 shaping process Methods 0.000 description 2
- 206010016322 Feeling abnormal Diseases 0.000 description 1
- 102100023600 Fibroblast growth factor receptor 2 Human genes 0.000 description 1
- 101000827688 Homo sapiens Fibroblast growth factor receptor 2 Proteins 0.000 description 1
- 230000009471 action Effects 0.000 description 1
- 230000006978 adaptation Effects 0.000 description 1
- 238000004891 communication Methods 0.000 description 1
- 230000007423 decrease Effects 0.000 description 1
- 230000001934 delay Effects 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000001514 detection method Methods 0.000 description 1
- 238000002592 echocardiography Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 230000007717 exclusion Effects 0.000 description 1
- 239000012634 fragment Substances 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000012545 processing Methods 0.000 description 1
- 230000002250 progressing effect Effects 0.000 description 1
- 230000000644 propagated effect Effects 0.000 description 1
- 238000011160 research Methods 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 238000012552 review Methods 0.000 description 1
- 230000007727 signaling mechanism Effects 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
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/30—Flow control; Congestion control in combination with information about buffer occupancy at either end or at transit nodes
-
- 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/26—Flow control; Congestion control using explicit feedback to the source, e.g. choke packets
- H04L47/263—Rate modification at the source after receiving feedback
-
- 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/50—Queue scheduling
- H04L47/62—Queue scheduling characterised by scheduling criteria
- H04L47/624—Altering the ordering of packets in an individual queue
Definitions
- the present invention describes a way of re-marking packets in order to indicate the length of a queue at a buffer in a packet network and specifically it relates to a method and apparatus for transmission rate adaptation based on the indicated queue length.
- a data source faces a dilemma whenever it has little or no information about how much capacity is available, but it needs to send data as fast as possible without causing undue congestion.
- a data source faces this dilemma every time it starts a new data flow, every time it re-starts after an idle period, and every time another flow finishes that has been sharing the same capacity.
- the family of congestion control algorithms that have been proposed for TCP combine two forms of operation: one dependent on congestion feedback (closed-loop control), the other at times when there is no feedback (open-loop control).
- closed-loop control On the current Internet, open loop control has to be used at the start or re-start of a flow or at the end of a competing flow, when the sender has little or no information on how much capacity is available.
- a large majority of TCP algorithms uses the same 'slow-start' algorithm to exponentially increase the sending rate, probing for more capacity by doubling the sending rate every round trip, until the receiver feeds back that it has detected a loss as the first signal of congestion.
- the sender receives this feedback one round trip time after its sending rate exceeded available capacity. By the time it receives this signal it will already be sending more than twice as fast as the available capacity.
- a concept called the congestion window is used within the TCP algorithm to control its rate.
- the window is the amount of data that can be sent in excess of the data that has been acknowledged.
- open-loop With little or no knowledge of the available capacity (open-loop) it is difficult to argue whether one congestion window is better than another - any behaviour could be safe in some circumstances and unsafe in others.
- Internet standards say a flow should start with a window of no more than 4380B (3 full-sized packets over Ethernet), and a window of 10 packets is currently being experimented with. Numbers like these are set by convention to control a flow's behaviour while it has no better information about actual available capacity (open-loop control).
- TCP doubles its window every round trip during its start-up phase Doubling certainly matches the halving that another part of the TCP algorithm does during its closed-loop (or
- TCP has already taken 11 round trip times, over 2 seconds in this case, to find its correct operating rate. Further, when TCP drops such a large number of packets, it can take a long time to recover, sometimes leading to a black-out of many more seconds (100 seconds has been reported [Ha08] due to long time-outs or the time it takes for the host to free-up large numbers of buffers). In the process, the voice flow is also likely to black-out for at least 200ms and often much longer, due to at least 50% of the voice packets being dropped over this period.
- a number of different methods for signalling congestion in packet networks i.e. that queues are building up, are known in the prior art, for example active queue management (AQM) techniques (e.g. RED, REM, PI, PIE, CoDel) can be configured to drop a proportion of packets when it is detected that a queue is starting to grow but before the queue is full. All AQM algorithms drop more packets as the queue grows longer.
- AQM active queue management
- An active queue management algorithm can be arranged to discard a greater proportion of traffic marked with a lower class-of-service, or marked as out-of-contract. For instance, weighted random early detection [WRED] determines whether to drop an arriving packet using the RED AQM algorithm but the parameters used for the algorithm depend on the class of service marked on each arriving packet.
- WRED weighted random early detection
- Explicit Congestion Notification (ECN) [RFC3168] conveys congestion signals in TCP/IP networks by means of a two-bit ECN field in the IP header, whether in IPv4 ( Figure 2) or IPv6 ( Figure 3).
- ECN Explicit Congestion Notification
- these two bits Prior to the introduction of ECN, these two bits were present in both types of IP header, but always set to zero. Therefore, if these bits are both zero, a queue management process assumes that the packet comes from a transport protocol on the end-systems that will not understand the ECN protocol so it only uses drop, not ECN, to signal congestion.
- a queue management process When a queue management process detects congestion, for packets with a non-zero ECN field, it sets the ECN field to the Congestion Experienced (CE) codepoint.
- CE Congestion Experienced
- a TCP receiver On receipt of such a marked packet, a TCP receiver sets the Echo Congestion Experienced (ECE) flag in the TCP header of packets it sends to acknowledge the data packets it has received.
- ECE Echo Congestion Experienced
- a standard TCP source interprets ECE feedback as if the packet has been dropped, at least for the purpose of its rate control. But of course, it does not have to retransmit the ECN marked packet.
- Drop and congestion signals are not mutually exclusive signals, and flows that enable ECN have the potential to detect and respond to both signals.
- ECN3168 deliberately assigns the same meaning to both the ECN codepoints with one bit set (01 and 10). They both mean that the transport is ECN-capable (ECT), and if they need to be distinguished they are termed ECT(l) and ECT(0) respectively. The intention was to allow scope for innovative new ways to distinguish between these fields to be proposed in future. There are some known alternative uses for the two ECN-capable transport (ECT) codepoints.
- PCN pre-congestion notification
- PCN uses a virtual queue, which is not actually a queue; rather it is a number that represents the length of queue that would have formed if the buffer were drained more slowly than the real buffer drains.
- PCN uses two virtual queues one configured to drain at a slower rate than the other. When the slower virtual queue fills, it marks packets with the ECT(l) codepoint and when the faster virtual queue fills it marks packets with the CE codepoint.
- AQM and ECN are not exclusive to IP-aware devices. Many non-IP devices use AQM to drop packets before the queue fills the buffer and some protocols layered below IP include the facility to signal congestion explicitly instead of dropping packets (e.g. MPLS [RFC5129]). Such lower-layer protocols typically encapsulate an IP packet.
- any ECN marking on the outer MPLS header is propagated into the inner IP header to be forwarded onward to its destination
- the encoding of ECN in the MPLS header is flexible enough to be able to define more than one level of severity for congestion notification, at least within the constraints of the size of the MPLS header. Then, for instance, the two levels of PCN marking can be encoded.
- each packet carries a bit called the Anti-ECN bit in its header.
- the bit is initially set to zero.
- Each router along the packet's route checks to see if it can allow the flow to increase its sending rate by determining whether the packet has arrived at an empty virtual queue. If so, the router sets the bit to one. If on arrival the virtual queue is non-empty, it sets the bit to zero. The receiver then echoes the bit back to the sender using the ACK packet. If the bit is set to one, the sender increases its congestion window and hence its rate.
- Patent application US2002009771 [6] discloses a traffic shaping and scheduling function for the release of packets from a queue.
- a packet eligible for transmission is provided with a tag, created for the packet, which tag may operate as a criterion for sorting the packet in a binary tree of tags.
- the tag is one of the determinants of the order in which several packets are selected for transmission, however, the tag is not used for indicating any kind of congestion at the node.
- a method for handling packets at a node in a packet network comprising: receiving at a queue a packet carrying a status tag set to a first status value; checking if any packet already in the queue at the time of arrival of said packet has upon leaving the queue a tag set to the first status value; and if so changing the tag status value of the received packet to a different status value.
- an explicit queue length at the node can be determined from a sequence of status tags irrespective of which unit the node measures the queue length in. Further, end-systems receiving a sequence of status tags are able to rapidly detect the very first sign of queue growth from said sequence.
- a node for handling packets in a packet network comprising: an interface arranged in operation to receive and enqueue a packet having a status tag set to a first status value; and a module arranged in operation to check if any packet already in the queue at the time of arrival of said packet has upon leaving the queue a tag set to the same first status value; and if so to change the tag status value of the received packet to a different status value.
- a method for estimating a length of a queue of packets awaiting handling at a network node comprising: receiving at another node a sequence of tag status values associated with packets which have been routed via said network node, where said tag status value is set to either a first or a different status value; and estimating the length of the queue from said sequence of tag status values.
- a sender node By estimating the queue length from the sequence of received status tags, a sender node will be able to tell if it has been sending out packets too slowly or it will be able to quantify how much faster its transmission rate has been than the available capacity and adapting its packet transmission rate accordingly. Further, the sender node will be aware of an increasing queue length at an early stage, long before there is actual congestion, and hence react faster to any problems.
- a receiving node will typically reflect the status tags it receives back to a sender node as encoded feedback messages, so that the sender can determine the queue length from the spacing between packets carrying the first status value.
- the receiving node may determine this spacing itself, and continually derive the queue length. Then the receiving node may continually feed a value representing this queue length back to the sender, or the receiving node may even determine a new rate for the sender to use and feed a value representing this rate back to the sender.
- a node in a packet network arranged in operation to estimate a length of a queue of packets awaiting handling at a network node, which network node is adapted to operate according to claims 3 or 4, said node comprising: an interface arranged in operation to receive a sequence of tag status values associated with packets which have been routed via said network node, where said tag status value is set is to either a first or a different status value; and a module arranged in operation to estimate the length of the queue from said sequence of tag status values.
- Figure 1 shows a schematic diagram of a typical packet network.
- Figure 2 shows an IPv4 packet header.
- Figure 3 shows an IPv6 packet header.
- Figure 4 shows the current definition of the Explicit Congestion Notification (ECN) field in either IPv4 or IPv6.
- Figure 5 shows an exemplary diagram of the unqueuable ECN marking process as queue length evolves.
- ECN Explicit Congestion Notification
- Figure 6 shows a buffer with a single unmarked packet queue.
- Figure 7 shows a flow diagram of the relevant parts of the enqueuing and dequeueing algorithms of the unqueueable ECN marking algorithm.
- Figure 8 shows unqueueable ECN marking mixed with non-ECN capable packets.
- Figure 9 shows a flow diagram of the relevant parts of the enqueuing and dequeueing algorithms of an alternative unqueueable ECN marking algorithm.
- Figure 10 shows an exemplary diagram of an alternative unqueuable ECN marking process as queue length evolves.
- Figure 11a shows an exemplary embodiment of a sender/receiver node.
- Figure lib shows an exemplary embodiment of a router node.
- FIG. 1 shows a schematic diagram of a typical packet network (10).
- a sender node (11) sends data packets along path (12) towards receiver (18).
- a sequence of routers forward the data packets along the path.
- the sender node (11) forwards them to a customer edge (CE) router (13), which in turn forwards them to a provider edge (PE) router (14).
- CE customer edge
- PE provider edge
- Other senders (not shown) will typically be connected to the CE router and other CE routers (not shown) will typically be connected to the PE router.
- the PE router forwards the data packets to a core router, which in turn may forward them via one or more core routers towards a second PE router (16), which forwards them to the receiver node (18) via another CE router (17).
- the path from a sender node to a receiver node may pass through different numbers of routers to those depicted in Figure 1.
- sender/receiver node (11, 18) comprises an interface (22) for transmitting and receiving packets to/from network (10), a bus (21), a processor CPU (23), at least one memory (24), at least one store (25) for storing one or more program modules (27) and optionally a buffer (20).
- the program module (27) will when loaded into memory (24) and executed by processor (23) perform the queue length estimating method later described.
- each router (13, 14, 15, 16, 17) comprises a processor CPU (23), at least one memory (24), at least one store (25) for storing one or more program modules (26) and at least one buffer (20) for each outgoing interface (22) and a bus (21).
- the one or more program modules (26) will, when loaded into memory (24) and executed by processor (23), perform the packet handling methods later described.
- Figure 6 depicts one of these buffers (20) with a few packets (93, 94) which have arrived in a certain order.
- selected information from the packet headers may be buffered separately from the actual packets, but only a single buffer is shown for simplicity.
- the router may have determined which packets to queue in this buffer.
- the buffer and its management consists of a packet store (90), a dequeuing function module (91) that forwards packets to the line and an enqueuing function module (92) that enqueues arriving data packets.
- the enqueuing and dequeuing function modules may be implemented on the same network interface card. Alternatively, in distributed machine architectures they may be implemented on separate cards while sharing access to common control information about the distributed buffer memory. In such a case the components of the buffer (20) will be associated together logically rather than physically.
- 'router' has been used for all the network nodes, this is not intended to preclude non-IP-aware nodes, e.g. Ethernet switches or MPLS switches, from implementing the invention in their buffers. Similarly, it does not preclude functions with a buffer but no routing or switching from implementing the invention, e.g. end-systems, firewalls or network address translators.
- Figure 5 shows in a graph the queue length as a function of time for arriving/departing packets
- Time is divided into timeslots (110) along the horizontal axis, with packets (113) illustrated as little rectangles.
- packets (113) illustrated as little rectangles.
- one packet is forwarded by the dequeueing function module (91) from the buffer to the line, represented by the stream (112) of single packets leaving the system in the direction of the diagonal arrows from under the horizontal axis.
- Zero, one or more packets (113) may arrive during a timeslot (110), represented by the stack of arriving packets shown along the top of the diagram, with diagonal arrows (114) showing that the whole arriving stack of packets joins the queue during the next timeslot (110).
- the length of the queue in each timeslot is shown by the height of the stack of packets in the body of the graph.
- the packets that have just been added into the queue within the current timeslot are shown with thicker borders.
- the character (115)(or lack of character) within each packet (113) in Figure 5 represents the value of the ECN codepoint in that packet, using the abbreviated forms in the legend at the bottom of the figure.
- all arriving packets come from senders that have set the ECN field to ECT(O), which is the standard ECN behaviour.
- This spacing can be measured in packets, in bytes or in time.
- arriving packets would be different sizes.
- the packet marking process would be no different to that already described, in that each arriving packet will still be re-marked to the ECT(l) codepoint if there were a packet marked ECT(O) already in the queue.
- the number of transmitted bytes between the start of one ECT(O) packet and the start of the previous ECT(O) packet would then represent the length of the queue in bytes at the instant that the second of the two packets arrived.
- the duration between one ECT(O) packet starting to be dequeued and the previous ECT(O) packet starting to be dequeued would represent the queuing delay experienced by the second ECT(O) packet.
- the algorithm consists of two functions that are part of the enqueue module (92) and the dequeue (91) module.
- the two functions share a binary variable ectOinQ (100) used to communicate between the two, that is set as TRUE if there is a packet carrying the ECT(O) codepoint in the queue. It is initialised as follows.
- Figure 6 illustrates the packet store (90) already containing two packets, the first (93) with the ECT(O) marking and the second (94) with the ECT(l) marking.
- stage (101) the newly arriving packet is tested for whether it carries the ECT(O) marking, which it does so it passes to stage (102) which tests the shared variable ectOinQ. Because the ECT(O) packet (93) is still sitting at the head of the queue, ectOinQ is still TRUE. So this time execution passes to stage (103) where the ECN field is re-marked to ECT(l). Then execution again passes to stage (105) where the usual enqueuing machinery is executed to add the packet to the buffer's memory structure.
- stage (106) passes execution to stage (107) that sets the shared ectOinQ flag to FALSE, indicating that there is no longer an ECT(O) packet in the queue. This will allow a new ECT(O) packet into the queue by the next execution of stage (102) in the enqueuing function, because it will pass to stage (104) not (103), as has already been explained.
- stage (106) will do nothing other than pass execution straight back to the outer dequeue function to process the next packet.
- the enqueue (92) and dequeue (91) parts can be executed on independent parallel processors, because there is no possibility that any order of events or race conditions can ever allow two ECT(O) packets into the queue at the same time.
- the spacing between unmarked (ECT(O)) packets in the outgoing packet stream (112) represents the queue length at the instant the later ECT(O) packet arrived at the queue.
- the receiving node (18) must feed back to the sender (11) an encoding of how many of each type of ECN codepoint it has received in a data flow.
- the receiving node may determine this spacing itself, and continually derive the queue length. Then the receiving node may continually feed a value representing this queue length back to the sender, or the receiving node may even determine a new rate for the sender to use and feed a value representing this rate back to the sender. Nonetheless, it will be most straightforward for the receiver to simply reflect an encoding of the values of the ECN field that it receives, because this feedback is already provided by newer end-to- end transport protocols, and it is being added to older ones such as TCP.
- sender (11) is connected to the link between the CE router (13) and the (PE) router (14), other senders may also be connected to the CE router. Also, within sender (11), multiple independent processes may be sending data through this link. Therefore the packets in Figure 5 may be divided into subsets, each belonging to different data flows between different sending and receiving processes.
- the unqueuable ECN marking scheme signals the queue length into each of these independent data flows, so that it is not merely useful when one data flow is alone on the link.
- the average measurement becomes more precise the more packets there are in any one data flow, so that short flows receive a rough estimate of the queue length, while larger flows develop a more accurate view of the evolving queue length.
- This is sufficiently useful, because a short flow can do limited damage to other flows if its estimate of the queue length is too large or too small, whereas a larger flow has the potential to cause much more harm to other flows if its measurement of queue length is significantly incorrect.
- the queue of packets in Figure 5 is a constant standing queue of 10 packets, so that every tenth packet in the stream departing from the buffer carries the ECT(O) codepoint while the every other nine carry ECT(l).
- the stream of packets consists of two data flows, one that on average consumes 20% of the capacity of the link while the other consumes 80%. Assuming packets arrive randomly from each flow the first flow will pick up about 20% of the ECT(l) markings and 20% of the ECT(O) markings.
- the unqueuable ECN marking scheme does not directly enable any one data source to determine its own contribution to the queue length as distinct from the total queue length.
- inference techniques would be possible to estimate this. For instance, by varying its own data rate and correlating its variation with changes in the aggregate queue length, a sender could determine the proportion of the queue that it was responsible for.
- the unqueuable ECN marking scheme does not give end-systems the full picture of the combined queue from all traffic.
- This can be either a limitation or an advantage.
- the limitation is that the actual queue length including legacy traffic may be longer than the queue length reported by the unqueuable ECN marking scheme. Therefore the scheme cannot be used alone as the only congestion signalling mechanism; even sources that support it must also take note of pre-existing congestion signalling schemes, such as packet drop or the congestion experienced signals of the original ECN standard.
- Unqueuable ECN marking scheme is used in combination with the original ECN marking scheme.
- the original standard ECN approach involves a congested buffer marking a proportion of ECN-capable packets with the congestion experienced (CE) codepoint, instead of dropping them, which it would do if the same packets were not ECN-capable.
- the unqueuable ECN marking scheme and the original standard ECN approach [RFC3168] can both be deployed and simultaneously applied to the same ECN-capable packets.
- the unqueuable ECN algorithm it would be preferable for the unqueuable ECN algorithm to be executed after the original standard ECN marking algorithm, because the outcome of unqueuable ECN marking depends on the ECN codepoint in the incoming packet, whereas the original standard ECN marking does not. This ordering would ensure faster convergence on a precise value for the queue length between the signals.
- the signal will represent the average length of the queue of ECN packets without counting CE packets. Given, the proportion of CE-marked packets is typically small and nearly always very small, the error in estimated queue length will typically be very small too.
- the reasoning can be derived from the earlier reasoning about non-ECN-capable packets, because CE packets are also ignored by the unqueuable ECN marking algorithm.
- the original standard ECN scheme might well mark packets at a congested node later in the path, following a node earlier in the path that has marked them with the unqueuable ECN scheme. In such cases, the signal will still give the correct average queue length, it will just take longer to converge on the average.
- the reasoning can be derived from the earlier reasoning about multiple flows sharing a bottleneck. CE marking is applied randomly so it can be thought of as a separate randomly selected subset of packets that will have the same effect on the queue length signal as will separating out a flow of packets.
- the resulting signal will give an estimate of the length of the longest of the queues. If the longest queue is later in the path, this measurement will be rounded up to the next integer multiple of the queue length earlier in the path.
- the queue lengths will be variable rather than constant. Then the spacing between ECT(O) markings from the combined queues will vary and the average will be close to the results above.
- a sender node can use the feedback of the unqueuable ECN marking signals.
- the open-loop control phase of a flow e.g. at flow-start when the sender is trying to sense how rapidly it could send out packets, it can send out brief bursts of packets at the rate of its attached interface (usually much faster than a bottleneck later in the path). It will send all packets with the ECT(O) codepoint in the ECN field.
- the sender can infer that n > 2, n ⁇ 3 and n > V7, or 2.65 ⁇ M ⁇ 3.
- the sender could start releasing further packets while continually updating its best estimate of the available capacity.
- the sender's best estimate of n would be 2.5 (central between 2 and 3). It would therefore be able to start sending packets paced at about 1/2.5 of the rate at which it sent the first round of ten packets (the first round reference rate). Even just before the fourth ACK, the sender would know that n >2.
- packet sizes may be increased during each chirp. Changing the packet size also helps distinguish between different types of queues, namely if the queue is caused by inability to transmit bits fast enough or caused by inability to process headers fast enough.
- the inter-packet sending rate will probably be below the bottleneck capacity and not form any queue. Then as the packets get closer together, they will start to induce a queue, and the unqueuable ECN marking algorithm will signal the length of this queue by re-marking the requisite number of packets to ECT(l). When one chirp ends and the next starts, it will allow the queue to drain. Then part-way through the next chirp, the queue will start to build again. In this way, the sender can interrogate how much of a queue would build at a range of rates around the average rate/ in order to adapt its rate up to the currently available capacity of the bottleneck. This process is possible whether the sender's data flow is alone in the bottleneck, or competing with other flows.
- the sender should proceed cautiously if there are signs of a bottleneck that does not implement unqueuable ECN marking. It can test this by measuring the ACK-rate , that is, the rate at which acknowledgements are returned. Then it calculates a tentative rate that it will use based on unqueuable ECN markings. If the ACK-rate is significantly slower than this tentative rate, the sender should proceed cautiously (e.g. using the traditional TCP slow-start). If the ACK-rate and the tentative rate are approximately the same, the sender can assume that the rate it has tentatively inferred from unqueuable ECN marking is good to use.
- the invention may be used for estimating the queue length at a node or across a path through a network of nodes to solve problems other than that where a sender wishes to quickly adapt its sending rate to the available capacity. For instance:
- test probe may wish to send a minimal amount of test traffic to measure available
- Such a probe may be used:
- a network operator may wish to regularly monitor the length of queues in the network by passively measuring the spacing between ECT(O) markings in traffic passing a monitoring point, by selecting packets with source and destination addresses that indicate they have traversed a point of interest in the network, or a path of interest through multiple nodes.
- a network operator or an application may send a stream of packets to monitor the delay due to queuing on the path indicated by the delay between two ECT(O) markings.
- a network operator or an application may send a stream of packets to monitor the base delay along a path through the network by measuring the overall delay and subtracting the queuing delay.
- the one-way base delay could be measured by taking two packets that arrive at the receiver with ECT(0) markings and measuring the time between sending the second and receiving the first.
- the two-way base-delay could be measured similarly by echoing packets off an echo-server at the remote end of the network and adding together the oneway base delays in either direction, by monitoring the spacing between feedback of ECN markings in the forward direction and the spacing of ECN markings themselves in the reverse direction.
- the base delay could be measured by sending a stream of well-spaced-out packets and measuring the delay for those that return with a sequence of ECT(0) values that prove no queuing had been experienced.
- the enqueue process is a simple loop in which, as each packet (pkt) arrives, at stage (110) the wall- clock time on arrival is stored in a memory structure associated with the packet (pkt . tsi), where tsi stands for 'timestamp in', because this is equivalent to time-stamping the packet on arrival.
- Figure 10 shows the value of tsi stamped on each packet in the queue. For simplicity, all the packets that arrive within one timeslot (edged with thicker lines) are shown stamped with the same value, although in practice the granularity of timestamps may be finer. As time passes, these packets progress through the queue, which is depicted in Figure 10 as packets with the same timestamp progressing diagonally down and to the right. At stage (105) the other normal steps necessary to enqueue a packet are carried out.
- the packet at the head of the queue is checked to see if it carries the ECT(O) marking. If it does not, there is no need to determine whether it should be changed from ECT(O), so no further processing is necessary to complete the dequeuing process for that packet. But, if the packet carries the ECT(O) marking, it passes to stage (112).
- the timestamp associated with the packet when it arrived is compared with the stored time tO when the last ECT(O) marked packet departed. If the timestamp is no greater than to, it implies that this packet arrived at the queue before the last ECT(O) packet left the queue. Therefore, this packet should be re-marked to ECT(l) at stage (114) because it was added to the queue when there was already another ECT(O) packet in the queue. If, on the other hand, the timestamp is greater than to, it implies that this packet arrived after the last ECT(O) packet left the queue.
- a multibit field is defined in the packet header as a queue length field.
- an IPv6 extension header may be defined specifically for this purpose, or a sub-field of the packet identifier (ID) field in the IPv4 header may be reused in packets in which the ID field is not used for its original purpose because the 'do not fragment' (DNF) flag is set.
- ID packet identifier
- a buffer implementing a naive version of this embodiment would maintain the length of the queue (e.g. in bytes) as an internal variable then write the current value of this number as an integer into every packet able to carry such a value in this newly defined field.
- a more practical version of this embodiment would write a standardised encoding of the queue length into this field. For instance the base 2 log of the queue length in bytes may be used, or a number in a standardised floating point format. It may write the queue length on arrival or on departure.
- the buffer For packets arriving with a value other than zero already in this queue length counter field, the buffer would only overwrite the value with the length of its own queue if it was greater than the value already in the packet. In this way the scheme would signal the maximum queue on a path through the network.
- the advantage of this embodiment is that an encoding of the precise value of the instantaneous queue length is made available in every packet, whereas in the embodiments described previously, the queue length can only be known precisely on the occasions when a packet carrying ECT(O) is received.
- One disadvantage of this embodiment is that it requires a new field to be defined in IP (and in other lower layer protocols).
- Another disadvantage is that the unit in which queue length is measured is restricted to that defined for the scheme (bytes in the example), whereas in the embodiments described previously the queue length can be measured in units of bytes, packets or time by choosing in which units to measure the spacing between marked packets.
- Exemplary embodiments of the invention are realised, at least in part, by executable computer program code which may be embodied in application program data provided by program modules managing the buffers of respective routers, switches or other middleboxes in the network or in end- systems.
- executable computer program code When such computer program code is loaded into the memory of each router, switch, middlebox or end-system for execution by the respective processor, it provides a computer program code structure which is capable of performing the functions of the buffer in accordance with the above described exemplary embodiments of the invention.
- each step of the processes can correspond to at least one line of computer program code and that such, in combination with the processor in the respective router, switch, middlebox or end-system, provides apparatuses for effecting the described process.
- modules or part of the modules for effecting the described process can be implemented in hardware or a combination of hardware and software.
- the method for determining the buffer queue length of an intermediate node, and the modules needed therefore, can be implemented in the sender node, the receiver node, another intermediate node or partly in each.
- the receiving node could calculate the queue length and feed it back together with the sequence of tag values to the sender node where after the sender could perform a more detailed analysis of the tag value sequence such as determining the discrepancy between the packet sending rate and the rate of the buffer and adapting the packet sending rate to the rate of the buffer.
- a method and apparatus for changing a packet tag status value from a first value to a different value upon said packet arriving at a buffer if there already is a packet in the buffer queue having the same first status value A sequence of tag status values in packets received at an end node is used to determine the queue length of the buffer in the packet network. An end node can thereafter adapt its sending rate to the rate of the buffer.
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 (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
EP14716368.7A EP2979407B1 (en) | 2013-03-28 | 2014-03-27 | Re-marking of packets for queue control |
Applications Claiming Priority (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
EP20130250049 EP2784997A1 (en) | 2013-03-28 | 2013-03-28 | Re-marking of packets for congestion control |
GB201307077A GB201307077D0 (en) | 2013-04-18 | 2013-04-18 | Re-marking of packets for queue control |
PCT/GB2014/000121 WO2014155043A1 (en) | 2013-03-28 | 2014-03-27 | Re-marking of packets for queue control |
EP14716368.7A EP2979407B1 (en) | 2013-03-28 | 2014-03-27 | Re-marking of packets for queue control |
Publications (2)
Publication Number | Publication Date |
---|---|
EP2979407A1 true EP2979407A1 (en) | 2016-02-03 |
EP2979407B1 EP2979407B1 (en) | 2018-09-12 |
Family
ID=50473695
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
EP14716368.7A Active EP2979407B1 (en) | 2013-03-28 | 2014-03-27 | Re-marking of packets for queue control |
Country Status (4)
Country | Link |
---|---|
US (1) | US9985899B2 (en) |
EP (1) | EP2979407B1 (en) |
CN (1) | CN105075202B (en) |
WO (1) | WO2014155043A1 (en) |
Families Citing this family (19)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2014155043A1 (en) | 2013-03-28 | 2014-10-02 | British Telecommunications Public Limited Company | Re-marking of packets for queue control |
US9426418B2 (en) | 2014-07-29 | 2016-08-23 | Qualcomm Incorporated | Reducing delay in video telephony |
US9667722B2 (en) * | 2014-10-20 | 2017-05-30 | Arista Networks, Inc. | Method and system for non-tagged based latency calculation |
US9923836B1 (en) * | 2014-11-21 | 2018-03-20 | Sprint Spectrum L.P. | Systems and methods for configuring a delay based scheduler for an access node |
CN105744635B (en) * | 2014-12-12 | 2019-01-18 | 北京永安信通科技股份有限公司 | Based on the rear packet transmission scheduling method and apparatus to valve |
US9667560B2 (en) * | 2014-12-24 | 2017-05-30 | Nicira, Inc. | Flow sequencing |
CN105873224B (en) * | 2015-01-22 | 2019-04-02 | 北京永安信通科技股份有限公司 | The packet transmission scheduling method and apparatus compared based on interactive slope |
US10645013B2 (en) | 2015-04-02 | 2020-05-05 | Nicira, Inc | Data flow identifiers |
CN107852372B (en) | 2015-08-06 | 2021-05-11 | 英国电讯有限公司 | Data packet network |
US10645016B2 (en) | 2015-08-06 | 2020-05-05 | British Telecommunications Public Limited Company | Data packet network |
US10148582B2 (en) * | 2016-05-24 | 2018-12-04 | Samsung Electronics Co., Ltd. | Managing buffers for rate pacing |
US10986021B2 (en) * | 2018-03-06 | 2021-04-20 | International Business Machines Corporation | Flow management in networks |
US10673648B1 (en) * | 2018-07-06 | 2020-06-02 | Netronome Systems, Inc. | Network interface device that sets an ECN-CE bit in response to detecting congestion at an internal bus interface |
CN116418757A (en) * | 2018-12-12 | 2023-07-11 | 深圳市中兴微电子技术有限公司 | Congestion control method and device, network equipment and storage medium |
CN110098893B (en) * | 2018-12-21 | 2021-09-10 | 中南大学 | Differential explicit feedback transmission control method facing IPv6 |
US11502965B2 (en) * | 2020-09-09 | 2022-11-15 | Hewlett Packard Enterprise Development Lp | Burst packet preload for ABW estimation with rate limiters |
CN112059183A (en) * | 2020-09-14 | 2020-12-11 | 南京铁道职业技术学院 | Laser melting system and method thereof |
CN114338545A (en) * | 2020-09-30 | 2022-04-12 | 华为技术有限公司 | Traffic shaping method and device |
CN116170380B (en) * | 2023-04-21 | 2023-08-29 | 中国科学技术大学 | ECN marking strategy and queue management method and system based on congestion prediction |
Family Cites Families (52)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5426640A (en) | 1992-01-21 | 1995-06-20 | Codex Corporation | Rate-based adaptive congestion control system and method for integrated packet networks |
GB9520807D0 (en) | 1995-10-11 | 1995-12-13 | Newbridge Networks Corp | Fair queue servicing using dynamic weights |
EP0789076A3 (en) | 1996-02-07 | 1999-04-14 | Takeda Chemical Industries, Ltd. | G protein coupled receptor proteins, their production and use |
JP3123447B2 (en) | 1996-11-13 | 2001-01-09 | 日本電気株式会社 | Switch control circuit of ATM exchange |
US6128642A (en) | 1997-07-22 | 2000-10-03 | At&T Corporation | Load balancing based on queue length, in a network of processor stations |
US6646987B1 (en) | 1998-10-05 | 2003-11-11 | Nortel Networks Limited | Method and system for transmission control protocol (TCP) packet loss recovery over a wireless link |
US6215769B1 (en) | 1998-10-07 | 2001-04-10 | Nokia Telecommunications, Inc. | Enhanced acknowledgment pacing device and method for TCP connections |
US6252848B1 (en) | 1999-03-22 | 2001-06-26 | Pluris, Inc. | System performance in a data network through queue management based on ingress rate monitoring |
US6618378B1 (en) | 1999-07-21 | 2003-09-09 | Alcatel Canada Inc. | Method and apparatus for supporting multiple class of service connections in a communications network |
US6839321B1 (en) | 2000-07-18 | 2005-01-04 | Alcatel | Domain based congestion management |
US7266613B1 (en) | 2000-08-09 | 2007-09-04 | Microsoft Corporation | Fast dynamic measurement of bandwidth in a TCP network environment |
AU2001286447A1 (en) | 2000-08-11 | 2002-02-25 | The Regents Of The University Of California | Receiver-initiated multiple access for ad-hoc networks (rima) |
US7120159B2 (en) | 2000-10-30 | 2006-10-10 | Matsushita Electric Industrial Co., Ltd. | Apparatus and method for packet transmission |
US6836475B2 (en) | 2000-12-01 | 2004-12-28 | Nokia Corporation | Method and apparatus for traffic shaping for IP router queues/egress |
US20020078164A1 (en) | 2000-12-13 | 2002-06-20 | Marnetics Ltd. | System and method for data transfer acceleration in a TCP network environment |
GB2372172B (en) | 2001-05-31 | 2002-12-24 | Ericsson Telefon Ab L M | Congestion handling in a packet data network |
US6480500B1 (en) | 2001-06-18 | 2002-11-12 | Advanced Micro Devices, Inc. | Arrangement for creating multiple virtual queue pairs from a compressed queue pair based on shared attributes |
US6958998B2 (en) | 2001-07-09 | 2005-10-25 | International Business Machines Corporation | Traffic management in packet-based networks |
US7095750B2 (en) | 2001-08-16 | 2006-08-22 | International Business Machines Corporation | Apparatus and method for virtualizing a queue pair space to minimize time-wait impacts |
US7286483B2 (en) * | 2002-11-14 | 2007-10-23 | Intel Corporation | Electronic data transfer based on selective storage of incoming packets |
JP4049777B2 (en) | 2003-03-31 | 2008-02-20 | 富士通株式会社 | Communication apparatus and communication method |
US7324535B1 (en) | 2003-04-10 | 2008-01-29 | Cisco Technology, Inc. | Methods and apparatus for maintaining a queue |
US7372865B2 (en) * | 2003-07-09 | 2008-05-13 | Fujitsu Limited | Processing data packets using time stamped marker packets |
US20050190779A1 (en) | 2004-03-01 | 2005-09-01 | Cisco Technology, Inc., A California Corporation | Scalable approach to large scale queuing through dynamic resource allocation |
CN1327677C (en) | 2003-11-21 | 2007-07-18 | 清华大学 | ECN based congestion control method with prediction verification |
US7609640B2 (en) | 2003-12-19 | 2009-10-27 | Nokia Corporation | Methods and applications for avoiding slow-start restart in transmission control protocol network communications |
US7426181B1 (en) | 2004-03-26 | 2008-09-16 | Packeteer, Inc. | Slow-start adaptive mechanisms to improve efficiency of bandwidth allocation |
US7457296B2 (en) * | 2004-09-30 | 2008-11-25 | Intel Corporation | Method and apparatus for sorting packets in packet schedulers using a connected trie data structure |
US7339899B2 (en) | 2004-09-30 | 2008-03-04 | Microsoft Corporation | Method and system for network emulation using packet reorder emulation techniques |
KR100597425B1 (en) | 2005-02-16 | 2006-07-05 | 삼성전자주식회사 | Method for preventing unnecessary retransmission caused by transmission delay in wireless network and communication apparatus using the same |
US7680038B1 (en) | 2005-04-25 | 2010-03-16 | Electronic Arts, Inc. | Dynamic bandwidth detection and response for online games |
US7567508B2 (en) | 2005-05-23 | 2009-07-28 | Cisco Technology, Inc. | Method and system for providing delay bound and priortized packet dropping |
KR100739710B1 (en) | 2005-06-14 | 2007-07-13 | 삼성전자주식회사 | Method and apparatus for discriminating the type of packet loss |
US7831970B2 (en) | 2005-06-30 | 2010-11-09 | Avaya Inc. | Method and apparatus for scheduling periodic tasks based on synthetic homogenization |
US7606159B2 (en) * | 2005-08-30 | 2009-10-20 | Cisco Technology, Inc. | Method and apparatus for updating best path based on real-time congestion feedback |
US7961621B2 (en) | 2005-10-11 | 2011-06-14 | Cisco Technology, Inc. | Methods and devices for backward congestion notification |
CN101034346A (en) * | 2006-03-10 | 2007-09-12 | 北京佳讯飞鸿电气有限责任公司 | Date storage method for circulating queue |
US7733893B2 (en) | 2007-06-29 | 2010-06-08 | Global Ip Solutions (Gips) Ab | Method and receiver for determining a jitter buffer level |
US7843817B2 (en) | 2008-03-11 | 2010-11-30 | Cisco Technology, Inc. | Congestion control in wireless mesh networks |
EP2266254B1 (en) | 2008-03-26 | 2012-05-16 | Telefonaktiebolaget L M Ericsson (publ) | Available bandwidth estimation in a packet-switched communication network |
US8483701B2 (en) | 2009-04-28 | 2013-07-09 | Pine Valley Investments, Inc. | System and method for controlling congestion in cells within a cellular communication system |
EP2398194A1 (en) | 2010-06-17 | 2011-12-21 | British Telecommunications Public Limited Company | Monitoring path characterisation information |
US9178789B2 (en) | 2011-08-19 | 2015-11-03 | Futurewei Technologies, Inc. | System and method for transmission control protocol slow-start |
US9509805B2 (en) | 2011-12-01 | 2016-11-29 | Telefonaktiebolaget Lm Ericsson (Publ) | Reduction of packet header compression overhead due to high ECN rate |
US9699103B2 (en) | 2012-09-05 | 2017-07-04 | Flash Networks, Ltd | Method and system for flow controlling |
WO2014155043A1 (en) | 2013-03-28 | 2014-10-02 | British Telecommunications Public Limited Company | Re-marking of packets for queue control |
EP2784997A1 (en) | 2013-03-28 | 2014-10-01 | British Telecommunications public limited company | Re-marking of packets for congestion control |
GB201313760D0 (en) | 2013-07-31 | 2013-09-18 | British Telecomm | Fast friendly start for a data flow |
EP2869514A1 (en) | 2013-10-30 | 2015-05-06 | Alcatel Lucent | Method and system for queue management in a packet-switched network |
WO2015078492A1 (en) | 2013-11-27 | 2015-06-04 | Telefonaktiebolaget L M Ericsson (Publ) | Controlling a transmission control protocol window size |
CN107852372B (en) | 2015-08-06 | 2021-05-11 | 英国电讯有限公司 | Data packet network |
US10645016B2 (en) | 2015-08-06 | 2020-05-05 | British Telecommunications Public Limited Company | Data packet network |
-
2014
- 2014-03-27 WO PCT/GB2014/000121 patent/WO2014155043A1/en active Application Filing
- 2014-03-27 EP EP14716368.7A patent/EP2979407B1/en active Active
- 2014-03-27 US US14/780,685 patent/US9985899B2/en active Active
- 2014-03-27 CN CN201480018721.3A patent/CN105075202B/en active Active
Non-Patent Citations (2)
Title |
---|
None * |
See also references of WO2014155043A1 * |
Also Published As
Publication number | Publication date |
---|---|
WO2014155043A1 (en) | 2014-10-02 |
EP2979407B1 (en) | 2018-09-12 |
CN105075202B (en) | 2019-07-12 |
US20160057065A1 (en) | 2016-02-25 |
US9985899B2 (en) | 2018-05-29 |
CN105075202A (en) | 2015-11-18 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
EP2979407B1 (en) | Re-marking of packets for queue control | |
EP3120253B1 (en) | Flow aware buffer management for data center switches | |
US6535482B1 (en) | Congestion notification from router | |
US6625118B1 (en) | Receiver based congestion control | |
EP3028419B1 (en) | Fast friendly start for a data flow | |
EP2784997A1 (en) | Re-marking of packets for congestion control | |
US20020154602A1 (en) | Method for improving TCP performance over wireless links | |
CN107852371B (en) | Data packet network | |
WO2002087276A2 (en) | Method and device for robust real-time estimation of bottleneck bandwidth | |
AU2006336276A1 (en) | Efficient loss recovery architecture for loss-decoupled TCP | |
EP0955749A1 (en) | Receiver based congestion control and congestion notification from router | |
WO2014095927A1 (en) | Probing a network | |
CN107852372B (en) | Data packet network | |
US10063489B2 (en) | Buffer bloat control | |
Rüngeler et al. | Congestion and flow control in the context of the message-oriented protocol SCTP | |
Eshete et al. | On the flow fairness of aggregate queues | |
US20230353472A1 (en) | Method for verifying flow completion times in data centers | |
Zhang et al. | RETCP: A ratio estimation approach for data center incast applications | |
Lee et al. | A Novel Scheme for Improving the Fairness of Queue Management in Internet Congestion Control | |
JP2006186889A (en) | End-to-end quality estimation device and method | |
Zheng | Adaptive Explicit Congestion Notification (AECN) for Heterogeneous Flows | |
Magalhaes et al. | Improving Performance of Rate-Based Transport Protocols in Wireless Environments | |
Zou et al. | SF-SCTP: a new transport protocol to support QoS for FCS applications |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PUAI | Public reference made under article 153(3) epc to a published international application that has entered the european phase |
Free format text: ORIGINAL CODE: 0009012 |
|
17P | Request for examination filed |
Effective date: 20150914 |
|
AK | Designated contracting states |
Kind code of ref document: A1 Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR |
|
AX | Request for extension of the european patent |
Extension state: BA ME |
|
DAX | Request for extension of the european patent (deleted) | ||
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: EXAMINATION IS IN PROGRESS |
|
17Q | First examination report despatched |
Effective date: 20170330 |
|
RAP1 | Party data changed (applicant data changed or rights of an application transferred) |
Owner name: BRITISH TELECOMMUNICATIONS PUBLIC LIMITED COMPANY |
|
REG | Reference to a national code |
Ref country code: DE Ref legal event code: R079 Ref document number: 602014032223 Country of ref document: DE Free format text: PREVIOUS MAIN CLASS: H04L0012801000 Ipc: H04L0012825000 |
|
GRAP | Despatch of communication of intention to grant a patent |
Free format text: ORIGINAL CODE: EPIDOSNIGR1 |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: GRANT OF PATENT IS INTENDED |
|
RIC1 | Information provided on ipc code assigned before grant |
Ipc: H04L 12/825 20130101AFI20180416BHEP Ipc: H04L 12/875 20130101ALI20180416BHEP Ipc: H04L 12/833 20130101ALI20180416BHEP Ipc: H04L 12/863 20130101ALI20180416BHEP Ipc: H04L 12/835 20130101ALI20180416BHEP |
|
INTG | Intention to grant announced |
Effective date: 20180508 |
|
GRAS | Grant fee paid |
Free format text: ORIGINAL CODE: EPIDOSNIGR3 |
|
GRAA | (expected) grant |
Free format text: ORIGINAL CODE: 0009210 |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: THE PATENT HAS BEEN GRANTED |
|
AK | Designated contracting states |
Kind code of ref document: B1 Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR |
|
REG | Reference to a national code |
Ref country code: GB Ref legal event code: FG4D |
|
REG | Reference to a national code |
Ref country code: CH Ref legal event code: EP |
|
REG | Reference to a national code |
Ref country code: IE Ref legal event code: FG4D |
|
REG | Reference to a national code |
Ref country code: DE Ref legal event code: R096 Ref document number: 602014032223 Country of ref document: DE |
|
REG | Reference to a national code |
Ref country code: AT Ref legal event code: REF Ref document number: 1041899 Country of ref document: AT Kind code of ref document: T Effective date: 20181015 |
|
REG | Reference to a national code |
Ref country code: NL Ref legal event code: MP Effective date: 20180912 |
|
REG | Reference to a national code |
Ref country code: LT Ref legal event code: MG4D |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: FI Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20180912 Ref country code: BG Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20181212 Ref country code: GR Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20181213 Ref country code: NO Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20181212 Ref country code: SE Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20180912 Ref country code: RS Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20180912 Ref country code: LT Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20180912 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: AL Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20180912 Ref country code: LV Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20180912 Ref country code: HR Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20180912 |
|
REG | Reference to a national code |
Ref country code: AT Ref legal event code: MK05 Ref document number: 1041899 Country of ref document: AT Kind code of ref document: T Effective date: 20180912 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: ES Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20180912 Ref country code: PL Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20180912 Ref country code: IS Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20190112 Ref country code: CZ Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20180912 Ref country code: AT Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20180912 Ref country code: IT Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20180912 Ref country code: RO Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20180912 Ref country code: NL Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20180912 Ref country code: EE Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20180912 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: SM Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20180912 Ref country code: PT Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20190112 Ref country code: SK Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20180912 |
|
REG | Reference to a national code |
Ref country code: DE Ref legal event code: R097 Ref document number: 602014032223 Country of ref document: DE |
|
PLBE | No opposition filed within time limit |
Free format text: ORIGINAL CODE: 0009261 |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: NO OPPOSITION FILED WITHIN TIME LIMIT |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: DK Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20180912 |
|
26N | No opposition filed |
Effective date: 20190613 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: SI Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20180912 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: MC Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20180912 |
|
REG | Reference to a national code |
Ref country code: CH Ref legal event code: PL |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: LU Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES Effective date: 20190327 |
|
REG | Reference to a national code |
Ref country code: BE Ref legal event code: MM Effective date: 20190331 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: LI Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES Effective date: 20190331 Ref country code: IE Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES Effective date: 20190327 Ref country code: CH Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES Effective date: 20190331 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: BE Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES Effective date: 20190331 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: TR Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20180912 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: MT Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES Effective date: 20190327 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: CY Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20180912 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: HU Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT; INVALID AB INITIO Effective date: 20140327 |
|
REG | Reference to a national code |
Ref country code: DE Ref legal event code: R079 Ref document number: 602014032223 Country of ref document: DE Free format text: PREVIOUS MAIN CLASS: H04L0012825000 Ipc: H04L0047263000 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: MK Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20180912 |
|
P01 | Opt-out of the competence of the unified patent court (upc) registered |
Effective date: 20230623 |
|
PGFP | Annual fee paid to national office [announced via postgrant information from national office to epo] |
Ref country code: DE Payment date: 20240220 Year of fee payment: 11 Ref country code: GB Payment date: 20240220 Year of fee payment: 11 |
|
PGFP | Annual fee paid to national office [announced via postgrant information from national office to epo] |
Ref country code: FR Payment date: 20240220 Year of fee payment: 11 |