US20020114272A1 - Fast failure detection using RTT time considerations on a non-retransmit medium - Google Patents

Fast failure detection using RTT time considerations on a non-retransmit medium Download PDF

Info

Publication number
US20020114272A1
US20020114272A1 US09/734,783 US73478300A US2002114272A1 US 20020114272 A1 US20020114272 A1 US 20020114272A1 US 73478300 A US73478300 A US 73478300A US 2002114272 A1 US2002114272 A1 US 2002114272A1
Authority
US
United States
Prior art keywords
node
packet
communications link
rtt
sent
Prior art date
Legal status (The legal status 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 status listed.)
Granted
Application number
US09/734,783
Other versions
US20050088966A9 (en
US7027389B2 (en
Inventor
Randall Stewart
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Cisco Technology Inc
Original Assignee
Cisco Technology 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 Cisco Technology Inc filed Critical Cisco Technology Inc
Priority to US09/734,783 priority Critical patent/US7027389B2/en
Publication of US20020114272A1 publication Critical patent/US20020114272A1/en
Publication of US20050088966A9 publication Critical patent/US20050088966A9/en
Application granted granted Critical
Publication of US7027389B2 publication Critical patent/US7027389B2/en
Adjusted expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/66Arrangements for connecting between networks having differing types of switching systems, e.g. gateways
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06Management of faults, events, alarms or notifications
    • H04L41/0681Configuration of triggering conditions
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/06Generation of reports
    • H04L43/065Generation of reports related to network devices
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/08Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0805Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability
    • H04L43/0811Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability by checking connectivity
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/08Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0805Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability
    • H04L43/0817Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability by checking functioning
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/08Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0823Errors, e.g. transmission errors
    • H04L43/0847Transmission error
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/08Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0852Delays
    • H04L43/0864Round trip delays
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/16Threshold monitoring

Definitions

  • This invention pertains generally to communications systems.
  • this invention discloses a method and apparatus for detecting a failure condition between two communications nodes with improved reliability (fewer false failures) than previous detection methods.
  • VoIP Voice over Internet Protocol
  • voice communications which are typically transmitted using multiplexed analog based technologies, are instead transmitted in a packetized fashion. Used in this context, the packets are commonly referred to as datagrams.
  • each communication site or node on the VoIP network sends datagrams to other communication sites or nodes.
  • packets can be sent utilizing reliable protocols, that is, protocols that will use error control, acknowledgements, and other techniques that increase the reliable transmission of each datagram.
  • the other counter is used to allow the receiving node to know when to send a periodic equivalent of an “I'm alive and receiving” message to the sender.
  • the actual datagram sent for this case is typically the null datagram.
  • the method disclosed in Stewart et al. has some serious shortcomings when put to actual use.
  • a primary failure is its inability to deal with the “bursty” nature of the transmission media. That is, if either of the two end nodes, or an intermediate routing node, is temporarily subjected to a high peak workload such that the process handling the transmission in questions is swapped out, it may appear to the node where the process is still active that the transmission path has failed.
  • the swapped process becomes active in time to send before the receiving process decides it has lost a connection, the newly active process will tend to send a large burst of traffic (a relatively large number of datagrams) all at once.
  • the present invention discloses the use of an RTT (round trip time) based method and apparatus for detecting communications link failures between two communications nodes using a packetized communications protocol.
  • RTT round trip time
  • the disclosed invention uses one packet sent counter, an RTT-based time interval, a regular ACK or SACK packet sending capability, and a heuristically derived threshold value per node to determine the status of a communications link between two nodes.
  • the counter is set to 0, and a new RTT-based time interval started, each time a packet is received by a node.
  • the sent counter is incremented by one, and only one, while the RTT-based time interval has not been exceeded.
  • each sent packet increments the counter by one. If the counter exceeds the threshold value, it is assumed a communications link failure has occurred.
  • FIG. 1 is a block diagram of the current invention in a preferred use.
  • FIG. 2 is a flow chart according to the present invention.
  • the present invention provides a method for evaluating a communication link between two nodes in a packet network.
  • Each node once an association has been made between the two, increments a packet (datagram, data block, cell, message) sent counter when a packet is first sent within an RTT (Round Trip Time) interval, and will continue to increment the packet sent counter each time a packet is sent if those packets are sent after the endtime of the current RTT interval.
  • Any packet received from the other node resets the sent counter to 0, and begins a new RTT interval.
  • Each node compares the sent counter to a local sent threshold to see if it has exceeded a certain number. If so, this indicates that the communications path the two nodes had been using is down, as the local node is no longer receiving packets from the other node.
  • the present invention is shown in block form in FIG. 1, embedded in a preferred embodiment.
  • the diagram shows a mobile communications device 100 in operable communications over communications link 102 with node 104 .
  • Node 104 is shown as a first node, and in this case is a base transceiver station. It has an association with a second node, node 114 .
  • node 114 is a selection and distribution node, and is in operable communication with node 104 via communications link 112 .
  • Communications link 112 is a VoIP link in this case.
  • Node 114 has a communications link 116 to a PSTN gateway (Public Switched Telephone Network), which is connected to a standard PSTN 120 .
  • PSTN gateway Public Switched Telephone Network
  • a particular communications linkage, at the physical level, may or may not extend over the life of a communications session.
  • a communications session between nodes is one in which two endpoints, or end nodes, remain the same.
  • the connection of primary interest is VoIP communications link 112 between node 104 and node 114 .
  • RTT is the amount of time a packet has taken to make the trip from the originating node, to the target node, and back. There can be minor technical differences in the way RTT is specified for different networks and protocols; all such variations are fully contemplated by the present invention and remain within the inventive nature of the present disclosure.
  • the SCTP protocol uses a SACK packet that is sent to the originating node from the target node at every other packet. The SACK packets are also used to update the current RTT value. For specific implementation details, see the SCTP protocol specifications referenced in the last paragraph.
  • SACK packets are generated by the target node for every other packet received from the originating node, and the SACK packets provide updated RTT interval information.
  • RTT is the time it is taking to make a round trip from the originating node to the target node and back, including the processing time taken by the target node and any inter-arrival delays before sending a SACK.
  • the RTT interval is thus always current, and takes into account not only propagation delays along the communications path itself, but by including the processing time in the target node also takes into account any unusual delays occurring because of the target node.
  • Delays in the RTT include normal situations like rerouting delays and the like, but further include any time delays created by unusually busy nodes along the communications path as well as the fact that the target node may temporarily have a high work load, creating a momentary decrease in response time. Coupled with the use of a SACK packet being generated at the non-local node for every other packet received at the non-local node, the false indications of a failed communications path due to variations in response time and bursty traffic are virtually eliminated. In addition, the detection of a failed link remains very fast.
  • each node has a Sent Counter 106 , a Threshold Value 108 , and an RTT Value 110 .
  • the RTT value is updated regularly so that the current amount of time a round trip is taking is always known.
  • the threshold value is an assigned value based on heuristic knowledge of the configuration and application. In a preferred embodiment the thresholds are preferably set, jointly or separately, to some constant configuration parameters.
  • Threshold Value 108 as used and described in the present disclosure may be a derived value, a table lookup value, or in some implementations designed for limited or well-specified applications may be a constant. These variations and others will be apparent to one of ordinary skill in the art having the benefit of the present disclosure.
  • FIG. 2 shows a process according to the present invention. This process is the same on both nodes of a communication association (both end nodes).
  • Block 200 starts the process, where some type of packet event occurs in a communications session with a particular end node; either a packet is sent or one has been received. As soon as a packet event occurs, block 200 is left and decision point 202 entered.
  • Decision point 202 determines if a packet has just been sent, or if a packet has just been received from the other node in the communication association. If a packet has not been sent, then one must have just been received. In this case the “NO” exit is taken and block 212 entered.
  • Block 212 takes the action of resetting the local sent counter to 0. This is done because if the local node just received a packet from the non-local node, the communications path is open at least up until the delivery time of the packet just received. After resetting the local sent counter to 0, block 212 is exited and block 220 entered, where a new RTT time interval is started. After starting the new RTT time interval, block 220 is left and block 200 re-entered, waiting for the next packet event.
  • Decision point 204 determines if this packet has been sent within the current RTT interval.
  • the current RTT interval is the current time value associated with RTT.
  • the value of RTT is added to the time when the last packet was received from the non-local node, and that calculated time and the current time compared. This is carried out in block 220 , discussed above. If the current time is within the current RTT interval (that is, less than or equal to the value calculated by adding the RTT to time when the last packet was received from the non-local node), then decision point 204 is exited by taking the “YES” branch. Decision point 216 is now entered.
  • Decision point 216 determines if this is the first packet to be sent during the current RTT time interval. If so, the “YES” exit is taken to block 214 . In block 214 the sent counter is incremented by one, after which the process continues back to block 200 . If this is not the first packet to be sent during the current RTT time interval, the “NO” exit is taken, leading directly back to block 200 to wait for the next packet event.
  • the sent counter will now be incremented every time a packet is sent to the non-local node, until the local node receives another packet from the non-local node. If and when another packet is received from the non-local node, the sent counter will be reset to 0 and a new RTT time interval started. The local node is now counting how many packets it is sending after a “blank-out” time period corresponding to one round trip of the communications link.
  • block 206 is left for decision point 208 .
  • the current value of the sent counter is checked against the preset threshold value. If the sent counter exceeds the threshold value, the “YES” exit is taken to block 210 .
  • the action taken in block 210 is to issue a warning of some kind in the local system that the communication link between this node and the non-local node appears to be down, so the local system can take appropriate measures.
  • Block 210 is left and endpoint 218 entered, finishing the process for this communications association (this session) between the two current end nodes.
  • the present invention thus provides a method and apparatus for determining the status in a communications link between two end nodes where each end node is using some form of packetized networking.
  • the present invention will work using a protocol that does not include retransmit of packets (which is usually the case in a time-critical application such as VoIP).
  • the present invention detects failures very quickly, allowing for recovery of the communications link from a user's perspective before an actual disruption occurs.
  • any one end node may be supporting multiple communications sessions; each communications session may or may not have its own sent counter, RTT value, and threshold value depending on the identities of the other end nodes.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Environmental & Geological Engineering (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

The present invention provides a method and apparatus to determine the state of a communications link between two nodes in a network. Typically, each node will have an RTT-based value to use, a packets sent counter, and a threshold number to use against the packet sent counter to determine if there is a problem with their communications link. Using the RTT value makes the failure detection sensitive to the actual state of the communications link at any particular time; it also allows the failure detection algorithm to take into account the bursty nature of nodes in a packetized network connection. For each packet received from a non-local node, the local node sets the counter to 0 and starts a new RTT-based time interval. The local node then increments the counter only once, regardless of how many packets it sends to the non-local node, during the RTT-based time interval. Once the time interval is up, the counter is incremented for each packet sent. The counter is compared to the fixed threshold value to determine if it is likely a communications link failure has occurred.

Description

    BACKGROUND OF THE INVENTION
  • 1. Field of the Invention [0001]
  • This invention pertains generally to communications systems. In particular, this invention discloses a method and apparatus for detecting a failure condition between two communications nodes with improved reliability (fewer false failures) than previous detection methods. [0002]
  • 2. The Prior Art [0003]
  • Packetized methods of communicating between sites or nodes on a network are well known. A relatively recent application of packetized communications is Voice over Internet Protocol (VoIP), where voice communications, which are typically transmitted using multiplexed analog based technologies, are instead transmitted in a packetized fashion. Used in this context, the packets are commonly referred to as datagrams. [0004]
  • When using VoIP, each communication site or node on the VoIP network sends datagrams to other communication sites or nodes. When data integrity is important, packets can be sent utilizing reliable protocols, that is, protocols that will use error control, acknowledgements, and other techniques that increase the reliable transmission of each datagram. [0005]
  • However, because of the real-time limitations of delivering a realistic voice message (when compared to other applications such as text transmittal) there is often not enough time to detect failures in the transmission path—missing packets, a downed intermediate node creating added transmission time for a set of datagrams, etc. Normally the damaged or missing datagrams are rejected or ignored by the receiving node, as there is no time to send a request for a retransmit and to wait for a response from the source node. [0006]
  • This leads to a situation where the two end nodes (or communication sites) do not detect a break in the transmission until a significant amount of time has passed, or don't detect the communications break at all, and the link is lost. [0007]
  • There have been recent attempts to correct this situation, with the most apropos solution found in U.S. Pat. No. 6,134,221 issued Oct. 17, 2000, by Stewart et al. Stewart reveals a method where two end nodes, who are communicating using datagrams, each have two counters and two thresholds. There is one threshold for each counter. The two counters at each node consist of one “messages sent” counter and one “messages received” counter. Basically, one counter is used to determine if the local node has sent too many messages without getting a response (conclusion—communication path is down). To handle the case where a communication may be one-sided for specific intervals during the life of the overall communication, that is, where one would expect to send a large number of datagrams without receiving any, the other counter is used to allow the receiving node to know when to send a periodic equivalent of an “I'm alive and receiving” message to the sender. The actual datagram sent for this case is typically the null datagram. For further details, see U.S. Pat. No. 6,134,221. [0008]
  • The method disclosed in Stewart et al. has some serious shortcomings when put to actual use. A primary failure is its inability to deal with the “bursty” nature of the transmission media. That is, if either of the two end nodes, or an intermediate routing node, is temporarily subjected to a high peak workload such that the process handling the transmission in questions is swapped out, it may appear to the node where the process is still active that the transmission path has failed. In addition, even if the swapped process becomes active in time to send before the receiving process decides it has lost a connection, the newly active process will tend to send a large burst of traffic (a relatively large number of datagrams) all at once. This causes the sent counter to increment faster than a datagram can be received from the target node, which will be misread by the sender as a false failure of the receiving node. That happens because the expected “I'm alive” datagram coming from the target node cannot be received by the time the sending node has incremented its sent counter past the number when an “I'm alive” datagram would ordinarily have been expected due to the quick burst of datagrams sent. [0009]
  • Thus, a need exists for a more reliable method and apparatus for evaluating a communication link between nodes using packets, datagrams, or any packetized protocol. [0010]
  • BRIEF DESCRIPTION OF THE INVENTION
  • The present invention discloses the use of an RTT (round trip time) based method and apparatus for detecting communications link failures between two communications nodes using a packetized communications protocol. The advantage this has over previous solutions is that by using a time element, rather than a packet counting-based method devoid of any time considerations, communications link trouble may be detected both quickly and with far more reliability (fewer false failure alarms) than using previous methods. [0011]
  • The disclosed invention uses one packet sent counter, an RTT-based time interval, a regular ACK or SACK packet sending capability, and a heuristically derived threshold value per node to determine the status of a communications link between two nodes. The counter is set to 0, and a new RTT-based time interval started, each time a packet is received by a node. When the node sends packets, the sent counter is incremented by one, and only one, while the RTT-based time interval has not been exceeded. As soon as the RTT-based time interval is exceeded, each sent packet increments the counter by one. If the counter exceeds the threshold value, it is assumed a communications link failure has occurred. [0012]
  • BRIEF DESCRIPTION OF THE DRAWING FIGURES
  • FIG. 1 is a block diagram of the current invention in a preferred use. [0013]
  • FIG. 2 is a flow chart according to the present invention.[0014]
  • DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS
  • Person of ordinary skill in the art will realize that the following description of the present invention is illustrative only and not in any way limiting. Other embodiments of the invention will readily suggest themselves to such skilled persons having the benefit of this disclosure. [0015]
  • The present invention provides a method for evaluating a communication link between two nodes in a packet network. Each node, once an association has been made between the two, increments a packet (datagram, data block, cell, message) sent counter when a packet is first sent within an RTT (Round Trip Time) interval, and will continue to increment the packet sent counter each time a packet is sent if those packets are sent after the endtime of the current RTT interval. Any packet received from the other node resets the sent counter to 0, and begins a new RTT interval. Each node compares the sent counter to a local sent threshold to see if it has exceeded a certain number. If so, this indicates that the communications path the two nodes had been using is down, as the local node is no longer receiving packets from the other node. [0016]
  • The present invention is shown in block form in FIG. 1, embedded in a preferred embodiment. The diagram shows a [0017] mobile communications device 100 in operable communications over communications link 102 with node 104. Node 104 is shown as a first node, and in this case is a base transceiver station. It has an association with a second node, node 114. In this embodiment node 114 is a selection and distribution node, and is in operable communication with node 104 via communications link 112. Communications link 112 is a VoIP link in this case. Node 114 has a communications link 116 to a PSTN gateway (Public Switched Telephone Network), which is connected to a standard PSTN 120. A particular communications linkage, at the physical level, may or may not extend over the life of a communications session. A communications session between nodes is one in which two endpoints, or end nodes, remain the same.
  • For the purposes of this disclosure, the connection of primary interest is [0018] VoIP communications link 112 between node 104 and node 114. In a preferred embodiment, the protocol in use would be SCTP over IP (Stream Control Transmission Protocol over Internet Protocol). Details of the protocols are publicly available and will not be discussed in unneeded detail; please refer to the IETF (Internet Engineering Task Force) at www.ietf.org for further information and details of the SCTP (Stream Control Transmission Protocol), including its use and specification of RTT (Round Trip Time) and SACK (Selective ACKnowledgement) packets (http://www.ietf.org/rfc/rfc2960.txt?number=2960). Although the preferred embodiment of the present invention makes use of the RTT calculation ability built into SCTP, and uses SACKs for both RTT purposes and counter reset purposes, it will be readily apparent to a person of ordinary skill in the art and with the benefit of the present disclosure that any two nodes communicating using any type of packet-based protocol can make use of the current invention by using, or implementing, functionality that is the equivalent of that described herein using SCTP-specific terms.
  • RTT is the amount of time a packet has taken to make the trip from the originating node, to the target node, and back. There can be minor technical differences in the way RTT is specified for different networks and protocols; all such variations are fully contemplated by the present invention and remain within the inventive nature of the present disclosure. In addition, the SCTP protocol uses a SACK packet that is sent to the originating node from the target node at every other packet. The SACK packets are also used to update the current RTT value. For specific implementation details, see the SCTP protocol specifications referenced in the last paragraph. [0019]
  • For the purposes of this disclosure the important details are that SACK packets are generated by the target node for every other packet received from the originating node, and the SACK packets provide updated RTT interval information. RTT is the time it is taking to make a round trip from the originating node to the target node and back, including the processing time taken by the target node and any inter-arrival delays before sending a SACK. The RTT interval is thus always current, and takes into account not only propagation delays along the communications path itself, but by including the processing time in the target node also takes into account any unusual delays occurring because of the target node. Delays in the RTT include normal situations like rerouting delays and the like, but further include any time delays created by unusually busy nodes along the communications path as well as the fact that the target node may temporarily have a high work load, creating a momentary decrease in response time. Coupled with the use of a SACK packet being generated at the non-local node for every other packet received at the non-local node, the false indications of a failed communications path due to variations in response time and bursty traffic are virtually eliminated. In addition, the detection of a failed link remains very fast. [0020]
  • Referring back to FIG. 1, each node has a Sent [0021] Counter 106, a Threshold Value 108, and an RTT Value 110. In the preferred embodiment, the RTT value is updated regularly so that the current amount of time a round trip is taking is always known. The threshold value is an assigned value based on heuristic knowledge of the configuration and application. In a preferred embodiment the thresholds are preferably set, jointly or separately, to some constant configuration parameters.
  • [0022] Threshold Value 108 as used and described in the present disclosure may be a derived value, a table lookup value, or in some implementations designed for limited or well-specified applications may be a constant. These variations and others will be apparent to one of ordinary skill in the art having the benefit of the present disclosure.
  • FIG. 2 shows a process according to the present invention. This process is the same on both nodes of a communication association (both end nodes). Block [0023] 200 starts the process, where some type of packet event occurs in a communications session with a particular end node; either a packet is sent or one has been received. As soon as a packet event occurs, block 200 is left and decision point 202 entered.
  • [0024] Decision point 202 determines if a packet has just been sent, or if a packet has just been received from the other node in the communication association. If a packet has not been sent, then one must have just been received. In this case the “NO” exit is taken and block 212 entered.
  • [0025] Block 212 takes the action of resetting the local sent counter to 0. This is done because if the local node just received a packet from the non-local node, the communications path is open at least up until the delivery time of the packet just received. After resetting the local sent counter to 0, block 212 is exited and block 220 entered, where a new RTT time interval is started. After starting the new RTT time interval, block 220 is left and block 200 re-entered, waiting for the next packet event.
  • If, at [0026] decision point 202, the answer is yes and a packet has just been sent, then the “YES” exit is taken and decision point 204 entered.
  • [0027] Decision point 204 determines if this packet has been sent within the current RTT interval. The current RTT interval is the current time value associated with RTT. The value of RTT is added to the time when the last packet was received from the non-local node, and that calculated time and the current time compared. This is carried out in block 220, discussed above. If the current time is within the current RTT interval (that is, less than or equal to the value calculated by adding the RTT to time when the last packet was received from the non-local node), then decision point 204 is exited by taking the “YES” branch. Decision point 216 is now entered.
  • [0028] Decision point 216 determines if this is the first packet to be sent during the current RTT time interval. If so, the “YES” exit is taken to block 214. In block 214 the sent counter is incremented by one, after which the process continues back to block 200. If this is not the first packet to be sent during the current RTT time interval, the “NO” exit is taken, leading directly back to block 200 to wait for the next packet event.
  • The effect of this portion of the process is that, during the initial RTT time interval, the sent counter is only incremented once. This takes into account the current behavior of the communications link and the processing time of the non-local node, as no further incrementing is done until after current RTT interval has passed. Using RTT in this manner circumvents the problems of previous solutions where, because RTT was not used, incremented the sent counter regardless of any time considerations which relate to the current traversal speed of the communications link. [0029]
  • Returning now to [0030] decision point 204 in FIG. 2, if the packet has been sent and the current RTT time interval value has been passed, then the “NO” exit is taken and block 206 entered. The action taken in block 206 is to increment the sent counter.
  • The sent counter will now be incremented every time a packet is sent to the non-local node, until the local node receives another packet from the non-local node. If and when another packet is received from the non-local node, the sent counter will be reset to 0 and a new RTT time interval started. The local node is now counting how many packets it is sending after a “blank-out” time period corresponding to one round trip of the communications link. [0031]
  • Note: you may get packets from the non-local node during the “blank-out” period, depending on the rate the non-local node is sending packets. That is OK—the local sent counter is reset to 0 each time and a new RTT time interval started each time. In addition, as will be apparent to one of ordinary skill in the art and with the benefit of the present disclosure, it is not necessary to set the sent counter to “[0032] 0” in the literal sense when using the present invention. Any preset value or base value may be used, and any method of changing the value in the sent counter may be used coupled with any value in the threshold value so long as a comparison between the two yields the desired functional state information of the communications link in question. Setting the sent counter to 0 and incrementing the sent counter by 1 in accordance with the current state of the RTT time interval when a packet is received is a preferred embodiment.
  • Returning now to block [0033] 206 in FIG. 2, block 206 is left for decision point 208. The current value of the sent counter is checked against the preset threshold value. If the sent counter exceeds the threshold value, the “YES” exit is taken to block 210. The action taken in block 210 is to issue a warning of some kind in the local system that the communication link between this node and the non-local node appears to be down, so the local system can take appropriate measures. Block 210 is left and endpoint 218 entered, finishing the process for this communications association (this session) between the two current end nodes.
  • If, at [0034] decision point 208, the sent counter value is less than the threshold value, the “NO” exit is taken which leads directly back to block 200. The next packet event will trigger the next traversal of the method shown.
  • The present invention thus provides a method and apparatus for determining the status in a communications link between two end nodes where each end node is using some form of packetized networking. Of particular importance is that the present invention will work using a protocol that does not include retransmit of packets (which is usually the case in a time-critical application such as VoIP). In addition to being able to detect a communications link failure using the present invention, by using RTT and the SCTP SACK packets (alternatively, any packet-oriented protocol that can be programmed to send any type of non-data or null-data packet at regular intervals) the present invention detects failures very quickly, allowing for recovery of the communications link from a user's perspective before an actual disruption occurs. And, just as important from a systems view, the current invention accounts for the actual nature of many communications links, including the creation of very bursty traffic by either an end node or an intermediate node, thus preventing the issuing of false communications failure alerts. Finally, as will be readily apparent to one of ordinary skill in the art and with the benefit of the present invention, any one end node may be supporting multiple communications sessions; each communications session may or may not have its own sent counter, RTT value, and threshold value depending on the identities of the other end nodes. [0035]
  • The present invention has been partially described through the use of a flow chart. As is appreciated by those of ordinary skill in the art and with the benefit of the present disclosure, the procedures described herein may be repeated as continuously, as often, or as little as necessary to satisfy the needs described and details or order of steps may vary without departing from the basic concepts of the present invention. [0036]
  • As will be readily apparent to a person of ordinary skill in the art and having the benefit of this disclosure, there will be a large number of possible ways of representing the data and the program running at each end node, used to implement the current invention, and how the data is stored on machine readable media at each end node. All such implementations are contemplated by the present invention, and may be used while staying within the inventive nature of the present disclosure. When speaking of a communications system within a node, any and all software and hardware components needed to complete an operation associated with any communications task within the system is intended, regardless of where those individual components may be within the node. In addition, there are many more modifications than mentioned above are possible without departing from the inventive concepts contained herein. The invention, therefore, is not to be restricted except in the spirit of the associated claims. [0037]

Claims (27)

What is claimed is:
1. A communications link failure detection system comprising:
at least two nodes, including a first node and a second node, each node having disposed therein a communications system configured to operate at least one packetized communications link, and further where each node of said at least two nodes has at least one communications link where said communications link is in operable communication with said communications system;
where said first node's communication link and said second node's communications link are in operable communication with each other; and,
where said communications system disposed within said first node further comprises a sent counter, a threshold value having an initial value, and an RTT value where said RTT value is set to a value corresponding to the time it takes a packet to make a trip from said first node to said second node and back to said first node, and where said second node sends periodic packets to said first node, and where said communications system can detect a communications link failure using said sent counter, said threshold value, and said RTT value.
2. The communications link failure detection system of claim 1 where said second node further comprises, within the communications system disposed therein, a second sent counter, a second threshold value having an initial value, and a second RTT value where said second RTT value is set to a value corresponding to the time it takes a packet to make a trip from said second node to said first node and back to said second node, and where said communications system can detect a communications link failure using said second sent counter, said second threshold value, and said second RTT value.
3. The communications link failure detection system of claim 2 where said first sent counter and said second sent counter are set to 0 at the start of a communications session.
4. The communications link failure detection system of claim 2 where said threshold values are a constant.
5. The communications link failure detection system of claim 2 where said threshold values are partially dependent on individual communications sessions.
6. The communications link failure detection system of claim 2 where said communications link uses an SCTP/IP-compliant protocol, and where said at least two nodes send a SACK-compliant packet from a local node to a non-local node regularly.
7. The communications link failure detection system of claim 6 where said at least two nodes send said SACK-compliant packet from a local node to a non-local node after two data packets are received from said non-local node at said local node.
8. A method for detecting the status of a communications link between a first node and a second node, the method comprising:
establishing an RTT value for use in said first node using said second node;
setting a sent counter in said first node to 0 and starting an RTT-based time interval in said first node when a packet is received from said second node;
incrementing said sent counter when a packet is sent to said second node from said first node according to said RTT-based time interval; and,
using said sent counter to determine if a failure has occurred in said communications link between said first node and said second node.
9. The method of claim 8 wherein said communications link uses an SCTP/IP-compliant protocol.
10. A method for detecting the status of a communications link between a first node and a second node, the method comprising:
establishing an RTT value for use in said first node using said second node;
establishing an RTT value for use in said second node using said first node;
setting a first sent counter in said first node to 0 and starting an RTT-based time interval in said first node when a packet is received from said second node;
setting a second sent counter in said second node to 0 and starting an RTT-based time interval in said second node when a packet is received from said first node;
incrementing said first sent counter when a packet is sent to said second node from said first node according to said RTT-based time interval;
incrementing said second sent counter when a packet is sent to said first node from said second node according to said RTT-based time interval; and,
using either said first sent counter or said second sent counter to determine if a failure has occurred in said communications link between said first node and said second node.
11. The method of claim 10 wherein said communications link uses an SCTP/IP-compliant protocol.
12. A method for detecting the status of a communications link between two nodes, including a local and a non-local node, the method comprising:
(a) detecting a packet event in said local node;
(b) determining if said packet event was a packet send or packet receive event;
(c) resetting a sent counter to 0 and starting a new RTT time interval if said packet event was a packet receive event on said local node;
(d) incrementing said sent counter if said packet event is a send packet event and said packet event is the first send packet event to occur within the current RTT time interval on said local node;
(e) incrementing said sent counter if said packet event is a send packet event and said packet event occurs after the expiration of the most recently started RTT time interval on said local node;
(f) comparing said sent counter with a threshold value and issuing a communications link failure message if said sent counter is larger than said threshold value on said local node; and,
(g) continuing with step (a) if no communications link failure message has been issued.
13. The method of claim 12 wherein said communications link uses an SCTP/IP-compliant protocol.
14. A program storage device readable by a machine, tangibly embodying a program of instructions executable by a machine for detecting the status of a communications link between two machines, including a local and a non-local machine, the method comprising:
(a) detecting a packet event in said local machine;
(b) determining if said packet event was a packet send or packet receive event;
(c) resetting a sent counter to 0 and starting a new RTT time interval if said packet event was a packet receive event on said local machine;
(d) incrementing said sent counter if said packet event is a send packet event and said packet event is the first send packet event to occur within the current RTT time interval on said local machine;
(e) incrementing said sent counter if said packet event is a send packet event and said packet event occurs after the expiration of the most recently started RTT time interval on said local machine;
(f) comparing said sent counter with a threshold value and issuing a communications link failure message if said sent counter is larger than said threshold value on said local machine; and,
(g) continuing with step (a) if no communications link failure message has been issued.
15. The program storage device machine for detecting the status of a communications link between two machines of claim 14 wherein said communications link uses an SCTP/IP-compliant protocol.
16. In a local node having a communications link to a non-local node, a system for detecting the status of the communications link between the local node and the non-local node, the system comprising:
means for detecting a packet event in said local node;
means for determining if said packet event was a packet send or packet receive event;
means for resetting a sent counter to 0 and starting a new RTT time interval if said packet event was a packet receive event on said local node;
means for incrementing said sent counter if said packet event is a send packet event and said packet event is the first send packet event to occur within the current RTT time interval on said local node;
means for incrementing said sent counter if said packet event is a send packet event and said packet event occurs after the expiration of the most recently started RTT time interval on said local node; and,
means for comparing said sent counter with a threshold value and issuing a communications link failure message if said sent counter is larger than said threshold value on said local node.
17. The system for detecting the status of the communications link between a local node and a non-local node of claim 16, wherein said communications link uses an SCTP/IP-compliant protocol.
18. A communications link failure detection system between a first node and a second node comprising:
a communications system operably disposed within said first node, wherein said communications system in said first node further comprises an RTT determiner component operably disposed therein, and where said RTT determiner is in operable communication with said second node and configured to establish an RTT value usable in said first node using said second node;
wherein said communications system in said first node further comprises a sent counter operably disposes therein, and where said sent counter is further configured to be set to a value corresponding to an RTT time interval and a previous sent counter value when a packet is received from said second node; and,
wherein said communications system in said first node further comprises a threshold value operably disposed therein, and where said threshold value is further configured to be compared to said sent counter, enabling said communications system to make a communications link status determination thereby.
19. The communications link failure detection system of claim 18 wherein said communications system uses an SCTP/IP-compliant protocol.
20. The communications link failure detection system of claim 18 where said sent counter is set to 0 at the start of a communications session.
21. The communications link failure detection system of claim 18 where said threshold value is a constant.
22. The communications link failure detection system of claim 18 where said threshold value is partially dependent on individual communications sessions.
23. The communications link failure detection system of claim 19 where said communications system is further configured to use said SCTP/IP-compliant protocol to send a SACK-compliant packet between said first node and said second node regularly.
24. A program storage device readable by a machine, tangibly embodying a program of instructions executable by a machine for detecting the status of a communications link between a first node and a second node, the method comprising:
establishing an RTT value for use in said first node using said second node;
setting a sent counter in said first node to a base value and starting an RTT-based time interval in said first node when a packet is received from said second node;
incrementing said sent counter when a packet is sent to said second node from said first node according to said RTT-based time interval; and,
using said sent counter to determine if a failure has occurred in said communications link between said first node and said second node.
25. The method of claim 24 wherein said communications link uses an SCTP/IP-compliant protocol.
26. In a first node having a communications link to a second node, a system for detecting the status of a communications link between the first node and the second node comprising:
means for establishing an RTT value for use in said first node using said second node;
means for setting a sent counter in said first node to a base value and starting an RTT-based time interval in said first node when a packet is received from said second node;
means for incrementing said sent counter when a packet is sent to said second node from said first node according to said RTT-based time interval; and,
means using said sent counter to determine if a failure has occurred in said communications link between said first node and said second node.
27. The method of claim 26 wherein said communications link uses an SCTP/IP-compliant protocol.
US09/734,783 2000-12-11 2000-12-11 Fast failure detection using RTT time considerations on a non-retransmit medium Expired - Lifetime US7027389B2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US09/734,783 US7027389B2 (en) 2000-12-11 2000-12-11 Fast failure detection using RTT time considerations on a non-retransmit medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US09/734,783 US7027389B2 (en) 2000-12-11 2000-12-11 Fast failure detection using RTT time considerations on a non-retransmit medium

Publications (3)

Publication Number Publication Date
US20020114272A1 true US20020114272A1 (en) 2002-08-22
US20050088966A9 US20050088966A9 (en) 2005-04-28
US7027389B2 US7027389B2 (en) 2006-04-11

Family

ID=34523088

Family Applications (1)

Application Number Title Priority Date Filing Date
US09/734,783 Expired - Lifetime US7027389B2 (en) 2000-12-11 2000-12-11 Fast failure detection using RTT time considerations on a non-retransmit medium

Country Status (1)

Country Link
US (1) US7027389B2 (en)

Cited By (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040174817A1 (en) * 2002-12-12 2004-09-09 Dilithium Networks Pty Ltd. Methods and system for fast session establishment between equipment using H.324 and related telecommunications protocols
US20050249123A1 (en) * 2004-05-10 2005-11-10 Finn Norman W System and method for detecting link failures
US20050286416A1 (en) * 2004-06-25 2005-12-29 Nec Corporation Communication system
US20060029041A1 (en) * 2002-12-12 2006-02-09 Dilithium Networks Pty Ltd Methods and system for fast session establishment between equipment using H.324 and related telecommunications protocols
EP1696646A1 (en) * 2005-02-28 2006-08-30 Samsung Electronics Co.,Ltd. Method and system for link failure recovery
EP1703671A1 (en) * 2005-03-15 2006-09-20 Fujitsu Limited Device and method for network monitoring
US20070005985A1 (en) * 2005-06-30 2007-01-04 Avigdor Eldar Techniques for password attack mitigation
KR100717219B1 (en) * 1999-08-17 2007-05-11 텔레폰악티에볼라겟엘엠에릭슨(펍) Method and device for determining a time-parameter
US7236476B2 (en) 2003-10-02 2007-06-26 International Business Machines Corporation mSCTP based handover of a mobile device between non-intersecting networks
US20070230358A1 (en) * 2006-03-31 2007-10-04 Ashok Narayanan Facilitating application synchronization with a reservation protocol at a sender without application receiver participation
US20070266161A1 (en) * 2002-12-12 2007-11-15 Dilithium Networks Pty Ltd. Methods and system for fast session establishment between equipment using h.324 and related telecommunications protocols
US20070275760A1 (en) * 2004-05-05 2007-11-29 Telefonaktiebolaget Lm Ericsson (Publ) Hdspa Flow Control, Control Frames Rtt Measurement
US20070297352A1 (en) * 2002-12-12 2007-12-27 Dilithium Networks Pty Ltd. Methods and apparatus for combining session acceleration techniques for media oriented negotiation acceleration
US20080151933A1 (en) * 2006-12-22 2008-06-26 Jean-Philippe Vasseur Optimization of distributed tunnel rerouting in a computer network with intermediate node feedback
CN1921417B (en) * 2005-08-25 2010-10-06 华为技术有限公司 Method for reporting conversation state of two-way transfer detection
US8767532B2 (en) 2006-12-22 2014-07-01 Cisco Technology, Inc. Optimization of distributed tunnel rerouting in a computer network with path computation at an intermediate node
US20160291697A1 (en) * 2015-03-30 2016-10-06 Google Inc. Methods and Systems for Gesture Based Switch for Machine Control
TWI561031B (en) * 2014-12-04 2016-12-01 Inventec Corp Method of determining status of serving node
CN112771818A (en) * 2018-10-05 2021-05-07 高通股份有限公司 System and method for fast round trip time measurement distribution
US11263047B2 (en) * 2018-02-15 2022-03-01 Sap Se Metadata management for multi-core resource manager

Families Citing this family (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040240431A1 (en) * 2003-05-30 2004-12-02 Makowski Steven L. Bearer path assurance test for call set-up using IP networks
US8139585B1 (en) * 2003-07-10 2012-03-20 Sprint Spectrum L.P. Method and system for controlling sessions from a subscriber terminal
JP4153502B2 (en) * 2005-03-29 2008-09-24 富士通株式会社 Communication device and logical link error detection method
US8264962B2 (en) * 2005-06-27 2012-09-11 Cisco Technology, Inc. System and method for dynamically responding to event-based traffic redirection
US8144644B1 (en) 2006-02-07 2012-03-27 Sprint Spectrum L.P. Network-side setup of a packet-data communication session on behalf of a mobile station, followed by transfer of the communication session to the mobile station
US7978599B2 (en) * 2006-11-17 2011-07-12 Cisco Technology, Inc. Method and system to identify and alleviate remote overload
TWI336189B (en) * 2006-12-07 2011-01-11 Inst Information Industry Heterogeneous network transmission apparatus,method,application program and computer readable medium capable of transmitting a packet with a plurality of network paths according to a dispatch ratio
CN101729360B (en) * 2008-10-22 2012-01-04 华为技术有限公司 Method and device for setting path state
CN102548026B (en) * 2009-08-06 2014-12-31 华为技术有限公司 Method and device for processing connection resource release
CN101640941B (en) 2009-08-06 2012-03-21 华为技术有限公司 Connection resource release processing method and device
US8566682B2 (en) 2010-06-24 2013-10-22 International Business Machines Corporation Failing bus lane detection using syndrome analysis
US8862944B2 (en) * 2010-06-24 2014-10-14 International Business Machines Corporation Isolation of faulty links in a transmission medium
US9419888B2 (en) 2011-12-22 2016-08-16 Itron, Inc. Cell router failure detection in a mesh network
KR20170094554A (en) * 2013-03-29 2017-08-18 브이아이디 스케일, 인크. Early packet loss detection and feedback
US10834065B1 (en) 2015-03-31 2020-11-10 F5 Networks, Inc. Methods for SSL protected NTLM re-authentication and devices thereof
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

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5170391A (en) * 1989-10-13 1992-12-08 Gec Plessey Telecommunications Limited Fault detection and bandwidth monitoring means for a packet switching arrangement
US5513185A (en) * 1992-11-23 1996-04-30 At&T Corp. Method and apparatus for transmission link error rate monitoring
US5563874A (en) * 1995-01-27 1996-10-08 Bell Communications Research, Inc. Error monitoring algorithm for broadband signaling
US6134221A (en) * 1999-04-15 2000-10-17 Motorola, Inc. Method for evaluating a communication link between a first and a second communication site
US6442140B1 (en) * 1999-01-04 2002-08-27 3Com Corporation Method for automatic setup of missing RM cell count parameter CRM in an ATM traffic management descriptor
US6545979B1 (en) * 1998-11-27 2003-04-08 Alcatel Canada Inc. Round trip delay measurement
US6687251B1 (en) * 1999-12-08 2004-02-03 Nortel Networks Limited Method and apparatus for distributed MTP Level 2 architecture

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5170391A (en) * 1989-10-13 1992-12-08 Gec Plessey Telecommunications Limited Fault detection and bandwidth monitoring means for a packet switching arrangement
US5513185A (en) * 1992-11-23 1996-04-30 At&T Corp. Method and apparatus for transmission link error rate monitoring
US5563874A (en) * 1995-01-27 1996-10-08 Bell Communications Research, Inc. Error monitoring algorithm for broadband signaling
US6545979B1 (en) * 1998-11-27 2003-04-08 Alcatel Canada Inc. Round trip delay measurement
US6442140B1 (en) * 1999-01-04 2002-08-27 3Com Corporation Method for automatic setup of missing RM cell count parameter CRM in an ATM traffic management descriptor
US6134221A (en) * 1999-04-15 2000-10-17 Motorola, Inc. Method for evaluating a communication link between a first and a second communication site
US6687251B1 (en) * 1999-12-08 2004-02-03 Nortel Networks Limited Method and apparatus for distributed MTP Level 2 architecture

Cited By (45)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100717219B1 (en) * 1999-08-17 2007-05-11 텔레폰악티에볼라겟엘엠에릭슨(펍) Method and device for determining a time-parameter
US7161949B2 (en) * 2002-12-12 2007-01-09 Dilithium Networks Pty Ltd. Methods and system for fast session establishment between equipment using H.324 and related telecommunications protocols
US7483441B2 (en) 2002-12-12 2009-01-27 Dilithium Networks Pty Ltd. Methods and system for fast session establishment between equipment using H.324 and related telecommunications protocols
US7206316B2 (en) 2002-12-12 2007-04-17 Dilithium Networks Pty Ltd. Methods and system for fast session establishment between equipment using H.324 and related telecommunications protocols
US20060176877A1 (en) * 2002-12-12 2006-08-10 Dilithium Networks Pty Ltd. Methods and system for fast session establishment between equipment using H.324 and related telecommunications protocols
US20070086583A1 (en) * 2002-12-12 2007-04-19 Dilithium Networks Pty Ltd. Methods and system for fast session establishment between equipment using h.324 and related telecommunications protocols
US8009686B2 (en) 2002-12-12 2011-08-30 Rpx Corporation Methods and system for fast session establishment between equipment using H.324 and related telecommunications protocols
US20080310438A1 (en) * 2002-12-12 2008-12-18 Dilithium Networks Pty Ltd. Methods and system for fast session establishment between equipment using H.324 and related telecommunications protocols
US7672322B2 (en) 2002-12-12 2010-03-02 Rpx Corporation Methods and system for fast session establishment between equipment using H.324 and related telecommunications protocols
US20060250992A1 (en) * 2002-12-12 2006-11-09 Dilithium Networks Pty Ltd. Methods and system for fast session establishment between equipment using H.324 and related telecommunications protocols
US7139279B2 (en) 2002-12-12 2006-11-21 Dilithium Networks Pty Ltd. Methods and system for fast session establishment between equipment using H.324 and related telecommunications protocols
US7688837B2 (en) 2002-12-12 2010-03-30 Rpx Corporation Methods and system for fast session establishment between equipment using H.324 and related telecommunications protocols
US7366192B2 (en) 2002-12-12 2008-04-29 Dilithium Networks Pty. Ltd. Methods and system for fast session establishment between equipment using H.324 and related telecommunications protocols
US20060029041A1 (en) * 2002-12-12 2006-02-09 Dilithium Networks Pty Ltd Methods and system for fast session establishment between equipment using H.324 and related telecommunications protocols
US7388873B2 (en) 2002-12-12 2008-06-17 Dilithium Networks Pty Ltd. Methods and system for fast session establishment between equipment using H.324 and related telecommunications protocols
US20040174817A1 (en) * 2002-12-12 2004-09-09 Dilithium Networks Pty Ltd. Methods and system for fast session establishment between equipment using H.324 and related telecommunications protocols
US20070297352A1 (en) * 2002-12-12 2007-12-27 Dilithium Networks Pty Ltd. Methods and apparatus for combining session acceleration techniques for media oriented negotiation acceleration
US20070171922A1 (en) * 2002-12-12 2007-07-26 Dilithium Networks Pty Ltd. Methods and system for fast session establishment between equipment using h.324 and related telecommunications protocols
US7680143B2 (en) 2002-12-12 2010-03-16 Rpx Corporation Methods and apparatus for combining session acceleration techniques for media oriented negotiation acceleration
US20070266161A1 (en) * 2002-12-12 2007-11-15 Dilithium Networks Pty Ltd. Methods and system for fast session establishment between equipment using h.324 and related telecommunications protocols
US7236476B2 (en) 2003-10-02 2007-06-26 International Business Machines Corporation mSCTP based handover of a mobile device between non-intersecting networks
US20070275760A1 (en) * 2004-05-05 2007-11-29 Telefonaktiebolaget Lm Ericsson (Publ) Hdspa Flow Control, Control Frames Rtt Measurement
US20050249123A1 (en) * 2004-05-10 2005-11-10 Finn Norman W System and method for detecting link failures
US7983173B2 (en) 2004-05-10 2011-07-19 Cisco Technology, Inc. System and method for detecting link failures
US8125910B2 (en) * 2004-06-25 2012-02-28 Nec Corporation Communication system
US20050286416A1 (en) * 2004-06-25 2005-12-29 Nec Corporation Communication system
US7710861B2 (en) 2005-02-28 2010-05-04 Samsung Electronics Co., Ltd. Network system and method for link failure recovery
EP1696646A1 (en) * 2005-02-28 2006-08-30 Samsung Electronics Co.,Ltd. Method and system for link failure recovery
US20060193311A1 (en) * 2005-02-28 2006-08-31 Si-Baek Kim Network system and method for link failure recovery
US7577098B2 (en) 2005-03-15 2009-08-18 Fujitsu Limited Device and method for network monitoring
US20060209699A1 (en) * 2005-03-15 2006-09-21 Fujitsu Limited Device and method for network monitoring
EP1703671A1 (en) * 2005-03-15 2006-09-20 Fujitsu Limited Device and method for network monitoring
US8132018B2 (en) * 2005-06-30 2012-03-06 Intel Corporation Techniques for password attack mitigation
US20070005985A1 (en) * 2005-06-30 2007-01-04 Avigdor Eldar Techniques for password attack mitigation
CN1921417B (en) * 2005-08-25 2010-10-06 华为技术有限公司 Method for reporting conversation state of two-way transfer detection
US20070230358A1 (en) * 2006-03-31 2007-10-04 Ashok Narayanan Facilitating application synchronization with a reservation protocol at a sender without application receiver participation
US7702816B2 (en) 2006-03-31 2010-04-20 Cisco Technology, Inc. Facilitating application synchronization with a reservation protocol at a sender without application receiver participation
US7693055B2 (en) 2006-12-22 2010-04-06 Cisco Technology, Inc. Optimization of distributed tunnel rerouting in a computer network with intermediate node feedback
US20080151933A1 (en) * 2006-12-22 2008-06-26 Jean-Philippe Vasseur Optimization of distributed tunnel rerouting in a computer network with intermediate node feedback
US8767532B2 (en) 2006-12-22 2014-07-01 Cisco Technology, Inc. Optimization of distributed tunnel rerouting in a computer network with path computation at an intermediate node
TWI561031B (en) * 2014-12-04 2016-12-01 Inventec Corp Method of determining status of serving node
US20160291697A1 (en) * 2015-03-30 2016-10-06 Google Inc. Methods and Systems for Gesture Based Switch for Machine Control
US9965042B2 (en) * 2015-03-30 2018-05-08 X Development Llc Methods and systems for gesture based switch for machine control
US11263047B2 (en) * 2018-02-15 2022-03-01 Sap Se Metadata management for multi-core resource manager
CN112771818A (en) * 2018-10-05 2021-05-07 高通股份有限公司 System and method for fast round trip time measurement distribution

Also Published As

Publication number Publication date
US20050088966A9 (en) 2005-04-28
US7027389B2 (en) 2006-04-11

Similar Documents

Publication Publication Date Title
US7027389B2 (en) Fast failure detection using RTT time considerations on a non-retransmit medium
Samaraweera Non-congestion packet loss detection for TCP error recovery using wireless links
US7200111B2 (en) Method for improving TCP performance over wireless links
Bohacek et al. A new TCP for persistent packet reordering
US7756032B2 (en) Method and apparatus for communicating data within measurement traffic
JP4778453B2 (en) Communication terminal, congestion control method, and congestion control program
US7876678B2 (en) Congestion control for signalling transport protocols
US7672241B2 (en) Link-aware transmission control protocol
US20030161321A1 (en) Method and apparatus for characterizing the quality of a network path
US7925775B2 (en) TCP congestion control based on bandwidth estimation techniques
WO2002033896A2 (en) Method and apparatus for characterizing the quality of a network path
KR20040015009A (en) Method for reliable and efficient support of congestion control in nack-based protocols
KR20040027176A (en) congestion control method over wireless link
Firoiu et al. A framework for practical performance evaluation and traffic engineering in IP networks
CN101141393A (en) Communication terminal, communication control method, and communication control program
Zou et al. Improving TCP robustness over asymmetry with reordering marking and coding in data centers
US6134221A (en) Method for evaluating a communication link between a first and a second communication site
WO2002033893A2 (en) Method and apparatus for communicating data within measurement traffic
Geva et al. QoSoDoS: If you can't beat them, join them!
Weinrank et al. RACK for SCTP
Biaz et al. Performance of tcp congestion predictors as loss predictors
Mondal et al. Upgrading mice to elephants: effects and end-point solutions
KR101933175B1 (en) Mediatioin appratus mediating communication betwwen server and client
Guduru et al. Overload control in SIP signalling networks with redirect servers
Prasanthi et al. A new TCP mechanism for reducing retransmission timeouts over multi-hop wireless networks

Legal Events

Date Code Title Description
AS Assignment

Owner name: CISCO TECHNOLOGY, INC., CALIFORNIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:STEWART, RANDALL R.;REEL/FRAME:011553/0879

Effective date: 20001219

STCF Information on status: patent grant

Free format text: PATENTED CASE

FPAY Fee payment

Year of fee payment: 4

FPAY Fee payment

Year of fee payment: 8

MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 12TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1553)

Year of fee payment: 12