1111111111111111 IIIIII IIIII 11111 1111111111 1111111111 111111111111111 IIIII IIIIII IIII 11111111
`US 20070133419Al
`
`c19) United States
`c12) Patent Application Publication
`Segel
`
`c10) Pub. No.: US 2007/0133419 Al
`Jun. 14, 2007
`(43) Pub. Date:
`
`(54) COMMUNICATION TRAFFIC CONGESTION
`MANAGEMENT SYSTEMS AND METHODS
`
`(75)
`
`Inventor: Jonathan Dean Segel, Ottawa (CA)
`
`Correspondence Address:
`Arnold B. Silverman
`Eckert Seamans Cherin & Mellott, LLC
`44th Floor
`600 Grant Street
`Pittsburgh, PA 15219 (US)
`
`(73) Assignee: Alcatel
`
`(21) Appl. No.:
`
`11/301,714
`
`(22) Filed:
`
`Dec. 13, 2005
`
`Publication Classification
`
`(51)
`
`Int. Cl.
`H04L 12126
`(2006.01)
`(52) U.S. Cl. .............................................................. 370/236
`
`(57)
`
`ABSTRACT
`
`Communication traffic congestion management systems and
`methods are disclosed. Communication traffic is analyzed to
`determine its type, and a traffic congestion management
`function to be applied to the received communication traffic
`is selected based on the determined type and a level of
`communication traffic congestion. Congestion levels may be
`determined from congestion feedback signals provided by
`downstream communication components to which a traffic
`flow controller outputs communication traffic. A traffic con(cid:173)
`gestion management function may be selected and applied
`on a packet-by-packet or other block-specific basis, or to an
`entire stream of communication traffic.
`
`END USER
`EQUIPMENT
`12
`
`NETWORK
`ELEMENT
`13
`
`NETWORK
`ELEMENT
`16
`
`END USER
`EQUIPMENT
`18
`
`Microsoft
`Ex. 1005 - Page 1
`
`

`

`Patent Application Publication Jun. 14, 2007 Sheet 1 of 6
`
`US 2007/0133419 Al
`
`10
`~
`
`END USER
`EQUIPMENT
`12
`
`NETWORK
`ELEMENT
`13
`
`COMMUNICATION
`NETWORK
`14
`
`NETWORK
`ELEMENT
`16
`
`END USER
`EQUIPMENT
`18
`
`FIG.1
`
`Microsoft
`Ex. 1005 - Page 2
`
`

`

`> :g -....
`(') a .... 0 =
`""O = O" = (') a .... 0 =
`
`2' =
`
`i,
`
`I
`
`Traffic
`-Flow
`controller ~
`24
`
`I'
`
`-
`
`:
`:
`
`I congestion
`Monitor
`27 -
`-
`Downstream
`component(s)
`25
`
`-
`
`-I
`
`20
`~
`
`Fro
`m
`ffic
`Tra
`Sour
`ce(~
`
`Traffic
`Type
`Lookup
`Module
`26
`
`-
`
`J
`
`I
`
`I
`
`Traffic Ty~e
`Determination
`Module
`22
`
`-
`
`Memory
`29
`I
`Traffic
`Processor t---J
`28 -
`
`FIG. 2
`
`Microsoft
`Ex. 1005 - Page 3
`
`

`

`Patent Application Publication Jun. 14, 2007 Sheet 3 of 6
`
`US 2007/0133419 Al
`
`Probability of
`Discard IPbl
`
`100%
`
`Pbl----
`
`- --
`
`0%
`
`1
`
`AQD1
`Minimum
`
`Maximum
`
`Congestion Feedback Level
`
`FIG. 3A
`
`Probability of
`Discard IPbl
`
`100%
`
`0%
`
`34
`
`32
`
`, , , , \~//<;:'
`
`~ -~ - - - - - · · · · · · · · · · · · · · · · ·
`
`Congestion Feedback Level
`
`FIG. 3B
`
`Microsoft
`Ex. 1005 - Page 4
`
`

`

`Patent Application Publication Jun. 14, 2007 Sheet 4 of 6
`
`US 2007/0133419 Al
`
`Pb
`
`100%
`
`MAXp
`
`Pb
`
`100%
`
`MINth MAXth
`
`Congestion Feedback Level
`
`FIG. 3C
`
`Congestion Feedback Level
`
`FIG. 3D
`
`Microsoft
`Ex. 1005 - Page 5
`
`

`

`Patent Application Publication Jun. 14, 2007 Sheet 5 of 6
`
`US 2007/0133419 Al
`
`Probability of
`Discard !Pb)
`
`100%
`
`Pbl
`
`0%
`
`Probability of
`Discard !Pb)
`
`100%
`
`0%
`
`Maximum
`
`Congestion Feedback Level
`
`FIG. 3E
`
`Maximum
`
`Congestion Feedback Level
`
`FIG. 3F
`
`Microsoft
`Ex. 1005 - Page 6
`
`

`

