Search Images Maps Play YouTube News Gmail Drive More »
Sign in
Screen reader users: click this link for accessible mode. Accessible mode has the same essential features but works better with your reader.

Patents

  1. Advanced Patent Search
Publication numberUS20150023366 A1
Publication typeApplication
Application numberUS 13/943,018
Publication dateJan 22, 2015
Filing dateJul 16, 2013
Priority dateJul 16, 2013
Publication number13943018, 943018, US 2015/0023366 A1, US 2015/023366 A1, US 20150023366 A1, US 20150023366A1, US 2015023366 A1, US 2015023366A1, US-A1-20150023366, US-A1-2015023366, US2015/0023366A1, US2015/023366A1, US20150023366 A1, US20150023366A1, US2015023366 A1, US2015023366A1
InventorsCheng-Jia Lai, Wenyi Wang, Shih-cheng Stan Yang
Original AssigneeCisco Technology, Inc.
Export CitationBiBTeX, EndNote, RefMan
External Links: USPTO, USPTO Assignment, Espacenet
Adaptive marking for wred with intra-flow packet priorities in network queues
US 20150023366 A1
Abstract
In one embodiment, a router receives a packet, and determines an intra-flow packet priority level of the packet. The router may then map the intra-flow packet priority level to a weighted random early detection (WRED) marking based on running statistics of intra-flow packet priority levels across received flows, and marks the packet with the mapped WRED marking. By placing the marked packet into an outgoing network queue for transmission, the router may then forward or drop the marked packet based on the network queue, accordingly.
Images(8)
Previous page
Next page
Claims(20)
What is claimed is:
1. A method, comprising:
receiving a packet;
determining an intra-flow packet priority level of the packet;
mapping the intra-flow packet priority level to a weighted random early detection (WRED) marking based on running statistics of intra-flow packet priority levels across received flows;
marking the packet with the mapped WRED marking;
placing the marked packet into an outgoing network queue for transmission; and
forwarding or dropping the marked packet based on the network queue.
2. The method as in claim 1, further comprising:
normalizing the mapping of the intra-flow packet priority level to a WRED marking based on running statistics of intra-flow packet priority levels across received flows.
3. The method as in claim 2, further comprising:
recalculating normalization periodically.
4. The method as in claim 2, further comprising:
recalculating normalization per packet.
5. The method as in claim 2, further comprising:
recalculating normalization using a heuristic algorithm.
6. The method as in claim 2, further comprising:
mapping each lower intra-flow packet priority level to a lower WRED marking as much as possible.
7. The method as in claim 1, wherein the intra-flow packet priority level is based on at least one of a packet type or a packet marking.
8. The method as in claim 1, wherein the WRED marking is a Differentiated Services (DiffServ) marking.
9. The method as in claim 1, wherein the packet is a video packet.
10. The method as in claim 9, wherein the intra-flow packet priority level is based on whether the packet is an instantaneous decode refresh (IDR) packet, a sequence parameters packet, a referenced P packet, a non-referenced P packet, or a non-referenced B packet.
11. An apparatus, comprising:
one or more network interfaces to communicate within a computer network;
a processor coupled to the network interfaces and adapted to execute one or more processes; and
a memory configured to store a process executable by the processor, the process when executed operable to:
receive a packet;
determine an intra-flow packet priority level of the packet;
map the intra-flow packet priority level to a weighted random early detection (WRED) marking based on running statistics of intra-flow packet priority levels across received flows;
mark the packet with the mapped WRED marking;
place the marked packet into an outgoing network queue for transmission; and
forward or drop the marked packet based on the network queue.
12. The apparatus as in claim 11, wherein the process when executed is further operable to:
normalize the mapping of the intra-flow packet priority level to a WRED marking based on running statistics of intra-flow packet priority levels across received flows.
13. The apparatus as in claim 12, wherein the process when executed is further operable to:
recalculate normalization either periodically, per packet, or using a heuristic algorithm.
14. The apparatus as in claim 12, wherein the process when executed is further operable to:
map each lower intra-flow packet priority level to a lower WRED marking as much as possible.
15. The apparatus as in claim 11, wherein the intra-flow packet priority level is based on at least one of a packet type or a packet marking.
16. The apparatus as in claim 11, wherein the WRED marking is a Differentiated Services (DiffServ) marking.
17. The apparatus as in claim 11, wherein the packet is a video packet.
18. One or more computer-readable storage media encoded with software comprising computer executable instructions and when the software is executed operable to:
receive a packet;
determine an intra-flow packet priority level of the packet;
map the intra-flow packet priority level to a weighted random early detection (WRED) marking based on running statistics of intra-flow packet priority levels across received flows;
mark the packet with the mapped WRED marking;
place the marked packet into an outgoing network queue for transmission; and
forward or drop the marked packet based on the network queue.
19. The computer-readable storage media as in claim 18, wherein the software when executed is further operable to:
normalize the mapping of the intra-flow packet priority level to a WRED marking based on running statistics of intra-flow packet priority levels across received flows.
20. The computer-readable storage media as in claim 18, wherein the intra-flow packet priority level is based on at least one of a packet type or a packet marking.
Description
    TECHNICAL FIELD
  • [0001]
    The present disclosure relates generally to computer networks, and, more particularly, to packet marking for weighted random early detection (WRED).
  • BACKGROUND
  • [0002]
    Video streams are typically encoded in compression with packetization when transmitted over packet-switched networks such as the Internet, enterprise virtual private networks (VPNs), and service provider Internet Protocol Television (IPTV) networks. Video codec specifications such as ITU-T H.264 and H.263 define the packet formats to carry the encoded video data in slices, where the payload headers contain the slice types of video data in the payloads. Thus, network devices in the middle may be able to distinguish the more important packets from the less important by packet markings or deep packet inspection (DPI) when packet drops are needed in a network queue upon congestion or for congestion avoidance.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • [0003]
    The embodiments herein may be better understood by referring to the following description in conjunction with the accompanying drawings in which like reference numerals indicate identically or functionally similar elements, of which:
  • [0004]
    FIG. 1 illustrates an example communication network;
  • [0005]
    FIG. 2 illustrates an example network device/node;
  • [0006]
    FIG. 3 illustrates an example of an unfairness problem in weighted random early detection (WRED) with intra-flow priority (IFP) marking;
  • [0007]
    FIG. 4 illustrates an example of adaptive marking by IFP statistics;
  • [0008]
    FIG. 5 illustrates an example of fairness by adaptive marking with IFP;
  • [0009]
    FIG. 6 illustrates an example of normalization in adaptive marking; and
  • [0010]
    FIG. 7 illustrates an example simplified procedure for adaptive marking for WRED with intra-flow packet priorities in network queues.
  • DESCRIPTION OF EXAMPLE EMBODIMENTS Overview
  • [0011]
    According to one or more embodiments of the disclosure, a router receives a packet, and determines an intra-flow packet priority level of the packet. The router may then map the intra-flow packet priority level to a weighted random early detection (WRED) marking based on running statistics of intra-flow packet priority levels across received flows, and marks the packet with the mapped WRED marking. By placing the marked packet into an outgoing network queue for transmission, the router may then forward or drop the marked packet based on the network queue, accordingly.
  • Description
  • [0012]
    A computer network is a geographically distributed collection of nodes interconnected by communication links and segments for transporting data between end nodes, such as personal computers and workstations. Many types of networks are available, with the types ranging from local area networks (LANs) to wide area networks (WANs). LANs typically connect the nodes over dedicated private communications links located in the same general physical location, such as a building or campus. WANs, on the other hand, typically connect geographically dispersed nodes over long-distance communications links, such as common carrier telephone lines, optical lightpaths, synchronous optical networks (SONET), or synchronous digital hierarchy (SDH) links. The Internet is an example of a WAN that connects disparate networks throughout the world, providing global communication between nodes on various networks. The nodes typically communicate over the network by exchanging discrete frames or packets of data according to predefined protocols, such as the Transmission Control Protocol/Internet Protocol (TCP/IP) or more particularly the User Datagram Protocol (UDP) or Real-time Transport Protocol (RTP) (which defines a standardized packet format for delivering audio and video over IP networks). In this context, a protocol consists of a set of rules defining how the nodes interact with each other. Computer networks may be further interconnected by an intermediate network node, such as a router, to extend the effective “size” of each network.
  • [0013]
    Since management of interconnected computer networks can prove burdensome, smaller groups of computer networks may be maintained as routing domains or autonomous systems. The networks within an autonomous system (AS) are typically coupled together by conventional “intradomain” routers configured to execute intradomain routing protocols, and are generally subject to a common authority. To improve routing scalability, a service provider (e.g., an ISP) may divide an AS into multiple “areas” or “levels.” It may be desirable, however, to increase the number of nodes capable of exchanging data; in this case, interdomain routers executing interdomain routing protocols are used to interconnect nodes of the various ASes. Moreover, it may be desirable to interconnect various ASes that operate under different administrative domains. As used herein, an AS, area, or level is generally referred to as a “domain.”
  • [0014]
    FIG. 1 is a schematic block diagram of an example computer network 100 illustratively comprising various interconnected network devices (e.g., servers, routers, etc.) which may form local networks that are interconnected by a global network (e.g., the public Internet) or WAN 115, as shown. Illustratively, various client devices (“C”) 110 and various servers (“S”) 105 may be interconnected via the WAN 115 (and/or within respective local networks), which may comprise a plurality of routers 120. Those skilled in the art will understand that any number of network devices may be implemented in the computer network 100, that the network devices may be interconnected with one another in any suitable configuration, and that the view shown herein is for simplicity.
  • [0015]
    Data packets 140 may be exchanged among the network devices of the computer network 100 over links using predefined network communication protocols such as certain known wired protocols, wireless protocols, or other protocols where appropriate. In this context, a protocol consists of a set of rules defining how the devices interact with each other.
  • [0016]
    FIG. 2 is a schematic block diagram of an example device 200 that may be used with one or more embodiments described herein, e.g., such as any of the routers 120 or other devices as shown in FIG. 1 above. The device may comprise one or more network interfaces 210, one or more processors 220, and a memory 240 interconnected by a system bus 250. The network interface(s) 210 contain the mechanical, electrical, and signaling circuitry for communicating data over links coupled to the network 100. The network interfaces may be configured to transmit and/or receive data using a variety of different communication protocols, including, inter alia, TCP, RTP, UDP, ATM, synchronous optical networks (SONET), wireless protocols, Frame Relay, Ethernet, Fiber Distributed Data Interface (FDDI), etc. Notably, a physical network interface 210 may also be used to implement one or more virtual network interfaces, such as for Virtual Private Network (VPN) access, known to those skilled in the art.
  • [0017]
    The memory 240 comprises a plurality of storage locations that are addressable by the processor(s) 220 and the network interfaces 210 for storing software programs and data structures associated with the embodiments described herein. The processor 220 may comprise hardware elements or hardware logic adapted to execute the software programs and manipulate the data structures 245. An operating system 242, portions of which are typically resident in memory 240 and executed by the processor(s), functionally organizes the device by, inter alia, invoking operations in support of software processes and/or services executing on the device. These software processes and/or services may comprise routing process/services 244 and an illustrative weighted random early detection (WRED) process 248, as described herein, which may alternatively be located within individual network interfaces (e.g., process 248 a).
  • [0018]
    It will be apparent to those skilled in the art that other processor and memory types, including various computer-readable media, may be used to store and execute program instructions pertaining to the techniques described herein. Also, while the description illustrates various processes, it is expressly contemplated that various processes may be embodied as modules configured to operate in accordance with the techniques herein (e.g., according to the functionality of a similar process). Further, while the processes have been shown separately, those skilled in the art will appreciate that processes may be routines or modules within other processes.
  • [0019]
    Routing process/services 244 contain computer executable instructions executed by processor 220 to perform functions provided by one or more routing protocols, such as the Interior Gateway Protocol (IGP) (e.g., Open Shortest Path First, “OSPF,” and Intermediate-System-to-Intermediate-System, “IS-IS”), the Border Gateway Protocol (BGP), etc., as will be understood by those skilled in the art. These functions may be configured to manage a forwarding information database (not shown) containing, e.g., data used to make forwarding decisions. In particular, changes in the network topology may be communicated among routers 200 using routing protocols, such as the conventional OSPF and IS-IS link-state protocols (e.g., to “converge” to an identical view of the network topology). Notably, routing services 244 may also perform functions related to virtual routing protocols, such as maintaining VRF instances (not shown), or tunneling protocols, such as for Multi-Protocol Label Switching (MPLS), generalized MPLS (GMPLS), etc., each as will be understood by those skilled in the art.
  • [0020]
    As noted above, video streams are typically encoded in compression with packetization when transmitted over packet-switched networks such as the Internet, enterprise virtual private networks (VPNs), and service provider Internet Protocol Television (IPTV) networks. Video codec specifications such as ITU-T H.264 and H.263 define the packet formats to carry the encoded video data in slices, where the payload headers contain the slice types of video data in the payloads. Thus, network devices in the middle may be able to distinguish the more important packets from the less important by packet markings or deep packet inspection (DPI) when packet drops are needed in a network queue upon congestion or for congestion avoidance.
  • [0021]
    However, those packet priority levels are seen not only inter-flow but also intra-flow for video, that is, inside the same flow, packets may have multiple priority levels. For example, H.264 Network Abstraction Layer (NAL) unit header contains fields that can show which type of video data is carried in this packet, such as instantaneous decode refresh (IDR), sequence parameters, referenced P, non-referenced P, non-referenced B, etc. Depending on which type, intra-flow priorities can be decided in a predefined order according to how strong of an impact it is to the video quality if the very packet is discarded. Those intra-flow priorities should only be compared within the same flow, i.e. presenting a local order in a flow, instead of a global order between flows. Thus, the intra-flow priorities are unlike the inter-flow priorities such as differentiated services code point (DSCP) and IP Precedence, and will require special handling in network queues.
  • [0022]
    In fact, new technologies have recently been proposed to improve video flow quality of service (QoS) by protecting those video packets that are more important for decoding so that they should not be dropped unless the less-important packets are already dropped. For example, there are existing initiatives in media frame protection (MFP) for video flows at network congestion. Some of those mechanisms rely on the existing Differentiated Services (DiffServ) model by packet classification and weighted random early detection (WRED) where the more important video packets are marked to receive a lower packet drop rate and/or setting a higher threshold before starting random drops. Those markings are put in either the packet headers (e.g., DSCP and IP Precedence) or internal metadata of a packet in the network device (e.g. qos-group and discard-class).
  • [0023]
    Then, the active queue management (AQM) of the network queue can base on those markings to run WRED. In the congestion avoidance stage, those mechanisms may also be combined with the markings of Explicit Congestion Notification (ECN) or Pre-Congestion Notification (PCN) bits in packet headers for adaptive endpoints.
  • [0024]
    Unfortunately, the existing marking mechanisms for WRED cannot correctly handle the intra-flow priorities (IFP). If the intra-flow priorities are simply mapped to the marking values for inter-flow without special handling, it may result in unfair bandwidth sharing among video flows. This is because the video flows are very likely to be generated from different encoders in different video contents, such that each individual video flow has a different distribution of intra-flow priorities, in terms of how many packets per intra-flow priority level. Thus, when simply mapped (say, linearly or by table lookup) to the markings for WRED, those flows may see different per-flow packet drop rates simply due to their own intra-flow priority distributions, which is not fair. Instead, to achieve fairness, those flows should see equal per-flow packet drop rates and thresholds, while they see different packet drop rates and thresholds only among packets inside the same flow, i.e. due to the intra-flow priorities.
  • [0025]
    Said differently, if WRED is configured to protect more important video packets by IFP markings as weights for packet-drop rates and thresholds, it can be unfair among different flows in the same queue. For instance, the following examples may occur:
      • Flows with all I-frames−−>all important, so all protected;
      • Flows with extra SVC layers−−>too humble, so suffer;
      • Flows with different contents−−>various ratio of I/P/B packets;
      • Flow with an adaptive bit rate−−>constantly changing.
        As such, the techniques described below “normalize” intra-flow priority markings for WRED in a manner that is adaptive to each flow's traffic characteristics, and that allows comparison of intra-flow priorities of packets across flows.
  • [0030]
    As one example of unfairness, suppose flow A generates 10% IDR slices and 90% P slices while flow B generates 25% IDR slices and 75% P slices. If the network queue with WRED is configured to protect traffic class of IDR slices (regardless of flows) against P slices, the result is likely that flow B consumes more bandwidth over flow A on congestion. This is unfair. Instead, to be fair, flow A and B should be able to share the bandwidth equally (or with some weights if somehow configured). Then within flow A the packet drops are only on packets of P slices while the same within flow B. It means that the intra-flow priorities of packets should not affect the bandwidth sharing by packets between flows, but only the bandwidth sharing by packets within the same flow.
  • [0031]
    As another example, visually (and for comparison below), FIG. 3 illustrates an example of an unfairness problem in WRED with intra-flow priority (IFP) marking between three flows, A, B, and C. In particular, assume that flow A has 2 Mbps of data at priority “2”, and 1Mbps each at priority “1” and “0”. Also, flow B has 2 Mbps at each of priorities 1 and 0, while flow C has all 4 Mbps at priority 0. Assuming an overall drop rate of 2.48 Mbps, all of the WRED class 2 (priority 2) packets are dropped, and 16% of the class 1 packets are dropped. In this instance, flow A suffers greatly (54% drops), while flows B and C remain relatively untouched (8% and 0% drops, respectively).
  • [0032]
    The adaptive marking techniques herein, on the other hand, provide fairness of bandwidth sharing in network queues while addressing the intra-flow priorities among packets that are typically seen in video flows with modern codec technologies. Notably, the techniques herein may be applied to any type of data flow, and are not limited to video flows (used merely as one example of data flows with intra-flow priorities). The techniques herein can be used together with the existing WRED in the DiffSery model, but may use running statistics to normalize the mapping from intra-flow priorities to the marking values that will be used in WRED.
  • [0033]
    Specifically, according to one or more embodiments of the disclosure as described in detail below, when a router receives a packet, it determines an intra-flow packet priority level of the packet. The router may then map the intra-flow packet priority level to a weighted random early detection (WRED) marking based on running statistics of intra-flow packet priority levels across received flows, and marks the packet with the mapped WRED marking. By placing the marked packet into an outgoing network queue for transmission, the router may then forward or drop the marked packet based on the network queue, accordingly.
  • [0034]
    Illustratively, the techniques described herein may be performed by hardware, software, and/or firmware, such as in accordance with the WRED process 248/248 a, which may contain computer executable instructions executed by the processor 220 (or independent processor of interfaces 210) to perform functions relating to the techniques described herein. For example, the techniques herein may be treated as extensions to conventional packet marking protocols (e.g., WRED, DiffServ, etc.), and as such, may be processed by similar components understood in the art that execute those protocols, accordingly.
  • [0035]
    Operationally, FIG. 4 illustrates an example of adaptive marking by IFP statistics. In particular, upon receiving a packet 140, a router 120 may determine the intra-flow packet priority level “L” based on a packet type or marking. The received levels L may be used to update a running statistic of intra-flow packet priority levels, such that the general solution for optimization is based on the statistics of all L samples known in the past. Note that although this may not fully optimize the future unless the future statistics is exactly the same as the past statistics, those samples should be representative so it is relevant if properly updated. Through normalization (described below), the statistics may be used to map the intra-flow packet priority level of the packet to a WRED marking (e.g., a DiffSery marking), “M”. By them marking the packet with “M” (WRED/DiffServ), the packet may be placed in the network queue of the corresponding interface 210.
  • [0036]
    According to the techniques herein, therefore, FIG. 5 illustrates an example of fairness by adaptive marking with IFP. In particular, assuming the same intra-flow priority distribution as in FIG. 3 above between flows A, B, and C, and the same overall drop rate of 2.48 Mbps, the techniques herein can be shown to more fairly drop packets across all flows (e.g., 20.67% for each flow). For instance, based on the running statistics of intra-flow packet priority levels, the router may determine an appropriate mapping between the IFP and the WRED marking per-flow, such as the mappings shown between L and M for each flow in FIG. 5. From this mapping, 20% of the traffic is identified as WRED class 2 (M=2), 30% as class 1 (M=1), and 50% as class 0 (M=0). As such, for a 20.67% drop (2.48 Mbps), 100% of the class 2 (M=2) traffic is dropped, with only 2.2% for class 1 (M=1) and 0% for class 0 (M=0). As such, the “more important” traffic is generally forwarded, while “less important” traffic may be dropped, while at the same time ensuring fairness between the flows since each flow has a different proportion of more/less important traffic.
  • [0037]
    FIG. 6 illustrates an example of normalization in adaptive marking according to the techniques herein. In particular, based on the running statistics of L, through normalization these L values can be mapped to corresponding target markings M. A general mapping solution as shown may be ideal and could be done by solving a system of linear equations with optimization, such that each lower L is mapped to lower M as much as possible, i.e., a “greedy algorithm”. For instance, given the target markings M (e.g., 0, 1, 2, etc.), a normalization array can be solved by a greedy algorithm and applied to the running statistics of L (i.e., the distribution of all known L samples). As an example, the normalization array may be solved where for all k=1, 2, . . . ,
  • [0000]

    Σall i(t ki)=1,  Eq. 1
  • [0000]
    where for all i, 0≦tki≦1. Note that the complexity per flow of the techniques herein may be illustrated as follows:
      • Time is on the order of (#L+#M) to re/calculate the normalization array.
      • Space is on the order of (#L◊#M) to store the normalization array.
        To reduce the computation overhead, one may choose to recalculate the normalization array only periodically (e.g., every 10 seconds), instead of recalculating whenever the statistics is updated per packet arrival, or use some heuristic algorithm with much reduced complexity in time and space, just to achieve semi-fairness (e.g., where a heuristic algorithm may have reduced complexity so it may be preferred in some implementations if scalability is a concern in system performance).
  • [0040]
    FIG. 7 illustrates an example simplified procedure 700 for adaptive marking for WRED with intra-flow packet priorities in network queues in accordance with one or more embodiments described herein. The procedure 700 may start at step 705, and continues to step 710, where, as described in greater detail above, a router 120 may receive a packet 140, and determines an intra-flow packet priority level of the packet in step 715. Notably, as described above, the intra-flow packet priority level may be based on a packet type and/or a packet marking. For instance, where the packet is a video packet, the intra-flow packet priority level is based on whether the packet is an IDR packet, a sequence parameters packet, a referenced P packet, a non-referenced P packet, a non-referenced B packet, etc.
  • [0041]
    In step 720, the router maps the intra-flow packet priority level to a WRED marking based on running statistics of intra-flow packet priority levels across received flows, as described above. In particular, in one or more embodiments, the router normalizes the mapping of the intra-flow packet priority level to a WRED marking based on running statistics of intra-flow packet priority levels across received flows, e.g., mapping each lower intra-flow packet priority level to a lower WRED marking as much as possible. Note that the normalization may be recalculated periodically, per packet, or using a heuristic algorithm, as mentioned above.
  • [0042]
    In step 725, the router may then mark the packet with the mapped WRED marking (e.g., DiffSery marking), and places the marked packet into an outgoing network queue for transmission in step 730. Accordingly, in step 735, the router may either forward or drop the marked packet based on the network queue as described above, and the procedure 700 ends in step 740 until another packet is received.
  • [0043]
    It should be noted that while certain steps within procedure 700 may be optional as described above, the steps shown in FIG. 7 are merely examples for illustration, and certain other steps may be included or excluded as desired. Further, while a particular order of the steps is shown, this ordering is merely illustrative, and any suitable arrangement of the steps may be utilized without departing from the scope of the embodiments herein.
  • [0044]
    The techniques described herein, therefore, provide for adaptive marking for WRED with intra-flow packet priorities in network queues. In particular, the techniques herein provide both fairness and better QoS (e.g., video QoS) against network congestion by classifying/marking “per-flow” and then queuing “per-class”, and may be compliant with the existing ECN mechanism for endpoints. For instance, the techniques herein can protect the more important packets (e.g., video packets) in each flow, unless all the less important packets in the same flow are already dropped at congestion, so that the receiver (e.g., client device 110) may see better QoS and quality of experience (QoE) after decoding, while each flow sees fairness in terms of packet drop rates upon network congestion. For example, the techniques herein are able to prioritize video IDR-packets over other flows' packets that may mostly be P-packets instantaneously, while also offering a normalization mechanism for fairness.
  • [0045]
    While there have been shown and described illustrative embodiments that provide for adaptive marking for WRED with intra-flow packet priorities in network queues, it is to be understood that various other adaptations and modifications may be made within the spirit and scope of the embodiments herein. For example, the embodiments have been shown and described herein with specific relation to video flows. However, the embodiments in their broader sense are not as limited, and may, in fact, be used with other types of data flows with intra-flow priorities. In addition, while certain protocols are shown, such as UPD/RTP, other suitable protocols may be used, accordingly. Also, it should be noted that drop/mark precedence for video flows may be based on packet priority or picture importance, and not necessarily on picture type. In other words, some intra-pictures are more important pictures, and may be accounted for properly according to the techniques herein.
  • [0046]
    The foregoing description has been directed to specific embodiments. It will be apparent, however, that other variations and modifications may be made to the described embodiments, with the attainment of some or all of their advantages. For instance, it is expressly contemplated that the components and/or elements described herein can be implemented as software being stored on a tangible (non-transitory) computer-readable medium (e.g., disks/CDs/RAM/EEPROM/etc.) having program instructions executing on a computer, hardware, firmware, or a combination thereof. Accordingly this description is to be taken only by way of example and not to otherwise limit the scope of the embodiments herein. Therefore, it is the object of the appended claims to cover all such variations and modifications as come within the true spirit and scope of the embodiments herein.
Patent Citations
Cited PatentFiling datePublication dateApplicantTitle
US5500899 *May 20, 1982Mar 19, 1996The United States Of America As Represented By The Director, NsaSecure voice conferencing apparatus
US6389468 *Mar 1, 1999May 14, 2002Sun Microsystems, Inc.Method and apparatus for distributing network traffic processing on a multiprocessor computer
US6567861 *Sep 17, 1997May 20, 2003International Business Machines CorporationMethod and apparatus for remotely running objects using data streams and/or complex parameters
US7065779 *Jan 24, 2000Jun 20, 2006Cisco Technology, Inc.Technique for synchronizing multiple access controllers at the head end of an access network
US7139281 *Apr 7, 2000Nov 21, 2006Teliasonera AbMethod, system and router providing active queue management in packet transmission systems
US7349336 *Feb 18, 2003Mar 25, 2008Lucent Technologies Inc.Random early drop with per hop behavior biasing
US7711844 *Aug 15, 2002May 4, 2010Washington University Of St. LouisTCP-splitter: reliable packet monitoring methods and apparatus for high speed networks
US7725919 *May 23, 2002May 25, 2010Microsoft CorporationManage content in a short-term content buffer with content identifiers
US7869428 *Jul 13, 2005Jan 11, 2011Nippon Telegraph And Telephone CorporationPacket transmission method and packet transmission device
US7917648 *Jun 27, 2002Mar 29, 2011Nokia CorporationSelf-adaptive scheduling method and network element
US8005012 *Jan 30, 2009Aug 23, 2011Juniper Networks, Inc.Traffic analysis of data flows
US8027305 *Jan 8, 2007Sep 27, 2011Sprint Communications Company L.P.Communication network and method employing state information in providing communication services to a mobile device
US8046479 *Jul 11, 2007Oct 25, 2011Telefonaktiebolaget Lm Ericsson (Publ)Media channel management
US8085775 *Jul 31, 2006Dec 27, 2011Sable Networks, Inc.Identifying flows based on behavior characteristics and applying user-defined actions
US8194545 *Dec 18, 2009Jun 5, 2012Fujitsu LimitedPacket processing apparatus
US8238241 *Jul 28, 2004Aug 7, 2012Citrix Systems, Inc.Automatic detection and window virtualization for flow control
US8238246 *Jun 17, 2011Aug 7, 2012Juniper Networks, Inc.Filtering and route lookup in a switching device
US8310934 *Oct 17, 2011Nov 13, 2012Huawei Technologies Co., Ltd.Method and device for controlling information channel flow
US8718131 *Apr 21, 2008May 6, 2014Samsung Electronics Co., Ltd.Method and apparatus for generating and processing packet in MPEG-2 transport stream
US8850590 *Mar 5, 2008Sep 30, 2014Broadcom CorporationSystems and methods for using transport stream splicing for programming information security
US8867529 *Sep 20, 2010Oct 21, 2014Cisco Technology, Inc.System and method for providing a fate sharing identifier in a network environment
US20020107908 *Dec 28, 2000Aug 8, 2002Alcatel Usa Sourcing, L.P.QoS monitoring system and method for a high-speed diffserv-capable network element
US20030115480 *Dec 17, 2001Jun 19, 2003Worldcom, Inc.System, method and apparatus that employ virtual private networks to resist IP QoS denial of service attacks
US20030188252 *Mar 27, 2003Oct 2, 2003Se-Hyoung KimApparatus and method for receiving packet data control channel in a mobile communication system
US20040030745 *May 14, 2003Feb 12, 2004Boucher Laurence B.Method and apparatus for distributing network traffic processing on a multiprocessor computer
US20040141530 *Jan 21, 2003Jul 22, 2004The Boeing CompanyMethod and apparatus for very high data rate satellite transmission
US20050094726 *Sep 16, 2004May 5, 2005Samsung Electronics Co., Ltd.System for encoding video data and system for decoding video data
US20070006293 *Jun 30, 2005Jan 4, 2007Santosh BalakrishnanMulti-pattern packet content inspection mechanisms employing tagged values
US20070070907 *Sep 29, 2005Mar 29, 2007Alok KumarMethod and apparatus to implement a very efficient random early detection algorithm in the forwarding path
US20070121615 *Nov 28, 2005May 31, 2007Ofer WeillMethod and apparatus for self-learning of VPNS from combination of unidirectional tunnels in MPLS/VPN networks
US20080013542 *Jul 12, 2007Jan 17, 2008Samsung Electronics Co., Ltd.Apparatus and method for transmitting media data and apparatus and method for receiving media data
US20080056153 *Sep 1, 2006Mar 6, 2008Comcast Cable Holdings, LlcSystem and method for monitoring a data packet
US20080080382 *Sep 28, 2007Apr 3, 2008Dahshan Mostafa HRefined Assured Forwarding Framework for Differentiated Services Architecture
US20080201733 *Dec 21, 2007Aug 21, 2008Phorm Uk, Inc.Systems and methods for channeling client network activity
US20090022134 *Feb 7, 2007Jan 22, 2009Sung-Duck ChunMethod for operating enhanced rlc entity and rnc entity for wcdma and system thereof
US20090241170 *Mar 18, 2009Sep 24, 2009Applied IdentityAccess, priority and bandwidth management based on application identity
US20090287807 *May 13, 2009Nov 19, 2009Sony CorporationManaging apparatus, information processing apparatus, program, and information processing system
US20100043068 *Nov 14, 2008Feb 18, 2010Juniper Networks, Inc.Routing device having integrated mpls-aware firewall
US20100088756 *Oct 7, 2009Apr 8, 2010Intel CorporationMulti-pattern packet content inspection mechanisms employing tagged values
US20100103837 *Nov 12, 2009Apr 29, 2010Jungck Peder JTransparent provisioning of network access to an application
US20110022721 *Oct 19, 2009Jan 27, 2011Wael William DiabMethod and system for packetizing data for servicing traffic end-to-end
US20110110382 *Dec 23, 2009May 12, 2011Cisco Technology, Inc., A Corporation Of CaliforniaDistribution of Packets Among PortChannel Groups of PortChannel Links
US20110113218 *Oct 18, 2010May 12, 2011Electronics And Telecommunications Research InstituteCross flow parallel processing method and system
US20110158146 *Dec 29, 2009Jun 30, 2011Jeelan PoolaMethod and system for multicast video streaming over a wireless local area network (wlan)
US20110216774 *Mar 2, 2010Sep 8, 2011Intrusion Inc.Packet file system
US20110255408 *Jun 30, 2011Oct 20, 2011Juniper Networks, Inc.Traffic analysis of data flows
US20110295983 *Aug 23, 2010Dec 1, 2011Juniper Networks, Inc.Application-layer traffic optimization service endpoint type attribute
US20110317557 *Jun 28, 2010Dec 29, 2011Alcatel-Lucent Canada, Inc.System and method for generating and updating pcc rules based on service requests
US20120014282 *Sep 23, 2011Jan 19, 2012Pappu Surya KIdentifying flows based on behavior characteristics and applying user-defined actions
IB03103238A1 * Title not available
Non-Patent Citations
Reference
1 *J. Shin, JongWon Kim, D. C. Lee and C. C. J. Kuo, "Adaptive packet forwarding for relative differentiated services and categorized packet video," Communications, 2001. ICC 2001. IEEE International Conference on, Helsinki, 2001, pp. 763-767 vol.3.doi: 10.1109/ICC.2001.937342
2 *Jitae Shin et al., titled "Quality of Service Mapping Mechanism for Packet Video in Differentiated Services Network" (SHIN hereinafter) was presented in part at Packet Video Workshop 2000, Sardinia Italy, May 2000.
3 *Jitae Shin et al., titled ‚ Quality of Service Mapping Mechanism for Packet Video in Differentiated Services Network‚ (SHIN hereinafter) was presented in part at Packet Video Workshop 2000, Sardinia Italy, May 2000.
4 *Title, "Providing Fairness in Diffserv Architecture created by Sungwon Yi, Xidong Deng, George Kesidis, and Chita R. DasDepartment of Computer Science & Engineering The Pennsylvania State University, University Park, PA 16802
Referenced by
Citing PatentFiling datePublication dateApplicantTitle
US20150078395 *Sep 3, 2014Mar 19, 2015Fujitsu LimitedTraffic control apparatus, buffering control method and packet relay apparatus
Classifications
U.S. Classification370/412
International ClassificationH04L12/863
Cooperative ClassificationH04N21/64792, H04L47/32, H04L47/2433, H04L47/2416, H04L47/6215
Legal Events
DateCodeEventDescription
Jul 16, 2013ASAssignment
Owner name: CISCO TECHNOLOGY, INC., CALIFORNIA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:LAI, CHENG-JIA;WANG, WENYI;YANG, SHIH-CHENG STAN;REEL/FRAME:030805/0363
Effective date: 20130715