Patent ID: 12206591

DETAILED DESCRIPTION OF EMBODIMENT(S)

FIG.1shows an example traffic flow of data packets in selected components of a communication network100. A traffic flow can be understood as a collection of data packets111,123,125,126,128that are sent from a sender110, i.e. a source node, to a receiver130, i.e. a destination node. The communication network100can include one or more senders110that transmit data as packets111,123,125,126,128to a destination node, i.e. receiver130. The data packets111,123,125,126,128can comprise information such as, for example, emails, voice calls, or streaming video. The sender110can for example, amongst others, be a server or router device. The receiver130can for example be a laptop, a smartphone, a tablet, or any other destination node in a communication network known to the skilled person. The packets111,123,125,126,128travel through one or more intermediate network nodes such as network communication node120. Network communication node120receives the transmitted packets111and forwards the packets128on the next leg of their journey, i.e. towards the intended receiver130.

The network communication node120can for example, amongst others, be a router or a switch that has input and output ports coupled to a physical transmission medium, e.g. an optical fibre, a coax cable, a copper wire, or an air interface. The network communication node120can further comprise one or more network queues122for enqueuing124and dequeuing127packets123,128at the ports to control the reception and transmission of packets123,128on an established communication link.

The communication network100can experience data traffic congestion when the rate of sent packets111, i.e. the amount of packets111sent by sender110in a certain time interval, exceed what the network communication node120can handle. This results in a build-up of excess packets125in the network communication node120as packets have to wait in the network queue122before being forwarded to the receiver130. Therefore, the network communication node120can be configured to manage or control data traffic congestion in the communications network100, typically referred to as active queue management, AQM.

To this end, an AQM module121in the network communication node120selectively drops or marks packets111,123,125,126,128under certain conditions to control congestion. In particular, the AQM module121can apply marks to packets when congestion is detected and/or predicted, i.e. when queue122is overflowing or is about to overflow and, thus, that the excess packets125are experiencing or about to experience excessive queueing delays. The receivers130can be configured to reflect these applied marks, i.e. congestion signals, back to the respective sender110of the packet. Based on the received marks, a congestion control algorithm can then adjust the packet transmission rate of the sender110to avoid congestion and the resulting network issues such as, for example, packet loss, retransmission, high latency, and/or jitter.

Traditional congestion control algorithms, also referred to as classic or unscalable congestion control, apply a multiplicative reduction of the packet transmission rate for every marked packet that is reflected to the sender110, e.g. halve the transmission rate for every marked packet. By this multiplicative reduction, the utilization and queueing delay in the network queue will vary substantially when traffic flow rates increase. Unscalable congestion control algorithms can include, for example, Tahoe, Reno, New Reno, Vegas, Hybla, binary increase congestion control, BIC, CUBIC, bottleneck bandwidth and round-trip propagation time, BBR, or any other unscalable congestion control algorithm known to the skilled person. Packets sent according to a protocol that supports unscalable congestion control, e.g. transmission control protocol, TCP, can be referred to as unscalable packets.

Scalable congestion control algorithms apply a reduction of the packet transmission rate proportionally to the amount of reflected marked packets. In scalable congestion control, the average time from one congestion signal to the next, i.e. the recovery time, remains invariant as the flow rate scales. As scalable congestion control allows senders110to closely track the link capacity of the network communication node and reduce the queuing delay, low latency communication with limited jitter can be achieved. Scalable congestion control can include, amongst others, BBRv2, Prague, and SCReaM. Packets sent according to a protocol that supports scalable congestion control, e.g. data centre transmission control protocol, DCTCP, or QUIC, can be referred to as scalable packets.

Because of the difference in packet transmission rate adjustment at the sender110, the unscalable packets and the scalable packets require a different marking strategy, i.e. a different marking density. As unscalable and scalable packets coexist in communication networks100, it can be desirable to provide network communication node120with an AQM that is compatible with both packet types.

FIG.2shows steps200according to an example embodiment for managing data traffic congestion in the network communication node ofFIG.1that is compatible with scalable packets and unscalable packets.