`Patent Application Publication Jun. 14, 2007 Sheet 6 of 6
`
`US 2007/0133419 Al
`
`40
`~
`
`Receive traffic
`
`Determine type
`
`42
`
`44
`
`y
`
`Select Congestion
`Management Function
`
`48
`
`Forward traffic
`
`49
`
`FIG. 4
`
`50
`~
`
`r 52
`Traffic
`Stream m
`
`r 53
`
`r 54
`
`r 55
`
`...
`
`Traffic Type
`
`...
`
`r 56
`Congestion
`Management
`Function
`
`r 57
`
`...
`
`FIG. 5
`
`Microsoft
`Ex. 1005 - Page 7
`
`

`

`US 2007/0133419 Al
`
`Jun. 14,2007
`
`1
`
`COMMUNICATION TRAFFIC CONGESTION
`MANAGEMENT SYSTEMS AND METHODS
`
`FIELD OF THE INVENTION
`[0001] This invention relates generally to connnunications
`and, in particular, to handling connnunication traffic con(cid:173)
`gestion.
`
`BACKGROUND
`[0002] A standard mechanism in Internet Protocol (IP)
`networks for dealing with congestion is Random Early
`Discard (RED), sometimes also known as Random Early
`Detection. When a router sees an impending problem con(cid:173)
`dition, it starts randomly throwing away packets. A Trans(cid:173)
`mission Control Protocol (TCP) protocol client, which
`would be aware of any packet loss, concludes from observed
`loss that it is sending packets too quickly, and throttles back
`its sending rate to thereby alleviate congestion.
`
`[0003]
`In general, the actual packet loss observed by a
`TCP client is a result of packets being dropped at a receiving
`device, namely a router in the above example. According to
`a simple discard mechanism, when the depth of packets in
`a traffic queue at the receiving device exceeds a discard
`threshold, packets arriving at that queue are dropped 'off the
`tail' of the queue until the queue depth recedes below the
`discard threshold. One problem with this procedure, in the
`case of TCP connections, is that packets can tend to be
`dropped from a single TCP connection, resulting in an unfair
`service impact between customers.
`
`[0004] RED can address this problem for TCP connections
`by using queue depth to determine whether to keep or
`discard each packet as it arrives at a queue. A packet discard
`probability, which is dependent on the average depth of the
`queue over some time period, is compared to a random
`number. The packet is discarded if its discard probability
`exceeds the random number. Discard probabilities may be
`determined using a discard probability function, which
`might remain at zero until a minimum threshold is reached,
`increase linearly until a maximum threshold is reached, and
`remain at 100% for average queue depths greater than the
`maximum threshold.
`
`[0005]
`In so-called weighted RED, there are multiple
`discard probability functions, each of which results in a
`different discard probability for the same average queue
`depth. The particular discard probability function that is
`used for a packet depends on the drop precedence of the
`packet, which is determined by examining the DiffServ
`Code Point (DSCP) field in the IP header of the packet.
`Packets that exceed agreements on their connections have
`their drop precedence and thus their discard probability
`function changed by an IP policing procedure. As with RED,
`the determination to keep or discard a packet is made by
`comparing the discard probability of the packet to a random
`number. A variation of this procedure uses different prob(cid:173)
`ability curves in accordance with a class of service (CoS) of
`a packet. The CoS of a packet is also determined by
`examining the DSCP field in the IP header.
`
`[0006] One of the limitations of standard or weighted RED
`is that these techniques are used only on TCP flows. As
`non-TCP applications such as streaming video, VoIP, and IP
`video-telephony increase in popularity, the effectiveness of
`RED decreases because it operates only on the TCP portion
`of traffic.
`
`[0007] This also creates issues with respect to ensuring
`fairness between users. In a mixed traffic scenario, RED may
`either discard all packet types, which means that it is
`degrading the quality of non-TCP traffic types to no useful
`effect, or it can discard only TCP traffic. In the latter case, it
`effectively treats all User Datagram Protocol (UDP) and
`other protocols that do not verify successful delivery as high
`priority and all TCP applications as low priority. This might
`not reflect the priorities that a service provider would prefer,
`since in this case radio-over-the-Internet streaming audio
`might have a higher priority than business-critical client
`server applications, for instance.
`[0008]
`Intelligent Deep Packet Inspection (DPI) engines
`are being developed which are capable of looking inside a
`stream of traffic (beyond the header of each packet) to detect
`what kind of traffic is flowing in a network. These engines
`can distinguish between web browsing, email, VoIP, gaming,
`peer-to-peer, and other application types, for example. How(cid:173)
`ever, DPI is not currently used for dealing with traffic
`congestion.
`[0009] There remains a need for improved connnunication
`traffic congestion management techniques.
`
`SUMMARY OF THE INVENTION
`[0010] As noted above, randomly discarding data packets
`to respond to traffic congestion can adversely affect some
`connnunication traffic types, such as traffic associated with
`different applications, more than others. Therefore, tech(cid:173)
`niques for intelligently discarding data packets or flows in
`order to manage traffic congestion would be useful.
`[0011] Embodiments of the invention combine the con(cid:173)
`cepts of RED and type- or application-sensitive traffic flow
`treatment to minimize the effect of discarding packets on
`certain types of applications. For example, data packets from
`peer-to-peer and file transfer traffic might be discarded
`initially. With increasing traffic congestion, data packets
`from other applications such as web browsing or gaming,
`which are more sensitive to packet loss, could then be
`discarded only as needed to control congestion. A discard
`mechanism that is aware of traffic types also offers the
`opportunity to discard entire traffic streams as opposed to
`packets. This enables management of traffic congestion for
`even non-TCP applications such as VoIP, which do not
`usually respond to RED, by preventing establishment of
`connnunication sessions when congestion is being experi(cid:173)
`enced.
`[0012]
`In addition, by spotting and blocking setup mes(cid:173)
`sages at the beginning of a connnunication session, the
`session establishment can be blocked, thereby reducing the
`load on the network even from non-TCP applications.
`[0013] According to one aspect of the present invention, a
`connnunication traffic congestion management apparatus
`includes a traffic type determination module and a traffic
`flow controller operatively coupled to the traffic type deter(cid:173)
`mination module. The traffic type determination module is
`adapted for determining a type of received connnunication
`traffic, and the traffic flow controller is adapted for selecting,
`based on the determined type and a level of connnunication
`traffic congestion, a traffic congestion management function
`to be applied to the received connnunication traffic.
`[0014] The traffic type determination module may include
`a communication traffic processor adapted for processing the
`received communication traffic to determine its type.
`
`Microsoft
`Ex. 1005 - Page 8
`
`

`

