Systems and methods for controlling congestion of a data network are provided. An engine round-trip time (RTT) and a fabric RTT for a network flow are determined. An engine-based congestion window size for the flow is determined based on the engine RTT and a target engine RTT. A fabric-based congestion window size for the flow is determined based on the fabric RTT and a target fabric RTT. The smaller of the engine-based congestion window size and the fabric-based window size is selected for use in transmitting a future packet associated with the flow. The target engine RTT is determined based in part on the current congestion window used to transmit packets for the flow and/or the target fabric RTT is determined based on a number of hops packets associated with the flow traverse from a source to a destination associated with the flow.

Data transmission methods and apparatuses for wireless backhaul networks are described. A wireless backhaul node determines one or more reporting nodes for a data volume of a first-type data packet from a plurality of next-hop nodes of the wireless backhaul node on an uplink based on the data volume of the first-type data packet, a data volume of a second-type data packet, and a data volume of a third-type data packet. The wireless backhaul node sends, to the one or more reporting nodes, a buffer status report used to indicate the data volume of the first-type data packet. At least one of the first-type data packet, the second-type data packet, and the third-type data packet includes a data packet from an adaptation layer entity of the wireless backhaul node and/or a data packet from a radio link control layer entity of the wireless backhaul node.

Data transmission methods and apparatuses for wireless backhaul networks are described. A wireless backhaul node determines one or more reporting nodes for a data volume of a first-type data packet from a plurality of next-hop nodes of the wireless backhaul node on an uplink based on the data volume of the first-type data packet, a data volume of a second-type data packet, and a data volume of a third-type data packet. The wireless backhaul node sends, to the one or more reporting nodes, a buffer status report used to indicate the data volume of the first-type data packet. At least one of the first-type data packet, the second-type data packet, and the third-type data packet includes a data packet from an adaptation layer entity of the wireless backhaul node and/or a data packet from a radio link control layer entity of the wireless backhaul node.

Methods and systems for providing quality of service over IP networks are disclosed. In one aspect, a flow label field of a header may be divided into first and second portions. The first portion defines a quality of service. The second portion identifies a message flow. Once the first portion defining the quality of service is established by the sending node, no nodes in the transmission path may change the quality of service value. Each node may route packets based on the quality of service field, or may modify the traffic class field of the header based on the quality of service and then route the packet based on the traffic class field. The QoS field can be used to complement a DSCP/traffic class field and provide a better mechanism for end-to-end QoS using IPv6. A service provider can use DSCP within its own administrative domain(s), and end users can set and maintain QoS using the methods described herein, thereby providing a framework for end-to-end QoS using IP packets.

Methods and systems for providing quality of service over IP networks are disclosed. In one aspect, a flow label field of a header may be divided into first and second portions. The first portion defines a quality of service. The second portion identifies a message flow. Once the first portion defining the quality of service is established by the sending node, no nodes in the transmission path may change the quality of service value. Each node may route packets based on the quality of service field, or may modify the traffic class field of the header based on the quality of service and then route the packet based on the traffic class field. The QoS field can be used to complement a DSCP/traffic class field and provide a better mechanism for end-to-end QoS using IPv6. A service provider can use DSCP within its own administrative domain(s), and end users can set and maintain QoS using the methods described herein, thereby providing a framework for end-to-end QoS using IP packets.

A method and an apparatus for processing a low-latency service flow, where the method includes that a first forwarding device obtains a low latency identifier corresponding to a first service flow, and obtains a second data packet based on the first data packet and the low latency identifier after determining that a received first data packet belongs to the first service flow, where the second data packet includes the first data packet and the low latency identifier, the low latency identifier instructing a forwarding device that receives the first service flow to forward the first service flow in a low-latency forwarding mode, and the low-latency forwarding mode is a mode in which fast forwarding of the first service flow is implemented under dynamic control, and the first forwarding device sends the second data packet to a second forwarding device in the low-latency forwarding mode.

A method and an apparatus for processing a low-latency service flow, where the method includes that a first forwarding device obtains a low latency identifier corresponding to a first service flow, and obtains a second data packet based on the first data packet and the low latency identifier after determining that a received first data packet belongs to the first service flow, where the second data packet includes the first data packet and the low latency identifier, the low latency identifier instructing a forwarding device that receives the first service flow to forward the first service flow in a low-latency forwarding mode, and the low-latency forwarding mode is a mode in which fast forwarding of the first service flow is implemented under dynamic control, and the first forwarding device sends the second data packet to a second forwarding device in the low-latency forwarding mode.

Known intra-domain routing methods (e.g., OSPF and IS-IS) are link-state routing protocols with hop-by-hop forwarding that sacrifice optimal traffic engineering for ease of implementation and management. Known optimal traffic engineering procedures are either not link-state methods or require source routing—characteristics that make them difficult to implement. Certain embodiments of the present invention include a fully distributed, adaptive, link-state routing protocol with hop-by-hop forwarding configured to achieve optimal traffic engineering. Such embodiments facilitate significant performance improvements relative to known intra-domain routing methods and decrease network infrastructure requirements.

Known intra-domain routing methods (e.g., OSPF and IS-IS) are link-state routing protocols with hop-by-hop forwarding that sacrifice optimal traffic engineering for ease of implementation and management. Known optimal traffic engineering procedures are either not link-state methods or require source routing—characteristics that make them difficult to implement. Certain embodiments of the present invention include a fully distributed, adaptive, link-state routing protocol with hop-by-hop forwarding configured to achieve optimal traffic engineering. Such embodiments facilitate significant performance improvements relative to known intra-domain routing methods and decrease network infrastructure requirements.

A Time-To-Live budget can be determined for network packets and used to understand an impact of network expansion on dropped packets. Additionally, the TTL budget can be used to determine how network expansion impacts services provided in the data center. In one embodiment, agents executing on data center routers are used to transmit packet header data including a TTL budget to a collector server computer. The collector server computer can discern signal (production flows) from noise (traceroutes and probing traffic) to detect packets that are at risk of being dropped or have been dropped due to TTL expiration. Alerts can be generated for packet flows with dangerously low remaining TTL budget or no remaining budget, which are at high risk of expiring due to operational events resulting in traffic temporarily traversing slightly longer paths. A dashboard can be provided with historic TTL budget data and trends.