In a first step201, a packet210processed by the network queue is classified as a scalable packet or as an other packet. A processed packet can refer to a packet231that is received by the network communication node but not yet enqueued in the network queue122, e.g. before packet segmentation. Alternatively, a processed packet can also refer to a packet232that is dequeued from the network queue but not yet transmitted or forwarded to the respective receiver, e.g. before packet serialization. Network queue122may further be a real network queue or a virtual network queue.

The classifying in step201is based on an identifier212that is included in the processed packet210in addition to data211, e.g. a message, a document, or a video stream. The identifier212can, for example, be added to the packet by the sender or by the congestion control algorithm of the sender. The identifier212can be included in an explicit congestion notification, ECN, field of an internet protocol, IP, header of the packet210. Such an identifier212in the ECN field can have a distinct value, e.g. predetermined bits, to indicate a scalable packet, an other packet supporting unscalable congestion control, or an other packet not supporting unscalable congestion control. For example, the ECN field can contain identifier bits0b01to indicate a scalable packet,0b10to indicate an other packet supporting unscalable congestion control, and0b00to indicate an other packet not supporting unscalable congestion control.

In a second step202, a marking probability223is maintained based on a marking ratio. The marking probability allows to determine whether an other packet should be used to signal data traffic congestion, i.e. if the packet should be marked. The marking ratio is derived as the ratio between the change in packets responsible for congestion Δpacketscongestion221and the change in total number of packets processed by the network queue Δpacketsprocessed222, i.e.

ΔpacketscongestionΔpacketsprocessed.

The change in total number of packets processed by the network queue Δpacketsprocessed222can for example be tracked by updating a counter when a packet231is enqueued241in the network queue122or dequeued242from the network queue122. The change in packets responsible for congestion Δpacketscongestion221can for example be tracked by updating a counter when a packet233is identified as responsible for congestion in the network queue122. A packet responsible for congestion233can refer to a packet that causes a congestion parameter, e.g. the queuing delay238or the queue size237, to exceed a threshold235,236.

According to an example embodiment, identifying packets230as responsible for congestion in the network queue can be performed before enqueuing241the packet in the network queue122. As such, packets can be identified as responsible for congestion when a size237of the network queue exceeds a size threshold235. For example, the build-up of excess packets233in the network queue122can be identified as packets responsible for congestion. The size threshold235represents a maximum allowable size of the network queue, i.e. a maximum amount of packets234or a maximum amount of data that can be present in the queue without resulting in congestion. The size threshold235can for example be 1500 B at a bit rate of 12 Mbps. A packet231received by the network communication node can thus be identified as responsible for congestion when enqueuing241that packet results in a queue size237that exceeds the size threshold235. This allows implementation in network communication nodes that aggregate the received packets231upon enqueuing241, or in network communication nodes with an inaccessible network queue122, e.g. a queue that resides in an inaccessible circuitry such as a closed or protected system on chip, SOC.

According to an alternative example embodiment, identifying packets230as responsible for congestion in the network queue can be performed upon dequeuing242the packet231from the network queue122. As such, a packet can be identified as responsible for congestion when a sojourn time238exceeds a time threshold236. For example, the build-up of excess packets233in the network queue122can be identified as packets responsible for congestion. The sojourn time238of a packet231is indicative of the time needed for the packet to travel through the network queue122, i.e. the difference between the enqueue time239and the dequeue time240of the packet231. This difference, i.e. the sojourn time238, can for example be measured upon dequeuing242the packet231. The time threshold236represents a maximum allowable sojourn time of a packet without resulting in congestion of the network queue122. The time threshold236can for example be 1 ms. A packet forwarded or outputted by the network communication node can thus be identified as responsible for congestion when the sojourn time238of the packet231exceeds the time threshold236upon dequeuing242the packet. This allows to implement the method in software applications, e.g. in a queuing discipline, qdisc, of a Linux network interface. This has the further advantage that the method can be independent of the rate at which packets are received by the network communication node, i.e. the serving rate, and/or variations in the serving rate.

It will be apparent that the congestion parameter in the example embodiments described above is interchangeable as the sojourn time238can be converted to a queue size237, and vice-versa, based on the bit rate of the network communication node. In other words, packets responsible for congestion233can also be identified based on the sojourn time238before enqueuing241the packet, and packets responsible for congestion233can also be identified based on the queue size237upon dequeuing242the packet. It will further be apparent that the maintaining of the marking probability223in step202and the identifying230of packets responsible for congestion in the network queue can be performed substantially before the classifying in step201, substantially after the classifying in step201, or substantially simultaneous with the classifying in step201, i.e. in parallel.

