WO2003043285A2 - Flow control between performance enhancing proxies over variable bandwidth split links - Google Patents

Flow control between performance enhancing proxies over variable bandwidth split links Download PDF

Info

Publication number
WO2003043285A2
WO2003043285A2 PCT/US2002/036282 US0236282W WO03043285A2 WO 2003043285 A2 WO2003043285 A2 WO 2003043285A2 US 0236282 W US0236282 W US 0236282W WO 03043285 A2 WO03043285 A2 WO 03043285A2
Authority
WO
WIPO (PCT)
Prior art keywords
tcp
pep
data
intermediate device
connections
Prior art date
Application number
PCT/US2002/036282
Other languages
French (fr)
Other versions
WO2003043285A3 (en
Inventor
Jason Neale
Andrew M. Pether
Abdul-Kader Mohsen
Guy Begin
Original Assignee
Ems Technologies, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Ems Technologies, Inc. filed Critical Ems Technologies, Inc.
Priority to AU2002357711A priority Critical patent/AU2002357711A1/en
Publication of WO2003043285A2 publication Critical patent/WO2003043285A2/en
Publication of WO2003043285A3 publication Critical patent/WO2003043285A3/en

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04BTRANSMISSION
    • H04B7/00Radio transmission systems, i.e. using radiation field
    • H04B7/14Relay systems
    • H04B7/15Active relay systems
    • H04B7/185Space-based or airborne stations; Stations for satellite systems
    • H04B7/18578Satellite systems for providing broadband data service to individual earth stations
    • H04B7/18582Arrangements for data linking, i.e. for data framing, for error recovery, for multiple access
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1829Arrangements specially adapted for the receiver end
    • H04L1/1832Details of sliding window management
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1829Arrangements specially adapted for the receiver end
    • H04L1/1848Time-out mechanisms
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2854Wide area networks, e.g. public data networks
    • H04L12/2856Access arrangements, e.g. Internet access
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/19Flow control; Congestion control at layers above the network layer
    • H04L47/193Flow control; Congestion control at layers above the network layer at the transport layer, e.g. TCP related
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/29Flow control; Congestion control using a combination of thresholds
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/30Flow control; Congestion control in combination with information about buffer occupancy at either end or at transit nodes
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/32Flow control; Congestion control by discarding or delaying data units, e.g. packets or frames
    • H04L47/323Discarding or blocking control packets, e.g. ACK packets
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/36Flow control; Congestion control by determining packet size, e.g. maximum transfer unit [MTU]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/04Protocols specially adapted for terminals or networks with limited capabilities; specially adapted for terminal portability
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/161Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/163In-band adaptation of TCP data exchange; In-band control procedures
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/165Combined use of TCP and UDP protocols; selection criteria therefor
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/166IP fragmentation; TCP segmentation
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40Network security protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W28/00Network traffic management; Network resource management
    • H04W28/02Traffic management, e.g. flow control or congestion control
    • H04W28/0273Traffic management, e.g. flow control or congestion control adapting protocols for flow control or congestion control to wireless environment, e.g. adapting transmission control protocol [TCP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W8/00Network data management
    • H04W8/02Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
    • H04W8/04Registration at HLR or HSS [Home Subscriber Server]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18Automatic repetition systems, e.g. Van Duuren systems
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/326Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the transport layer [OSI layer 4]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W72/00Local resource management
    • H04W72/04Wireless resource allocation
    • H04W72/044Wireless resource allocation based on the type of the allocated resource
    • H04W72/0453Resources in frequency domain, e.g. a carrier in FDMA
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W80/00Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/06Transport layer protocols, e.g. TCP [Transport Control Protocol] over wireless
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W84/00Network topologies
    • H04W84/02Hierarchically pre-organised networks, e.g. paging networks, cellular networks, WLAN [Wireless Local Area Network] or WLL [Wireless Local Loop]
    • H04W84/04Large scale networks; Deep hierarchical networks
    • H04W84/06Airborne or Satellite Networks

Definitions

  • This invention relates to data telecommunications satellites, and more specifically to the use of hardware and/or software, referred to as
  • Performance Enhancing Proxies to optimize the performance of the Transmission Control Protocol (TCP) over satellite links with varying
  • the Internet is a world-wide computer super-network, which is made up of a large number of component networks and their interconnections.
  • Computer networks may consist of a wide variety of connected paths or network links serving to transport user information in the form of data
  • a fiber optic cable typically provides a high bandwidth, low per bit cost, low error rate and low delay point-to-point network link.
  • a satellite link typically provides a lower bandwidth, higher per bit cost, higher error rate and longer delay point-to-multi-point network link.
  • IP Internet Protocol
  • IP primarily provides the routing functionality for packets (bits or
  • TCP Transmission Control Protocol
  • TCP IP's unreliable datagram (packet) service.
  • TCP underlies the vast majority, estimated to be around 90%, of all the traffic on the Internet.
  • TCP supports the World Wide Web (WWW), electronic mail (email) and file transfers, along with other common applications.
  • WWW World Wide Web
  • email electronic mail
  • file transfers along with other common applications.
  • TCP was introduced in 1981 and since then has evolved in many ways, but today TCP still provides reliable and largely
  • TCP may
  • PEP shall be described as an Intermediate Node between the endpoints of a connection, and any network element between the PEPs, such as a Satellite
  • Gateway Gateway, Satellite or Satellite Terminal
  • a connection refers to an end-to-end
  • connection between a client and a server which is broken up into three
  • connection segments client to PEP, PEP to PEP and PEP to Server, such that the client or server remain largely aware of the splitting.
  • point-to-point communications system includes an intermediate device that is required to request bandwidth based on the amount of data in
  • bandwidth-on-demand satellite system scheme will naturally change the allocated capacity to a given terminal (based on, but not limited to, Traffic conditions and Quality of
  • QoS Quality of Service
  • TCP performance is typically degraded to some extent in terms of
  • PEPs may function as one or more Intermediate Nodes or pieces of
  • PEP units may, for example, surround a satellite link. PEPs modify the traffic flow to attempt to alleviate the issues of TCP traffic on a
  • PEPs may use many methods either alone or in concert to enhance performance.
  • a type of PEP known as a distributed, connection splitting PEP, is commonly chosen due to that fact that it allows for the use of a proprietary protocol across the satellite link. This protocol can then be chosen or
  • a distributed connection splitting PEP uses more than one PEP in an end-to-end connection, most
  • connection segments The end connections must remain TCP for compatibility, but the inter-PEP connection may be any protocol.
  • acknowledgement (ACK) driven algorithms such as slow-start and
  • congestion-avoidance algorithms to manage the flow of data from the sender to the receiver to mitigate the effects of congestion and prevent over-flow of the receiver's buffers. These algorithms often mistake transmission errors as
  • TCP window-scaling option helps with the later and fast-retransmission /
  • TCP is unable to quickly make use of free capacity for hungry connections when other connections start to slowly supply the link, relying instead on a slow-ramp through congestion avoidance. Indeed, the overall throughput is often reduced as a result of a
  • fairness is defined as the ideal condition where each connection has an equal share of
  • the invention provides methods and systems for the management of
  • This changing bandwidth condition is characteristic of a Bandwidth on Demand (BOD) satellite
  • the invention further provides systems and methods that enable the
  • the distribution process according to the invention prevents slow running TCP connections, at the receiver end, from unfairly
  • invention allows the fair sharing or satellite link resources between
  • the invention provides satellite communication systems where the
  • bandwidth between two PEPs is controlled by a Gateway and is subject to wide variations due to competing traffic, among other things.
  • a Gateway bandwidth between two PEPs is controlled by a Gateway and is subject to wide variations due to competing traffic, among other things.
  • Such a Bandwidth-on-Demand (BoD) scheme typically facilitates a fast variation in bandwidth allocation
  • the invention provides for improved performance of TCP over a
  • invention provides for the management of the flow of traffic from a PEP to an Intermediate Device in a satellite environment where the bandwidth and
  • TCP transport protocol
  • EMS proprietary
  • FP Flight Protocol
  • GEO links is traditionally very poor from a user perspective in terms of transfer time and throughput for web browsing and file transfer among other
  • Figure 1 is an illustration showing the overall satellite network
  • Figure 2 illustrates the end-to-end satellite protocol stacks for TCP/IP utilizing the PEPs; and Figure 3 shows an algorithm and procedures for making a PEP-to- intermediate device (Terminal) communication, and in particular, steps in
  • the PEP component consists of two main parts: a TCP Emulator
  • TCP* Flight Protocol
  • FP Flight Protocol
  • components and methods of the invention are different depending on whether they are functioning in a Receive or a Transfer mode, i.e., depending on
  • the PEP is designed to be used in pairs, one on each
  • TCP Emulator (TCP*) is present in the transmit and receive PEPs
  • PEPl is the first PEP in the transfer chain (the Transmitter) and PEP2 is the
  • TCP emulator depends on the function of the PEP.
  • the TCP Emulator converts TCP segments into FP packets.
  • the Receive PEP receives
  • TCP Emulator receives the FP packets, converts them back to standard TCP packets and transmits them over a new TCP connection to
  • the client and the server are the communication system's endpoints or end users.
  • TCP Emulator emulates a standard TCP connection between
  • TCP/IP Flight Protocol
  • This behavior includes
  • Flight Protocol FP is the inventive transport protocol that is used over the satellite link between the transmit and receive PEPs that are
  • the FP is optimized to operate over this link by not using the TCP Slow Start and Congestion Avoidance algorithms, and instead, utilizes the full available
  • the FP also avoids the delays associated with the TCP three-way
  • This setup mechanism may be used with either a half or full duplex connection allowing
  • the invention involves the principle of an Intermediate Device breaking
  • the principle involves the PEP sending sufficient data to at least partially
  • the terminal sending SNMP traps when its queue reaches a certain level or in the case where the PEP and
  • Terminal are co-located in the same device some form of direct linkage.
  • the flow of data from the PEP to the Terminal could be made more accurate by
  • the PEP having knowledge of the current and future bandwidth allocations of the intermediate device (Terminal).
  • TCP connections The former is dealt with by the use of conventional window
  • the maximum bandwidth- delay product of a communications link is (x)
  • the amount of capacity given to a connection, before allowance for the PEP to Intermediate device flow is (x/n).
  • the invention provides for a return link in the Terminal- Satellite- Gateway direction that is shared between a number of Terminals and thus subject to varying bandwidth conditions. Likewise the output queue in the
  • Terminal that is tested and then filled is a queue for all traffic.
  • the Gateway could enjoy varying bandwidth conditions facilitating the need for such a scheme or the Intermediate Device
  • TCP/IP queue could have several output queues, requiring a different parameter to be polled (e.g. the TCP/IP queue).
  • FIG. 1 illustrates a simplified view of a performance enhancing proxy (PEP)
  • communications system 100 including equipment and links involved in a
  • client 101 initiates a connection attempt to a server 107 via a satellite 104.
  • the client is connected by a local area network (LAN) segment 108 to a terminal-side PEPl 102, via another LAN segment 109 to a satellite terminal
  • LAN local area network
  • Traffic from a terminal 103 passes over
  • Gateway-side PEP2 106 Traffic leaving the Gateway passes via a LAN segment 112 to a gateway-side PEP2 106.
  • PEP2 106 then sends the traffic via a wide area network (WAN), such as part of the Internet, 113 to the server 107.
  • WAN wide area network
  • the traffic may be a client request
  • the gateway PEP2 106 to server 107 uses known TCP protocols.
  • Data transfer over the satellite link from the PEPl 102 to the PEP2 106 uses the flight protocol (FP) described in greater detail above. The data transfer is
  • FIG. 2 shows the stacks involved in the various elements in a TCP- FP-TCP transfer.
  • FIG. 2 shows the stacks of a transfer end point application which include an application/presentation/session layer 285, a TCP layer 206,
  • FIG. 2 also shows the stacks in a first PEPl (first PEP
  • TCP layer (TCP*) 207 an application/presentation/session layer 201, an FP
  • the IP layer 212 the Ethernet 222, the UTP layer 233, the UTP layer
  • incoming FP packets are grabbed by a modified IP layer 219, after passing through the physical UTP layer 240 and link Ethernet 229 layers, and then
  • the invention allows for the exchange of information between the Intermediate Device (the "Terminal”) and PEPl. This is to aid overall flow control and the sharing of bandwidth within the Intermediate Device (the "Terminal”) and PEPl.
  • This issue mainly relates to the terminal population and its access to return link capacity.
  • O&M Operations Administration & Management
  • this queue could be an output queue for all packets or purely for
  • SNMP Simple Network Management Protocol
  • the PEP could make use of known future capacity allocations to manage the flow of incoming TCP/IP connections more accurately. For example, if the PEP knows of any Constant Rate Assignments (CRAs) to the Terminal PEPl 102 (i.e. not dynamic and
  • CRAs Constant Rate Assignments
  • the Simple Network Management Protocol (SNMP) is a request-reply
  • SNMP is an
  • MIB Management Information Base
  • MIB-II MIB-II
  • the PEP behind the terminal can assume the role of a local management station, thereby getting read access to MIB-II objects of the Intermediate
  • Buffering in the terminal is limited by number of packets rather than by volume of data (although we note that data bytes could be used if the
  • the PEP either knows (or otherwise, can determine) the maximum size
  • MaxQlen MaxQlen
  • MIB-II objects for deriving buffer occupancy information are in the interfaces group (the group of MIB-II objects related to the network interfaces of the device), specifically, for any of the interfaces
  • IfOutQlen is a gauge indicating the number of packets in the outbound
  • IfOutOctets is a counter indicating the total number of octets transmitted
  • IfOutUcastpkts is a counter indicating the number of unicast packets
  • the Intermediate Device could send the PEP an SNMP Set when
  • the returned value allows the PEP to control the amount of data that is fed to the terminal.
  • the algorithm is packet-driven: no actions are performed unless there are packets to send on the satellite link.
  • a flow chart 300 for the algorithm is illustrated in Figure 3.
  • the algorithm proceeds as follows: In step 301, the variables FreeQ_i and FreeQ_(i-l) are first initialized. The process then moves to step 302. In step 302, the PEP
  • step 303 when there are packets
  • a test is performed to check whether the PEP is already aware of a
  • step 304 the PEP sends packets up to (FreeQ_(i-l))
  • step S305 the PEP sends a SNMP GetRequest for IfOutQlen.
  • the terminal responds with a SNMP GetResponse containing a value for IfOutQlen.
  • the process then moves to
  • step 307 the PEPs send the
  • step 308 the system determines whether FreeQ_i > Packets_to_send.
  • FreeQ_(i-l) FreeQ_i - Packets_to_send and the process returns to step
  • step 311 to wait Query_timer and then returns to step 305.
  • MaxQlen maximum size (in number of packets) of the Intermediate
  • Query_timer a delay to avoid querying the terminal too frequently. Its
  • value may be set based on the time required to empty a full queue at a
  • Thresh a threshold (in number of packets) for deciding whether the queue
  • Margin a security margin to account for an unknown amount of traffic
  • FreeQ_i free satellite link buffer space maximum on the terminal.
  • FreeQ_(i-l) remaining free satellite link buffer space available.
  • FreeQ_i In a situation where packets to send are few and far between, FreeQ_i will
  • step 303 avoids one SNMP query when the PEP is
  • the PEP could be made to wait for a certain delay before returning to step 302 after step 308, thereby avoiding sending a certain number of SNMP queries.
  • step 308 without delay. At worst, there will therefore be one query
  • step 311 the PEP will wait until the expiration of a query timer if FreeQ_i is not greater than a threshold. This is to prevent un-necessary
  • the PEP should also make use of some form of PEP rate control clocking-
  • the PEP includes both a Transmit and a Receive Buffer. On arrival at
  • a packet from the terrestrial world is queued in the TCP* 207 layer's buffer.
  • This buffer is equivalent to a conventional TCP buffer at the receiving end point, with the space in the buffer being linked to the advertised window on the TCP connection. This linkage' allows the TCP
  • connection on the terrestrial link to slow down the flow of packets to the PEP as the TCP* buffer becomes full, in much the same way as TCP would slow
  • connection buffer utilization is less than its allowed buffer space
  • the packet can be pushed.
  • the FP buffer also stored in the FP buffer and associated to a connection.
  • the FP buffer also stored in the FP buffer and associated to a connection.
  • the FP total buffer space can become artificially high. For example, if the global size is 3 Mbytes, then if three
  • each connection will be allowed 1 Mbyte for its individual transmit buffer.
  • the buffer utilization mechanism will redistribute equally the global transmit buffer size between the four opened connections.
  • connection will be allowed to use a new individual transmit buffer size of 0.75
  • the PEP can pull a packet from the applicable TCP* buffer.
  • the PEP includes a re-transmission procedure, based on timers, to ensure that data is re -transmitted if presumed lost, thereby guaranteeing
  • Each terminal can be assumed to operate at a maximum receive rate in the
  • the RTT is actually the time for a packet to be sent and the associated FP ACK to be sent back and clear the packet from the transmit buffer or open
  • the utilization factor adjusts the calculated buffer sizes to maintain PEP/FP performance under heavier buffer utilization due to packet
  • a single BDP sized buffer allows the link to stay
  • the receive buffer will be full and transmission of new packets must be halted while the lost packet is
  • TCP operates, a window mechanism is used from the receiving PEP to the transmitting PEP to indicate the status of each connection's buffer space and
  • transmission of data means the passing of a
  • the PEP When space becomes available (either because of a changed window parameter or an ACK removing a packet from the FP Tx Buffer), the PEP

Abstract

The invention provides a method and system for dealing with the flow of data between one Performance Enhancement Proxy ('PEPI')and another ('PEPI') in the context of split links for TCP over satellite performance improvement. The environment according to the invention may include one or more intermediate nodes (103, 105) experiencing variable latency and bandwidth allocations. The method and system manage the data flow to ensure bandwidth fairness between competing TCP/IP connections, prevention of PEP receiver buffer overflow and near 100% usage of the available satellite bandwidth without the need for conventional TCP/IP ACK driven probing algorithms. The near 100% usage of capacity being achieved, in part, through PEP to intermediate node message exchange.

Description

FLOW CONTROL BETWEEN PERFORMANCE ENHANCING PROXIES OVER VARIABLE BANDWIDTH SPLIT LINKS
CROSS-REFERENCE TO RELATED APPLICATIONS
This application claims priority to U.S. Provisional Application No.
60/333,608 to Jason D. Neale et. al., entitled "Performance Enhancing
Proxies for Satellite Transmission Control Protocols," filed on November 13,
2001.
BACKGROUND OF THE INVENTION
1. Field of the Invention
This invention relates to data telecommunications satellites, and more specifically to the use of hardware and/or software, referred to as
Performance Enhancing Proxies (PEPs), to optimize the performance of the Transmission Control Protocol (TCP) over satellite links with varying
bandwidth.
2. Description of Related Art
The Internet is a world-wide computer super-network, which is made up of a large number of component networks and their interconnections.
Computer networks may consist of a wide variety of connected paths or network links serving to transport user information in the form of data
between a diverse array of computer end systems. Different network links are more or less suitable for different network requirements. For example, a fiber optic cable typically provides a high bandwidth, low per bit cost, low error rate and low delay point-to-point network link. Alternatively, for example, a satellite link typically provides a lower bandwidth, higher per bit cost, higher error rate and longer delay point-to-multi-point network link.
The wide variety of links and thus link characteristics encountered on the
Internet or other private Internet Protocol (IP) based networks have a variety
of effects on the behavior of protocols in the IP suite.
IP primarily provides the routing functionality for packets (bits or
bytes of data) over a network. It acts at the network layer to direct packets from their sources to their destinations. Transmission Control Protocol (TCP)
is the reliable transport layer protocol of the IP suite of protocols and, as such, layers on top of IP, providing reliability to applications and building on
IP's unreliable datagram (packet) service. TCP underlies the vast majority, estimated to be around 90%, of all the traffic on the Internet. TCP supports the World Wide Web (WWW), electronic mail (email) and file transfers, along with other common applications. TCP was introduced in 1981 and since then has evolved in many ways, but today TCP still provides reliable and largely
efficient service over a wide variety of links as evidenced by its omnipresent
nature. However, there are a variety of conditions under which TCP may
perform below expectations, its use with geosynchronous satellite links being an example. In response to the established use of TCP and also of certain
link types, such as satellite, which are not ideal for TCP, Performance Enhancing Proxies (PEPs) were introduced. In any point-to-point communications system, such as PEP to PEP,
flow control between the two elements is important to prevent starvation or
over-flow of data in any other Intermediate Device (such as the Terminal) as well as the receiving point. For the purposes of describing the invention, a
PEP shall be described as an Intermediate Node between the endpoints of a connection, and any network element between the PEPs, such as a Satellite
Gateway, Satellite or Satellite Terminal, shall be described as an Intermediate Device. Furthermore, a connection refers to an end-to-end
connection between a client and a server which is broken up into three
connection segments, client to PEP, PEP to PEP and PEP to Server, such that the client or server remain largely aware of the splitting. Starvation of
data implies inefficient use of available communications capacity, and overflow of data implies packet loss and retransmissions of data. Moreover, where the point-to-point communications system includes an intermediate device that is required to request bandwidth based on the amount of data in
its queue, then ensuring the queue is adequately provisioned guarantees that capacity requests will be made.
Ensuring any particular intermediate device (such as the Terminal)
between the two points (PEPs) is accurately supplied with an appropriate
amount of data is difficult if the amount of bandwidth capacity allocated to the device is constantly changing. However a bandwidth-on-demand satellite system scheme will naturally change the allocated capacity to a given terminal (based on, but not limited to, Traffic conditions and Quality of
Service (QoS) agreements).
TCP performance is typically degraded to some extent in terms of
lowered throughout and link utilization by, but not limited to, the following
link characteristics; long delay, high bandwidth, high error rate, link
asymmetry and link variabihty, all of which may be encountered on satellite
and similar links.
PEPs may function as one or more Intermediate Nodes or pieces of
software placed in the end-to-end path that suffers TCP performance
degradation. PEP units may, for example, surround a satellite link. PEPs modify the traffic flow to attempt to alleviate the issues of TCP traffic on a
specific link. PEPs may use many methods either alone or in concert to enhance performance.
A type of PEP, known as a distributed, connection splitting PEP, is commonly chosen due to that fact that it allows for the use of a proprietary protocol across the satellite link. This protocol can then be chosen or
designed to mitigate problems specific to the link. A distributed connection splitting PEP uses more than one PEP in an end-to-end connection, most
commonly, two PEPs are used, although the invention can be applied to systems using greater number of PEPs with the FP protocol of this invention. If two PEP devices are used, the end-to-end connection may be split into 3
connection segments. The end connections must remain TCP for compatibility, but the inter-PEP connection may be any protocol. Several
protocols are available for use on the satellite link that provide improved
performance over that of TCP. Examples of these protocols are Xpress
Transport Protocol (XTP), Satellite Transport Protocol (STP), Space Systems
Control Protocol Suite - Transport Protocol (SSCPS-TP) or even non- standard modified TCP.
Current versions of TCP use a window mechanism and
acknowledgement (ACK) driven algorithms, such as slow-start and
congestion-avoidance algorithms, to manage the flow of data from the sender to the receiver to mitigate the effects of congestion and prevent over-flow of the receiver's buffers. These algorithms often mistake transmission errors as
congestion and fail to fully-supply the satellite link with data. Although the TCP window-scaling option helps with the later and fast-retransmission /
fast-recovery help with the former, the overall link usage often remains well below the available capacity. The aforementioned satellite protocols and PEPs address some of these problems by facilitating larger windows,
discriminating between congestion losses and in some cases making use of
link rate knowledge (where that rate is constant). However, all of the PEP
solutions use some form of capacity probing procedure (akin to a slow-start technique) and thus are unable to immediately employ the full link capacity without fear of losses (due to packet discard at an Intermediate Device). More importantly, none of the other solutions are able to fully supply a variable bandwidth and/or latency link for the duration of a TCP transfer.
Additionally, they are unable to communicate directly with Intermediate
Devices, relying instead on PEP-to-PEP messages to determine capacity, with
the inevitable reduction in throughput associated with a satellite round-trip
delay message exchange. As a solution to this problem, the method and
system described in this invention facilitate a near 100% usage of link capacity for the entire duration of the PEP-to-PEP transfer without the risk
of packets being discarded or receiver buffer-overflow.
In terms of the sharing of resources to guarantee fairness while not limiting hungry connections when satellite resources permit, conventional TCP merely dedicates a buffer per end-to-end connection and manages those
connections independently. Thus TCP is unable to quickly make use of free capacity for hungry connections when other connections start to slowly supply the link, relying instead on a slow-ramp through congestion avoidance. Indeed, the overall throughput is often reduced as a result of a
lack of acknowledgments. Although many of the PEPs and other protocols
are able to prevent the flow from diminishing because of a lack of ACKs, none of them include a flow fairness technique to ensure 100% supply to the link
and fairness (assuming TCP/IP traffic supplies allow). Herein, fairness is defined as the ideal condition where each connection has an equal share of
the link, as long as it has enough traffic to use this portion of the resources. If a connection is running more slowly, its unused share of capacity will be
provided for the use of all other connections, in a fair way.
SUMMARY OF THE INVENTION
The invention provides methods and systems for the management of
the flow of data between two PEPs where the link conditions, in terms of bandwidth resources and latency, are changing in relation to network traffic
conditions and QoS profiles, among other things. This changing bandwidth condition is characteristic of a Bandwidth on Demand (BOD) satellite
communications system.
The invention further provides systems and methods that enable the
fair distribution of satellite resources between a number of competing TCP connections at a PEP, while facilitating the full usage of the available satellite bandwidth by accurately supplying a particular Intermediate Device
with sufficient data and preventing the receiving PEP's buffers from
overflowing. Additionally, the distribution process according to the invention prevents slow running TCP connections, at the receiver end, from unfairly
being allocated excess link capacity whilst allowing for full usage of bandwidth at the transmitting PEP's end by distributing unused satellite
capacity among hungry TCP connections.
The methods and systems in accordance with the invention allow
satellite resources to be fairly shared between competing TCP connections while also facilitating the full use of the link capacity by hungry connections should resources allow. The overall flow strategy in accordance with the
invention allows the fair sharing or satellite link resources between
connections while achieving near 100% usage and not over-flowing the
receiving end's buffers.
The invention provides satellite communication systems where the
bandwidth between two PEPs is controlled by a Gateway and is subject to wide variations due to competing traffic, among other things. As an example,
communication between two PEPs relies on an Intermediate Device (Terminal), forward and return satellite links and a Gateway. In such a
network, numerous terminals could be operating with the Gateway, each
terminal receiving data packets from a PEP, then requesting and receiving bandwidth allocations from the Gateway. Such a Bandwidth-on-Demand (BoD) scheme typically facilitates a fast variation in bandwidth allocation
and substantial latency changes dependent on the number of terminals in
operation, their traffic supplies and guaranteed quality of service agreements.
Thus, the invention provides for improved performance of TCP over a
satellite link or other large bandwidth delay network. Moreover, the
invention provides for the management of the flow of traffic from a PEP to an Intermediate Device in a satellite environment where the bandwidth and
latency are fluctuating. This may be accomplished in part by replacing TCP with a new transport protocol, the EMS (proprietary) Flight Protocol (FP), over the wireless satellite link only and maintaining TCP connections over
the terrestrial portions of the end-to-end connection. TCP performance over
GEO links is traditionally very poor from a user perspective in terms of transfer time and throughput for web browsing and file transfer among other
applications relying on a TCP transport layer.
The above aspects of the invention are achieved by addressing and in
part accessing the characteristics of the satellite link, including available capacity, and treating a lack of acknowledgements from the receiver as errors
and not congestion. The PEP invention described herein will improve the
throughput and transfer times and achieve a higher utilization factor of the
assigned link rates.
BRIEF DESCRIPTION OF THE DRAWINGS
The accompanying drawings, which are included to provide a further
understanding of the invention and are incorporated in and constitute a part of this specification, illustrate embodiments of the invention. Together with the written description, these drawings serve to explain the principles of the
invention. In the drawings:
Figure 1 is an illustration showing the overall satellite network with
the location of the PEPs, as exemplary of connections and equipment in a distributed, connection splitting PEP deployment;
Figure 2 illustrates the end-to-end satellite protocol stacks for TCP/IP utilizing the PEPs; and Figure 3 shows an algorithm and procedures for making a PEP-to- intermediate device (Terminal) communication, and in particular, steps in
making a query of the Terminal's buffer status and determining the amount
of data to be sent to the Terminal.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
The invention is described in the context of a bi-directional transfer of
data between a client and a server over a communications link consisting of both terrestrial segments and up and down segments, or links, over satellite,
as generally shown in Figure 1. It is important to note that the use of a satellite is merely illustrative of one embodiment of the invention and that the invention is applicable to both terrestrial hard-wired and terrestrial wireless applications.
The PEP component consists of two main parts: a TCP Emulator
(TCP*) and a Flight Protocol (FP) Processor. While the operation of inventive
components and methods of the invention are different depending on whether they are functioning in a Receive or a Transfer mode, i.e., depending on
whether the data is being sent by the client or server, it is to be understood that the components and methods are reciprocal. A description of the
operation for sending data, for example, from a client to a server is essentially equivalent to data being sent in the reverse direction, from server to client, in this respect the PEP system is reciprocal. Figure 2 presents an
illustration generally showing where the TCP* and FP layers sit in a conventional stack. The PEP is designed to be used in pairs, one on each
terrestrial side of the satellite link.
The TCP Emulator (TCP*) is present in the transmit and receive PEPs
and behaves as if it is a TCP connection endpoint. The TCP Emulator
transparently interrupts the TCP connection going from the client to the server (or server to client) and acts as a TCP endpoint. It translates TCP
traffic into FP traffic, the inventive transport protocol used over the satellite
link (or other large bandwidth * delay network) between the two PEPs. PEPl is the first PEP in the transfer chain (the Transmitter) and PEP2 is the
second PEP in the transfer chain (the Receiver), whichever direction of packet is being discussed. The names PEPl and PEP2 do not necessarily apply to the terminal-side or gateway-side PEPs respectively. The role of the
TCP emulator depends on the function of the PEP. In the Transmit PEP, the TCP Emulator converts TCP segments into FP packets. In the Receive PEP,
the TCP Emulator (TCP*) receives the FP packets, converts them back to standard TCP packets and transmits them over a new TCP connection to
their final destination: the communication's endpoint. The client and the server are the communication system's endpoints or end users.
With the introduction of the two PEPs, the standard connection going from the server to the client will be replaced with the following three
connections: 1. A TCP connection from the client to the first, terminal, PEP (PEPl) 2. A FP connection going from PEPl to PEP2 (gateway PEP)
3. A TCP connection from PEP2 to the server
The TCP Emulator (TCP*) emulates a standard TCP connection between
the external end user, the client and server, and converts TCP/IP packets into Flight Protocol (FP) packet 'shells'. The TCP Emulator filters TCP/IP
packets entering from the outside world (the real end points) and emulates the TCP behavior of the destination transport layer. This behavior includes
the TCP three-way handshake, acknowledgements, flow control, re¬
transmissions and all other TCP functionality. It also manages the flow of traffic to the Flight Protocol Processor section of the PEP.
The Flight Protocol FP is the inventive transport protocol that is used over the satellite link between the transmit and receive PEPs that are
connected, respectively, to a terrestrial/satellite gateway and a user terminal. The FP is optimized to operate over this link by not using the TCP Slow Start and Congestion Avoidance algorithms, and instead, utilizes the full available
satellite capacity immediately and consistently throughout the lifetime of the
connection, also improving link utilization efficiency. This throughput
utilization is achieved despite bandwidth fluctuations, prevalent in a BoD satellite network, by linking the PEP with the Intermediate Device
experiencing the said fluctuations. Other future protocols may also be used, the FP should be considered as merely one current example of such suitable protocols. While this invention is described with reference to the FP, it is to
be understood that the invention is not limited to this protocol. It can equally
be used with and applied to a variety of other protocols.
The FP also avoids the delays associated with the TCP three-way
handshake by not using a pre-data handshaking (negotiation) mechanism of
any form. Instead, the FP connection Initiator simply informs the remote
entity that a new connection has been created and then immediately begins
to send data. The assumption is that the FP connection will be created successfully unless evidence demonstrates to the contrary. The alternative
rationale, as implemented by conventional TCP, assumes failure until success is explicitly signaled. This feature of the FP of this invention removes
an additional one-off delay (per connection) that is significant for very small files or short duration transfers such as those typical of current web pages
that at present comprise the greatest volume of Internet traffic. This setup mechanism may be used with either a half or full duplex connection allowing
for bi-directional data communication on a single connection or alternatively
with two associated simplex connections.
The invention involves the principle of an Intermediate Device breaking
an end-to-end TCP and splitting the connection into a TCP/IP protocol and TCP/IP connections by the use of PEPs; and then managing the flow of data
between the PEP and the Intermediate device (Terminal) by knowledge of the status of the Terminal queue. One of ordinary skill in the art will recognize
other variations, modifications, and alternatives.
The principle involves the PEP sending sufficient data to at least partially
or fully fill the Terminal queue (to a pre-defined level), and after adequate
time for some of the data to be transmitted, checking the status of the Terminal, using some protocol, and then re-filling the Terminal queue to the
previous level. This method could be as simple as the PEP sending regular
SNMP get messages to the terminal MIB, the terminal sending SNMP traps when its queue reaches a certain level or in the case where the PEP and
Terminal are co-located in the same device some form of direct linkage. The flow of data from the PEP to the Terminal could be made more accurate by
the PEP having knowledge of the current and future bandwidth allocations of the intermediate device (Terminal).
Beyond the management of the flow of data from the PEP to the intermediate device two other functions are key to the successful flow of data
from the PEP to PEP; firstly not overflowing the receiver's window and secondly the fair distribution of the satellite bandwidth between competing
TCP connections. The former is dealt with by the use of conventional window
mechanisms, as in TCP, and the latter is achieved by the sharing of resources by the number (n) of connections by the use of transmission storage. For
example where the maximum bandwidth- delay product of a communications link is (x), the amount of capacity given to a connection, before allowance for the PEP to Intermediate device flow, is (x/n). When the sum of all actual capacity usage by each individual connection (n) is less than (x), then the
available capacity is shared by any connections wishing to exceed their
allocations. This allows the full capacity of the link to be employed if several
incoming TCP/IP connections (from the terrestrial side) are running slowly.
Additionally, when new connections arrive, they are guaranteed (x/n)
capacity even if the result is a temporarily over-supply of capacity; the existing connections flows are naturally reduced to the new lower rate. This
is achieved by the use of a buffer to manage the flow, with packets only being
allowed storage in the buffer when the afore mentioned rules are met. For example, if IMb/s was previously shared between 10 connections a new connection would result in the over supply of 90.909Kb/s (10*100Kb/s + 1* 90.909Kb/s). However the existing connections are forced down to around
90.909Kb/s by preventing new incoming TCP/IP packets from the terrestrial side to progress from the TCP Emulator to the FP, until sufficient buffer space is created. Any temporary over-supply, until the system returns to the
steady-state, is achieved by allowing the new connection packets to be stored
in an output queue. The existing connections being denied further capacity
until the new connection has reached its allocation and sufficient space exists in the output queue. The end result being a natural back-press ire to the
TCP senders of the over-supplying connections and prevention of the new connection being starved of capacity when the link was previously fully
occupied.
The transmission of data from the PEP to the intermediate device and
onwards to the other PEP, depends on the passing of three conditions laid out
above; namely: sufficient transmission buffer space (allowing for the rules
above), sufficient space in the receiver window (allowing for the amount of data already transmitted since the last window update (as in TCP)) and
sufficient capacity / buffer space at the intermediate device (Terminal). If any of these tests fail, data can be stored in an applicable Input or Output
queue within the PEP (TCP Emulator or FP) thereby creating natural back pressure to the TCP sender in the regular window updates sent form the PEP to the TCP sender.
The invention provides for a return link in the Terminal- Satellite- Gateway direction that is shared between a number of Terminals and thus subject to varying bandwidth conditions. Likewise the output queue in the
Terminal that is tested and then filled is a queue for all traffic. Variations
are possible, for example, the Gateway could enjoy varying bandwidth conditions facilitating the need for such a scheme or the Intermediate Device
could have several output queues, requiring a different parameter to be polled (e.g. the TCP/IP queue).
Referring now to the method of implementing the transfer of data in this environment according to an embodiment of the invention, Figure 1 illustrates a simplified view of a performance enhancing proxy (PEP)
communications system 100 including equipment and links involved in a
PEP deployment in a satellite communication link environment. In Fig. 1, a
client 101 initiates a connection attempt to a server 107 via a satellite 104.
The client is connected by a local area network (LAN) segment 108 to a terminal-side PEPl 102, via another LAN segment 109 to a satellite terminal
or satellite modem of some form 103. Traffic from a terminal 103 passes over
the communications links 110 and 111 via the satellite 104 to the Gateway,
central hub equipment or other satellite modem 105. Traffic leaving the Gateway passes via a LAN segment 112 to a gateway-side PEP2 106. The
PEP2 106 then sends the traffic via a wide area network (WAN), such as part of the Internet, 113 to the server 107. The traffic may be a client request,
which could generate server response traffic in the reverse direction.
Data transfer from the client 101 to the terminal PEPl 102, and from
the gateway PEP2 106 to server 107 uses known TCP protocols. Data transfer over the satellite link from the PEPl 102 to the PEP2 106 uses the flight protocol (FP) described in greater detail above. The data transfer is
thus sent over TCP-FP-TCP protocol links.
Figure 2 shows the stacks involved in the various elements in a TCP- FP-TCP transfer. Fig. 2 shows the stacks of a transfer end point application which include an application/presentation/session layer 285, a TCP layer 206,
an IP layer 212, an Ethernet or equivalent layer 222 and a UTP or equivalent layer 233. Fig. 2 also shows the stacks in a first PEPl (first PEP
in the transfer direction front end) which includes a UTP or equivalent layer
234, an Ethernet or equivalent layer 223, a modified IP layer 213, a modified
TCP layer (TCP*) 207, an application/presentation/session layer 201, an FP
layer 208, a modified IP layer 214, an Ethernet or equivalent layer 224 and a
UTP or equivalent layer 235. A transfer originating from an end point 285 is
acted upon using conventional data communication rules by the TCP layer
206, the IP layer 212, the Ethernet 222, the UTP layer 233, the UTP layer
234 and the Ethernet 223 before it is grabbed by the modified IP layer 213 and passed up the stack to the modified TCP layer 207, translated by the
application/presentation/session layer 201 and then managed by the FP layer 208 before being sent through the modified IP layer 214, the Ethernet 224
and UTP layer 235.
Following the arrows in Figure 2 illustrates the conventional stacks of the satellite gateway and terminal and also the stacks of a PEP2. In PEP2,
incoming FP packets are grabbed by a modified IP layer 219, after passing through the physical UTP layer 240 and link Ethernet 229 layers, and then
managed by the FP layer 209 before passing, via
application/presentation/session/layer 204 to TCP* 210 which along with the modified IP layer 220 manages the terrestrial TCP/IP connection.
As described earlier, the invention allows for the exchange of information between the Intermediate Device (the "Terminal") and PEPl. This is to aid overall flow control and the sharing of bandwidth within the
overall flow, between incoming (terrestrial network-to-PEP) and outgoing
(PEP-to-terrestrial network) TCP connections by managing buffer resources
associated to the link Bandwidth Delay Product (BDP). Additionally, the
novel overall flow control scheme ensures near 100% throughput, assuming
sufficient TCP/IP traffic as an input, while allowing for the receiving PEPs buffer requirements, through conventional window mechanisms, and fairly
sharing the capacity between a number of connections. The following section describes further aspects of the invention in greater detail.
From the PEP-Intermediate Device (Terminal) point of view, actual return link capacity available for PEP traffic at any given time is normally an
unknown. This issue mainly relates to the terminal population and its access to return link capacity. When packets are queued in the terminal 103 shown
in Figure 1, capacity is requested related to the number of packets being queued, however a capacity request may be only partially fulfilled, or not fulfilled at all. In this case, it becomes possible for terminal PEPl 102 to
oversupply or under supply the terminal which may result in dropping or low
usage. This dropping may increase buffering at Intermediate Devices and
lead to greater jitter and latency that results in low bandwidth usage and hence a loss of revenue potential. In brief, the PEP is unaware of the return
link capacity because of : 1. Limited knowledge about terminal queue status and size. 2. Dynamic capacity assignment to the terminal.
3. Non zero probability of loss on the local PEP-terminal link.
4. No confirmation of data transfer between PEP and terminal.
5. Unknown amount of traffic originating from the terminal itself, notably
Operations Administration & Management (OA&M) traffic.
For accurate flow control purposes, what is really needed is information concerning the status of the Intermediate Device output queue, and for the
PEP to supply data packets to fill the queue to a pre-determined level. We note that this queue could be an output queue for all packets or purely for
TCP/IP traffic.
It is possible to obtain some valuable information by taking advantage of functionality often provided for network management. What follows is a description of how a PEP device could have knowledge of the Intermediate
Devices (Terminal) queue status, and use this information to ensure that the queue is neither over-supplied nor under-supplied. Although the solution
uses Simple Network Management Protocol (SNMP), it should be understood that other protocols could be used to exchange information and, moreover, the Intermediate Device and PEP could be co-located in the same unit with some
form of direct linkage to erase the need for protocol driven communication.
Furthermore, if the PEP were located in the terminal, it could make use of known future capacity allocations to manage the flow of incoming TCP/IP connections more accurately. For example, if the PEP knows of any Constant Rate Assignments (CRAs) to the Terminal PEPl 102 (i.e. not dynamic and
varying capacity) it can at least ensure that sufficient TCP/IP flow is
maintained to fill its future assignments and possibly buffer space.
The Simple Network Management Protocol (SNMP) is a request-reply
protocol running over User Datagram Protocol (UDP). SNMP is an
asymmetric protocol, operating between a management station and an agent. Intermediate Devices (Terminals) are expected to support SNMP messaging for network management. The Management Information Base (MIB)
specified for Terminals incorporates several (but not all) generic MIB-II (MIB
version 2) objects. The following assumptions are made:
1. The PEP behind the terminal can assume the role of a local management station, thereby getting read access to MIB-II objects of the Intermediate
Device (Terminal) using the appropriate community name.
2. Buffering in the terminal is limited by number of packets rather than by volume of data (although we note that data bytes could be used if the
Intermediate Device output queue length in bytes were known).
3. The PEP either knows (or otherwise, can determine) the maximum size
(in number of packets) of the Intermediate Device output queue. This parameter may be called MaxQlen.
Potentially useful MIB-II objects for deriving buffer occupancy information are in the interfaces group (the group of MIB-II objects related to the network interfaces of the device), specifically, for any of the interfaces
given below. While these are specific, it should be understood that one of
ordinary skill in the art would recognize possible use of other interface
variations, modifications, and alternatives.
1. IfOutQlen: is a gauge indicating the number of packets in the outbound
queue.
2. IfOutOctets: is a counter indicating the total number of octets transmitted
out of the interface including framing octets.
3. IfOutUcastpkts: is a counter indicating the number of unicast packets
whose transmission to a single address was requested.
4. IfOutNUcastpkts: is a counter indicating the total number of packets
whose transmission to a multicast or broadcast address was requested. The basic idea for PEP to Intermediate Device communication is for the
PEP to regularly send SNMP GetRequest queries to the Intermediate Device (Terminal) for the IfOutQlen of the satellite link interface, although it is to be
noted that the Intermediate Device could send the PEP an SNMP Set when
its IfOutQlen reaches a pre-defined limit. The returned value allows the PEP to control the amount of data that is fed to the terminal.
From the point of view of a PEP, the algorithm is packet-driven: no actions are performed unless there are packets to send on the satellite link.
A flow chart 300 for the algorithm is illustrated in Figure 3. The algorithm proceeds as follows: In step 301, the variables FreeQ_i and FreeQ_(i-l) are first initialized. The process then moves to step 302. In step 302, the PEP
then waits until there are packets to send to the terminal (Packets_to_send
>0). The process then moves to step 303. In step 303, when there are packets
to send, a test is performed to check whether the PEP is already aware of a
certain amount of buffer space available on the terminal (FreeQ_(i-l)). If there is buffer space, the process moves to step 304, otherwise the process
moves to step 305. In step 304, the PEP sends packets up to (FreeQ_(i-l))
packets. The process then moves to step S305. In step S305, the PEP sends a SNMP GetRequest for IfOutQlen. The terminal responds with a SNMP GetResponse containing a value for IfOutQlen. The process then moves to
step S306. In step 306, the PEP computes FreeQ_i = (MaxQlen - OutQlen - Margin). The process then moves to step 307. In step 307, the PEPs send the
minimum of {FreeQ_I, Packets_to_send} packets to the terminal. The process then moves to step 308.
In step 308, the system determines whether FreeQ_i > Packets_to_send.
If yes, the process moves to step 309 where there is more buffer space
available on the terminal, and FreeQ_(i-l) is updated to the remaining space, i.e., FreeQ_(i-l)=FreeQ_i - Packets_to_send and the process returns to step
302. If no, the process continues to step 310. In step 310, If (FreeQ_i >= Thresh) then the process returns to step 305. Otherwise, the process moves
to step 311 to wait Query_timer and then returns to step 305. The following parameters employed by the process above are described: 1. MaxQlen: maximum size (in number of packets) of the Intermediate
Device (Terminal) satellite link outbound queue.
2. Query_timer: a delay to avoid querying the terminal too frequently. Its
value may be set based on the time required to empty a full queue at a
given return link maximum rate.
3. Thresh: a threshold (in number of packets) for deciding whether the queue
is full enough to wait before going back to query. A suitable low value
should be used.
4. Margin: a security margin to account for an unknown amount of traffic
originating from the terminal itself, for inaccuracies in the OutQlen
values reported. This should be set in such a way that the probability of dropping packets due to overflows at the terminal is suitably low to keep the costs of lost FP packets low.
The following variables are also defined:
1. FreeQ_i: free satellite link buffer space maximum on the terminal.
2. FreeQ_(i-l): remaining free satellite link buffer space available.
In a situation where packets to send are few and far between, FreeQ_i will
be much larger than Packets_to_send and the PEP will go through steps 302
to 308 each and every time a packet to send arrives. This entails one SNMP query per run, since step 303 avoids one SNMP query when the PEP is
already aware of some buffer space available on the terminal. The PEP could be made to wait for a certain delay before returning to step 302 after step 308, thereby avoiding sending a certain number of SNMP queries. However,
there is no simple way to avoid this delay when a large number of packets to
send arrive in a burst. Since the delay would slow transmission down in that
very important case, it is more efficient to go back to step 302 and run
through step 308 without delay. At worst, there will therefore be one query
per packet if packets arrive one by one, but in such a case, SNMP queries will
not hamper traffic since there will be virtually no traffic to interfere with.
In step 311 the PEP will wait until the expiration of a query timer if FreeQ_i is not greater than a threshold. This is to prevent un-necessary
SNMP queries being sent to an Intermediate Device when there is little
chance of the PEP sent packets having been sent beyond the Intermediate Device (Terminal). Another, lower timer, could be employed between the tests of step 310 and step 305 should FreeQ_i be greater than the threshold
to allow the Intermediate Device (Terminal) time to process the packets.
The PEP should also make use of some form of PEP rate control clocking-
out mechanism to ensure that the transmission rate from the PEP to the Intermediate Device (Terminal) does not over run the Terminal input queue
and processing rate when sending bursts to fill up the said queue. Finally,
note that packets arriving at the PEP from the terrestrial side, while the packet-driven algorithm is in process, are queued and subsequently drawn
from the queue when the algorithm returns to step 302, this process being consistent with the packet driven format of the PEP. Management of individual competing TCP/IP connection flows within
the general flow is achieved by sharing a buffer space equivalent to the
Bandwidth-Delay Product of the satellite link. In principle, every time a
packet arrives from the terrestrial side it is associated with a connection and,
before transgressing from the TCP* layer 207 to the FP layer 208 shown in Fig. 2, three tests are undertaken. This section describes the "buffer
utilization" test that is employed to share resources among the different
connections.
The PEP includes both a Transmit and a Receive Buffer. On arrival at
the PEP, a packet from the terrestrial world is queued in the TCP* 207 layer's buffer. This buffer is equivalent to a conventional TCP buffer at the receiving end point, with the space in the buffer being linked to the advertised window on the TCP connection. This linkage' allows the TCP
connection on the terrestrial link to slow down the flow of packets to the PEP as the TCP* buffer becomes full, in much the same way as TCP would slow
down the flow of packet as the receiving ends buffers become full.
Before a packet can pass from the TCP* buffer to the FP layer it must pass the following rules to ensure that sufficient space exists in the FP buffer:
1. If the connection buffer utilization is less than its allowed buffer space
(allowed buffer space = FP total buffer space / n connections, where the
total buffer space is sufficient space to fill one bandwidth-delay product) then the packet can be pushed; or 2. If the total buffer utilization (among all n connections) is less than the FP
total buffer space allowed, then the packet can be pushed.
3. Otherwise the packet remains in the TCP* buffers.
Once a packet is allowed to pass from the TCP* layer to the FP layer, it is
also stored in the FP buffer and associated to a connection. The FP buffer
facilitates re-transmissions if necessary and the sharing of the satellite link resources between competing TCP connections, as described.
It is important to note that the FP total buffer space can become artificially high. For example, if the global size is 3 Mbytes, then if three
connections are opened, each connection will be allowed 1 Mbyte for its individual transmit buffer.
When opening a fourth connection, even if the three connections are
using their whole transmit buffer, the new connection will immediately use its whole share of the transmit buffer. The FP global transmit buffer size will then become 3.75 Mbytes (1 + 1 + 1 + 0.75). The buffer utilization test allows
to exceed the global transmit buffer size, but this situation will never last
very long. The buffer utilization mechanism will redistribute equally the global transmit buffer size between the four opened connections. Each
connection will be allowed to use a new individual transmit buffer size of 0.75
Mbyte (3/4), thus pausing the flow of data on the three excessive connections. Eventually, the global transmit buffer size will decrease to 3 Mytes (0.75 + 0.75 + 0.75 + 0.75) and therefore, the size of the global transmit buffer will
fall back to 3 Mbytes in the steady state.
When space becomes available in the FP buffer (because of an
acknowledgement signal, ACK, from the receiving ending indicating the
successful arrival of a packet and thereby removing the packet from the FP Buffer), the PEP can pull a packet from the applicable TCP* buffer. This
mechanism ensures that when the FP Buffer and even TCP* buffers are full,
then the flow of a connection can be re-triggered by the arrival of ACKs. (note that, although the mechanism is not described as it is a known
mechanism, the PEP includes a re-transmission procedure, based on timers, to ensure that data is re -transmitted if presumed lost, thereby guaranteeing
the arrival of ACKs to re-trigger the flow or, if the satellite link is lost, a connection tear-down).
The following is an illustrative example for calculating default buffer sizes for the gateway and terminal-side PEP transmit and receive buffers. For purposes of this example, it is presumed that the total forward link rate
is 60 mega-bits per second (Mbps) and the total return link rate is 48Mbps.
Each terminal can be assumed to operate at a maximum receive rate in the
forward link of 8Mbps and a maximum transmit rate in the return link of 2Mbρs. In the forward direction the transmit bandwidth and thus transmit
buffer should assume 60Mbps. At the terminal (forward link receiver) the
bandwidth is 8Mbps. In the return link, the transmit and receive
bandwidths are 2Mbps and 48Mbps respectively. To calculate the Bandwidth
Delay Product (BDP) and hence the buffer requirements, 2 more factors are required: the Round Trip Time (RTT) and what can be called the utilization
factor.
The RTT is actually the time for a packet to be sent and the associated FP ACK to be sent back and clear the packet from the transmit buffer or open
up more receive buffer space through window advertisements. This is the RTT between the PEPs and includes any ACK delay timers used to provide a
minimum ACK frequency. From satellite testing, a value of 600ms is reasonable for Terminals that have been allocated a constant rate of
bandwidth (Constant Rate Assignment — CRA) for this example and a delayed ACK timer of 500ms could be assumed. For Terminals operating in a
pure BoD environment using Variable Bandwidth Dynamic Capacity
(NBDC), the mean RTT measured was around 1400ms which would obviously require a larger buffer.
The utilization factor adjusts the calculated buffer sizes to maintain PEP/FP performance under heavier buffer utilization due to packet
loss/corruption. From simulation and theory, we expect transmit buffer utilization to be around 102-105% of the calculated buffer size depending upon error conditions and packet sizes. Each FP packet that is lost must
remain buffered for an additional RTT to allow for successful retransmission
and acknowledgement.
At the receiver, a decision must be made regarding how many
retransmissions of any individual packet must be supported before FP performance is impacted. A single BDP sized buffer allows the link to stay
fully utilized as long as the receiver is processing the packets quickly enough
and there are no errors. If a packet loss occurs, the missing packet (hole) will progress to the left edge of the receive window (as the receiver processes data)
and the buffer will begin to fill. After one RTT the receive buffer will be full and transmission of new packets must be halted while the lost packet is
retransmitted. Effectively, a single RTT pause is inserted for any packet lost once. If a double BDP buffer is used, then virtually any number of packets can be lost once with the FP and the connection will still send new data at full speed if available.
The following calculations are for example only, but an attempt has
been made to make this example as efficient as possible. The two values given are for CRA and NBDC, respectively. It is important to note that one of
ordinary skill in the art would recognize other variations, modifications, and
alternatives GW PEP TX BUFFER = 60Mbps / 8 bits per byte * 105% * 1.1s to 1.9s = 8.7M
bytes to 14.9M bytes
GW PEP RX BUFFER = 48Mbps / 8 bits per byte * 200% * 1.1s to 1.9s =
13.2M bytes to 22.8M bytes
Terminal PEP TX BUFFER = 2Mbps / 8 bits per byte * 105% * 1.1s to 1.9s =
288K bytes to 499K bytes
Terminal PEP RX BUFFER = 8Mbps / 8 bits per byte * 200% * 1.1s to 1.9s =
2.2M bytes to 3.8M bytes
The description above has dealt with the use of the "buffer utilization" test to
share resources between competing TCP/IP connections in the terrestrial to
PEP direction. However, the same technique is used to manage the flow of
resources between the PEP and the terrestrial world using a Receive Buffer.
This allows for the fair sharing of resources between connections, the distribution of free resources if one or more connections are not employing their allocation and the prevention of slow connections dominating the link.
(In simulations it was found that if connections are not limited in their
allocation, then slow TCP/IP connections would tend to dominate the link).
The scheme works using the same rules but in reverse, this time the
intention being to decide whether or not to accept incoming FP packets from
the satellite. FP packets that are allowed to be stored in the FP Receiver buffer are cleared by a TCP acknowledgement. In much the same way, as
TCP operates, a window mechanism is used from the receiving PEP to the transmitting PEP to indicate the status of each connection's buffer space and
thus prevent over-flow.
The task for an overall flow control mechanism applicable for a large
bandwidth-delay product environment with changing bandwidth and latency,
such as a satellite system, is to achieve the following goals:
1. Maximize the flow of data from the sender to the satellite network without under-supplying or over-supplying the intermediate node (i.e. the
terminal that requests and receives bandwidth capacity).
2. Share satellite and terrestrial bandwidth within the overall flow so as to
ensure fairness while allowing unused capacity to be employed by hungry connections and preventing slow connections from dominating the link capacity.
3. Prevent the overflow of the receiving end PEPs buffer associated per
connection.
As used in this section, transmission of data means the passing of a
packet from the TCP* layer to the FP layer, the re -transmission of a FP data packet or an acknowledgment packet signaling the successful arrival of data.
In general (with the exception of re-transmissions and ACKs) packets are
pushed, upon arrival from the terrestrial world, from the TCP* 207 to the FP layer 208 as shown on Fig. 2, and then sent via the satellite with a copy being stored in the FP Transmit buffer. Before packets can be pushed (or re¬
transmitted / acknowledged) they have to pass three tests at PEPl, the transmitter PEP over satellite where the flow is client to server: a local
(transmit) buffer space test (Distribution of Satellite Resources amongst
TCP/IP connections at the PEP), a PEP-to-Intermediate Node Communication test, and a sufficient buffer space test. Sufficient buffer space
at the receiving PEP is signalled using a conventional window strategy in
packets (data or ACKs) flowing from the receiving PEP to the sending PEP.
When space becomes available (either because of a changed window parameter or an ACK removing a packet from the FP Tx Buffer), the PEP
pulls a packet from the applicable TCP* buffer 207, providing that the three flow control rules allow this. This technique, in combination with the above
rules and large initial windows, allows nearly 100% usage of available capacity, while managing the distribution of bandwidth in a variable bandwidth / latency system. Natural back pressure from the TCP* buffers
slows down the terrestrial TCP/IP connection flow.
It will be apparent to those skilled in the art that various modifications
and variations can be made to this invention without departing from the spirit or scope of the invention. Thus, it is intended that the present
invention covers the modifications and variations of this invention provided
that they come within the scope of any claims and their equivalents.

Claims

CLAIMS:
1. In a distributed connection splitting system, which comprises at least
two intermediate nodes, a method for managing data flow between the
intermediate nodes and through an intermediate device, comprising the steps
of: obtaining status data of the intermediate device; and
managing the flow of data between the intermediate nodes and the
intermediate device by determining the status of an intermediate device queue.
2. The method of claim 1, wherein the amount of at least one of data and packet space in the intermediate device is used to determine the quantity of
at least one of data and packets which should be sent to the intermediate device.
3. The method of claim 1, wherein the intermediate nodes send sufficient data to at-least partially fill the intermediate device queue to a pre-defined
level, and after a pre-determined delay to allow data to be transmitted,
checks the status of the intermediate device and then re -fills the intermediate device queue to a previous level.
4. The method of claim 1, wherein the intermediate nodes send regular
SNMP get messages to an intermediate device MIB or the intermediate device sends SNMP traps when a queue reaches a pre-detemined level to
indicate the current queue status.
5. The method of claim 1, wherein the flow of data from the intermediate
nodes to the intermediate device is more accurate by the intermediate nodes
having knowledge of current and future bandwidth information from the
intermediate device.
6. The method of claim 5, wherein the intermediate nodes and the
intermediate device are co-located in the same device with some form of direct linkage between the allocated bandwidth / queue and the intermediate
nodes.
7. A method of fairly distributing bandwidth among connections in a communications system, comprising the step of sharing of transmission storage amongst a number N connections.
8. The method according to claim 7, wherein the step of sharing further includes the steps of: calculating an amount of capacity given to a connection before allowance
for any applicable intermediate node to Intermediate device flow is X/N, where X is the maximum bandwidth-delay product of a communication and N is the number of connections;
determining if a sum of all the actual capacity usage by each individual
connection N is less than X, wherein the available capacity is shared by any
connections wishing to exceed an allocation; and determining, if new connections arrive, whether they are guaranteed
(X/N) capacity even if the result is a temporarily over-supply of capacity to a
link resulting in buffering at an output queue of the intermediate node.
9. A method for managing the flow of data from an intermediate node to
an intermediate device so that the transmission of data depends upon:
sufficient transmission buffer space in the sending intermediate node;
sufficient space in the receiver window of the receiving intermediate node; and sufficient capacity / buffer space at one of the intermediate devices.
10. The method of claim 9, wherein the failure of a test causes data to be
stored in an applicable input or output queue within the intermediate node thereby creating natural back pressure to a TCP sender in the regular
window updates sent from the intermediate node to the TCP sender.
PCT/US2002/036282 2001-11-13 2002-11-13 Flow control between performance enhancing proxies over variable bandwidth split links WO2003043285A2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU2002357711A AU2002357711A1 (en) 2001-11-13 2002-11-13 Flow control between performance enhancing proxies over variable bandwidth split links

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US33360801P 2001-11-13 2001-11-13
US60/333,608 2001-11-13

Publications (2)

Publication Number Publication Date
WO2003043285A2 true WO2003043285A2 (en) 2003-05-22
WO2003043285A3 WO2003043285A3 (en) 2004-06-10

Family

ID=23303516

Family Applications (3)

Application Number Title Priority Date Filing Date
PCT/US2002/036282 WO2003043285A2 (en) 2001-11-13 2002-11-13 Flow control between performance enhancing proxies over variable bandwidth split links
PCT/US2002/036217 WO2003043288A1 (en) 2001-11-13 2002-11-13 Enhancements for tcp perfomance enhancing proxies
PCT/US2002/036219 WO2003043289A2 (en) 2001-11-13 2002-11-13 Performance enhancing proxy techniques for internet protocol traffic

Family Applications After (2)

Application Number Title Priority Date Filing Date
PCT/US2002/036217 WO2003043288A1 (en) 2001-11-13 2002-11-13 Enhancements for tcp perfomance enhancing proxies
PCT/US2002/036219 WO2003043289A2 (en) 2001-11-13 2002-11-13 Performance enhancing proxy techniques for internet protocol traffic

Country Status (5)

Country Link
US (3) US6975647B2 (en)
EP (1) EP1446931A1 (en)
AU (2) AU2002357711A1 (en)
CA (1) CA2473863A1 (en)
WO (3) WO2003043285A2 (en)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2738983A4 (en) * 2011-07-26 2015-03-11 Hitachi Ltd Communication device
US9143450B2 (en) 2011-12-30 2015-09-22 Industrial Technology Research Institute Communication system and method for assisting with the transmission of TCP packets
US9264365B2 (en) 2012-07-31 2016-02-16 International Business Machines Corporation Split transport control protocol (TCP) flow control management in a cellular broadband network

Families Citing this family (294)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8996705B2 (en) 2000-04-17 2015-03-31 Circadence Corporation Optimization of enhanced network links
US20110128972A1 (en) 2000-04-17 2011-06-02 Randy Thornton Peer to peer dynamic network link acceleration
US20020002625A1 (en) 2000-04-17 2002-01-03 Mark Vange System and method for reformatting data traffic
US6850732B2 (en) * 2001-03-30 2005-02-01 Wengen Wireless Llc Scalable satellite data communication system that provides incremental global broadband service using earth-fixed cells
US6778825B2 (en) * 2001-05-08 2004-08-17 The Boeing Company Path discovery method for return link communications between a mobile platform and a base station
US20050198379A1 (en) 2001-06-13 2005-09-08 Citrix Systems, Inc. Automatically reconnecting a client across reliable and persistent communication sessions
US7320833B2 (en) * 2001-11-07 2008-01-22 E.I. Du Pont De Nemours And Company Electroluminescent platinum compounds and devices made with such compounds
DE60322988D1 (en) * 2002-01-28 2008-10-02 Hughes Network Systems Llc Method and device for integrating performance improvement functions in a virtual private network (VPN)
US7389533B2 (en) * 2002-01-28 2008-06-17 Hughes Network Systems, Llc Method and system for adaptively applying performance enhancing functions
US8976798B2 (en) * 2002-01-28 2015-03-10 Hughes Network Systems, Llc Method and system for communicating over a segmented virtual private network (VPN)
EP1335289A1 (en) * 2002-02-07 2003-08-13 Siemens Aktiengesellschaft Method for software downloads in a radio communications system
US7042857B2 (en) 2002-10-29 2006-05-09 Qualcom, Incorporated Uplink pilot and signaling transmission in wireless communication systems
US7542471B2 (en) * 2002-10-30 2009-06-02 Citrix Systems, Inc. Method of determining path maximum transmission unit
US7630305B2 (en) 2003-07-29 2009-12-08 Orbital Data Corporation TCP selective acknowledgements for communicating delivered and missed data packets
US7616638B2 (en) * 2003-07-29 2009-11-10 Orbital Data Corporation Wavefront detection and disambiguation of acknowledgments
US8270423B2 (en) 2003-07-29 2012-09-18 Citrix Systems, Inc. Systems and methods of using packet boundaries for reduction in timeout prevention
US8233392B2 (en) 2003-07-29 2012-07-31 Citrix Systems, Inc. Transaction boundary detection for reduction in timeout penalties
JP4283589B2 (en) * 2003-03-25 2009-06-24 株式会社エヌ・ティ・ティ・ドコモ COMMUNICATION DEVICE, COMMUNICATION CONTROL METHOD, AND PROGRAM
US7349400B2 (en) * 2003-04-29 2008-03-25 Narus, Inc. Method and system for transport protocol reconstruction and timer synchronization for non-intrusive capturing and analysis of packets on a high-speed distributed network
US7177297B2 (en) * 2003-05-12 2007-02-13 Qualcomm Incorporated Fast frequency hopping with a code division multiplexed pilot in an OFDMA system
US20040236855A1 (en) * 2003-05-23 2004-11-25 Amir Peles Multi-link tunneling
WO2004107185A1 (en) * 2003-05-27 2004-12-09 Macdonald, Dettwiler And Associates Ltd. Satellite communications system for providing global, high quality movement of very large data files
US7760729B2 (en) * 2003-05-28 2010-07-20 Citrix Systems, Inc. Policy based network address translation
FI20030929A (en) * 2003-06-19 2004-12-20 Nokia Corp Procedure and arrangement for conducting wireless information transmission in a means of communication
US20040264368A1 (en) * 2003-06-30 2004-12-30 Nokia Corporation Data transfer optimization in packet data networks
US8275910B1 (en) * 2003-07-02 2012-09-25 Apple Inc. Source packet bridge
WO2005004418A1 (en) * 2003-07-04 2005-01-13 Nippon Telegraph And Telephone Corporation Remote access vpn mediation method and mediation device
US7385937B2 (en) * 2003-07-23 2008-06-10 International Business Machines Corporation Method and system for determining a path between two points of an IP network over which datagrams are transmitted
US7460472B2 (en) * 2003-07-25 2008-12-02 Nokia Corporation System and method for transmitting information in a communication network
US7698453B2 (en) 2003-07-29 2010-04-13 Oribital Data Corporation Early generation of acknowledgements for flow control
US8238241B2 (en) * 2003-07-29 2012-08-07 Citrix Systems, Inc. Automatic detection and window virtualization for flow control
US7656799B2 (en) 2003-07-29 2010-02-02 Citrix Systems, Inc. Flow control system architecture
WO2005013083A2 (en) 2003-07-29 2005-02-10 Orbital Data Corporation Flow control architecture
US8432800B2 (en) 2003-07-29 2013-04-30 Citrix Systems, Inc. Systems and methods for stochastic-based quality of service
US8437284B2 (en) 2003-07-29 2013-05-07 Citrix Systems, Inc. Systems and methods for additional retransmissions of dropped packets
US7286476B2 (en) * 2003-08-01 2007-10-23 F5 Networks, Inc. Accelerating network performance by striping and parallelization of TCP connections
KR100506529B1 (en) 2003-08-06 2005-08-03 삼성전자주식회사 Apparatus, system and method for path mtu discovery in data communication network
US7376418B2 (en) * 2003-09-08 2008-05-20 Wells Loren L System and method for multiple access control in satellite communications system
US8553572B2 (en) * 2003-09-10 2013-10-08 Hyperdata Technologies, Inc. Internet protocol optimizer
US7058058B2 (en) 2003-11-05 2006-06-06 Juniper Networks, Inc. Transparent optimization for transmission control protocol initial session establishment
JP2007533172A (en) * 2003-11-11 2007-11-15 サイトリックス ゲートウェイズ, インコーポレイテッド Virtual private network with fake server
US7978716B2 (en) 2003-11-24 2011-07-12 Citrix Systems, Inc. Systems and methods for providing a VPN solution
US20050122977A1 (en) * 2003-12-05 2005-06-09 Microsoft Corporation Efficient download mechanism for devices with limited local storage
US7760636B1 (en) * 2004-01-26 2010-07-20 Cisco Technology, Inc. Retransmission and flow control in a logical network tunnel
US8611283B2 (en) * 2004-01-28 2013-12-17 Qualcomm Incorporated Method and apparatus of using a single channel to provide acknowledgement and assignment messages
US7792147B1 (en) * 2004-02-09 2010-09-07 Symantec Corporation Efficient assembly of fragmented network traffic for data security
US7616644B2 (en) * 2004-02-25 2009-11-10 Nokia Corporation Method and apparatus providing a protocol to enable a wireless TCP session using a split TCP connection
US7360083B1 (en) 2004-02-26 2008-04-15 Krishna Ragireddy Method and system for providing end-to-end security solutions to aid protocol acceleration over networks using selective layer encryption
US7895648B1 (en) * 2004-03-01 2011-02-22 Cisco Technology, Inc. Reliably continuing a secure connection when the address of a machine at one end of the connection changes
US20050210122A1 (en) * 2004-03-22 2005-09-22 Qualcomm Incorporated HTTP acceleration over a network link
US20050210121A1 (en) * 2004-03-22 2005-09-22 Qualcomm Incorporated Satellite anticipatory bandwith acceleration
US7539176B1 (en) * 2004-04-02 2009-05-26 Cisco Technology Inc. System and method for providing link, node and PG policy based routing in PNNI based ATM networks
US20060031571A1 (en) * 2004-04-29 2006-02-09 International Business Machines Corporation Data communications through a split connection proxy
WO2005114960A1 (en) * 2004-05-19 2005-12-01 Computer Associates Think, Inc. Method and apparatus for low-overhead service availability and performance moniroring
US8416694B2 (en) * 2004-06-22 2013-04-09 Telefonaktiebolaget Lm Ericsson (Publ) Network feedback method and device
US8739274B2 (en) 2004-06-30 2014-05-27 Citrix Systems, Inc. Method and device for performing integrated caching in a data communication network
US7757074B2 (en) 2004-06-30 2010-07-13 Citrix Application Networking, Llc System and method for establishing a virtual private network
US8495305B2 (en) 2004-06-30 2013-07-23 Citrix Systems, Inc. Method and device for performing caching of dynamically generated objects in a data communication network
US8891349B2 (en) 2004-07-23 2014-11-18 Qualcomm Incorporated Method of optimizing portions of a frame
JP2008507928A (en) 2004-07-23 2008-03-13 サイトリックス システムズ, インコーポレイテッド System and method for optimizing communication between network nodes
US7606902B2 (en) 2004-07-23 2009-10-20 Citrix Systems, Inc. Method and systems for routing packets from an endpoint to a gateway
CA2576569A1 (en) 2004-08-13 2006-02-23 Citrix Systems, Inc. A method for maintaining transaction integrity across multiple remote access servers
TW200608224A (en) * 2004-08-23 2006-03-01 Lite On It Corp Player and method for processing a file with vector-based format
US8224966B2 (en) * 2004-08-24 2012-07-17 Cisco Technology, Inc. Reproxying an unproxied connection
US7895431B2 (en) * 2004-09-10 2011-02-22 Cavium Networks, Inc. Packet queuing, scheduling and ordering
US20060056379A1 (en) * 2004-09-14 2006-03-16 Motorola, Inc. System and method for network-assisted connection in a wireless environment
US7975064B2 (en) * 2004-09-16 2011-07-05 International Business Machines Corporation Envelope packet architecture for broadband engine
US7711835B2 (en) 2004-09-30 2010-05-04 Citrix Systems, Inc. Method and apparatus for reducing disclosure of proprietary data in a networked environment
US7748032B2 (en) 2004-09-30 2010-06-29 Citrix Systems, Inc. Method and apparatus for associating tickets in a ticket hierarchy
US8613048B2 (en) 2004-09-30 2013-12-17 Citrix Systems, Inc. Method and apparatus for providing authorized remote access to application sessions
US7769863B2 (en) 2004-11-19 2010-08-03 Viasat, Inc. Network accelerator for controlled long delay links
WO2006058212A2 (en) * 2004-11-24 2006-06-01 Ist International, Inc. Methods and apparatus for estimating bandwidth of a data network
US7515566B2 (en) * 2004-12-09 2009-04-07 Viasat, Inc. Partial mesh communication in hub based system
US7551620B1 (en) * 2004-12-15 2009-06-23 Orbital Data Corporation Protecting data integrity in an enhanced network connection
US7480301B2 (en) * 2004-12-16 2009-01-20 International Business Machines Corporation Method, system and article for improved TCP performance during retransmission in response to selective acknowledgement
US8831115B2 (en) 2004-12-22 2014-09-09 Qualcomm Incorporated MC-CDMA multiplexing in an orthogonal uplink
US8238923B2 (en) 2004-12-22 2012-08-07 Qualcomm Incorporated Method of using shared resources in a communication system
US7453849B2 (en) * 2004-12-22 2008-11-18 Qualcomm Incorporated Method of implicit deassignment of resources
US8954595B2 (en) 2004-12-30 2015-02-10 Citrix Systems, Inc. Systems and methods for providing client-side accelerated access to remote applications via TCP buffering
US8700695B2 (en) 2004-12-30 2014-04-15 Citrix Systems, Inc. Systems and methods for providing client-side accelerated access to remote applications via TCP pooling
US8706877B2 (en) 2004-12-30 2014-04-22 Citrix Systems, Inc. Systems and methods for providing client-side dynamic redirection to bypass an intermediary
US8549149B2 (en) 2004-12-30 2013-10-01 Citrix Systems, Inc. Systems and methods for providing client-side accelerated access to remote applications via TCP multiplexing
US7810089B2 (en) 2004-12-30 2010-10-05 Citrix Systems, Inc. Systems and methods for automatic installation and execution of a client-side acceleration program
US7581005B2 (en) * 2005-01-20 2009-08-25 Citrix Systems, Inc. Systems and methods for preserving transport layer protocol options
US8077632B2 (en) * 2005-01-20 2011-12-13 Citrix Systems, Inc. Automatic LAN/WAN port detection
CN102104632B (en) 2005-01-24 2012-08-22 茨特里克斯系统公司 Systems and methods for performing caching of dynamically generated objects in a network
US8255456B2 (en) 2005-12-30 2012-08-28 Citrix Systems, Inc. System and method for performing flash caching of dynamically generated objects in a data communication network
US8024568B2 (en) 2005-01-28 2011-09-20 Citrix Systems, Inc. Method and system for verification of an endpoint security scan
KR100597425B1 (en) * 2005-02-16 2006-07-05 삼성전자주식회사 Method for preventing unnecessary retransmission caused by transmission delay in wireless network and communication apparatus using the same
US9118717B2 (en) * 2005-02-18 2015-08-25 Cisco Technology, Inc. Delayed network protocol proxy for packet inspection in a network
JP4785551B2 (en) * 2005-03-07 2011-10-05 キヤノン株式会社 Communication apparatus, communication method, and computer executable program
US9055088B2 (en) * 2005-03-15 2015-06-09 International Business Machines Corporation Managing a communication session with improved session establishment
WO2006099883A1 (en) * 2005-03-23 2006-09-28 Telefonaktiebolaget Lm Ericsson (Publ) System and method for transporting data units through a communication network
US7697524B2 (en) * 2005-04-05 2010-04-13 Cisco Technology, Inc. Method and system for determining path maximum transfer unit for IP multicast
US7535907B2 (en) * 2005-04-08 2009-05-19 Oavium Networks, Inc. TCP engine
US8204080B2 (en) 2005-04-22 2012-06-19 Cisco Technology, Inc. Techniques for encapsulating point to point (PPP) over Ethernet frames
US7525972B2 (en) * 2005-04-22 2009-04-28 Cisco Technology, Inc. Techniques for encapsulating point to point protocol (PPP) over Ethernet frames
US7782758B2 (en) * 2005-05-06 2010-08-24 California Institute Of Technology Efficient loss recovery architecture for loss-decoupled TCP
US8675486B2 (en) * 2005-05-17 2014-03-18 Hughes Network Systems, Llc Method and system for efficient flow control in a spot beam satellite system
US7706314B2 (en) * 2005-05-20 2010-04-27 Cisco Technology, Inc. Approach for implementing IPsec in performance enhancing proxy (PEP) environments
KR101114737B1 (en) * 2005-05-31 2012-02-29 삼성전자주식회사 Method for reporting packet received result in a mobile communication system
US8370583B2 (en) * 2005-08-12 2013-02-05 Silver Peak Systems, Inc. Network memory architecture for providing data based on local accessibility
US8171238B1 (en) 2007-07-05 2012-05-01 Silver Peak Systems, Inc. Identification of data stored in memory
US8095774B1 (en) 2007-07-05 2012-01-10 Silver Peak Systems, Inc. Pre-fetching data into a memory
US8392684B2 (en) 2005-08-12 2013-03-05 Silver Peak Systems, Inc. Data encryption in a network memory architecture for providing data based on local accessibility
EP1768336B1 (en) * 2005-09-22 2009-11-18 Alcatel Lucent Network device for manipulation of TCP segments for increase of efficiency in the transmission
US8929402B1 (en) 2005-09-29 2015-01-06 Silver Peak Systems, Inc. Systems and methods for compressing packet data by predicting subsequent data
US8489562B1 (en) 2007-11-30 2013-07-16 Silver Peak Systems, Inc. Deferred data storage
US8811431B2 (en) * 2008-11-20 2014-08-19 Silver Peak Systems, Inc. Systems and methods for compressing packet data
US7940713B2 (en) * 2005-12-08 2011-05-10 Electronics And Telecommunications Research Institute Apparatus and method for traffic performance improvement and traffic security in interactive satellite communication system
EP1798890B1 (en) * 2005-12-15 2009-03-18 Nokia Corporation Methods, device and computer program product for maintaining mapping relationship
US8301839B2 (en) 2005-12-30 2012-10-30 Citrix Systems, Inc. System and method for performing granular invalidation of cached dynamically generated objects in a data communication network
US8406220B2 (en) * 2005-12-30 2013-03-26 Honeywell International Inc. Method and system for integration of wireless devices with a distributed control system
US7921184B2 (en) 2005-12-30 2011-04-05 Citrix Systems, Inc. System and method for performing flash crowd caching of dynamically generated objects in a data communication network
US20070156879A1 (en) * 2006-01-03 2007-07-05 Klein Steven E Considering remote end point performance to select a remote end point to use to transmit a task
US8151323B2 (en) 2006-04-12 2012-04-03 Citrix Systems, Inc. Systems and methods for providing levels of access and action control via an SSL VPN appliance
US8605730B2 (en) * 2006-04-13 2013-12-10 Directpacket Research, Inc. System and method for multimedia communication across disparate networks
US8004973B2 (en) 2006-04-25 2011-08-23 Citrix Systems, Inc. Virtual inline configuration for a network device
US7894509B2 (en) * 2006-05-18 2011-02-22 Harris Corporation Method and system for functional redundancy based quality of service
GB0611249D0 (en) * 2006-06-07 2006-07-19 Nokia Corp Communication system
US7856012B2 (en) 2006-06-16 2010-12-21 Harris Corporation System and methods for generic data transparent rules to support quality of service
US8064464B2 (en) 2006-06-16 2011-11-22 Harris Corporation Method and system for inbound content-based QoS
US8516153B2 (en) 2006-06-16 2013-08-20 Harris Corporation Method and system for network-independent QoS
US7990860B2 (en) 2006-06-16 2011-08-02 Harris Corporation Method and system for rule-based sequencing for QoS
US20070291767A1 (en) * 2006-06-16 2007-12-20 Harris Corporation Systems and methods for a protocol transformation gateway for quality of service
US7916626B2 (en) 2006-06-19 2011-03-29 Harris Corporation Method and system for fault-tolerant quality of service
US8730981B2 (en) 2006-06-20 2014-05-20 Harris Corporation Method and system for compression based quality of service
KR101298265B1 (en) * 2006-07-07 2013-08-22 삼성전자주식회사 Method for receiving and sending packets
US8300653B2 (en) 2006-07-31 2012-10-30 Harris Corporation Systems and methods for assured communications with quality of service
US20100241759A1 (en) * 2006-07-31 2010-09-23 Smith Donald L Systems and methods for sar-capable quality of service
US8755381B2 (en) * 2006-08-02 2014-06-17 Silver Peak Systems, Inc. Data matching using flow based packet data storage
US8885632B2 (en) * 2006-08-02 2014-11-11 Silver Peak Systems, Inc. Communications scheduler
US7953889B2 (en) * 2006-08-03 2011-05-31 Citrix Systems, Inc. Systems and methods for routing VPN traffic around network disruption
US8677007B2 (en) * 2006-08-03 2014-03-18 Citrix Systems, Inc. Systems and methods for bypassing an appliance
US8572721B2 (en) * 2006-08-03 2013-10-29 Citrix Systems, Inc. Methods and systems for routing packets in a VPN-client-to-VPN-client connection via an SSL/VPN network appliance
US7907621B2 (en) * 2006-08-03 2011-03-15 Citrix Systems, Inc. Systems and methods for using a client agent to manage ICMP traffic in a virtual private network environment
EP2055048B1 (en) * 2006-08-18 2010-05-05 Koninklijke Philips Electronics N.V. Decoupled connections
US7769869B2 (en) * 2006-08-21 2010-08-03 Citrix Systems, Inc. Systems and methods of providing server initiated connections on a virtual private network
US8493858B2 (en) 2006-08-22 2013-07-23 Citrix Systems, Inc Systems and methods for providing dynamic connection spillover among virtual servers
US8655357B1 (en) * 2006-08-22 2014-02-18 At&T Mobility Ii Llc Systems and methods for identifying applications on a communications device
US8312120B2 (en) * 2006-08-22 2012-11-13 Citrix Systems, Inc. Systems and methods for providing dynamic spillover of virtual servers based on bandwidth
US7933257B2 (en) * 2006-09-20 2011-04-26 Cisco Technology, Inc. Using QoS tunnels for TCP latency optimization
US20080181108A1 (en) * 2006-10-06 2008-07-31 Viasat, Inc. Dynamic Feedback For Outbound Link Rate Adjustment In Multi-Rate Downstream
EP1912402B1 (en) * 2006-10-10 2019-08-28 Mitsubishi Electric R&D Centre Europe B.V. Protection of the data transmission network systems against buffer oversizing attacks
US7646728B2 (en) * 2006-10-13 2010-01-12 SafeMedia Corp. Network monitoring and intellectual property protection device, system and method
US8102768B2 (en) * 2006-10-18 2012-01-24 D & S Consultants, Inc. Method and system for traffic flow control in a communication network
US8533846B2 (en) 2006-11-08 2013-09-10 Citrix Systems, Inc. Method and system for dynamically associating access rights with a resource
US20080130504A1 (en) * 2006-12-04 2008-06-05 D&S Consultants, Inc. Integrated Quality of Service and Resource Management in a Network Edge Device
US20080137863A1 (en) * 2006-12-06 2008-06-12 Motorola, Inc. Method and system for using a key management facility to negotiate a security association via an internet key exchange on behalf of another device
KR101329150B1 (en) * 2006-12-08 2013-11-14 삼성전자주식회사 PANA Authentication Method and System
US7664857B2 (en) * 2007-01-26 2010-02-16 Citrix Systems, Inc. Systems and methods of using an IP ID field for automatic WAN/LAN detection
US8477804B2 (en) * 2007-03-02 2013-07-02 Hitachi, Ltd. ICMP translator
US7760642B2 (en) 2007-03-12 2010-07-20 Citrix Systems, Inc. Systems and methods for providing quality of service precedence in TCP congestion control
US7796510B2 (en) * 2007-03-12 2010-09-14 Citrix Systems, Inc. Systems and methods for providing virtual fair queueing of network traffic
US7706266B2 (en) 2007-03-12 2010-04-27 Citrix Systems, Inc. Systems and methods of providing proxy-based quality of service
DE102007012143A1 (en) 2007-03-12 2008-09-18 Viprinet Gmbh Arrangement and method for transmitting a data stream via bundled network access lines, as well as transmitting and receiving auxiliary device and transmitting and receiving method for it
US7743160B2 (en) * 2007-03-29 2010-06-22 Blue Coat Systems, Inc. System and method of delaying connection acceptance to support connection request processing at layer-7
EP2174516B1 (en) * 2007-05-15 2015-12-09 Broadcom Corporation Transporting gsm packets over a discontinuous ip based network
US8997115B2 (en) 2007-08-31 2015-03-31 International Business Machines Corporation Method for data delivery in a network
US8908700B2 (en) 2007-09-07 2014-12-09 Citrix Systems, Inc. Systems and methods for bridging a WAN accelerator with a security gateway
US8334787B2 (en) 2007-10-25 2012-12-18 Trilliant Networks, Inc. Gas meter having ultra-sensitive magnetic material retrofitted onto meter dial and method for performing meter retrofit
US8305896B2 (en) * 2007-10-31 2012-11-06 Cisco Technology, Inc. Selective performance enhancement of traffic flows
US8502640B2 (en) 2007-11-25 2013-08-06 Trilliant Networks, Inc. System and method for transmitting and receiving information on a neighborhood area network
EP2215556B1 (en) 2007-11-25 2019-08-28 Trilliant Networks, Inc. System and method for transmitting power status notifications in an advanced metering infrastructure network
WO2009067251A1 (en) 2007-11-25 2009-05-28 Trilliant Networks, Inc. Communication and message route optimization and messaging in a mesh network
US8138934B2 (en) 2007-11-25 2012-03-20 Trilliant Networks, Inc. System and method for false alert filtering of event messages within a network
CA2705074A1 (en) 2007-11-25 2009-05-28 Trilliant Networks, Inc. Energy use control system and method
US8307115B1 (en) 2007-11-30 2012-11-06 Silver Peak Systems, Inc. Network memory mirroring
US7970928B2 (en) * 2007-12-17 2011-06-28 Microsoft Corporation Transparent auto-discovery of network devices logically located between a client and server
EP2107464A1 (en) * 2008-01-23 2009-10-07 Comptel Corporation Convergent mediation system with dynamic resource allocation
US8442052B1 (en) 2008-02-20 2013-05-14 Silver Peak Systems, Inc. Forward packet recovery
US7965721B1 (en) * 2008-03-21 2011-06-21 Nextel Communications Inc. System and method of transferring communications between networks
US7991008B2 (en) * 2008-06-26 2011-08-02 Dell Products L.P. Method for identifying the transmission control protocol stack of a connection
US9717021B2 (en) 2008-07-03 2017-07-25 Silver Peak Systems, Inc. Virtual network overlay
US10805840B2 (en) 2008-07-03 2020-10-13 Silver Peak Systems, Inc. Data transmission via a virtual wide area network overlay
US8743683B1 (en) 2008-07-03 2014-06-03 Silver Peak Systems, Inc. Quality of service using multiple flows
US10164861B2 (en) 2015-12-28 2018-12-25 Silver Peak Systems, Inc. Dynamic monitoring and visualization for network health characteristics
JP5200755B2 (en) * 2008-08-20 2013-06-05 日本電気株式会社 Wireless base station, wireless communication system, path connection method and program
EP2321983B1 (en) 2008-09-04 2018-05-09 Trilliant Networks, Inc. Method for implementing mesh network communications using a mesh network protocol
US8958363B2 (en) 2008-10-15 2015-02-17 Viasat, Inc. Profile-based bandwidth scheduler
US8387112B1 (en) 2008-10-29 2013-02-26 Juniper Networks, Inc. Automatic software update on network devices
US8560908B2 (en) * 2008-11-06 2013-10-15 Qualcomm Incorporated Methods and systems for ARQ feedback message improvement
US8140687B2 (en) * 2008-11-13 2012-03-20 Hughes Network Systems, Llc Performance enhancing proxy handover
US8289182B2 (en) 2008-11-21 2012-10-16 Trilliant Networks, Inc. Methods and systems for virtual energy management display
US8891338B2 (en) 2009-01-29 2014-11-18 Itron, Inc. Measuring the accuracy of an endpoint clock from a remote device
US8319658B2 (en) 2009-03-11 2012-11-27 Trilliant Networks, Inc. Process, device and system for mapping transformers to meters and locating non-technical line losses
US8374091B2 (en) * 2009-03-26 2013-02-12 Empire Technology Development Llc TCP extension and variants for handling heterogeneous applications
US8396960B2 (en) * 2009-05-08 2013-03-12 Canon Kabushiki Kaisha Efficient network utilization using multiple physical interfaces
US8880716B2 (en) * 2009-05-08 2014-11-04 Canon Kabushiki Kaisha Network streaming of a single data stream simultaneously over multiple physical interfaces
US8325601B2 (en) * 2009-05-08 2012-12-04 Canon Kabushiki Kaisha Reliable network streaming of a single data stream over multiple physical interfaces
EP2446590B1 (en) * 2009-06-22 2015-11-25 Citrix Systems, Inc. Systems and methods for platform rate limiting
US8589570B2 (en) * 2009-08-13 2013-11-19 Verizon Patent And Licensing Inc. Dynamic handler for SIP max-size error
US8781462B2 (en) 2009-09-28 2014-07-15 Itron, Inc. Methodology and apparatus for validating network coverage
US8780823B1 (en) 2009-10-08 2014-07-15 Viasat, Inc. Event driven grant allocation
US20110134930A1 (en) * 2009-12-09 2011-06-09 Mclaren Moray Packet-based networking system
WO2011075670A1 (en) * 2009-12-18 2011-06-23 Google Inc. Matching encoder output to network bandwidth
CA2785842A1 (en) * 2009-12-31 2011-07-07 Bce Inc. Method and system for increasing performance of transmission control protocol sessions in data networks
US9137166B2 (en) * 2010-01-28 2015-09-15 Brocade Communications Systems, Inc. In-order traffic aggregation with reduced buffer usage
US8356109B2 (en) 2010-05-13 2013-01-15 Canon Kabushiki Kaisha Network streaming of a video stream over multiple communication channels
US9294506B2 (en) * 2010-05-17 2016-03-22 Certes Networks, Inc. Method and apparatus for security encapsulating IP datagrams
CA2809034A1 (en) 2010-08-27 2012-03-01 Randy Frei System and method for interference free operation of co-located tranceivers
US9013173B2 (en) 2010-09-13 2015-04-21 Trilliant Networks, Inc. Process for detecting energy theft
US8832428B2 (en) 2010-11-15 2014-09-09 Trilliant Holdings Inc. System and method for securely communicating across multiple networks using a single radio
US20120131245A1 (en) * 2010-11-19 2012-05-24 Silicon Image, Inc. Transfer of control bus signaling on packet-switched network
US20120151087A1 (en) * 2010-12-14 2012-06-14 Nuvel, Inc. System and method for providing a network proxy data tunnel
US8364641B2 (en) * 2010-12-15 2013-01-29 International Business Machines Corporation Method and system for deduplicating data
US20120163167A1 (en) * 2010-12-27 2012-06-28 Symbol Technologies, Inc. Transmission control protocol optimization systems and methods for wireless networks
US9282383B2 (en) 2011-01-14 2016-03-08 Trilliant Incorporated Process, device and system for volt/VAR optimization
WO2012103072A2 (en) 2011-01-25 2012-08-02 Trilliant Holdings, Inc. Aggregated real-time power outages/restoration reporting (rtpor) in a secure mesh network
EP3288236B1 (en) 2011-02-10 2020-04-01 Trilliant Holdings, Inc. Device and method for facilitating secure communications over a cellular network
US9041349B2 (en) 2011-03-08 2015-05-26 Trilliant Networks, Inc. System and method for managing load distribution across a power grid
CN102739569B (en) * 2011-04-01 2015-04-15 中国科学院空间科学与应用研究中心 Gateway used in satellite communication and method for enhancing TCP performance
US9515925B2 (en) 2011-05-19 2016-12-06 Qualcomm Incorporated Apparatus and methods for media access control header compression
US20130128809A1 (en) * 2011-05-19 2013-05-23 Qualcomm Incorporated Apparatus and methods for media access control header compression
JP5258938B2 (en) * 2011-07-26 2013-08-07 株式会社日立製作所 Communication device
US9001787B1 (en) 2011-09-20 2015-04-07 Trilliant Networks Inc. System and method for implementing handover of a hybrid communications module
US9167614B2 (en) * 2011-09-28 2015-10-20 Marvell International Ltd. Tunneled direct link setup systems and methods with consistent link information maintenance
US9130991B2 (en) 2011-10-14 2015-09-08 Silver Peak Systems, Inc. Processing data packets in performance enhancing proxy (PEP) environment
US9626224B2 (en) 2011-11-03 2017-04-18 Silver Peak Systems, Inc. Optimizing available computing resources within a virtual environment
CN103200622A (en) * 2012-01-09 2013-07-10 株式会社Ntt都科摩 Communication handling method, device and gateway equipment
US9025475B1 (en) * 2012-01-16 2015-05-05 Amazon Technologies, Inc. Proactively retransmitting data packets in a low latency packet data network
US9742732B2 (en) * 2012-03-12 2017-08-22 Varmour Networks, Inc. Distributed TCP SYN flood protection
US8938804B2 (en) * 2012-07-12 2015-01-20 Telcordia Technologies, Inc. System and method for creating BGP route-based network traffic profiles to detect spoofed traffic
US9236936B2 (en) * 2012-08-31 2016-01-12 Hughes Network Systems, Llc System and method for low-complexity, high-speed preprocessing of encapsulated packets in a broadband communications network
US9258335B1 (en) 2012-09-17 2016-02-09 Amazon Technologies, Inc. Connection-aggregation proxy service
CN103795632B (en) 2012-10-31 2017-02-22 华为技术有限公司 Data message transmission method, related equipment and system
JP6095362B2 (en) * 2012-12-27 2017-03-15 古野電気株式会社 Satellite communication device and satellite communication system
US9413652B2 (en) * 2013-02-19 2016-08-09 Dell Products L.P. Systems and methods for path maximum transmission unit discovery
US9887925B2 (en) * 2013-03-04 2018-02-06 Gilat Satellite Networks Ltd. Network performance enhancement
US9549371B2 (en) 2013-03-14 2017-01-17 Qualcomm Incorporated Access point proxy and multi-hop wireless communication
US9282172B2 (en) * 2013-05-10 2016-03-08 Blackberry Limited System and method for relaying data based on a modified reliable transport protocol
US9491261B1 (en) * 2013-07-29 2016-11-08 Amazon Technologies, Inc. Remote messaging protocol
US10102755B1 (en) 2013-10-07 2018-10-16 Satcom Direct, Inc. Method and system for aircraft positioning—automated tracking using onboard global voice and high-speed data
US9565618B1 (en) 2013-10-09 2017-02-07 Satcom Direct, Inc. Air to ground management of multiple communication paths
US9553658B1 (en) 2013-10-09 2017-01-24 Satcom Direct, Inc. Router for aircraft communications with simultaneous satellite connections
US9577742B1 (en) * 2013-10-10 2017-02-21 Satcom Direct, Inc. Data compression and acceleration for air to ground communications
JP2015095680A (en) * 2013-11-08 2015-05-18 株式会社日立製作所 Communication device and communication system
US9160553B2 (en) 2013-11-27 2015-10-13 Architecture Technology Corporation Adaptive multicast network communications
US9887974B2 (en) 2013-11-27 2018-02-06 Architecture Technology Corporation Method for network communication past encryption devices
US9191377B2 (en) * 2013-11-27 2015-11-17 Architecture Technology Corporation Method for network communication past encryption devices
US9635114B2 (en) * 2014-01-24 2017-04-25 Netapp, Inc. Externally initiated application session endpoint migration
US9973472B2 (en) 2015-04-02 2018-05-15 Varmour Networks, Inc. Methods and systems for orchestrating physical and virtual switches to enforce security boundaries
US10049508B2 (en) 2014-02-27 2018-08-14 Satcom Direct, Inc. Automated flight operations system
US9009332B1 (en) 2014-07-18 2015-04-14 Kaspersky Lab Zao Protection against network-based malicious activity utilizing transparent proxy services
US9948496B1 (en) 2014-07-30 2018-04-17 Silver Peak Systems, Inc. Determining a transit appliance for data traffic to a software service
US9875344B1 (en) 2014-09-05 2018-01-23 Silver Peak Systems, Inc. Dynamic monitoring and authorization of an optimization device
US9554275B1 (en) 2014-10-19 2017-01-24 Satcom Direct, Inc. Voice and SMS communication from a mobile device over IP network and satellite or other communication network
US9992088B1 (en) 2014-11-07 2018-06-05 Speedy Packets, Inc. Packet coding based network communication
US9992128B2 (en) * 2015-07-07 2018-06-05 Speedy Packets, Inc. Error correction optimization
US10999012B2 (en) 2014-11-07 2021-05-04 Strong Force Iot Portfolio 2016, Llc Packet coding based network communication
US9992126B1 (en) 2014-11-07 2018-06-05 Speedy Packets, Inc. Packet coding based network communication
US9825733B1 (en) 2014-11-07 2017-11-21 Speedy Packets, Inc. Packet coding based network communication
US10320526B1 (en) 2014-11-07 2019-06-11 Strong Force Iot Portfolio 2016, Llc Packet coding based network communication
WO2016100890A1 (en) * 2014-12-19 2016-06-23 Nokia Solutions And Networks Oy Smooth bandwidth-delay product variation inside wireless networks
US9503362B2 (en) * 2015-01-07 2016-11-22 Vmware, Inc. Reverse path maximum transmission unit (PMTU) discovery
US10993147B1 (en) 2015-02-25 2021-04-27 Satcom Direct, Inc. Out-of-band bandwidth RSVP manager
US10834065B1 (en) 2015-03-31 2020-11-10 F5 Networks, Inc. Methods for SSL protected NTLM re-authentication and devices thereof
US9525697B2 (en) 2015-04-02 2016-12-20 Varmour Networks, Inc. Delivering security functions to distributed networks
JP2016208315A (en) * 2015-04-23 2016-12-08 富士通株式会社 Communication device, communication processing method, and communication program
US9491282B1 (en) * 2015-05-13 2016-11-08 Cisco Technology, Inc. End-to-end call tracing
US9942171B2 (en) 2015-07-02 2018-04-10 Arista Networks, Inc. Network data processor having per-input port virtual output queues
CN105491016A (en) * 2015-07-21 2016-04-13 成都理工大学 Method for hiding network TCP port
US9819602B2 (en) * 2015-07-27 2017-11-14 Qualcomm Incorporated Efficient datagram segmentation and reassembly for packet-switched networks
US9979466B2 (en) * 2015-08-06 2018-05-22 Space Systems/Loral, Llc Reverse wireless broadband system
US9483317B1 (en) 2015-08-17 2016-11-01 Varmour Networks, Inc. Using multiple central processing unit cores for packet forwarding in virtualized networks
US10420012B2 (en) * 2015-09-14 2019-09-17 Prodatakey, Inc. Adaptive unicast timeout for a wireless network having optimized routing
WO2017053968A1 (en) 2015-09-25 2017-03-30 Fsa Technologies, Inc. Data redirection in a bifurcated communication trunk system and method
US10404698B1 (en) 2016-01-15 2019-09-03 F5 Networks, Inc. Methods for adaptive organization of web application access points in webtops and devices thereof
US10778809B2 (en) * 2016-02-26 2020-09-15 Arista Networks, Inc. Per-input port, per-control plane network data traffic class control plane policing
CN107306149B (en) * 2016-04-19 2020-06-26 航迅信息技术有限公司 Aviation communication method and system
US10432484B2 (en) 2016-06-13 2019-10-01 Silver Peak Systems, Inc. Aggregating select network traffic statistics
US9967056B1 (en) 2016-08-19 2018-05-08 Silver Peak Systems, Inc. Forward packet recovery with constrained overhead
CN106385279A (en) * 2016-09-14 2017-02-08 西安远眺卫星通信有限公司 Wireless routing device and method for satellite communication
US10033516B2 (en) * 2016-11-30 2018-07-24 International Business Machines Corporation Multi-domain connection establishment in computer networking communications
FR3060920B1 (en) * 2016-12-20 2019-07-05 Thales SYSTEM AND METHOD FOR DATA TRANSMISSION IN A SATELLITE SYSTEM
US10257082B2 (en) 2017-02-06 2019-04-09 Silver Peak Systems, Inc. Multi-level learning for classifying traffic flows
US10892978B2 (en) 2017-02-06 2021-01-12 Silver Peak Systems, Inc. Multi-level learning for classifying traffic flows from first packet data
US11044202B2 (en) 2017-02-06 2021-06-22 Silver Peak Systems, Inc. Multi-level learning for predicting and classifying traffic flows from first packet data
US10771394B2 (en) 2017-02-06 2020-09-08 Silver Peak Systems, Inc. Multi-level learning for classifying traffic flows on a first packet from DNS data
US9876612B1 (en) * 2017-02-06 2018-01-23 Naveen Maveli Data bandwidth overhead reduction in a protocol based communication over a wide area network (WAN)
US10440776B2 (en) * 2017-03-17 2019-10-08 Harris Corporation Non-standard alternate protocol based satellite communications
US10536382B2 (en) * 2017-05-04 2020-01-14 Global Eagle Entertainment Inc. Data flow control for dual ended transmission control protocol performance enhancement proxies
US10805434B2 (en) 2017-06-08 2020-10-13 Hyannis Port Research, Inc. Dynamic TCP stream processing with modification notification
US11212210B2 (en) 2017-09-21 2021-12-28 Silver Peak Systems, Inc. Selective route exporting using source type
US11133862B2 (en) * 2017-10-20 2021-09-28 Viasat, Inc. Using a low-latency network to allocate return-link bandwidth on a high-latency network
US10637721B2 (en) 2018-03-12 2020-04-28 Silver Peak Systems, Inc. Detecting path break conditions while minimizing network overhead
US10291598B1 (en) * 2018-08-07 2019-05-14 Juniper Networks, Inc. Transmitting and storing different types of encrypted information using TCP urgent mechanism
US10819420B2 (en) 2018-10-09 2020-10-27 Hughes Network Systems, Llc Multipath satellite backbone
US11031998B2 (en) * 2018-10-09 2021-06-08 Hughes Network Systems, Llc Bonding and redundancy for satellite transport paths
CN110401923B (en) * 2019-04-19 2021-08-10 广州天链通信科技有限公司 Method for simultaneously supporting VSAT terminal network bridge and routing mode and VSAT terminal
US11438805B2 (en) * 2019-09-25 2022-09-06 Verizon Patent And Licensing Inc. System and method for latency certification service
CN114039747B (en) * 2021-10-21 2023-05-16 烽火通信科技股份有限公司 DDOS data retransmission attack prevention method, device, equipment and storage medium
CN113839840B (en) * 2021-11-24 2022-02-18 北京航空航天大学 Bandwidth self-adaptive estimation method and system for bottleneck link of satellite network
US11750324B2 (en) 2021-11-30 2023-09-05 Analog Devices International Unlimited Company Methods for adaptive error avoidance to increase re-transmission reliability in time-slotted communication links

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0796027A2 (en) * 1996-03-15 1997-09-17 Nec Corporation Design of a closed loop feed back control for ABR service
WO2000041365A1 (en) * 1998-12-31 2000-07-13 Microsoft Corporation Method and system for credit-based data flow control
WO2001045331A1 (en) * 1999-12-13 2001-06-21 Nokia Corporation Congestion control method for a packet-switched network
WO2001065805A2 (en) * 2000-02-28 2001-09-07 Hughes Electronics Corporation Performance enhancing proxy and method for enhancing performance

Family Cites Families (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6115384A (en) * 1996-06-20 2000-09-05 Fourelle Systems, Inc Gateway architecture for data communication bandwidth-constrained and charge-by-use networks
US6273622B1 (en) * 1997-04-15 2001-08-14 Flash Networks, Ltd. Data communication protocol for maximizing the performance of IP communication links
US6339595B1 (en) * 1997-12-23 2002-01-15 Cisco Technology, Inc. Peer-model support for virtual private networks with potentially overlapping addresses
US6415329B1 (en) * 1998-03-06 2002-07-02 Massachusetts Institute Of Technology Method and apparatus for improving efficiency of TCP/IP protocol over high delay-bandwidth network
US6341129B1 (en) * 1998-04-03 2002-01-22 Alteon Networks, Inc. TCP resegmentation
US6327626B1 (en) * 1998-09-15 2001-12-04 Alteon Networks, Inc. Method and apparatus for MSS spoofing
US6215769B1 (en) * 1998-10-07 2001-04-10 Nokia Telecommunications, Inc. Enhanced acknowledgment pacing device and method for TCP connections
US6496505B2 (en) * 1998-12-11 2002-12-17 Lucent Technologies Inc. Packet tunneling optimization to wireless devices accessing packet-based wired networks
US6584083B1 (en) * 1999-02-02 2003-06-24 Mentat Inc. Internet over satellite method
US6654344B1 (en) * 1999-02-02 2003-11-25 Mentat Inc. Method and system for controlling data flow in an internet over satellite connection
US6460085B1 (en) * 1999-02-02 2002-10-01 Mentat Inc. Method and system for managing memory in an internet over satellite connection
US6529477B1 (en) * 1999-02-02 2003-03-04 Mentat Inc. Internet over satellite system
US6438108B1 (en) * 1999-03-11 2002-08-20 Telefonaktiebolaget L M Ericsson (Publ) System for improved transmission of acknowledgements within a packet data network
US6553032B1 (en) * 1999-09-01 2003-04-22 Tantivy Communications, Inc. Packeting timeout spoofing in a wireless data communications network
US6763005B1 (en) * 1999-10-01 2004-07-13 Nortel Networks Limited Satellite traffic routing
US7213063B2 (en) * 2000-01-18 2007-05-01 Lucent Technologies Inc. Method, apparatus and system for maintaining connections between computers using connection-oriented protocols
US7082467B2 (en) * 2000-02-10 2006-07-25 Hughes Network Systems Method and device for selective transport level spoofing based on information in transport level packet
US6947440B2 (en) * 2000-02-15 2005-09-20 Gilat Satellite Networks, Ltd. System and method for internet page acceleration including multicast transmissions
US6741555B1 (en) * 2000-06-14 2004-05-25 Nokia Internet Communictions Inc. Enhancement of explicit congestion notification (ECN) for wireless network applications
US6993584B2 (en) * 2000-07-21 2006-01-31 Hughes Network Systems Method and system for improving network performance by utilizing path selection, path activation, and profiles
US20030069926A1 (en) * 2001-10-09 2003-04-10 Weaver Jeffrey Charles System and method for managing an exchange between a gateway server and a client-side module
US7054902B2 (en) * 2001-10-23 2006-05-30 Packeteer, Inc. Multicast delivery systems and methods

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0796027A2 (en) * 1996-03-15 1997-09-17 Nec Corporation Design of a closed loop feed back control for ABR service
WO2000041365A1 (en) * 1998-12-31 2000-07-13 Microsoft Corporation Method and system for credit-based data flow control
WO2001045331A1 (en) * 1999-12-13 2001-06-21 Nokia Corporation Congestion control method for a packet-switched network
WO2001065805A2 (en) * 2000-02-28 2001-09-07 Hughes Electronics Corporation Performance enhancing proxy and method for enhancing performance

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
AFEK Y ET AL: "Phantom: a simple and effective flow control scheme" COMPUTER NETWORKS, ELSEVIER SCIENCE PUBLISHERS B.V., AMSTERDAM, NL, vol. 32, no. 3, March 2000 (2000-03), pages 277-305, XP004304670 ISSN: 1389-1286 *
BORDER J ET AL: "Performance Enhancing Proxies" INTERNET ENGINEERING TASK FORCE INTERNET DRAFT, XX, XX, 25 June 1999 (1999-06-25), pages 1-26, XP002198915 *
KUNG H T ET AL: "CREDIT-BASED FLOW CONTROL FOR ATM NETWORKS: CREDIT UPDATE PROTOCOL,ADAPTIVE CREDIT ALLOCATION, AND STATISTICAL MULTIPLEXING" COMPUTER COMMUNICATIONS REVIEW, ASSOCIATION FOR COMPUTING MACHINERY. NEW YORK, US, vol. 24, no. 4, 1 October 1994 (1994-10-01), pages 101-114, XP000477044 ISSN: 0146-4833 *
STEVENS W R: "TCP/IP Illustrated, Volume 1 The Protocols,TCP TIMEOUT AND RETRANSMISSION" , TCP/IP ILLUSTRATED. VOL. 1: THE PROTOCOLS, PROFESSIONAL COMPUTING SERIES, READING, MA: ADDISON WESLEY, US, VOL. VOL. 1, PAGE(S) 297-337 XP002223116 ISBN: 0-201-63346-9 paragraph [21.6] *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2738983A4 (en) * 2011-07-26 2015-03-11 Hitachi Ltd Communication device
US9143450B2 (en) 2011-12-30 2015-09-22 Industrial Technology Research Institute Communication system and method for assisting with the transmission of TCP packets
US9264365B2 (en) 2012-07-31 2016-02-16 International Business Machines Corporation Split transport control protocol (TCP) flow control management in a cellular broadband network

Also Published As

Publication number Publication date
AU2002352637A1 (en) 2003-05-26
US6975647B2 (en) 2005-12-13
WO2003043285A3 (en) 2004-06-10
US20030123481A1 (en) 2003-07-03
WO2003043289A2 (en) 2003-05-22
US20030131079A1 (en) 2003-07-10
AU2002357711A1 (en) 2003-05-26
WO2003043289A3 (en) 2004-01-29
CA2473863A1 (en) 2003-05-22
WO2003043288A1 (en) 2003-05-22
US20030123394A1 (en) 2003-07-03
EP1446931A1 (en) 2004-08-18

Similar Documents

Publication Publication Date Title
US20030123394A1 (en) Flow control between performance enhancing proxies over variable bandwidth split links
US7369498B1 (en) Congestion control method for a packet-switched network
US6643259B1 (en) Method for optimizing data transfer in a data network
Dukkipati Rate Control Protocol (RCP): Congestion control to make flows complete quickly
Ghani et al. TCP/IP enhancements for satellite networks
JP4433202B2 (en) Transport layer relay method, transport layer relay device, and program
US20050213586A1 (en) System and method to increase network throughput
EP1771742B1 (en) High performance tcp for systems with infrequent ack
US20070008884A1 (en) Immediate ready implementation of virtually congestion free guarantedd service capable network
Caini et al. Transport layer protocols and architectures for satellite networks
CA2628788A1 (en) Transmission control protocol with performance enhancing proxy for degraded communication channels
US8520520B2 (en) System and method for per flow guaranteed throughput, multiple TCP flow bandwidth provisioning, and elimination of packet drops for transmission control protocol (TCP) and TCP-friendly protocols
US20220294727A1 (en) Systems and methods for managing data packet communications
Henderson et al. Satellite transport protocol (STP): An SSCOP-based transport protocol for datagram satellite networks
Sooriyabandara et al. Dynamics of TCP over BoD satellite networks
Casoni et al. Reducing latency in satellite emergency networks through a cooperative transmission control
Wang et al. Use of TCP decoupling in improving TCP performance over wireless networks
Gerla et al. BA-TCP: A bandwidth aware TCP for satellite networks
Roseti et al. TCP Noordwijk: TCP-based transport optimized for web traffic in satellite networks
Roseti et al. TCP behaviour in a DVB-RCS environment
US20140369189A1 (en) Method of controlling packet transmission in network system and network system transmitting packet using pseudo-tcp agent
Zhou et al. TCP over GEO satellite hybrid networks
Venkataraman et al. A priority-layered approach to transport for high bandwidth-delay product networks
Wu et al. Dynamic congestion control to improve performance of TCP split-connections over satellite links
Liu et al. Mpmtp-ar: Multipath message transport protocol based on application-level relay

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ OM PH PL PT RO RU SC SD SE SG SI SK SL TJ TM TN TR TT TZ UA US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR IE IT LU MC NL PT SE SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP

WWW Wipo information: withdrawn in national office

Country of ref document: JP