1

Consider a client application that will establish a connection to server when it detects a electricity disruption event (though physical sensors tapped into the electricity system). The said electricity disruption could also cause some remote network equipment to persistently fail, which lays somewhere in the SYN packet's path, causing the packet to silently lost. The scenario assumes an alternative path exist between client and server, such that the re-transmission(s) of SYN packet can eventually reach the server. However, the normal fast re-transmission algorithm cannot help this situation because the round-trip-time estimator is yet to converge, instead, an rather long initial re-transmission timeout (RTO) is used (typically 3 sec).

The question is: how to achieve faster re-transmission? Of course the trivial solution is to reduce the initial RTO, but without prior knowledge on the RTT, setting an arbitrarily small value is not optimal and potentially leads to unnecessary re-transmissions.

Another question is: Is it necessary to take into account the routing protocol, since it takes time for routing tables to converge to the new topology after link failure.

| improve this question | |
  • 1
    Your scenario is confusing. When would a client application ever detect "a [sic] electricity disruption event?" It may be that the NIC in a client could detect that, but it would not be passed up to the application. Even if it could be passed to the application, shouldn't the application know immediately that a re-transmission was in order? Do you mean a disruption or a total link failure? Is it the client link, or one somewhere else in the path? If the client link fails, the client is down unless it has a secondary NIC. – Ron Maupin♦ Feb 29 '16 at 15:31
  • @Ron Maupin Sorry for the confusion. 1) the client application has access to physical sensors (say, a voltmeter) tapped into the electricity system, hence the ability to detect electricity disruption. 2) the said electricity disruption could cause some network equipment to persistently fail, which lays somewhere in the SYN packet's path, causing the packet lost. 3) the scenario assumes an alternative path exist between client and server, such that the re-transmission(s) of SYN packet can eventually reach the server, after a rather long timeout period (depending on the initial RTO). – 314314314 Feb 29 '16 at 16:46
  • You should edit your question to include the information. If the application knows that a link in the path is down, it should be designed such that it immediately retries to make the connection it knows may have been lost. – Ron Maupin♦ Feb 29 '16 at 16:50
  • @Ron Maupin Thank you for the advice, question edited. Is there any network protocol that can be used to inform the client application that a remote link in the path is down? – 314314314 Feb 29 '16 at 17:06
  • The sensor alert should tell the application. Other than that, you rely on TCP. Some routers support BFD for fast link-state detection, but that is on a link, not across a path. Your scenario seem very contrived, and I'm not sure it really fits this site. You, or anyone, can propose a new protocol to the IETF for consideration. If there is a compelling need it could become an RFC. Unfortunately, new protocol support in existing, installed is problematic. There are very, very smart people who do nothing but think about this stuff, all day, every day. – Ron Maupin♦ Feb 29 '16 at 17:13
0

Absent a direct sensor, such as you have proposed, the fastest way a link-down is communicated across the network is via the routing protocol.

Your client could be running a routing protocol with the routers (often not allowed in networks) in the network to have the latest routing information, Unfortunately, that information doesn't get sent up to the application, or any layer above layer-3. It would take a custom modification of the routing protocol to create such a connection, and it would likely be tied to a specific application.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.