The marking probability223can be based on a moving average of the marking ratio. The moving average can for example, amongst others, be a simple moving average, a cumulative average, a weighted moving average, an exponential moving average, or any other moving average known to the skilled person. Such a moving average of the marking ratio at step i may, for example, be determined as

Si=ewma⁡(Si-1,ΔpacketscongestionΔpacketsprocessed)(1)
wherein Si-1represents the moving average of the marking ratio at a previous step i−1 and

ewma⁡(Si-1,ΔpacketscongestionΔpacketsprocessed)
represents the exponentially weighted moving average determined by, for example:

ewma⁢(Si-1,ΔpacketscongestionΔpacketsprocessed)=α*ΔpacketscongestionΔpacketsprocessed+(1-α)*Si-1(2)
wherein α is a weight factor between zero and one.

The marking probability223can, for example, be a value between zero and one. Preferably, the maintaining of the marking probability can be performed at a predetermined time interval, e.g. every 30 ms, or at a predetermined change in the total number of packets222processed by the network queue, e.g. every 30 packets at a bit rate of 12 Mbps. In other words, the marking probability223is based on the change in packets responsible for congestion221and the change in the total number of packets processed by the network queue222during a predetermined interval. This allows to periodically derive or update the marking probability223rather than for every packet processed by the queue. This has the further advantage that it can limit the execution time and the consumed processing power of the method. The marking probability can, for example, be determined as

Pi(M)=(Si2)2(3)
wherein Pi(M) and Sirepresent the current marking probability and the moving average of the marking ratio at step i, respectively.

In a following step203, the classified packets are marked with a congestion mark213to signal congestion to the respective senders. Packets classified as scalable packets are marked with the congestion mark213when identified230as responsible for congestion. Packets classified as other packets are marked with the congestion mark213based on the marking probability223if they support unscalable congestion control. In other words, other packets that do not support unscalable congestion control may not be marked. Other packets can, for example, be marked when the marking probability Pi(M)223is equal to, or larger than a random value, e.g. when Pi(M)≥r and(0,1). In doing so, senders that implement an unscalable congestion control algorithm receive a smoothed congestion signal, i.e. a frequency of reflected marked packets214, compatible with their packet transmission rate adjustment mechanism.

This smoothed congestion signal for unscalable congestion control is thus coupled to the congestion signal for scalable congestion control by the marking probability223, which is based on the marking ratio. This marking ratio is indicative of the marking density that would be applied to packets in a scalable traffic queue reserved for scalable packets, i.e. a queue without other packets. In other words, the marking density that is applied to scalable packets for scalable congestion control is converted or translated to a marking density for unscalable congestion control that is applied to the other traffic. By this coupling of the respective marking densities for scalable packets and other packets, fairness can be achieved in the single queue122, i.e. network resources can be fairly distributed between the scalable packets and other packets in a shared queue.

Marking a packet can comprise adding the congestion mark213to the packet. Alternatively, marking a packet can comprise overwriting or adjusting the identifier212included in the packet210. According to an embodiment, the marking can preferably comprise overwriting an identifier212included in the explicit congestion notification, ECN, field of an internet protocol, IP, header of the packet210with the congestion mark213. In other words, the value or bits included in the ECN field of the IP header can be switched or adjusted to a predetermined value, e.g. to0b11, to mark the packet210with the congestion mark213.

A packet210received by a network communication node can further already include a congestion mark that was applied by the AQM-module of a preceding network communication node. For example, the ECN field of a received packet can already contain the congestion mark0b11. As this prevents the classifying of the packet as scalable or as an other packet, such a packet can preferably be treated as a scalable packet.

By the marking in step203, the scalable and unscalable congestion controls in different senders can closely track the capacity of the network communication node. This allows to maintain a low queue size237, and thus, a low queuing delay238regardless of the packet type, i.e. scalable packets or unscalable packets. The marking density for packets in the network queue122are thus directly determined by identifying or tracking packets responsible for congestion in the network queue, i.e. by leveraging a threshold-based mechanism. This allows to determine the marking densities without substantial convergence time, e.g. compared to a proportional integral, PI, control loop.

