I|||||||||||||||||||||I|||I|||||||||I||l||||||||||||||||||||||||||||||III||||||||||||II||
`
`US 20080l44502Al
`
`(19) United States
`(12; Patent Application Publication (10) Pub. N0.: US 2008/0144502 A1
`Jackowski et a].
`(43) Pub. Date:
`Jun. 19, 2008
`
`(54)
`
`[IV—BAN I) QUALITY—OF-SERVICE
`SIGNALING TO ENDPOINTS THAT
`ENFORCE TRAFFIC POLICIES AT TRAFFIC
`SOURCES USING POLICY MESSAGES
`PIGGYBACKICD ONTO Dlli‘Ii‘Sl'CRV BITS
`
`(75)
`
`Inventors:
`
`Steven J. Jackowski. Santa C 1112.
`(‘A (US): Seith K. Keith. Ins
`Gatos. CA (US)
`
`Correspondence Address:
`STUART 'l‘ AUVIN 1*] N
`429 26TH AVENUE
`SANTA CRUZ. (IA 95062-5319
`
`(73)
`
`Assignee:
`
`DETERMINIS'I'IC NETWORKS,
`INC.. Santa Cruz. (TA (US)
`
`(21)
`
`Appl. No;
`
`ll!613,073
`
`(22)
`
`Filed:
`
`Dec. 19., 2006
`
`Publication Classification
`
`Int. (11.
`H041. 12/156
`[1.5. Ci.
`
`(5 I)
`
`(52}
`
`(57}
`
`(2006.01)
`
`ABSTRACT
`
`3701'235
`
`11’ packets are scheduled at source devices such as cell phones
`on a private network that connect to the lnlernet at an edge
`device. A private trailic controller by the edge device detects
`pre—Intcrnet congestion on the private network. The private
`traffic controller uses in—band piggybackcd signaling of
`policy changes by intercepting return packets to the source
`devices and modifying hits such as DSCP bits in the header.
`Source traffic controllers in the source devices read the modi-
`lied DSCP hits and implement specified policy changes.
`dropping or delaying packets at the source device before
`transmission. Congestion on RF links from cell phones is
`reduced by the source traflic controllers dropping packets
`before transmission. The source device limits or drops future
`packets in response to the policies signaled by the DSC P bits.
`Rather than indicate the existing packet's priority. private
`DSCI‘ bits signal policy changes to the source device.
`
`
`
`TRAFFIC
`
`CTLR fl
`
`SRC
`TRAFFIC
`
`
`
`
`SERVER
`
`fl
`
`POLICY
`
`PKTS
`
`ROUTER
`
`1_CI
`
`
`
`
`INTERNET
`EDGE
`IL'IEVICEfl
`
`RETURN
`PRIVATE
`
`PACKET
`
`CEL LU LAR
`MODIFIER
`
`NETWORK
`
`
`as
`
`RFQ
`BASE
`STATION
`
`PRIVATE
`TRAFFIC
`
`CTLR g
`
`PRIVATE
`NETWORK
`MONITOR
`
`Microsoft
`
`Ex.1017- Page 1
`
`Microsoft
`Ex. 1017 - Page 1
`
`

`

`PatentApplication Publication
`
`Jun. 19, 2008 Sheet 1 0f 11
`
`US 2008l0144502 A1
`
`FIG. 1
`
`PRIOR ART
`
`
`
`
`12
`
`
`12
`
`DRO‘F)
`
`IP
`
`20
`
`24
`
`PKTS
`
`IPv4
`
`26
`
`PRIOR ART
`
`SRC
`TYPE OF
`VER LEN SERVICE FLAGS CKSM IP
`
`
`
`(1'08)
`
`ADR
`
`ADR
`
`
`
`FIG. 2A
`
`DST
`|p
`
`DATA
`
`122 124;
`
`126
`
`126
`
`132
`
`134
`
`136
`
`6—BIT
`'3' DSCP
`°
`
`.
`
`'
`
`22
`
`415
`
`DEFAULT. BEST-EFFORT;
`
`EXPEDITED FORWARDING;
`ASSURED FORWARDING;
`CLASS SELECTOR PHB'S
`
`w
`
`FIG. 2B
`
`
`
`TRAFFIC FLOW
`VER CLASS
`LBL
`(TC)
`
`NXT
`LEN HDR 3?:
`
`SRC
`1p
`ADR
`
`DST
`1p
`ADR
`
`DATA
`
`122
`
`144
`
`142
`
`124
`
`146
`
`148
`
`132
`
`134
`
`136
`
`Microsoft
`
`Ex. 1017 - Page 2
`
`Microsoft
`Ex. 1017 - Page 2
`
`

`

`PatentApplication Publication
`
`Jun. 19, 2008 Sheet 2 0f 11
`
`US 20081’0144502 A1
`
`
`
`
`TRAFFIC
`CTLR §§
`
`
`
`PRIVATE
`
`
`
`CELLULAR
`NETWORK
`E
`
`ROUTER
`
`RF 3
`BASE
`
`/ STATION
`
`INTERNET
`EDGE 38
`
`DEVICE—
`
`Ell
`=_=
`
`E
`55
`
`—
`
`2—3
`-:
`
`@
`
`@
`
`
`
`
`PRE-INTERNET
`CONGESTlON
`
`FIG- 3
`
`
`
`30
`
`PRIOR ART
`
`Microsoft
`
`Ex. 1017 - Page 3
`
`Microsoft
`Ex. 1017 - Page 3
`
`

`

`PatentApplication Publication
`
`Jun. 19, 2008 Sheet 3 0f 11
`
`US 20081’0144502 A1
`
`(-Hllg
`
`.NCRYPT
`
`.OUTER.0
`
`SERVER
`
`
`fl
`
`
`DECRYPT
`
`PRIOR ART
`
`F:|(3. 41
`
`Microsoft
`
`Ex. 1017 - Page 4
`
`Microsoft
`Ex. 1017 - Page 4
`
`

`

`PatentApplication Publication
`
`Jun. 19, 2008 Sheet 4 0f 11
`
`US 20081’0144502 A1
`
`SRC
`
`TRAFHC
`
`
`
`
`l
`SERVER
`
`
`TRAFHC
`
`CTLR §§
`
`PKTS
`
`‘—
`
`ROUTER
`
`1g
`
`
`
`
`SRC
`
`TRAFFIC
`CTLR fl
`
`SRC
`TRAFFIC
`
`CTLR 50
`
`PRIVATE
`CEI—I-U LAR
`NETWORK
`
`3g
`
`PRIVATE
`
`NETWORK
`
`MONITOR
`
`INTERNET
`
`EDGE 38
`DEVICE—
`
`RETURN
`
`PACKET
`MODIFIER
`
`gg
`
`RF
`BASE
`
`STATION
`
`PRIVATE
`
`TRAFFIC
`
`CTLR 2
`
`Microsoft
`
`Ex. 1017 - Page 5
`
`Microsoft
`Ex. 1017 - Page 5
`
`

`

`PatentApplication Publication
`
`Jun. 19, 2008 Sheet 5 0f 11
`
`US 20081’0144502 A1
`
`CTLR E
`
`REQ PKT
`
`REQ PKT
`
`SRC
`TRAFFIC
`
`CLIENT DATA
`
`CLIENT DATA
`
` INTERN ET
`fl
`
`SRC
`
`TRAFFIC
`
`CTLR E
`
`INTERNET
`
`EDGE
`DEVICEE
`
`;
`
`58
`
`1‘
`RETURN
`DSCP
`_ -.
`PACKET
`WRITER
`. ‘.
`MODIFIER
`
`
`CELLULAR
`
`
`
` PRIVATE
`
`
`
`NETWORK
`
`
`
`SRC
`
`TRAFFIC
`CTLR fl
`
`E
`
`PRIVATE
`NETWORK
`
`MONITOR
`
`RF _
`BASE
`
`STATION
`
`STATUS
`
`PRIVATE
`TRAFFIC
`
`CTLR Q
`
`ACTIVATE
`
`Microsoft
`
`Ex. 1017 - Page 6
`
`Microsoft
`Ex. 1017 - Page 6
`
`

`

`PatentApplication Publication
`
`Jun. 19, 2008 Sheet 6 0f 11
`
`US 2008l0144502 A1
`
`SRC
`
`TRAFFIC
`
`CTLR 50
`
`SRC
`TRAFFIC
`
`CTLR 50
`
`SERVER
`
`@
`
`RTN PKT
`
`SVR DATA
`
`
`INTERNET
`_
`l
`
`.l
`
`A"
`
`INTERNET
`EDGE
`DEVICEfi
`
`58
`
`
`
`
`
`RETURN
`DSCP
`
`PACKET
`WRITER
`MODIFIER
`
`
`
`SRC
`TRAFFIC
`CTLR fill
`
`PRIVATE
`NETWORK
`
`STATUS
`
`PRIVATE
`TRAFFIC
`
`
`MONITOR
`CTLR Q
`ACTIVATE
`
`Microsoft
`
`Ex. 1017 - Page 7
`
`PRIVATE
`CELLULAR
`NETWORK
`
`E
`
`32
`RF
`BASE _
`STATION
`
`DSCP=MSG
`
`
`
`
`Microsoft
`Ex. 1017 - Page 7
`
`

`

`PatentApplication Publication
`
`Jun. 19, 2008 Sheet 7 0f 11
`
`US 20081’0144502 A1
`
`
`
`
`
`§§
`
`
`SRC
`TRAFFIC
`
`CTLR fl
`
`SRC
`TRAFFIC
`
`CTLR E
`
`PRIVATE
`
`CELLULAR
`NETWORK
`
`SRC
`TRAFFIC
`CTuaéfl
`
`STATUS
`
`PHVATE
`NETWORK
`MONITOR
`
`DEVICE E RETURN
`
`SERVER
`
`@
`
`RTN PKT
`
`SVR DATA
`
`RTN PKT
`
`DSCP=MSG
`
`SVR DATA
`
` INTERN ET
`E .
`
`INTERN ET
`EDGE
`
`PACKET
`
`MODIFIER
`
`RF_
`BASE
`
`STATION
`
`PRNATE
`TRAFFIC
`CTLR fl
`
`ACTIVATE
`
`Microsoft
`
`Ex. 1017 - Page 8
`
`Microsoft
`Ex. 1017 - Page 8
`
`

`

`PatentApplication Publication
`
`Jun. 19, 2008 Sheet 8 0f 11
`
`US 2008l0144502 A1
`
`SVR DATA
`
`SERVER
`
`fl
`
` INTERNET
`fl
`
`
`
`
`E
` PRIVATE
`
`
`
`SRC
`
`TRAFFIC
`
`CTLR E
`
`SRO
`TRAFFIC
`CTLRQQ
`
`58
`
`DSCP
`WRITER
`
`DSCP=MSG
`
`INTERNET
`
`EDGE
`DEVICEE
`
`RETURN
`PACKET
`MODIFIER
`
`32
`RF
`BASE _
`STATION
`
`PRIVATE
`TRAFFIC
`
`CTLR 5—2
`
`CELLULAR
`
`NETWORK
`
`STATUS
`
`PRIVATE
`NETWORK
`
`MONITOR
`
`Microsoft
`
`Ex. 1017 - Page 9
`
`Microsoft
`Ex. 1017 - Page 9
`
`

`

`PatentApplication Publication
`
`Jun. 19, 2008 Sheet 9 0f 11
`
`US 20081’0144502 A1
`
`POLICY
`
`AGENT
`
`T74
`
`SIGNALLING
`
`PROTOCOL
`
`MODULE 7—0
`
`INCOMING
`66
`PACKET —
`SCHEDULER
`
`OUTGOING
`6—7
`PACKET
`SCH EDULER
`
`XMIT E
`MEDIA
`
`DRIVER LOCAL fl
`
`PROCESSES
`
`SOURCE TRAFFIC
`
`CONTROLLER
`
`50
`
`FIG. 7
`
`Microsoft
`
`Ex.1017- Page 10
`
`Microsoft
`Ex. 1017 - Page 10
`
`

`

`PatentApplication Publication
`
`Jun. 19, 2008 Sheet 10 ofll
`
`US 2008l0144502 A1
`
`SCH EDULERS PRIVATE TRAFFIC
`
`SIGNALLING
`
`PROTOCOL
`
`MODULE @
`
`OUTGOING
`PACKET E
`
`XMIT
`NETWORK
`
`38
`
`INCOMING
`PACKET E
`
`SCHEDULER
`
`CONTROLLER
`
`99-
`
`INTERFACES
`
`FIG. 8
`
`Microsoft
`
`Ex.1017- Page 11
`
`Microsoft
`Ex. 1017 - Page 11
`
`

`

`PatentApplication Publication
`
`Jun. 19, 2008 Sheet 11 ofll
`
`US 20081’0144502 A1
`
`TRIGGERWG
`PRIVATE TRAFFIC
`EVENT
`CONTROLLER 90
`— ..... DETECTED
`‘_______
`_______________D_919?: -SEET POLICY
`________________ ’
`
`—30URCETRAFF'C
`
`99W 50
`_
`
`DSCP= ACK SET ...................... '
`¢_____________________
`
`_______________Os_C_P= |NDX1=5
`____________________ *
`
`DSCP= ACK |NDX1 ...................... '
`4- _____________________
`
`_______________qs_c_:P= |NDX2=3
`_____________________ .
`
`DSCP= ACK INDXZ ...................... T
`4- .................
`
`_______________D-3193: POLICY RULE
`____________________ .
`
`DSCP= ACK RULE .......................'
`
`4'"""""""""
`
`l
`
`SOURCE
`POLICY
`
`FIG 9
`
`IMPLEMENTED
`
`Microsoft
`
`Ex.1017- Page 12
`
`Microsoft
`Ex. 1017 - Page 12
`
`

`

`US 2008K} 144502 Al
`
`Jun. 19, 2008
`
`IN-BAND QUALITY-OF—SERVICE
`SIGNALING TO ENDPOINTS 'l‘I-IAT
`ENFORCE TRAFFIC POLICIES AT TRAFFIC
`SOURCES USING POLICY MESSAGES
`PIGGYBACKEI) ONTO DI FFSERV BITS
`
`FIELD OF THE INVENTION
`
`[0001] This invention relates to network traffic control. and
`more particularly to in~band signaling to traffic sources for
`source control.
`
`BACKGROUND OF THE INVENTION
`
`[0002] Networks such as the public Internet and private
`cellular networks carry data that is encapsulated by packets
`that are switched through the networks. As user applications
`become more sophisticated. the amount of data increases.
`such as to carry video rather thanjust voice. Networks tend to
`get swamped by such increases in traffic.
`Intermediate
`switches or routers may be overwhelmed by the number of
`packets received and [nay be forced to drop sortie of the
`packets.
`[0003] Various trafiic control techniques have been imple-
`mented. Rather than just drop packets randomly.
`traffic
`classes can be established. Packets fora lower-priority traffic
`class are drapped, while packets with higher-priority traffic
`classes are passed through a congested router. Thus the lim-
`ited bandwidth of a congested router can be reserved for
`higher-priority traffic. The Quality-of-Service (QoS)
`for
`[uglier-priority packets can be improved.
`traffic
`[0004] Quality of Service (Q08) ensures that
`receives the correct attention in a network. Inherently. the
`Internet
`fairly shares network resources on a packet-by-
`packet basis. However, difi'erent types of traffic may need
`different levels of service. Unfortunately the type of traffic is
`not visible on a packet by packet basis. Quality of Service
`encompasses a variety of traflfic characteristics and control
`methods. Priority. maximum bandwidth, minimum band—
`width, latency, jitter, and error rates are parameters for (208.
`[0005]
`FIG. 1 slums a prior-art router that drops packets
`based on QoS rules. Router 10 is an intermediate node in a
`network such as the Internet and receives Internet Protocol
`(IF) packets 12. and routes these IP packets to other routers or
`devices along paths toward the packets’ destinations.
`[0006]
`Sometimes router 10 receives more incoming IP
`packets 12 than it can process. Router 10 may have an input
`buffer or queue that can store a limited amount ofdata. When
`too many Il’ packets 12 are received in a short period oftirne.
`this input buffer can fill up. and any additional IP packets are
`lost since there is no more room in the input buffer. Even when
`the input buffer does not overflow. packets entering the input
`buffer may be significantly delayed.
`[0007]
`To prevent this input—bufl‘er overflow. router 10
`implements a tratfic policy to guarantee a Quality—of—Service
`(Q08) for some higher-priority packets. Q08 rules 14 are
`received from a centraliaed QoS traffic controller that moni-
`tors network tratl'ic and issues updated to Q08 rules 14 as
`network conditions change. For example. when there is no
`congestion on the network, QoS rules 14 may instruct router
`10 to pass all IP packets 12 through. However. when sortie
`network congestion is detected. QoS rules 14 may be updated,
`causing router 10 to drop packets that have the lowest priority
`level. while passing higher-priority ll" packets 12 to its output.
`
`[0008] Using QoS rules helps to ensure that higher-priority
`packets are provided with a higher level or quality ofservice.
`For example. streaming data such as voice or video transmisv
`sions. or traffic from users who pay a premium for premium
`service. may have packets marked for a higher level ofservicc
`than data packets for web browsing or for text messages that
`may be safely delayed.
`[0009]
`FIGS. 2A-l3 show IP packets marked for service
`levels. FIG. 2A shows an older 11’ version 4 [IPv4) packet.
`IPv4 packet 20 carries data in data field 136 that is preceded
`by an IP header. Data lield I36 may contain headers for
`higher-level protocols, such as a 'l‘ransport-(Iontrol-Protocol
`(PCP) header. Version field 122 indicates the IP version that
`packet 20 is using. Length field 124 indicates the packet‘s
`length. while source IP address field 132 contains the IP
`address of the packet‘s source or sender. while destination IP
`address field 134 contains the IP address of the packet’s
`destination or ultimate receiver. These IP addresses may be
`altered such as to hide the sender’s true IP address behind a
`firewall. or to redirect or load-balance destination servers.
`
`[0010] Checksum field 128 contains a cyclical-redun-
`dancy-check (C RC J checksum of packet 20 that is useful for
`detecting errors. Flags 126 contain various flags.
`[0011] Typecf—service TOS field 26 is used to indicate the
`service level or priority. A widely used QoS protocol is Dif—
`ferentiated Services [l')ilI‘Serv). which uses 6 bits in T08 field
`26 that are known as the I.)ilTerentiatcd Services Code Point
`(DSCP) bits. The DSCP bits 22 in T08 field 26 can be set to
`certain predefined values to indicate the packet‘s traffic level
`or priority.
`[0012]
`For example. DSCI’ bits 22 in T08 field 26 can be
`set to indicate a lowest priority, which is the default. A router
`uses its best efforts to pass a packet with this default service
`level. A higher level of service is expedited Rim-aiding. while
`assured forwarding is an even higher level of service. Packets
`marked for assured forwarding are much more likely to be
`processed through a router than default packets. which are
`most likely to be dropped when congestion occurs.
`[0013] DSCP bits 22 in T08 field 26 can be set to other
`values. such as for class Selector per-hop-Ixthaviors {PI 18‘s]
`that can more precisely control service at certain routers.
`[0014]
`F 16. 213 shows a newer 1? version 6 (IPv6) packet.
`IPv6 packet 24 carries data in data field 136, and also has
`version field 122. length field 124. source IP address field
`132. and destination IP address field 134. Flow label field 142
`and next header field 146 allow for expanded functionality.
`[0015] Traffic class field 144 contains DSCP bits 22. much
`as 'l‘OS field 26 did for IPv4 packet 20. The traffic class or
`priority of this packet cart be set by 0861’ hits 22 in traffic
`class field 144. Hop limit field 148 can be used for limiting
`hops. which can also be used to network control tra fiic.
`[0016]
`FIG. 3 shows pro-Internet congestions despite (205
`traffic control on the Internet. Traffic control using QoS rules
`and Dift‘Serv setting of DSCP bits 22 in Haiti: class or type—
`of-service bytes in IP packets can help to manage traffic
`within lnterrtet 34. Traffic controller 33 monitors tra the and
`
`congestion and sends policy packets 35 to devices such as
`router 10 and edge device 38 to regulate tralfic. Policy packets
`35 can set QoS rules that indicate when to drop packets and
`what trafi‘lc classes to process.
`[0017] QoS policies may be implemented in two distinct
`entities: a policy decision point (PDP) and a policy enforce—
`ment point (PEP). In practice. these are often run in the same
`physical device, such as in a traffic controller. Traffic control-
`
`Microsoft
`
`Ex.1017- Page 13
`
`Microsoft
`Ex. 1017 - Page 13
`
`

`

`US 2008K} 144502 Al
`
`Jun. 19, 2008
`
`ler 33 is a Policy Decision Point (PD?) while routers and edge
`devices act as Policy Enforcement Points (PEP).
`[0018] While such traffic control is effective in handling
`congestion on Internet 34, sometimes congestion can occur in
`locations that are not controlled by trailic controller 33. For
`example. private cellular network 36 has thousands of cell
`phones 30 that send packets by radio-frequency (RF) trans-
`mission to base stations 32. Base station 32 refomlats these
`packets and sends them to edge device 38, where the packets
`enter Internet 34. The packets are then routed through Internet
`34.
`
`Intermediate devices such as router II] and edge
`[0019]
`device 38 can regulate packets from cell phones 30 using QoS
`rules. but only once these packets reach Internet 34. When too
`many packets are sent from cell phones 30. packets are
`dropped as they enter Internet 34. at edge device 38. However.
`these packets still pass between cell phones 30 and base
`station 32 before reaching edge device 38. causing congestion
`on the RI" links. This pro-Internet congestion on private cel-
`lular network 36 is undesirable. since voice calls may be
`blocked by IP packets to edge device 38 that are ultimately
`dropped.
`[0020] RF bandwidth is wasted by these dropped packets.
`Cell phones 30 may simply retransmit these packets over and
`over again. clogging the RI“ links with packets that are tilti-
`mately dropped by the Internet edge device anyway.
`[002]]
`l-‘IG. 4 shows that a virtual-private-netwurk (V’PN)
`tunnel can frustrate traffic control. Encryptor 42 on cell
`phones 30 or on another device before the Internet edge
`device may encrypt data in IP packets. The encrypted IP
`packets are sent over the Internet and routed by router 1t) and
`others to server 40. the destination. Server 40 decrypts the
`data in the IP packets using decryption software 44.
`[0022]
`Iincrypting the data in IP packets prevents others
`from reading the encrypted data. However. some higher—level
`[leaders may be included in the data field that is encrypted.
`These higher-level protocols may include information such as
`the name or type ofapplication program. a higher-level port.
`or flow information that may be useful in classifying the IP
`packets into trallic classes. A trailic classifier that looks for
`such information to classify the IF packet by writing DSCP
`bits 22 using Difi‘Serv may not be able to classify encrypted
`packets. and may use the lowest-priority default setting.
`[0023] When the traffic classifier examines packets within
`the VPN tunnel. after encryptor 42. information from these
`higher-level protocols can be hidden, preventing proper clas-
`sification. Intermediate routers such as router 10 are forced to
`use default priority settings, or must guess at the traffic class
`of these packets. Thus intermediate traffic control. such as
`within Internet 34 of FIG. 3. may be thwarted by packet
`encryption.
`[0024] What is desired is a traffic control mechanism that is
`effect ive despite packet encryption and VPN tunnels. A tratIic
`controller that can control traffic on both the Internet and on
`
`pro-Internet private networks is desirable. A traffic controller
`that adjusts packet traffic at the source is desirable to avoid
`bandwidth wasted by transmission of packets that are later
`dropped.
`
`BRIEF DESCRIPTION 01" Till? DRAWINGS
`
`FIG. 1 shows a prior~art router that drops packets
`[0025]
`based on QoS rules.
`[0026]
`PIGS. 2A-13 show IP packets marked for service
`levels.
`
`FIG. 3 shows pre-Intemet congestions despite QOS
`[0027]
`tratfrc control on the Internet.
`
`FIG. 4 shows that a virtual-privatehetwork (VPN)
`[0028]
`tunnel can frustrate traffic control.
`[0029]
`FIG. 5 highlights source tra Ilic control.
`[0030]
`FIGS. 6A-D illustrate source-based traffic control
`using in-band signaling of return packets.
`[0031]
`FIG. 7 is a block diagram ofa source traffic control-
`ler.
`
`[0032]
`ler.
`
`FIG. 8 is a block diagram ofa private traffic control~
`
`FIG. 9 is a flow diagram of meSsages being
`[0033]
`exchanged between a source tratfic controller and the private
`traffic controller.
`
`DETAILED DESCRIPTION
`
`[0034] The present invention relates to an improvement in
`pre—Internet traffic control. The following description is pre—
`sented to enable one of ordinary skill in the art to make and
`use the invention as provided in the context of a particular
`application and its requirements. Various modifications to the
`preferred embodiment will be apparent to those with skill in
`the art. and the general principles defined herein may be
`applied to other embodiments. Therefore, the present inven-
`tion is not intended to be limited to the particular embodi~
`ments shown and described. but is to be accorded the widest
`scope consistent with the principles and novel features herein
`disclosed.
`
`[0035] The inventors have realized that congestion on pri-
`vate networks before reaching the edge ofthe Internet can be
`a problem even when Internet traffic control methods such as
`QoS and DiffServ are deployed. Standard traffic control
`methods do not reach back into these private networks. The
`inventors realize that controlling tratllc at the source of the
`traffic can relieve pro-Internet congestion as well as lntemet
`congestion.
`[0036] The inventors further realize that generating addi-
`tional policy packets to control traffic is counter-productive.
`since the additional policy packets add to the congestion.
`Instead. iii—band signaling of policy using existing packets is
`desirable. since no additional packets are sent to signal policy
`changes. A further improvement to in-band signaling is to
`piggyback the policy information so that the sizes of the
`packet do not have to increase. Policy changes are signaled
`in-band by using existing packets. Policy changes are further
`piggybacked by setting trafl'ic control bits in the packets. The
`DSCP bits are used for this signaling, not to set the existing
`packet‘ s priority. but to signal the source device without using
`additional bandwidth. The source device Illen limits or drops
`future packets in response to the policies signaled by the
`DSCP bits.
`[0037] The standard use of DSCP bits is to indicate the
`priority of the current packet carrying DSCP bits. Each QoS
`router reads these DSCP bits from the current packet as that
`(208 router is switching the current packet. The inventors
`realize that the DSCP bits can be used in a different way to
`send a message back to the source of the packets. to instruct
`the source to stop or reduce transmission rates of future pack-
`ets.
`
`FIG. 5 highlights source traffic control. Source trafv
`[0038]
`fic controllers 50 are installed on cell phones 30. which are the
`source devices that generate packets sent over private cellular
`network 36 and Internet 34 to server 40 and other servers.
`
`Source traffic controllers 50 can be activated to drop packets
`
`Microsoft
`
`Ex. 1017 - Page 14
`
`Microsoft
`Ex. 1017 - Page 14
`
`

`

`US 2008K} 144502 AI
`
`Jun. 19, 2008
`
`before being transmitted over RF links to base station 32 by
`in-band signaling. Return packets from server 40 back to cell
`phones 30 are intercepted by return packet modifier 60. which
`sets DSCP bits in the return packets. When the modified
`return packet reaches cell phones 30. source traffic controllers
`50 detect the set DSC‘P bits and extract the traffic-control
`instructions. Traffic-control
`instructions can cause source
`
`traffic controllers 50 to drop future packets. to change the
`priorities of packets. to adjust latencies and jitter. and to
`provide for bandwidth limits and guarantees. Back—pressure
`can be applied to the source applications, causing source
`applications to reduce packet transmission rates.
`[0039] Once congestion on private cellular network 36
`cases as more cell phones 30 drop or delay packets before
`transmission. private network tnonitor 54 detects the reduc-
`tion in congestion. and signals the spare bandwidth to private
`traffic controller 52. Private traffic controller 52 adjusts the
`current policies on private cellular network 36 and instructs
`return packet modifier 60 to intercept return packets to cell
`phones 30. Return packet modifier 60 sets [)S(.‘P bits in these
`return packets. and when these return packets are received by
`cell phones 30. their source traffic controllers 50 read the
`DSCP bits and adjust their traffic policies. For example. the
`policy may be adjusted so that source traflfic controllers 50 no
`longer drop or delay packets.
`[0040]
`Tire flow of packets over private cellular network 36
`and into Internet 34 is controlled at the source of the packets.
`on cell phones 30. Source traffic controllers 50 can drop or
`delay packet transmission. freeing up bandwidth on the RF
`links to base station 32. Congestion is also reduced at down-
`stream locations. such as at edge device 38 and router 10 on
`Internet 34.
`
`[0041] This private traffic control can co-cxist with prior-
`art (205 signaling that controls trafiic within Internet 34.
`Traffic controller 33 generates policy packets 35 that are sent
`to router I 0. edge device 38. and other devices within Internet
`34 to signal QoS policies to implement using prior-art QoS
`signaling and traffic control. However. such priorvart QoS
`signaling is not effective at controlling traffic on private cel—
`lular network 36 since this is a private network before edge
`device 38.
`
`FIGS. 6A-D illustrate source-based traffic control
`[0042]
`using ill-band signaling of return packets. In FIG. 6A. a
`micro-browser or other application running on cell phone 30
`generates a request that causes request packet 62 to be sent
`across RF links to base station 32. The DSCP bits in request
`packet 62 are set to a default value. indicating that request
`packet 62 has a low priority for QoS-enabled routers such as
`router 10. Client data such as a cookie, query data, account
`information. etc. may be included in request packet 62. More
`than one request packet 62 may be sent. and several request
`and return packets may be exchanged with server 40.
`[0043] Base station 32 receives request packet 62 and for—
`wards it to edge device 38. which sends request packet 62'
`through Internet 34 to server 40. the destination of request
`packet 62. Some modification of reqimst packet 62 may occur
`during routing.
`[0044] Congestion on private cellular network 36 is
`detected by private network monitor 54. A status indicating
`the congestion is sent from private network monitor 54 to
`private traffic controller 52. Private traffic controller 52
`responds to the congestion by imposing tigrter policy restric—
`tions on cell phones 30. Return packet modifier 60 is activated
`by private traffic controller 52 to modify return packets to cell
`
`phones 30 to send the new policy to source traffic controllers
`50. Return packet modifier 60 waits for a retum packet to
`arrive from Internet 34.
`
`In FIG. 1513, server 40 responds to the client requests
`[0045]
`in request packet 62' by generating server data that is encap-
`sulated in one or more return packets 64. Return packet 64 has
`its destination address set
`to the source IP address from
`
`request packet 62' which is for one of cell phones 30. Retum
`packet 64 is routed through renters in Internet 34 and arrives
`at edge device 38 as it exits Internet 34 and enters private
`cellular network 36.
`[0046]
`In I'IG. 6C, private traffic controller 52 activates
`DSCP code generator 56 to generate an iii-band message to
`cell phones 30 to implement the new traffic policy. A special
`encoding of the 6 DSC‘P bits carries the message about the
`new traffic policy. When return packet 64 passes through edge
`device 38. it is sent to return packet modifier 60. DSC P writer
`58 over—writes the DSCP bits in retum packet 64 with the
`message MSG front private traffic controller 52. Modified
`return packet 64' is sent from return packet modifier 60 to base
`station 32. and is transmitted over the RF links of private
`cellular network 36 to cell phone 30.
`[0047]
`In FIG. 6]). cell phone 30 receives modified retum
`packet 64' with message MSG in the DSCP bits. The server
`data in return packet 64‘
`is sent
`to the application that
`requested the server data. Source traffic controller 50 detects
`that the DSCP bits contain message MSG. since the DSCP
`bits are marked as a “private DSCP". Source traffic controller
`50 decodes the embedded message MSG. and implements the
`new traffic policy.
`[0048]
`For example. message MSG may indicate to drop all
`data packets. but allow voice packets. Any data packets gen~
`eraled in the future by applications on cell phone 30 are
`dropped or prevented from being transmitted by source traffic
`controller 50. Voice packets may continue to be transmitted.
`[0049] Altemately. the message may limit the bandwidth
`used by cell phone 30. The policy may indicate a number of
`packets or aggregate size of data that may be transmitted by
`cell phone 30 over a period oftime such as 1 second. Once the
`limit is reached. Source traffic controller 50 blocks further
`packet transmission ttnlil the I second time limit has expired.
`[0050]
`Policies can be triggered for congestion control, to
`give different levels of service to users or applications. and to
`provide better network control by the users or by the network
`operators. 'I‘ne policies themselves may differ on different
`source endpoints. Policies may include bandwidth limits.
`guarantees. or priorities for the user, system. application.
`Policies may also include priorities to certain destinations
`(such as favoring the servers at the carrier as opposed to those
`on the Internet). latency guarantees. jitter controls. Policies
`may also block destinations. applications, and certain traffic
`types (cg broadcast traffic). Policies may include requests
`for additional bandwidth or access permissions. and may
`limit the number of sessions from this host. Many other poli—
`cies could be implemented.
`[0051] Other retum packets to other cell phones 30 could
`also be intercepted by return packet modifier 60 and modified
`with message MSG. causing the bandwidth used by cell
`phones 30 to decrease as more and more cell phones imple-
`ment the new traffic policy. Some cell phones 30 may not be
`transmitting request packets and thus may not receive return
`packets with the new policy: however, since they are not
`generating traffic. not receiving the new traffic policy has
`little effect on the bandwidth usage. Cell phones that are
`
`Microsoft
`
`Ex.1017- Page 15
`
`Microsoft
`Ex. 1017 - Page 15
`
`

`

`US 2008K} 144502 Al
`
`Jun. 19, 2008
`
`actively sending packets and causing the congestion are
`throttled back more rapidly than othercell phones that arej ust
`sending requests sporadically. Thus private traffic controller
`52 tends to target the sources that are causing the congestion.
`[0052]
`Private traffic controller 52 could also specify that
`some cell phones are signaled with the new policy while other
`cell phones are not signaled. A destination IP-address filter in
`return packet modifier 60 can identify which return packets to
`modify. Cell phones for users on a premium service plan
`could be allowed to continue with a less restrictive traffic
`policy while cell phones for lower-cost plans could receive
`return packets with the new restrictive policy.
`[0053]
`FIG. 7 is a block diagram ot'a source traffic control-
`ler. Source traffic controller 50 can intercept inbound and
`outbound packets. Inbound packets [such as return packets
`from servers) are received by media receiver 78 and pass
`through packet filer 72. Signaling protocol module 70 reads
`the DSCP bits in the header of each inbound packet and
`compares the values of the DSCP bits to pre-dcfined values.
`Sometimes the DSCP bits match values defined by DiffScrv
`or other public protocols. and these DSC P values are ignored
`by signaling protocol [nodule 70, and the packets are passed
`on to incoming packet scheduler 66 to be sent to one of local
`processes 68 that are running on the local client device (such
`as cell phone 30 ). An application table may be used by incom—
`ing packet scheduler 66 to associate incoming packets with
`applications and their local processes 68. such as by matching
`ports or sockets from higher—level headers in the data field.
`[0054] When the DSCP bits match proprietary values
`defined by the private traffic controller. signaling protocol
`module ’70 decodes these DSCI’ bits to re-generate the mes-
`sage that was sent by private traffic controller 52 (FIGS. 5, 6).
`This message may set, clear. or modify a current policy that is
`implemented by policy agent '74. For example. the message
`may be to stop all outgoing data packets.
`[0055] Once the DSCP bits are read. signaling protocol
`module 70 passes the incoming packet to incoming packet
`scheduler 66 to be sent to one of local processes 68. The
`server data in the return packet can be sent to the requesting
`application.
`[0056] When one or more local processes 68 generates a
`request packet to be sent out as an outgoing packet. the
`request packet is sent to signaling protocol module 70. When
`an acknowledgement message needs to be sent back to private
`tra [Iic controller 52. signaling protocol module 70 writes the
`acknowledgement message into the DSCP bits of the outgo—
`ing packet. The outgoing packet is sent from signaling pro—
`tocol module '70 to packet filter '72.
`[0057]
`Packet filter '72 is used by policy agent ’74 to enforce
`policies that have been set by messages received in return
`packet that were intercepted by private trafiic control ler 52. A
`policy to block all data packets is implemented by policy
`agent ’74 causing packet filter 72 to pass through voice pack~
`ets, but drop all data packets. Packet filter ’72 can perform
`packet classification. In a source-based system. the applica-
`tions that generate the traffic can be seen so that packet filter
`72 may not need to perform stateful inspection to identify
`types oft'rafiic. A policy to limit the number of'packets trans-
`mitted per tilue unit could increment a counter for each packet
`sent. and then drop all packets alter the counter reached the
`packet limit. Policy agent 74 or another process could clear
`the counter at the end of each time unit.
`
`[0058] A policy to drop all packets to a certain range ofIP
`address could cause packet Iilter ‘72 to examine the destina-
`
`tion IP addresses. and drop packets [hatching the prohibited
`range oflP addresses. Another pol icy might block all packets
`from a certain high~level application that is identifiable by a
`port used by that application. Packet filter 72 can scan packets
`for this p011. and drop packets with the matching port. A table
`that contains secondary information of each outgoing packet.
`such as port numbers or application names. m