`US 2007/0133419 Al
`
`Jun. 14,2007
`
`2
`
`[0015] The traffic type determination module may also
`include a traffic type lookup module adapted for determining
`whether the received communication traffic belongs to a
`communication traffic stream for which a type has previ(cid:173)
`ously been determined, and for associating the received
`communication traffic with the previously determined type
`where the received communication traffic belongs to a
`communication traffic stream for which a type has previ(cid:173)
`ously been determined. The communication traffic processor
`may then process the received communication traffic where
`the received communication traffic does not belong to a
`communication traffic stream for which a type has previ(cid:173)
`ously been determined.
`
`[0016] The apparatus may also include a memory opera(cid:173)
`tively coupled to the traffic type lookup module and to the
`communication traffic processor. In this case, the commu(cid:173)
`nication traffic processor may be adapted for storing in the
`memory an indication of the determined type of the received
`communication traffic. The traffic type lookup module may
`then perform the associating by accessing an indication of
`traffic type stored in the memory.
`
`[0017]
`In some embodiments, the selecting operation
`involves selecting a traffic discard probability function to be
`used in a Random Early Discard (RED) procedure.
`
`[0018] The traffic flow controller may be further adapted
`for outputting communication traffic to one or more traffic
`queues, and for detecting communication traffic congestion
`based on at least one of: an amount of communication traffic
`stored in the one or more traffic queues and a rate at which
`traffic is being delivered to the one or more queues.
`
`[0019] According to some embodiments, the received
`communication traffic includes communication traffic of one
`or more communication traffic streams, and the traffic flow
`controller is further adapted for outputting communication
`traffic to a downstream component, for receiving one or
`more congestion feedback signals from the downstream
`component, for detecting one or more levels of communi(cid:173)
`cation traffic congestion based on the one or more conges(cid:173)
`tion feedback signals, for determining which of the one or
`more communication traffic streams pertain to each conges(cid:173)
`tion feedback signal, and for selecting a traffic congestion
`management function to be applied to a communication
`traffic stream based on the determined type of the received
`communication traffic and the congestion feedback signal to
`which the communication traffic stream pertains.
`
`[0020] The traffic congestion management functions may
`cause the traffic flow controller to discard communication
`traffic types in a predetermined order as detected levels of
`traffic congestion increase, and cause the traffic flow con(cid:173)
`troller to pass communication traffic types in a reverse order
`of the predetermined order as detected levels of traffic
`congestion decrease.
`
`[0021] Where the received communication traffic includes
`blocks of communication traffic of a communication traffic
`stream, and the traffic flow controller may select, for each
`block of the communication traffic stream, a traffic conges(cid:173)
`tion management function to be applied to the block.
`
`[0023]
`In some embodiments, the traffic congestion man(cid:173)
`agement function is a communication traffic stream discard
`function, the communication traffic stream is one of a
`plurality of communication traffic streams, and the traffic
`flow controller is further adapted for selecting a communi(cid:173)
`cation traffic stream for discard according to the communi(cid:173)
`cation traffic stream discard function using a random discard
`probability function.
`
`[0024] The traffic congestion management function may
`involve detecting and discarding a signalled setup of a
`communication session.
`
`[0025] According to another embodiment, the traffic con(cid:173)
`gestion management function involves dropping all traffic of
`a communication traffic stream for a period of time.
`
`[0026] A communication traffic congestion management
`method is also provided, and involves receiving communi(cid:173)
`cation traffic for transfer to a downstream communication
`component, determining a type of the received communi(cid:173)
`cation traffic, and selecting, based on the determined type of
`the received communication traffic and a communication
`traffic congestion level, a traffic congestion management
`function to be applied to the received communication traffic
`for discarding traffic so as to avoid traffic drops at the
`downstream communication component.
`
`[0027] Determining may involve one or more of: process(cid:173)
`ing the received communication traffic to determine its type,
`and determining whether the received communication traffic
`belongs to a communication traffic stream for which a type
`has previously been determined.
`
`[0028] Where the downstream communication component
`includes one or more traffic queues, the method may also
`involve detecting traffic congestion at the downstream com(cid:173)
`munication component based on at least one of: an amount
`of communication traffic stored in the one or more traffic
`queues, an average amount of traffic stored in the one or
`more queues over a period of time, a rate of change of the
`amount of traffic stored in the one or more queues, and the
`amount or proportion of traffic dropped from a queue of the
`one or more queues which has overflowed.
`
`[0029]
`In some embodiments, the traffic congestion man(cid:173)
`agement function comprises one of a plurality of traffic
`congestion management functions associated with respec(cid:173)
`tive levels of communication traffic congestion at the down(cid:173)
`stream communication component, the method also involves
`detecting a level of communication traffic congestion at the
`downstream communication component, and selecting
`involves selecting the traffic congestion management func(cid:173)
`tion to be applied to the received communication traffic
`based on the determined type of the received communication
`traffic and the detected level of congestion.
`
`[0030] The received communication traffic may include
`blocks of communication traffic of a communication traffic
`stream. In this case, selecting may involve selecting respec(cid:173)
`tive traffic congestion management functions to be applied
`to each block of the communication traffic stream or select(cid:173)
`ing a traffic congestion management function to be applied
`to all of the blocks of the communication traffic stream.
`
`[0022] The traffic flow controller may instead select a
`traffic congestion management function to be applied to all
`communication traffic of the communication traffic stream.
`
`[0031] A further aspect of the invention provides a
`machine-readable medium storing a data structure. The data
`structure includes an indication of a communication traffic
`
`Microsoft
`Ex. 1005 - Page 9
`
`