It is an advantage that the marking can reduce jitter and that starvation of the network queue122can be avoided. It is a further advantage that a network queue122can be shared between scalable traffic and other traffic without affecting latency, allowing other traffic to benefit from the low latency communication provided by scalable traffic queues without latency penalties. An example of such a scalable traffic queue can be a queue according to the low latency, low loss, scalable throughput, L4S, framework of the Internet Engineering Task Force, IETF.

It is a further advantage that the method is compatible with existing transport protocols that support scalable congestion control, e.g. data centre transmission control protocol, DCTCP, or QUIC, and existing transport protocols that support unscalable congestion control, e.g. transmission control protocol, TCP. It is a further advantage that the method is compatible with existing scalable congestion controls, e.g. BBRv2, Prague, SCReAM, and unscalable congestion controls, e.g. New Reno and CUBIC.

FIG.3Ashows steps300according to an example embodiment wherein the steps of the method are performed upon dequeuing301a packet210from the network queue122. Upon dequeuing301the packet210, the change in total number of packets processed by the network queue Δpacketsprocessed302can be updated, e.g. by incrementing a counter by one. In a following step303, the dequeued packet210can be identified as responsible for congestion if the sojourn time Δtpacketof the packet210exceeds the time threshold Thtime. If this is the case, the change in packets responsible for congestion Δpacketscongestioncan be updated304, e.g. by incrementing a counter by one. Else, the method can continue to step305without updating Δpacketscongestion. In step305, the marking probability306can be maintained or updated as described in relation toFIG.2above.

The dequeued packet210can further be classified as a scalable packet311or an other packet312in step310. The classifying can be performed as described in relation toFIG.2above. The classifying in step310can be performed substantially after or substantially simultaneous with the identifying of packets responsible for congestion in step303and the maintaining of the marking probability in step305.

In a following step320, scalable packets311can be identified as responsible for congestion in the network queue122if the sojourn time Δtpacketof the packet210exceeds the time threshold Thtime. If this is the case, the scalable packet311is marked in step330, e.g. by overwriting identifier212with the congestion mark332. Else, the packet210is outputted in step380without marking it. Alternatively, in step320, scalable packets311can be identified as responsible for congestion in the network queue122based on a first time threshold Tht1and a second time threshold Tht2, wherein the second may be substantially larger than the first, i.e. Tht1<Tht2. For example, scalable packets311with a sojourn time Δtpacketsubstantially smaller than the first time threshold, i.e. Δtpacket<Tht1, may not be identified as responsible for congestion; packets with a sojourn time that exceeds the second time threshold, i.e. Tht2<Δtpacket, may always be identified as responsible for congestion; and packets with a sojourn time between the first time threshold and the second time threshold, i.e. Tht1≤Δtpacket≤Tht2, may be identified as responsible for congestion according to a probability function based on the actual sojourn time of the packet, e.g. a progressive probability to identify the packet as responsible for congestion between the first Tht1and second Tht2time threshold.

When the packet210is classified as an other packet312, the maintained or updated marking probability306is used to determine whether the packet210is eligible for marking. If, in step307, the marking probability306is larger or equal to a random value, e.g. between zero and one, the packet210is eligible for marking and the method proceeds to step350. Else, the packet210is outputted in step380without marking it.

The other packet312can be marked in step330when the other packet eligible for marking supports unscalable congestion control. This can, for example, be determined in step350based on the identifier212included in the packet210. Unscalable congestion control can, for example, not be supported when the sender of the packet210is not provided with a congestion control algorithm, or when the traffic transport protocol of the packet210does not support marking the packet with the congestion mark332. If the packet eligible for marking in step350does not support unscalable congestion control, the other packet312can be dropped in step360. Dropping a packet refers to substantially removing or discarding the packet from memory. This results in packet loss as the packet is not outputted, i.e. forwarded or transmitted, by the network communication node. This allows to manage the congestion in the network queue122in the presence of other packets312that do not support congestion control. It is a further advantage that futile marking of packets that do not support scalable congestion control can be avoided.

It will further be apparent that identifying a packet as responsible for congestion in the network queue in steps303and320can be performed only once. In a final step380, the marked scalable or other packet331can be forwarded or outputted by the network communication node.

