WO2014151428A1 - System and method for choosing lowest latency path - Google Patents
System and method for choosing lowest latency path Download PDFInfo
- Publication number
- WO2014151428A1 WO2014151428A1 PCT/US2014/025711 US2014025711W WO2014151428A1 WO 2014151428 A1 WO2014151428 A1 WO 2014151428A1 US 2014025711 W US2014025711 W US 2014025711W WO 2014151428 A1 WO2014151428 A1 WO 2014151428A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- path
- network
- latency
- packet
- server
- Prior art date
Links
- 238000000034 method Methods 0.000 title claims description 18
- 230000005540 biological transmission Effects 0.000 claims description 13
- 238000001514 detection method Methods 0.000 claims 2
- 230000007246 mechanism Effects 0.000 abstract description 2
- 230000003068 static effect Effects 0.000 abstract description 2
- 230000004044 response Effects 0.000 description 5
- 235000014510 cooky Nutrition 0.000 description 4
- 238000005259 measurement Methods 0.000 description 4
- 230000008569 process Effects 0.000 description 4
- 238000012545 processing Methods 0.000 description 4
- 230000001934 delay Effects 0.000 description 3
- 230000004048 modification Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 238000013459 approach Methods 0.000 description 1
- 230000008901 benefit Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 230000006870 function Effects 0.000 description 1
- 238000002955 isolation Methods 0.000 description 1
- 238000011084 recovery Methods 0.000 description 1
- 238000012163 sequencing technique Methods 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
- 230000005641 tunneling Effects 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/26—Route discovery packet
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/12—Shortest path evaluation
- H04L45/121—Shortest path evaluation by minimising delays
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/24—Multipath
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/70—Routing based on monitoring results
Definitions
- Latency is the measure of time delay in a system. In order for a packet switched network to operate efficiently, it is important that the latency of packet flows be low. For example, a response to a client Hypertext Transfer Protocol (HTTP) request that is subject to increased latency will seem unreasonably slow to a client user. Latency in a network may be measured as either round trip latency or one-way latency. Round trip latency measures the one way latency from a source to a destination and adds to it the one-way latency for the return trip. It does not include the time spent at the destination for processing a packet. One-way latency measures only the time spent sending a packet to a destination that receives it. In order to properly measure one way latency, synchronized clocks are usually required which in turn requires the control of the source and destination by a single entity.
- Round trip latency measures the one way latency from a source to a destination and adds to it the one-way latency for the return trip. It does not include the time spent at the destination for
- round- trip latency is more frequently used in accumulating network latency statistics as it can be measured from a single point.
- One well-known way to measure round-trip latency is for a source to "ping" a destination (sending a packet from a source to a destination where the packet is not processed but merely returned to the sender).
- the calculated latency must also account for the time spent forwarding the packet over each link and transmission delay at each link except the final one. Gateway queuing delays also may increase overall latency and should therefore also be considered when making a latency determination.
- Embodiments of the present invention reduce latency by choosing the lowest latency path, or a lower latency path, from server to client.
- the lowest latency path may be dynamically determined for each client connection at the time of connection establishment. Further, latency information may be periodically determined over time and averaged or otherwise utilized to account for changing network conditions when choosing a path for content delivery to the client.
- a computing-device implemented method for determining lowest path latency includes receiving at a server a request for content from a client device over an existing Transmission Control Protocol (TCP) connection.
- the method also includes transmitting near-identical packets to the client device over multiple network paths.
- the near-identical packets have identical TCP sequences and modified packet contents that include an instruction or attribute identifying an arrival network path upon which the near- identical packet was received.
- the server receives an identification from the client device of one of the network paths as the first network path which delivered one of the near-identical packets to the client device.
- the requested contents are transmitted over a selected one of the network paths based at least in part on the identification.
- a computing-device implemented system for determining lowest network path latency includes a server that receives a request for content from a client device over an existing TCP connection.
- the system also includes a packet duplicator for generating and transmitting near-identical packets to the client device over multiple network paths.
- the near-identical packets have identical TCP sequences and modified packet contents that include an instruction or attribute identifying an arrival network path upon which the near-identical packet was received.
- the client device transmits to the server an identification of one of the network paths as being a first path which delivered one of the near-identical packets to the client device upon receipt of a first of the near-identical packets.
- the server transmits the requested contents over a selected one of the network paths based at least in part on the identification.
- Figure 1 depicts an exemplary sequence of steps followed by an embodiment to make a dynamic determination regarding network path latency
- Figure 2 depicts an exemplary sequence of steps performed by a packet duplicator utilized by an embodiment of the present invention
- Figure 3 depicts an exemplary network environment suitable for practicing an embodiment of the present invention
- Figure 4 depicts an exemplary alternative network environment suitable for practicing an embodiment of the present invention.
- Figure 5 depicts an exemplary sequence of steps followed by an embodiment to utilize stored information regarding network path latency.
- Embodiments of the present invention make dynamic latency determinations regarding desirable network paths for a client connection at the time of a client request for content.
- the latency determination may be used in isolation to determine how to route packets from a server to the client. Alternatively, the determination may be used together with previously performed latency determinations for the requesting client to provide additional information on changing network conditions.
- embodiments of the present invention take advantage of operational characteristics of the Transmission Control Protocol (TCP). More particularly, TCP stacks as currently implemented that receive duplicate packets with identical TCP sequence numbers treat the first received packet as the "right" one and discard any additional received packets with that sequence number.
- TCP Transmission Control Protocol
- near-identical packets are sent at the same time (nearly simultaneously) to the client via different network paths. These near-identical packets have identical TCP sequence numbers but slightly different packet contents. Processing of the first received packet by the client results in the server being informed of the path that delivered its packet the fastest and the server then may deliver the requested content over this path or consider this new information together with stored information from previous latency determinations when making a network path routing determination.
- FIG. 1 depicts an exemplary sequence of steps followed by an embodiment to make a dynamic determination regarding network path latency.
- the sequence begins when the client connects to the server.
- a normal TCP handshake is conducted (SY - SY ACK - ACK) (step 102) and the client and server begin to communicate normally over the 'natural' network path (step 104).
- the "natural" network path in this case is the path chosen by the normal network routing protocols from among what is usually multiple available network paths from the server to the client.
- the client issues a request, such as an HTTP "GET" request, for content controlled by the server (step 106). Based on the request, the server may decide that the content needs to be sent over the lowest latency available path.
- the server may note that the client's last measurement had aged out or that the type of content requires low latency.
- the server sends back to the client nearly identical packets with identical TCP-sequence numbers and lengths but that have slightly different packet contents. These near-identical TCP-sequenced packets are sent to the client over different network paths. These packets are sent at approximately the same time within the same few milliseconds as described further below
- the determination of path latency in response to the client request for content may be made by means of an HTTP redirect that is sent to the client over the multiple network paths.
- a TCP frame in this HTTP redirect that is sent over the multiple network paths may be sent via a packet duplicator as discussed further below.
- This "special" TCP frame contains the same length, flags, and TCP sequence/ACK numbers.
- the frame looks to the network like a duplicated packet.
- the packets have different content and different TCP checksums.
- the TCP content of the duplicated frames may look like the following when the frames are being sent over 4 paths:
- the receipt of the first near-identical packet to arrive at the client device is processed (step 110).
- the processing of the packet triggers the client device to request that the content be delivered by the server using a specific path of the first packet, i.e.: the arrival path (step 1 12) .
- the client device For example, in the embodiment discussed above in which an HTTP redirect is employed , the browser on the client device will issue a request for a new page (the use of the 302 HTTP/ 1.1 redirect indicates to a receiving browser that the original requested page has temporarily moved to the specified page).
- the server upon receiving an URL with the 'path' attribute in this example, sends all data to the client over a selected path taking into account this new information regarding the lowest latency path (step 114).
- the mechanism by which the server gets the data to the client over that specific return path is outside the scope of this application but one example is that the server uses a tunneling protocol such as MPLS or GRE to direct the packets to an egress path to the client.
- An egress path is a path running from an egress point between the server's local network and the Internet or other network (such as a router), over the Internet or other network and to the client device.
- This approach by embodiments of the present invention utilizes standard TCP functionality for processing "duplicate" packets for which no client-side TCP changes are required.
- Embodiments may also work transparently with client-side equipment like firewalls and transparent proxies as well as with many web browsers available today.
- embodiments of the present invention are not limited to the use of HTTP redirects for determining a network path with a low latency.
- the use of the HTTP redirects in the near-identical packets introduces a slight delay as it requires a second browser request.
- an HTTP cookie may be employed instead of the HTTP redirect.
- the trigger is set in an HTTP cookie, and the duplicated frame is part of the HTTP cookie. Use of such an HTTP cookie removes the delay attendant to the use of an HTTP redirect.
- the description herein is based on HTTP for ease of explanation, other protocols that offer a similar API are also within the scope of the present invention.
- the above-described sending of near-identical packets over multiple network paths to a client by an embodiment of the present invention may make use of a packet duplicator.
- the packet duplicator may be an executable process running on a computing device separate from the device hosting the server or may be the same computing device hosting the server.
- a packet duplicator utilized by an embodiment may receive packets targeted for "duplication" by the server.
- the packet targeted for duplication is the specific packet to be sent, with the correct length, TCP sequence and acknowledgement numbers.
- the packet duplicator may duplicate the packets and modify the contents to instruct the client to tell the server which path is in use.
- the packet duplicator also may modify the TCP checksum. Other values may be left unaltered.
- the packet duplicator may also be responsible for making sure the packets are sent out by a designated egress point.
- All of the duplicated near-identical packets being sent to a client may be sent from the packet duplicator immediately in sequence at almost the same time in order to remove the impact of latency.
- a 1G Ethernet segment where 128-byte "duplicate" packets (including Ethernet overhead) are sent back-to-back may be a 1.024 microsecond difference between the start of one near-identical packet and the start of the next near-identical packet.
- Ten frames sent in succession would therefore only have a lOus difference between the start of the first frame and the start of the last frame.
- the packet duplicator may also be placed approximately equidistant (based on the network topology) from the egress points as compared to the server. With this configuration, the latency delays from the server to the client/user over the eventually chosen network path will be approximately the same as those latency delays that were experienced in sending the near-identical packets from the packet duplicator to the client/user over that path when the latency determination was originally made.
- FIG. 2 depicts an exemplary sequence of steps performed by a packet duplicator utilized by an embodiment of the present invention.
- the sequence begins with the packet duplicator receiving packets for "duplication" from the server (step 202).
- the packet duplicator may duplicate the packets (step 204) and then modify the contents of the duplicated packets to include a path instruction or attribute identifying the path over which the packet is being sent and the TCP checksum (step 206).
- the new packets may instead of first duplicating and then modifying the packets, the new packets may instead by modified as they are each constructed.
- the packets are forwarded to the client by the packet duplicator or another process through available egress points of the local network to which the server belongs (step 208).
- FIG. 3 depicts an exemplary network environment 300 suitable for practicing an embodiment of the present invention. As depicted there are four egress points 371, 372, 373 and 374 providing paths from a local network to the Internet 380 and the client device 350. It will be appreciated that the number of egress points 371-374 is illustrative. Also depicted is a computing device 305 hosting web server 310. Computing device 305 and client device 350 include one or more processors and one or more network interfaces. Web server 310 communicates with a duplicator process 320 (located on a separate computing device). In an embodiment of the present invention, an application 352 (such as a web browser) on the client device 350 may initiate a connection with the web server 310.
- an application 352 such as a web browser
- a TCP connection 360 may be established between the computing device 305 and the client device 350 using a normal network path established by conventional network routing protocols.
- a web server 310 in an embodiment of the present invention may decide to find the lowest latency path to the client device 350.
- the web server sends a specially crafted packet as described herein to the packet duplicator 320.
- the packet duplicator 320 then performs the "duplication" process discussed above in which only the path instruction in the contents and the TCP checksum is altered, and forwards the produced near-identical packets out through egress points 371-374 over the Internet 380 to the client device 350.
- the client device 350 receives one of the near- identical packets before the other near-identical packets.
- the client device 350 responds to the receipt of the packet contents by informing the server of the identity of the path on which the first arriving packet was transmitted.
- the first arriving packet may arrive via a network path that includes egress point #1.
- the web server 310 may send the originally requested content via a path 391 to egress point # 1 (371) and on to the client device 350 .
- the rerouting of the client connection to a specific egress point is also something that can happen transparently to the TCP session itself, and does not necessarily require the existing TCP session to be torn down. [026] In certain situations all packets sent from the packet duplicator to the client may be lost.
- the web server's TCP stack will not receive an acknowledgement identifying any packet as the first delivered.
- the server may then retry sending the packets, either by sending the packet to the duplicator again, or by just sending out the packet directly to the client.
- Figure 3 depicts an environment in which the packet duplicator 320 and web server 310 are located on separate devices
- Figure 4 depicts an exemplary alternative network environment 400 suitable for practicing an embodiment of the present invention.
- computing device 410 hosts both web server 412 and packet duplication module 414.
- a TCP connection 460 is established between the client device 450 and the computing device 410 and an application on the client device 450 requests the delivery of content.
- the web server 412 prepares a specialized packet and forwards it to the packet duplication module 414.
- the packet duplication module 414 generates and sends the near-identical packets previously discussed to the client device 450 via egress points 471, 472, 473 and 474 and the Internet 380.
- the first arriving near-identical packet is processed on the client device and the web server 412 is informed of which path delivered the first near- identical packet. With this information, web server 412 determines over which network path to send the requested content to the client device 450. With this configuration in which the same computing device hosts both the web server 412 and the packet duplication module 414, the need to attempt to make sure that the packet duplicator and web server are equidistant from the egress points in the network topology is eliminated.
- a customized TCP stack may be employed instead by an application server to perform the rewrite and duplication functions of the packet duplicator that are discussed herein.
- the gathered latency information may be utilized in combination with previously gathered information and other criteria. For example, if some packets are lost in the network from the packet duplicator to the client, a non-lowest latency path may be selected. Failure recovery to address such packet loss may consist of the web server periodically checking to see what egress the client is preferring or switching over to the lowest latency path not currently being used. The latency responses may also be weighted to pick the lowest latency path out of the last X samples.
- Network conditions change and the "lowest latency" path is not necessarily the one with the highest bandwidth.
- a network may experience temporary congestion or temporary network events may make one path have a high latency one time and a lower latency a few minutes later.
- an embodiment of the present invention enables the dynamic location of the lowest latency path at the time of measurement, an embodiment also allows the latency measurement to be repeated for a client in order to verify that an originally selected lowest latency path continues to be the path currently having the lowest latency.
- the paths selected for a client may be recorded and tracked over time. Based on adaptable criteria, the "best" path for a client/user may be selected even if the most recent measurement for that client/user has reported a lower latency path out a different egress.
- Figure 5 depicts an exemplary sequence of steps followed by an embodiment to utilize stored information regarding path latency.
- the sequence begins with the web server receiving a request for content (step 502).
- the near-identical packets described above are sent to a client over multiple paths (step 504) and a response is received from the client and the lowest latency path determined (step 506).
- the information about the lowest latency path and alternatively the relative latency of all of the paths (which may be determined by repeating the path comparison multiple times with different sets of paths tested each time) is stored (step 508).
- a determination is made as to whether the latency information is needed based on network conditions (step 509). For example, packet loss over certain paths may cause the web server to re-evaluate the currently selected network path.
- the sequence iterates and continues to gather latency information based on pre-determined and other criteria. If however, a determination is made that the stored latency information is needed (step 509), it can be used instead of, or in addition to, currently determined latency information to choose a network path to the client (step 510).
- Portions or all of the embodiments of the present invention may be provided as one or more computer-readable programs or code embodied on or in one or more non- transitory mediums.
- the mediums may be, but are not limited to, a hard disk, a compact disc, a digital versatile disc, ROM, PROM, EPROM, EEPROM, Flash memory, a RAM, or a magnetic tape.
- the computer-readable programs or code may be implemented in any computing language.
- the computer-executable instructions may be stored on one or more non-transitory computer readable media.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
A mechanism for reducing network latency by choosing the lowest latency network path, or a lower latency network path, from server to client. Instead of using a static, pre-built system for determining latency, the lowest latency path may be dynamically determined for each client connection at the time of connection establishment. Further, latency information may be periodically determined over time and averaged or otherwise utilized to account for changing network conditions.
Description
SYSTEM AND METHOD FOR CHOOSING LOWEST LATENCY PATH
RELATED APPLICATIONS
[001] This application claims priority to United States Patent Application No.
14/01 1,233, entitled "System and Method for Choosing Lowest Latency Path", filed August 27, 2013, which claims priority to United States Provisional Patent Application No.
61/790,241, entitled "System and Method for Choosing Lowest Latency Path to a Peer", filed March 15, 2013, both of which are incorporated herein by reference in their entirety.
BACKGROUND
[002] Latency is the measure of time delay in a system. In order for a packet switched network to operate efficiently, it is important that the latency of packet flows be low. For example, a response to a client Hypertext Transfer Protocol (HTTP) request that is subject to increased latency will seem unreasonably slow to a client user. Latency in a network may be measured as either round trip latency or one-way latency. Round trip latency measures the one way latency from a source to a destination and adds to it the one-way latency for the return trip. It does not include the time spent at the destination for processing a packet. One-way latency measures only the time spent sending a packet to a destination that receives it. In order to properly measure one way latency, synchronized clocks are usually required which in turn requires the control of the source and destination by a single entity.
[003] As a result of the control requirement for determining one-way latency, round- trip latency is more frequently used in accumulating network latency statistics as it can be measured from a single point. One well-known way to measure round-trip latency is for a source to "ping" a destination (sending a packet from a source to a destination where the packet is not processed but merely returned to the sender). In more complicated networks in which a packet is forwarded over many links, the calculated latency must also account for the time spent forwarding the packet over each link and transmission delay at each link except the final one. Gateway queuing delays also may increase overall latency and should therefore also be considered when making a latency determination.
1
SUMMARY
[004] Embodiments of the present invention reduce latency by choosing the lowest latency path, or a lower latency path, from server to client. Instead of using a static, pre-built system for determining latency, the lowest latency path may be dynamically determined for each client connection at the time of connection establishment. Further, latency information may be periodically determined over time and averaged or otherwise utilized to account for changing network conditions when choosing a path for content delivery to the client.
[005] In one embodiment, a computing-device implemented method for determining lowest path latency includes receiving at a server a request for content from a client device over an existing Transmission Control Protocol (TCP) connection. The method also includes transmitting near-identical packets to the client device over multiple network paths. The near-identical packets have identical TCP sequences and modified packet contents that include an instruction or attribute identifying an arrival network path upon which the near- identical packet was received. The server receives an identification from the client device of one of the network paths as the first network path which delivered one of the near-identical packets to the client device. The requested contents are transmitted over a selected one of the network paths based at least in part on the identification.
[006] In another embodiment a computing-device implemented system for determining lowest network path latency includes a server that receives a request for content from a client device over an existing TCP connection. The system also includes a packet duplicator for generating and transmitting near-identical packets to the client device over multiple network paths. The near-identical packets have identical TCP sequences and modified packet contents that include an instruction or attribute identifying an arrival network path upon which the near-identical packet was received. The client device transmits to the server an identification of one of the network paths as being a first path which delivered one of the near-identical packets to the client device upon receipt of a first of the near-identical packets. The server transmits the requested contents over a selected one of the network paths based at least in part on the identification.
BRIEF DESCRIPTION OF THE DRAWINGS
[007] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate one or more embodiments of the invention and, together with
the description, help to explain the invention. In the drawings:
[008] Figure 1 depicts an exemplary sequence of steps followed by an embodiment to make a dynamic determination regarding network path latency;
[009] Figure 2 depicts an exemplary sequence of steps performed by a packet duplicator utilized by an embodiment of the present invention;
[010] Figure 3 depicts an exemplary network environment suitable for practicing an embodiment of the present invention;
[011] Figure 4 depicts an exemplary alternative network environment suitable for practicing an embodiment of the present invention; and
[012] Figure 5 depicts an exemplary sequence of steps followed by an embodiment to utilize stored information regarding network path latency.
DETAILED DESCRIPTION
[013] Embodiments of the present invention make dynamic latency determinations regarding desirable network paths for a client connection at the time of a client request for content. The latency determination may be used in isolation to determine how to route packets from a server to the client. Alternatively, the determination may be used together with previously performed latency determinations for the requesting client to provide additional information on changing network conditions. To make this dynamic latency determination, embodiments of the present invention take advantage of operational characteristics of the Transmission Control Protocol (TCP). More particularly, TCP stacks as currently implemented that receive duplicate packets with identical TCP sequence numbers treat the first received packet as the "right" one and discard any additional received packets with that sequence number. In an embodiment of the present invention, near-identical packets are sent at the same time (nearly simultaneously) to the client via different network paths. These near-identical packets have identical TCP sequence numbers but slightly different packet contents. Processing of the first received packet by the client results in the server being informed of the path that delivered its packet the fastest and the server then may deliver the requested content over this path or consider this new information together with stored information from previous latency determinations when making a network path routing determination.
[014] Figure 1 depicts an exemplary sequence of steps followed by an embodiment to make a dynamic determination regarding network path latency. The sequence begins
when the client connects to the server. A normal TCP handshake is conducted (SY - SY ACK - ACK) (step 102) and the client and server begin to communicate normally over the 'natural' network path (step 104). The "natural" network path in this case is the path chosen by the normal network routing protocols from among what is usually multiple available network paths from the server to the client. Subsequently the client issues a request, such as an HTTP "GET" request, for content controlled by the server (step 106). Based on the request, the server may decide that the content needs to be sent over the lowest latency available path. For example, the server may note that the client's last measurement had aged out or that the type of content requires low latency. The server sends back to the client nearly identical packets with identical TCP-sequence numbers and lengths but that have slightly different packet contents. These near-identical TCP-sequenced packets are sent to the client over different network paths. These packets are sent at approximately the same time within the same few milliseconds as described further below
(step 108).
[015] The determination of path latency in response to the client request for content may be made by means of an HTTP redirect that is sent to the client over the multiple network paths. A TCP frame in this HTTP redirect that is sent over the multiple network paths may be sent via a packet duplicator as discussed further below. This "special" TCP frame contains the same length, flags, and TCP sequence/ACK numbers. As a result, the frame looks to the network like a duplicated packet. However, the packets have different content and different TCP checksums. For example, the TCP content of the duplicated frames may look like the following when the frames are being sent over 4 paths:
[016] Packet #1 :
HTTP/1.1 302 Moved
Location: http://www.example.com/?path=path_l
[017] Packet #2:
HTTP/1.1 302 Moved
Location: http://www.example.com/?path=path_2
[018] Packet #3 :
HTTP/1.1 302 Moved
Location: http://www.example.com/?path=path_3
[019] Packet #4:
HTTP/1.1 302 Moved
Location: http://www.example.com/?path=path_4
[020] The receipt of the first near-identical packet to arrive at the client device is processed (step 110). The processing of the packet triggers the client device to request that the content be delivered by the server using a specific path of the first packet, i.e.: the arrival path (step 1 12) . For example, in the embodiment discussed above in which an HTTP redirect is employed , the browser on the client device will issue a request for a new page (the use of the 302 HTTP/ 1.1 redirect indicates to a receiving browser that the original requested page has temporarily moved to the specified page). The server, upon receiving an URL with the 'path' attribute in this example, sends all data to the client over a selected path taking into account this new information regarding the lowest latency path (step 114). The mechanism by which the server gets the data to the client over that specific return path is outside the scope of this application but one example is that the server uses a tunneling protocol such as MPLS or GRE to direct the packets to an egress path to the client. An egress path is a path running from an egress point between the server's local network and the Internet or other network (such as a router), over the Internet or other network and to the client device. This approach by embodiments of the present invention utilizes standard TCP functionality for processing "duplicate" packets for which no client-side TCP changes are required. Embodiments may also work transparently with client-side equipment like firewalls and transparent proxies as well as with many web browsers available today.
[021 ] It should be appreciated that embodiments of the present invention are not limited to the use of HTTP redirects for determining a network path with a low latency. The use of the HTTP redirects in the near-identical packets introduces a slight delay as it requires a second browser request. To avoid this, in another embodiment, an HTTP cookie may be employed instead of the HTTP redirect. For example, in an embodiment, the trigger is set in an HTTP cookie, and the duplicated frame is part of the HTTP cookie. Use of such an HTTP cookie removes the delay attendant to the use of an HTTP redirect. Further, although the description herein is based on HTTP for ease of explanation, other protocols that offer a similar API are also within the scope of the present invention.
[022] The above-described sending of near-identical packets over multiple network paths to a client by an embodiment of the present invention may make use of a packet duplicator. The packet duplicator may be an executable process running on a computing device separate from the device hosting the server or may be the same computing device hosting the server. A packet duplicator utilized by an embodiment may receive packets targeted for "duplication" by the server. The packet targeted for duplication is the specific packet to be sent, with the correct length, TCP sequence and acknowledgement numbers. The packet duplicator may duplicate the packets and modify the contents to instruct the client to tell the server which path is in use. The packet duplicator also may modify the TCP checksum. Other values may be left unaltered. The packet duplicator may also be responsible for making sure the packets are sent out by a designated egress point.
[023] All of the duplicated near-identical packets being sent to a client may be sent from the packet duplicator immediately in sequence at almost the same time in order to remove the impact of latency. For example, on a 1G Ethernet segment where 128-byte "duplicate" packets (including Ethernet overhead) are sent back-to-back, may be a 1.024 microsecond difference between the start of one near-identical packet and the start of the next near-identical packet. Ten frames sent in succession would therefore only have a lOus difference between the start of the first frame and the start of the last frame. Since the latency differential between the network paths is typically observed to be on the order of 10-lOOms, the delay in the sequencing of the packets will not ordinarily be a concern as it is lOOOx - lOOOOx lower than the network path latency. In one embodiment, the packet duplicator may also be placed approximately equidistant (based on the network topology) from the egress points as compared to the server. With this configuration, the latency delays from the server to the client/user over the eventually chosen network path will be approximately the same as those latency delays that were experienced in sending the near-identical packets from the packet duplicator to the client/user over that path when the latency determination was originally made.
[024] Figure 2 depicts an exemplary sequence of steps performed by a packet duplicator utilized by an embodiment of the present invention. The sequence begins with the packet duplicator receiving packets for "duplication" from the server (step 202). The packet duplicator may duplicate the packets (step 204) and then modify the contents of the duplicated packets to include a path instruction or attribute identifying the path over which
the packet is being sent and the TCP checksum (step 206). Alternatively, it will be appreciated that instead of first duplicating and then modifying the packets, the new packets may instead by modified as they are each constructed. Following the modification of the packet contents, the packets are forwarded to the client by the packet duplicator or another process through available egress points of the local network to which the server belongs (step 208).
[025] Figure 3 depicts an exemplary network environment 300 suitable for practicing an embodiment of the present invention. As depicted there are four egress points 371, 372, 373 and 374 providing paths from a local network to the Internet 380 and the client device 350. It will be appreciated that the number of egress points 371-374 is illustrative. Also depicted is a computing device 305 hosting web server 310. Computing device 305 and client device 350 include one or more processors and one or more network interfaces. Web server 310 communicates with a duplicator process 320 (located on a separate computing device). In an embodiment of the present invention, an application 352 (such as a web browser) on the client device 350 may initiate a connection with the web server 310. A TCP connection 360 may be established between the computing device 305 and the client device 350 using a normal network path established by conventional network routing protocols. As discussed above, upon receiving a request for a particular type of content, a web server 310 in an embodiment of the present invention may decide to find the lowest latency path to the client device 350. The web server sends a specially crafted packet as described herein to the packet duplicator 320. The packet duplicator 320 then performs the "duplication" process discussed above in which only the path instruction in the contents and the TCP checksum is altered, and forwards the produced near-identical packets out through egress points 371-374 over the Internet 380 to the client device 350. The client device 350 receives one of the near- identical packets before the other near-identical packets. The client device 350 responds to the receipt of the packet contents by informing the server of the identity of the path on which the first arriving packet was transmitted. For example, the first arriving packet may arrive via a network path that includes egress point #1. Upon receiving the identity of the path from the client device, the web server 310 may send the originally requested content via a path 391 to egress point # 1 (371) and on to the client device 350 . It should be noted that the rerouting of the client connection to a specific egress point is also something that can happen transparently to the TCP session itself, and does not necessarily require the existing TCP session to be torn down.
[026] In certain situations all packets sent from the packet duplicator to the client may be lost. Accordingly, when this is the case, the web server's TCP stack will not receive an acknowledgement identifying any packet as the first delivered. Depending on the implementation, the server may then retry sending the packets, either by sending the packet to the duplicator again, or by just sending out the packet directly to the client.
[027] Although Figure 3 depicts an environment in which the packet duplicator 320 and web server 310 are located on separate devices, other configurations are possible within the scope of the present invention. For example, Figure 4 depicts an exemplary alternative network environment 400 suitable for practicing an embodiment of the present invention. In Figure 4, computing device 410 hosts both web server 412 and packet duplication module 414. A TCP connection 460 is established between the client device 450 and the computing device 410 and an application on the client device 450 requests the delivery of content. In response to the request, the web server 412 prepares a specialized packet and forwards it to the packet duplication module 414. The packet duplication module 414 generates and sends the near-identical packets previously discussed to the client device 450 via egress points 471, 472, 473 and 474 and the Internet 380. The first arriving near-identical packet is processed on the client device and the web server 412 is informed of which path delivered the first near- identical packet. With this information, web server 412 determines over which network path to send the requested content to the client device 450. With this configuration in which the same computing device hosts both the web server 412 and the packet duplication module 414, the need to attempt to make sure that the packet duplicator and web server are equidistant from the egress points in the network topology is eliminated.
[028] In another embodiment, a customized TCP stack may be employed instead by an application server to perform the rewrite and duplication functions of the packet duplicator that are discussed herein.
[029] Rather than automatically selecting the path with the lowest latency to the client, in an embodiment the gathered latency information may be utilized in combination with previously gathered information and other criteria. For example, if some packets are lost in the network from the packet duplicator to the client, a non-lowest latency path may be selected. Failure recovery to address such packet loss may consist of the web server
periodically checking to see what egress the client is preferring or switching over to the lowest latency path not currently being used. The latency responses may also be weighted to pick the lowest latency path out of the last X samples.
[030] Network conditions change and the "lowest latency" path is not necessarily the one with the highest bandwidth. A network may experience temporary congestion or temporary network events may make one path have a high latency one time and a lower latency a few minutes later. While an embodiment of the present invention enables the dynamic location of the lowest latency path at the time of measurement, an embodiment also allows the latency measurement to be repeated for a client in order to verify that an originally selected lowest latency path continues to be the path currently having the lowest latency. In one embodiment, the paths selected for a client may be recorded and tracked over time. Based on adaptable criteria, the "best" path for a client/user may be selected even if the most recent measurement for that client/user has reported a lower latency path out a different egress.
[031] Figure 5 depicts an exemplary sequence of steps followed by an embodiment to utilize stored information regarding path latency. The sequence begins with the web server receiving a request for content (step 502). The near-identical packets described above are sent to a client over multiple paths (step 504) and a response is received from the client and the lowest latency path determined (step 506). The information about the lowest latency path and alternatively the relative latency of all of the paths (which may be determined by repeating the path comparison multiple times with different sets of paths tested each time) is stored (step 508). A determination is made as to whether the latency information is needed based on network conditions (step 509). For example, packet loss over certain paths may cause the web server to re-evaluate the currently selected network path. If the latency information is not currently needed, the sequence iterates and continues to gather latency information based on pre-determined and other criteria. If however, a determination is made that the stored latency information is needed (step 509), it can be used instead of, or in addition to, currently determined latency information to choose a network path to the client (step 510).
[032] Although embodiments of the present invention have been described herein as employing a server-client configuration, it should be appreciated that the present invention is
not so limited. For example, embodiments may also be practiced in other configurations such as a peer-to-peer configuration rather than the above-described server-client arrangement.
[033] Portions or all of the embodiments of the present invention may be provided as one or more computer-readable programs or code embodied on or in one or more non- transitory mediums. The mediums may be, but are not limited to, a hard disk, a compact disc, a digital versatile disc, ROM, PROM, EPROM, EEPROM, Flash memory, a RAM, or a magnetic tape. In general, the computer-readable programs or code may be implemented in any computing language. The computer-executable instructions may be stored on one or more non-transitory computer readable media.
[034] Since certain changes may be made without departing from the scope of the present invention, it is intended that all matter contained in the above description or shown in the accompanying drawings be interpreted as illustrative and not in a literal sense.
Practitioners of the art will realize that the sequence of steps and architectures depicted in the figures may be altered without departing from the scope of the present invention and that the illustrations contained herein are singular examples of a multitude of possible depictions of the present invention.
[035] The foregoing description of example embodiments of the invention provides illustration and description, but is not intended to be exhaustive or to limit the invention to the precise form disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practice of the invention. For example, while a series of acts has been described, the order of the acts may be modified in other implementations consistent with the principles of the invention. Further, non-dependent acts may be performed in parallel.
Claims
1. A computing-device implemented method for determining lowest network path latency, comprising:
receiving at a server a request for content from a client device over an existing TCP connection;
transmitting to the client device over a plurality of network paths near-identical packets, the near-identical packets having identical TCP sequences and modified packet contents that include an instruction or attribute identifying an arrival network path upon which the near-identical packet was received;
receiving at the server from the client device an identification of one of the plurality of network paths as being a first network path which delivered one of the near- identical packets to the client device; and
transmitting the requested contents over a selected one of the plurality of the network paths based at least in part on the identification.
2. The method of claim 1, further comprising:
storing latency information based on the identification.
3. The method of claim 1 wherein the requested contents are transmitted over the selected one of the plurality of network paths based on stored latency information and the identification.
4. The method of claim 1 wherein each of the near-identical packets have a different path instruction or attribute.
5. The method of claim 1, further comprising:
transmitting the non-identical packets to the client device using a packet duplicator.
6. The method of claim 1 , further comprising:
transmitting the requested contents over a non-lowest latency network path in the plurality of network paths based on a detection of packet loss on an identified lowest latency
path in the plurality of network paths.
7. The method of claim I, further comprising:
periodically identifying one of the plurality of network paths as a lowest latency network path as a result of the transmission of the near-identical packets;
storing information related to the identifying for each transmission; and
transmitting the requested contents based on a determination of the identified lowest latency network path during a pre-determined time period using the stored information.
8. The method of claim 1 wherein the transmission of the requested content over the selected one of the plurality of network paths is switched to a different one of the plurality of network paths before the completion of the transmission of the requested content based on a subsequent receipt by the server of a second identification identifying the different one of the plurality of network paths as the first path to receive a near-identical packet following a second transmission of near-identical packets to the client device.
9. A non-transitory medium holding computing-device executable instructions for determining lowest path latency; the instructions when executed causing at least one computing device to:
receive at a server a request for content from a client device over an existing TCP connection;
transmit to the client device over a plurality of network paths near-identical packets, the near-identical packets having identical TCP sequences and modified packet contents that include an instruction or attribute identifying an arrival network path upon which the near- identical packet was received;
receive at the server from the client device an identification of one of the plurality of network paths as being a first network path which delivered one of the near-identical packets to the client device; and
transmit the requested contents over a selected one of the plurality of the network paths based at least in part on the identification.
10. The medium of claim 9 wherein the instructions when executed further cause the at least one computing device to:
store latency information based on the identification.
11. The medium of claim 9 wherein the requested contents are transmitted over the selected one of the plurality of network paths based on stored latency information and the identification.
12. The medium of claim 1 wherein each of the near-identical packets have a different path instruction or attribute.
13. The medium of claim 9 wherein the instructions when executed further cause the at least one computing device to:
transmit the non-identical packets to the client device using a packet duplicator.
14. The medium of claim 9 wherein the instructions when executed further cause the at least one computing device to:
transmit the requested contents over a non-lowest latency network path in the plurality of network paths based on a detection of packet loss on an identified lowest latency path in the plurality of network paths.
15 The medium of claim 9 wherein the instructions when executed further cause the at least one computing device to:
periodically identify one of the plurality of network paths as a lowest latency network path as a result of the transmission of the near-identical packets;
store information related to the identifying for each transmission; and
transmit the requested contents based on a determination of the identified lowest latency network path during a pre-determined time period using the stored information.
16. The medium of claim 9 wherein the transmission of the requested content over the selected one of the plurality of network paths is switched to a different one of the plurality of network paths before the completion of the transmission of the requested content based on a subsequent receipt by the server of a second identification identifying the different one of the plurality of network paths as the first path to receive a near-identical packet following a second transmission of near-identical packets to the client device.
17. A computing-device implemented system for determining lowest path latency, comprising:
a server, the server receiving a request for content from a client device over an existing TCP connection; and
a packet duplicator, the packet duplicator generating and transmitting to the client device over a plurality of network paths near-identical packets, the near-identical packets having identical TCP sequences and modified packet contents that include an instruction or attribute identifying an arrival network path upon which the near-identical packet was received, the client device transmitting to the server an identification of one of the plurality of network paths as being a first network path which delivered one of the near- identical packets to the client device upon receipt of a first of the near-identical packets,
wherein the server transmits the requested contents over a selected one of the plurality of the network paths based at least in part on the identification.
18. The system of claim 17 wherein the packet duplicator is located remotely from the server.
19. The system of claim 17 wherein the packet duplicator is located on a computing device hosting the server.
20. The system of claim 17 wherein the packet duplicator is located approximately equidistant as the server, based on network topology, from egress points to the plurality of network paths .
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201480024471.4A CN105164981A (en) | 2013-03-15 | 2014-03-13 | System and method for choosing lowest latency path |
EP14720784.9A EP2974178A1 (en) | 2013-03-15 | 2014-03-13 | System and method for choosing lowest latency path |
HK16108727.5A HK1221086A1 (en) | 2013-03-15 | 2016-07-20 | System and method for choosing lowest latency path |
Applications Claiming Priority (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US201361790241P | 2013-03-15 | 2013-03-15 | |
US61/790,241 | 2013-03-15 | ||
US14/011,233 | 2013-08-27 | ||
US14/011,233 US20150046558A1 (en) | 2013-03-15 | 2013-08-27 | System and method for choosing lowest latency path |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2014151428A1 true WO2014151428A1 (en) | 2014-09-25 |
Family
ID=50628947
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/US2014/025711 WO2014151428A1 (en) | 2013-03-15 | 2014-03-13 | System and method for choosing lowest latency path |
Country Status (6)
Country | Link |
---|---|
US (1) | US20150046558A1 (en) |
EP (1) | EP2974178A1 (en) |
CN (1) | CN105164981A (en) |
DE (1) | DE202014010900U1 (en) |
HK (1) | HK1221086A1 (en) |
WO (1) | WO2014151428A1 (en) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP3445007A1 (en) * | 2017-08-16 | 2019-02-20 | Hewlett Packard Enterprise Development L.P. | Routing packets in dimensional order in multidimensional networks |
US10498631B2 (en) | 2017-08-15 | 2019-12-03 | Hewlett Packard Enterprise Development Lp | Routing packets using distance classes |
Families Citing this family (17)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
IN2015CH04763A (en) * | 2015-09-08 | 2015-09-25 | Wipro Ltd | |
CN105847178A (en) * | 2016-03-21 | 2016-08-10 | 珠海迈科智能科技股份有限公司 | Network data request method and system for application program |
US20170293500A1 (en) * | 2016-04-06 | 2017-10-12 | Affirmed Networks Communications Technologies, Inc. | Method for optimal vm selection for multi data center virtual network function deployment |
CN109074360B (en) | 2016-04-12 | 2022-05-03 | 谷歌有限责任公司 | Reducing latency in downloading electronic resources using multiple threads |
CN106792798B (en) * | 2016-11-28 | 2020-09-11 | 北京奇虎科技有限公司 | Mobile terminal remote assistance connection detection method and device |
DE102017103938A1 (en) | 2017-02-24 | 2018-08-30 | Carl Zeiss Industrielle Messtechnik Gmbh | Device for measuring the roughness of a workpiece surface |
US20180331946A1 (en) * | 2017-05-09 | 2018-11-15 | vIPtela Inc. | Routing network traffic based on performance |
US11075830B2 (en) * | 2018-10-12 | 2021-07-27 | Massachusetts Institute Of Technology | Diversity routing to improve delay-jitter tradeoff in uncertain network environments |
KR20200083933A (en) | 2018-12-28 | 2020-07-09 | 알리바바 그룹 홀딩 리미티드 | Accelerate transaction delivery in blockchain networks using acceleration nodes |
SG11201907245VA (en) * | 2018-12-28 | 2019-09-27 | Alibaba Group Holding Ltd | Accelerating transaction deliveries in blockchain networks using transaction resending |
SG11201907248QA (en) | 2018-12-28 | 2019-09-27 | Alibaba Group Holding Ltd | Improving blockchain transaction speeds using global acceleration nodes |
US11082451B2 (en) * | 2018-12-31 | 2021-08-03 | Citrix Systems, Inc. | Maintaining continuous network service |
JPWO2020261393A1 (en) * | 2019-06-25 | 2020-12-30 | ||
JP7485768B2 (en) * | 2019-12-20 | 2024-05-16 | ナイアンティック, インコーポレイテッド | Data Hierarchy Protocol for Data Transmission Path Selection |
CN113543206B (en) * | 2020-04-21 | 2023-08-22 | 华为技术有限公司 | Method, system and device for data transmission |
US11689611B2 (en) * | 2021-06-22 | 2023-06-27 | Level 3 Communications, Llc | Network optimization system using server latency measurements |
CN113589675B (en) * | 2021-08-10 | 2022-07-29 | 贵州省计量测试院 | Network time synchronization method and system with traceability |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP1610496A1 (en) * | 2004-06-18 | 2005-12-28 | Avaya Technology Corp. | Rapid fault detection and recovery for internet protocol telephony |
US20060250965A1 (en) * | 2005-05-09 | 2006-11-09 | Bellsouth Intellectual Property Corporation | Methods, systems, and computer-readable media for optimizing the communication of data packets in a data network |
US20080304472A1 (en) * | 2007-06-05 | 2008-12-11 | Gourlay Douglas A | Communication embodiments and low latency path selection in a multi-topology network |
Family Cites Families (14)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6831898B1 (en) * | 2000-08-16 | 2004-12-14 | Cisco Systems, Inc. | Multiple packet paths to improve reliability in an IP network |
US9108107B2 (en) * | 2002-12-10 | 2015-08-18 | Sony Computer Entertainment America Llc | Hosting and broadcasting virtual events using streaming interactive video |
CN100481818C (en) * | 2002-12-11 | 2009-04-22 | 日本电信电话株式会社 | Method for multicast communication path calculation, setting method for multicast communication path, and calculation device thereof |
US7774461B2 (en) * | 2004-02-18 | 2010-08-10 | Fortinet, Inc. | Mechanism for determining a congestion metric for a path in a network |
CN1305279C (en) * | 2004-07-09 | 2007-03-14 | 清华大学 | Non-state end-to-end constraint entrance permit control method for kernel network |
US20060068818A1 (en) * | 2004-09-28 | 2006-03-30 | Amir Leitersdorf | Audience participation method and apparatus |
US7768926B2 (en) * | 2006-03-09 | 2010-08-03 | Firetide, Inc. | Effective bandwidth path metric and path computation method for wireless mesh networks with wired links |
CN101388831B (en) * | 2007-09-14 | 2011-09-21 | 华为技术有限公司 | Data transmission method, node and gateway |
FR2933834A1 (en) * | 2008-07-11 | 2010-01-15 | Canon Kk | METHOD FOR MANAGING DATA STREAM TRANSMISSION ON A TUNNEL TRANSPORT CHANNEL, TUNNEL HEAD, COMPUTER PROGRAM PRODUCT, AND CORRESPONDING STORAGE MEDIUM. |
US8483077B2 (en) * | 2009-09-16 | 2013-07-09 | At&T Intellectual Property I, L.P. | QoS in multi-hop wireless networks |
CN101552726B (en) * | 2009-05-14 | 2012-01-11 | 北京交通大学 | A grading services edge router |
CN101729230A (en) * | 2009-11-30 | 2010-06-09 | 中国人民解放军国防科学技术大学 | Multiplexing route method for delay tolerant network |
CN101860798B (en) * | 2010-05-19 | 2013-01-30 | 北京科技大学 | Repeated game-based multicast routing algorithm in cognitive wireless network |
CN102780637B (en) * | 2012-08-14 | 2015-01-07 | 虞万荣 | Routing method for data transmission in space delay/disruption tolerant network |
-
2013
- 2013-08-27 US US14/011,233 patent/US20150046558A1/en not_active Abandoned
-
2014
- 2014-03-13 EP EP14720784.9A patent/EP2974178A1/en not_active Withdrawn
- 2014-03-13 WO PCT/US2014/025711 patent/WO2014151428A1/en active Application Filing
- 2014-03-13 CN CN201480024471.4A patent/CN105164981A/en active Pending
- 2014-03-13 DE DE202014010900.1U patent/DE202014010900U1/en not_active Expired - Lifetime
-
2016
- 2016-07-20 HK HK16108727.5A patent/HK1221086A1/en unknown
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP1610496A1 (en) * | 2004-06-18 | 2005-12-28 | Avaya Technology Corp. | Rapid fault detection and recovery for internet protocol telephony |
US20060250965A1 (en) * | 2005-05-09 | 2006-11-09 | Bellsouth Intellectual Property Corporation | Methods, systems, and computer-readable media for optimizing the communication of data packets in a data network |
US20080304472A1 (en) * | 2007-06-05 | 2008-12-11 | Gourlay Douglas A | Communication embodiments and low latency path selection in a multi-topology network |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10498631B2 (en) | 2017-08-15 | 2019-12-03 | Hewlett Packard Enterprise Development Lp | Routing packets using distance classes |
EP3445007A1 (en) * | 2017-08-16 | 2019-02-20 | Hewlett Packard Enterprise Development L.P. | Routing packets in dimensional order in multidimensional networks |
US10374943B2 (en) | 2017-08-16 | 2019-08-06 | Hewlett Packard Enterprise Development Lp | Routing packets in dimensional order in multidimensional networks |
Also Published As
Publication number | Publication date |
---|---|
EP2974178A1 (en) | 2016-01-20 |
HK1221086A1 (en) | 2017-05-19 |
US20150046558A1 (en) | 2015-02-12 |
DE202014010900U1 (en) | 2017-01-13 |
CN105164981A (en) | 2015-12-16 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20150046558A1 (en) | System and method for choosing lowest latency path | |
CA2750264C (en) | Method and system for network data flow management | |
US10505838B2 (en) | System and method for diverting established communication sessions | |
US10798199B2 (en) | Network traffic accelerator | |
US7908393B2 (en) | Network bandwidth detection, distribution and traffic prioritization | |
US7624184B1 (en) | Methods and apparatus for managing access to data through a network device | |
KR20090014334A (en) | Systems and methods of improving performance of transport protocols | |
EP3574617B1 (en) | Method and apparatus for managing routing disruptions in a computer network | |
CN106331117B (en) | A kind of data transmission method | |
Luckie et al. | Measuring path MTU discovery behaviour | |
US10680922B2 (en) | Communication control apparatus and communication control method | |
CN116319422A (en) | Network performance monitoring using active measurement protocols and relay mechanisms | |
WO2019243890A2 (en) | Multi-port data transmission via udp | |
EP3136684B1 (en) | Multicast transmission using programmable network | |
US7978598B1 (en) | Connection replication | |
CN105208074A (en) | Path analysis method and device for asymmetric route based on Web server | |
Vernersson | Analysis of UDP-based reliable transport using network emulation | |
US8639822B2 (en) | Extending application-layer sessions based on out-of-order messages | |
KR101104599B1 (en) | Apparatus and method for defending TCP SYN flooding attacks | |
CA2874047C (en) | System and method for diverting established communication sessions | |
KR101396785B1 (en) | Method for performing tcp functions in network equipmment | |
EP3525419A1 (en) | Connectionless protocol with bandwidth and congestion control | |
EP3525413A1 (en) | Connectionless protocol with bandwidth and congestion control | |
EP3525412A1 (en) | Improved connectionless data transport protocol |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
WWE | Wipo information: entry into national phase |
Ref document number: 201480024471.4 Country of ref document: CN |
|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 14720784 Country of ref document: EP Kind code of ref document: A1 |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
WWE | Wipo information: entry into national phase |
Ref document number: 2014720784 Country of ref document: EP |