`

`US 2007/0133419 Al
`
`Jun. 14,2007
`
`3
`
`stream for which a communication traffic congestion level
`can be determined, an indication of a communication traffic
`type of the communication traffic stream, and an indication
`of a traffic congestion management function to be applied to
`communication traffic of the indicated type, the traffic con(cid:173)
`gestion management function defining a control action to be
`performed on traffic of the indicated type for a determined
`communication traffic congestion level.
`
`[0032] The identifier of a communication traffic stream
`may include a source and a destination of the communica(cid:173)
`tion traffic stream.
`
`[0033] The data structure may also include one or more
`linking data structures comprising information associating
`the indication of the communication traffic type with the
`indication of the traffic congestion management function.
`
`[0034] Other aspects and features of embodiments of the
`present invention will become apparent to those ordinarily
`skilled in the art upon review of the following description.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`[0035] Examples of embodiments of the invention will
`now be described in greater detail with reference to the
`accompanying drawings, in which:
`
`[0036] FIG. 1 is a block diagram of a communication
`system.
`
`[0037] FIG. 2 is a block diagram of a communication
`traffic congestion management apparatus.
`
`[0038] FIGS. 3A through 3F illustrate example traffic
`discard probability functions.
`
`[0039] FIG. 4 is a flow diagram showing a communication
`traffic congestion management method.
`
`[0040] FIG. 5 is a block diagram of a communication
`traffic congestion management data structure.
`
`DETAILED DESCRIPTION OF PREFERRED
`EMBODIMENTS
`
`[0041] FIG. 1 is a block diagram of a communication
`system, and is illustrative of a system in which embodiments
`of the present invention might be implemented. The com(cid:173)
`munication system 10 in FIG. 1 includes end user commu(cid:173)
`nication equipment 12, 18, network elements 13, 16, and a
`communication network 14. Although many installations of
`end user equipment 12, 18 and network elements 13, 16 may
`be connected to the communication network 14, only two
`examples of each of these components have been labelled in
`FIG. 1 to avoid visual complexity. It should therefore be
`appreciated that the system of FIG. 1, as well as the contents
`of the other drawings, are intended solely for illustrative
`purposes, and that the present invention is in no way limited
`to the particular example embodiments explicitly shown in
`the drawings and described herein.
`
`[0042] The end user equipment 12, 18 represents commu(cid:173)
`nication equipment that is configured to generate and trans(cid:173)
`mit and/or receive and terminate communication traffic.
`Although shown as being directly connected to the network
`elements 13, 16, it will be apparent that end user equipment
`12, 18 may communicate with the network elements 13, 16
`through other intermediate components (not shown).
`
`[0043] Switches and routers are illustrative of the types of
`communication equipment represented by the network ele(cid:173)
`ments 13, 16. The network elements 13, 16 provide access
`to the communication network 14 and thus have been shown
`separately in FIG. 1 for illustrative purposes.
`[0044] The communication network 14, in addition to the
`border or edge network elements 13, 16, may also include
`core network elements which route communication traffic
`through the communication network 14.
`[0045] Many different types of end user, intermediate, and
`network communication equipment, as well as the operation
`thereof, will be apparent to those skilled in the art. In
`general, communication traffic originating with the end user
`equipment 12, 18, and possibly other sources of communi(cid:173)
`cation traffic, for transfer to a remote destination through the
`communication network 14 is received by a network ele(cid:173)
`ment 13, 16, translated between different protocols or for(cid:173)
`mats if necessary, and routed through the communication
`network 14. Embodiments of the invention are not limited to
`any particular types of communication equipment, transfer
`mechanisms, or protocols.
`[0046] During transfer through the communication system
`10, communication traffic may become congested at any of
`various points. In communication equipment such as the
`network elements 13, 16, for example, communication traf(cid:173)
`fic may become congested at traffic queues in which traffic
`is stored before being scheduled for transmission through
`communication media. As described above, current tech(cid:173)
`niques for managing congestion are effective for only certain
`communication protocols such as TCP, and can lead to
`unfair or otherwise undesirable traffic discard patterns.
`[0047] One embodiment of the invention combines the
`concept of traffic type determination, which may use appli(cid:173)
`cation-aware DPI as described in further detail below, with
`type-specific
`traffic congestion management functions,
`which may use RED. In other words, when a network
`congestion problem threatens, communication traffic is ran(cid:173)
`domly discarded, but discards are handled differently for
`different traffic types, depending upon an application with
`which the traffic is associated, for instance.
`[0048] Traffic type-specific discarding, or more generally
`traffic type-specific congestion management, has several
`beneficial effects. A first benefit is that traffic that is least
`valuable or associated with an application for which loss of
`traffic, illustratively packet loss, is least important is dis(cid:173)
`carded first or more heavily. Another beneficial effect is that
`packet discards that will degrade performance of real-time
`applications and/or have no positive impact on congestion
`control can be avoided, at least until more serious congestion
`conditions arise. For example, VoIP over UDP is a real-time
`application for which discarding of packets will not have a
`positive effect on congestion control, since UDP does not
`respond to packet loss. A further benefit is that type-specific
`congestion management makes it possible to discard all
`communication traffic of a traffic stream, instead of discard(cid:173)
`ing traffic on a block-by-block basis, as might be imple(cid:173)
`mented at a packet data router in a packet-based communi(cid:173)
`cation system, for example. This stream discard feature
`provides a scheme for managing congestion, even from
`non-TCP applications, by randomly blocking session estab(cid:173)
`lishment under congestion conditions.
`[0049] The stream discard mode can operate in one of two
`fashions. In the first, the inspection discovers a session setup
`
`Microsoft
`Ex. 1005 - Page 10
`
`

`