FIG.3Bshows additional steps340,370according to a further example embodiment wherein the steps300of the method are performed upon dequeuing301a packet210from the network queue122.

If the marking probability306is larger or equal than a random value in step307, the other packet312can further be identified as responsible for congestion in the network queue122. This can be achieved by comparing the sojourn time Δtpacketof the packet210with the time threshold Thtimein additional step340. If the packet is identified as responsible for congestion, the method proceeds to step350and continues as described above in relation toFIG.3A. Else, the method proceeds to additional step370. Alternatively, step370can be skipped and the method proceeds directly to step380.

In step370, the sojourn time Δtpacketof a packet can further be compared to a first drop threshold Thdrop. The packet can be a marked packet331originating from step330, or an unmarked packet originating from step320,330, or340. Drop threshold Thdropcan preferably be substantially larger than the time threshold Thtime, e.g. a drop threshold of 1.5 ms when the time threshold is 1 ms. If the sojourn time Δtpacketof the packet exceeds the first drop threshold Thdrop, the packet can be dropped in step360. In other words, additional step370provides an overload protection to the network queue122. This can make the network queue122more resilient against sudden changes in queuing delay, e.g. due to a plurality of traffic flows starting up, unresponsive traffic flows, or a sudden burst of packets. It will be apparent that additional step370need not be performed at the end of the method, step370can for example also be performed before step310.

FIG.4Ashows steps400according to an example embodiment wherein the steps of the method are performed before enqueuing401a packet210received by a network communication node in the network queue122. Before enqueuing401the packet210, e.g. before segmentation, the change in total number of packets processed by the network queue Δpacketsprocessed302can be updated, e.g. by incrementing a counter by one. In a following step403the received packet210can be identified as responsible for congestion if enqueuing401packet210results in a queue size Qsizeof the network queue122that exceeds the size threshold Thsize. If this is the case, the change in packets responsible for congestion Δpacketscongestioncan be updated304, e.g. by incrementing a counter by one. Else, the method can continue to step305without updating Δpacketscongestion. In step305, the marking probability306can be maintained or updated as described in relation toFIG.2above.

The received packet210can further be classified as a scalable packet311or an other packet312in step310. The classifying can be performed as discussed in relation toFIG.2above. The classifying in step310can be performed substantially after or substantially simultaneous with identifying packets responsible for congestion in step303and maintaining of the marking probability in step305.

In a following step420, a scalable packet311can be identified as responsible for congestion in the network queue122when enqueuing401packet210results in a queue size Qsizeof the network queue122that exceeds the size threshold Thsize. If this is the case, the scalable packet311is marked in step330, e.g. by overwriting identifier212with the congestion mark332. Alternatively, in step420, scalable packets311can be identified as responsible for congestion in the network queue122based on a first size threshold Ths1and a second size threshold Ths2, wherein the second may be substantially larger than the first, i.e. Ths1<Ths2. For example, if the queue size Qsizeis substantially smaller than the first size threshold, i.e. Qsize<Ths1, the scalable packet311may not be identified as responsible for congestion; if the queue size Qsizeexceeds the second size threshold, i.e. Ths2<Qsize, the scalable packet311may always be identified as responsible for congestion; and if the queue size Qsizeis between the first size threshold and the second size threshold, i.e. Ths1≤Qsize≤Ths2, the scalable packet311may be identified as responsible for congestion according to a probability function based on the actual queue size Qsize, e.g. a progressive probability to identify the packet as responsible for congestion between the first Ths1and second Ths2time threshold.

When the packet210is classified as an other packet312, the maintained or updated marking probability306is used to determine whether the packet210is eligible for marking. If, in step307, the marking probability306is larger or equal to a random value, e.g. between zero and one, the packet210is eligible for marking and the method proceeds to step350. Else, the packet210is enqueued401without marking it.

The other packet312can be marked in step330when the other packet eligible for marking supports unscalable congestion control. This can, for example, be determined in step350based on the identifier212included in the packet210. Unscalable congestion control can, for example, not be supported when the sender of the packet210is not provided with a congestion control algorithm, or when the traffic transport protocol of the packet210does not support marking the packet with the congestion mark332. If the packet eligible for marking in step350does not support unscalable congestion control, the other packet312can be dropped in step360. Dropping a packet refers to substantially removing or discarding the packet from memory. This results in packet loss as the packet is not enqueued in the network queue122. This allows to manage the congestion in the network queue122in the presence of other packets312that do not support congestion control. It is a further advantage that futile marking of packets that do not support scalable congestion control can be avoided.

It will further be apparent that identifying a packet as responsible for congestion in the network queue in steps403and420can be performed only once. In a final step, the marked packet331can be enqueued401in network queue122of the network communication node i.e. added to network queue122.

FIG.4Bshows additional steps440,470according to a further example embodiment wherein the steps400of the method are performed before enqueuing401a packet210in the network queue122.

If the marking probability306is equal to or larger than a random value in step307, the other packet312can further be identified as responsible for congestion in the network queue122. This can be achieved by comparing the queue size Qsizeof the network queue122with the size threshold Thsizein additional step440. If the packet is identified as responsible for congestion, the method proceeds to step350and continues as described above in relation toFIG.4A. Else, the method proceeds to additional step470. Alternatively, step470can be skipped and the method proceeds by enqueuing401the packet.

In step470, the queue size Qsizeof the network queue122can further be compared to a second drop threshold Thdrop. The packet can be a marked packet331originating from step330, or an unmarked packet originating from step320,330, or340. Drop threshold Thdropcan preferably be substantially larger than the size threshold Thsize, e.g. a drop threshold of 2.25 MB when the size threshold is 1.5 MB. If the queue size Qsizeof the network queue122exceeds the second drop threshold Thdrop, the packet can be dropped in step360. In other words, additional step470provides an overload protection to the network queue122. This can make the network queue122more resilient against sudden changes in queuing delay, e.g. due to a plurality of traffic flows starting up, unresponsive traffic flows, or a sudden burst of packets. It will be apparent that additional step470need not be performed at the end of the method, step470can for example also be performed before step310.

FIG.5shows steps500according to an example embodiment wherein a portion of the steps of the method are performed before enqueuing401a received packet210, and another portion of the steps are performed upon dequeuing301the packet210.

In a first step310, a packet210received by the network communication node can be classified as a scalable packet311or an other packet312. All scalable packets311are flagged for marking in step501. Other packets312are flagged for marking in step501according to the maintained marking probability306, i.e. if the marking probability306is larger than or equal to a random value in step502. Flagging a packet for marking can, for example, include adding an identifier, stamp, or flag to the packet210. Hereafter, the flagged packets504and unflagged packets503are enqueued in the network queue122.

Upon dequeuing301the packets503,504, the change in total number of packets processed by the network queue Δpacketsprocessed302can be updated, e.g. by incrementing a counter by one. In a following step303, the dequeued packet can be identified as responsible for congestion. If this is the case, the change in packets responsible for congestion Δpacketscongestioncan be updated304, e.g. by incrementing a counter by one. Else, the method can continue to step305without updating Δpacketscongestion. In step305, the marking probability306can be maintained or updated as described in relation toFIG.2above.

In an optional step370, the sojourn time Δtpacketof a packet can further be compared to a first drop threshold Thdrop. If the sojourn time Δtpacketof the packet exceeds the first drop threshold Thdrop, the packet can be dropped in step360. It will be apparent that optional step370need not be performed directly after dequeuing301, step370can for example also be performed after step505or step350.

In a following step505, the packet can be checked for the presence of the flag in addition to identifying whether the packet is responsible for congestion. If this is not the case, the packet can be outputted or transmitted by the network communication node in step380. Else, the method proceeds to step350wherein it is checked if the packet eligible for marking supports congestion control. If so, the packet can be marked in step330and subsequently outputted in step380. If the packet does not support congestion control, the packet can be dropped in step360.

This allows to reduce the number of performed operations, the execution time, and the consumed processing power of the method in the dequeue pipeline of a network communication node. This further allows to implement the method in network communication nodes with a high throughput, i.e. bit rate, or low serialization time per packet, i.e. with a limited available time budget in the dequeue pipeline for marking.

It will be apparent that, while steps303,370, and505inFIG.5illustrates a time-based threshold and congestion parameter as in the embodiment illustrated inFIGS.3A and3B, a size-based threshold and congestion parameter as illustrated in the embodiments ofFIGS.4A and4Bcan also be used.