`US 2007/0133419 Al
`
`Jun. 14,2007
`
`4
`
`message associated with the stream and discards it. In the
`absence of a successful setup response, the initiating appli(cid:173)
`cation will normally retry until the congestion condition
`passes and the setup attempt succeeds. A second fashion in
`which the stream based discard can operate, when rejecting
`a stream, involves associating a randomly selected 'isolation
`period' with an end point. During the isolation period, all
`traffic (signalling or media) associated with a particular type
`of traffic from that end point will be discarded. A service
`provider can choose to have get any given level of relief
`from network load by locking out more users for a shorter
`'isolation period' or fewer users for a longer isolation period,
`for example. Selection of a particular stream for discarding
`may be based on a random discard probability function.
`[0050] Thus, stream based discard may allow a small
`number of users to lose all of their traffic for a period of time,
`rather than many users losing traffic. This produces the
`maximum relief from load on the network with an impact on
`a minimum number of users. Stream based discard enables
`a local network element to respond appropriately to a
`congestion situation, whether or not there is a signalling
`controller which is capable of detecting and responding to
`congestion, for example by implementing a session admis(cid:173)
`sion control function. Furthermore, stream based discard can
`be applied even where a communication protocol is not
`understood or a signalling protocol is encrypted, by simply
`discarding all traffic associated with defined ports and pro(cid:173)
`tocols for a particular user for a period of time.
`[0051] Stream based discard can be a more reliable means
`of dealing with congestion in the presence of signalled
`stream based communications than admission control. An
`admission control function compares an estimated current
`load against the theoretically available capacity to determine
`if a new session can start without oversubscribing some
`network resource. Admission control can therefore act inap(cid:173)
`propriately if the estimated load or capacity is not accurate.
`Congestion control is not prone to this problem, in that it
`does not take corrective action unless a real problem exists,
`and when a real problem exists, it always takes action.
`[0052] FIG. 2 is a block diagram of a communication
`traffic congestion management apparatus. The apparatus 20,
`which might be implemented in communication equipment
`such as a packet router for instance, includes a traffic type
`determination module 22 and a traffic flow controller 24
`operatively coupled thereto. The traffic type determination
`module 22 has a traffic type lookup module 26, a traffic
`processor 28 operatively coupled to the traffic type lookup
`module 26, and a memory 29 operatively coupled to the
`traffic type lookup module 26 and to the traffic processor 28.
`[0053] Communication equipment incorporating the appa(cid:173)
`ratus 20 may include additional components, represented
`generally as downstream component(s) 25 comprising a
`congestion monitor 27. It should also be appreciated that the
`specific division of functions represented by the components
`22, 24, 26, 28, 29 is intended solely for the purposes of
`illustration and not to limit the scope of the invention. Other
`embodiments of the invention may include further, fewer, or
`additional components interconnected in a similar or differ(cid:173)
`ent manner. Further, multiple implementations of the com(cid:173)
`ponents shown in FIG. 2 may be provided in communication
`equipment, including one implementation for control of
`'upstream' traffic, and another separate implementation for
`control of 'downstream' traffic.
`
`[0054] The components of the apparatus 20 may be opera(cid:173)
`tively coupled to each other through physical connections
`such as conductive traces on a substrate where the compo(cid:173)
`nents are provided on the same electronic circuit card and/or
`backplane conductors where the components are distributed
`between multiple cards in the same equipment. Logical
`interconnections are also contemplated, where any of the
`components of the apparatus 20 are implemented using
`software for execution by one or more processing elements.
`In this case, components may access data stored in common
`storage locations in the memory 29, for example, and may
`thus be considered to be coupled to each other through a
`logical connection.
`
`[0055] From the foregoing, it should be apparent that
`many of the components of the apparatus 20 may be
`implemented using hardware, software, firmware, or any
`combination thereof. Those skilled in the art will be familiar
`with many devices which may be used in implementing the
`apparatus 20, including microprocessors, microcontrollers,
`Application Specific Integrated Circuits (ASICs), Program(cid:173)
`mable Logic Devices (PLDs), and/or Field Programmable
`Gate Arrays (FPGAs ), for example.
`
`[0056]
`In view of the many possible implementations of
`the components shown in FIG. 2, these components are
`described herein primarily in terms of their function. Based
`on these functional descriptions, a skilled person would be
`enabled to implement embodiments of the invention in any
`of various ways.
`
`[0057] The memory 29, however, would generally be
`provided as a hardware component, and may include one or
`more memory devices. Solid state memory devices are
`common
`in communication equipment, although
`the
`memory 29 may also or instead include memory devices for
`use with movable or even removable memory media.
`
`[0058]
`In operation, the traffic type determination module
`22 receives communication traffic from one or more traffic
`sources and determines a type of the received communica(cid:173)
`tion traffic. Based on the determined traffic type, and an
`observed level of congestion feedback which maps to that
`traffic type as discussed below, the traffic flow controller 24
`selects a traffic congestion management function to be
`applied to the traffic in order to reduce or prevent traffic
`congestion.
`
`[0059] Communication traffic type may be determined by
`the traffic type lookup module 26 or by the traffic processor
`28. The traffic type lookup module 26 accesses the memory
`29 to determine whether the type of the received traffic had
`previously been identified by the traffic processor 28. A
`received packet, for example, may belong to a traffic stream
`for which a type has already been determined and stored in
`the memory 29. Otherwise, the traffic processor 28 processes
`the traffic to determine its type.
`
`[0060] The expression 'traffic stream' as used herein may
`refer to a communication session between two end points,
`such as end user equipment 12 and 18 in FIG. 1, or
`communication traffic associated with such as session. A
`stream may be identified by source and destination IP
`address for instance, and also use an additional label such as
`IP port and protocol to distinguish different types of traffic
`between session end points. The phrase '5-tuple' (of IP
`source and destination address, source and destination port,
`
`Microsoft
`Ex. 1005 - Page 11
`
`

`

`US 2007/0133419 Al
`
`Jun. 14,2007
`
`5
`
`and protocol) is one example of a stream identifier that may
`be used in some embodiments of the invention.
`
`[0061] Considering an example ofreceiving a first packet
`in a traffic stream, a traffic type for that packet would not
`have been previously determined, and accordingly the
`packet is processed by the traffic processor 28. The packet
`may be passed to the traffic processor 28 by the traffic type
`lookup module 26 directly, or indirectly by storing the
`packet to the memory 29 for instance.
`
`[0062] According to one relatively simple implementa(cid:173)
`tion, the traffic processor 28 processes the packet to detect its
`port number and protocol, and to determine the type of the
`packet, and specifically the application associated with the
`traffic, on the basis of the port number and protocol. How(cid:173)
`ever, much more sophisticated recognition approaches are
`also contemplated. These approaches may involve identifi(cid:173)
`cation based on information outside the packet head