FIG.6shows a suitable computing system600enabling to implement embodiments of the method for managing data traffic congestion in a network communication node. Computing system600may in general be formed as a suitable general-purpose computer and comprise a bus610, a processor602, a local memory604, one or more optional input interfaces614, one or more optional output interfaces616, a communication interface612, a storage element interface606, and one or more storage elements608. Bus610may comprise one or more conductors that permit communication among the components of the computing system600. Processor602may include any type of conventional processor or microprocessor that interprets and executes programming instructions. Local memory604may include a random-access memory (RAM) or another type of dynamic storage device that stores information and instructions for execution by processor602and/or a read only memory (ROM) or another type of static storage device that stores static information and instructions for use by processor602. Input interface614may comprise one or more conventional mechanisms that permit an operator or user to input information to the computing device600, such as a keyboard620, a mouse630, a pen, voice recognition and/or biometric mechanisms, a camera, etc. Output interface616may comprise one or more conventional mechanisms that output information to the operator or user, such as a display640, etc. Communication interface612may comprise any transceiver-like mechanism such as for example one or more Ethernet interfaces that enables computing system600to communicate with other devices and/or systems, for example with one or more source nodes, i.e. senders110of data packets, and with one or more destination nodes, i.e. receivers130of the data packets. The communication interface612of computing system600may be connected to such a source node or destination node by means of a local area network (LAN) or a wide area network (WAN) such as for example the internet. Storage element interface606may comprise a storage interface such as for example a Serial Advanced Technology Attachment (SATA) interface or a Small Computer System Interface (SCSI) for connecting bus610to one or more storage elements608, such as one or more local disks, for example SATA disk drives, and control the reading and writing of data to and/or from these storage elements608. Although the storage element(s)608above is/are described as a local disk, in general any other suitable computer-readable media such as a removable magnetic disk, optical storage media such as a CD or DVD, ROM, disk, solid state drives, flash memory cards, etc. could be used. Computing system600could thus correspond to the network communication node120as illustrated inFIG.1.

Although the present invention has been illustrated by reference to specific embodiments, it will be apparent to those skilled in the art that the invention is not limited to the details of the foregoing illustrative embodiments, and that the present invention may be embodied with various changes and modifications without departing from the scope thereof. The present embodiments are therefore to be considered in all respects as illustrative and not restrictive, the scope of the invention being indicated by the appended claims rather than by the foregoing description, and all changes which come within the scope of the claims are therefore intended to be embraced therein.

It will furthermore be understood by the reader of this patent application that the words “comprising” or “comprise” do not exclude other elements or steps, that the words “a” or “an” do not exclude a plurality, and that a single element, such as a computer system, a processor, or another integrated unit may fulfil the functions of several means recited in the claims. Any reference signs in the claims shall not be construed as limiting the respective claims concerned. The terms “first”, “second”, third”, “a”, “b”, “c”, and the like, when used in the description or in the claims are introduced to distinguish between similar elements or steps and are not necessarily describing a sequential or chronological order. Similarly, the terms “top”, “bottom”, “over”, “under”, and the like are introduced for descriptive purposes and not necessarily to denote relative positions. It is to be understood that the terms so used are interchangeable under appropriate circumstances and embodiments of the invention are capable of operating according to the present invention in other sequences, or in orientations different from the one(s) described or illustrated above.

As used in this application, the term “circuitry” may refer to one or more or all of the following: (a) hardware-only circuit implementations (such as implementations in only analogue and/or digital circuitry) and (b) combinations of hardware circuits and software, such as (as applicable): (i) a combination of analogue and/or digital hardware circuit(s) with software/firmware and (ii) any portions of hardware processor(s) with software (including digital signal processor(s)), software, and memory(ies) that work together to cause an apparatus to perform various functions) and (c) hardware circuit(s) and or processor(s), such as a microprocessor(s) or a portion of a microprocessor(s), that requires software (e.g., firmware) for operation, but the software may not be present when it is not needed for operation. This definition of circuitry applies to all uses of this term in this application, including in any claims. As a further example, as used in this application, the term circuitry also covers an implementation of merely a hardware circuit or processor (or multiple processors) or portion of a hardware circuit or processor and its (or their) accompanying software and/or firmware.