TCP has its own keep alives set.... , did you mean for an explanatory protocol which could set and capture all TCP events live?
And about knowing another machines TCP keep alives then we could test it or check it on an analyzer which captures the packet & datagram info. http://cisnetsolutions.yolasite.com my best regards; Chalikar, Sanjay; +91 9920291497; [email protected] 2010/6/26 <[email protected]> > If you have received this digest without all the individual message > attachments you will need to update your digest options in your list > subscription. To do so, go to > > https://www.ietf.org/mailman/listinfo/ietf > > Click the 'Unsubscribe or edit options' button, log in, and set "Get > MIME or Plain Text Digests?" to MIME. You can set this option > globally for all the list digests you receive at this point. > > > > Send Ietf mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/ietf > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Ietf digest..." > > Today's Topics: > > 1. Re: Protocol for TCP heartbeats? (Martin Sustrik) > 2. Re: Protocol for TCP heartbeats? (Bob Braden) > 3. Re: Protocol for TCP heartbeats? ( R?mi Denis-Courmont) > 4. Re: Protocol for TCP heartbeats? (Martin Sustrik) > 5. Re: Protocol for TCP heartbeats? (Martin Sustrik) > > > ---------- Forwarded message ---------- > From: Martin Sustrik <[email protected]> > To: "Rémi Denis-Courmont" <[email protected]> > Date: Fri, 25 Jun 2010 20:10:45 +0200 > Subject: Re: Protocol for TCP heartbeats? > Rémi Denis-Courmont wrote: > >> On Friday 25 June 2010 20:46:45 ext Martin Sustrik, you wrote: >> >>> I haven't been able to find it but maybe someone knows here: Have there >>> been a protocol defined for checking whether TCP peer is alive or not? >>> (I mean one that plays well with networks with various latencies and >>> throughputs and won't congest the network even if used on a wide scale.) >>> >> >> On most OSes, you can enable TCP keep-alives. Then your TCP socket will >> return a time out error if the other end "dies". So yes, there is a way to >> do this at the TCP protocol level. >> >> Unfortunately, there is no standard API to use and configure this feature >> of TCP. On Linux, you can adjust all parameter on a per-socket basis (refer >> to >> 'man 7 tcp' and look for TCP_KEEP for details) though. >> >> There is also no programmatic way to know that the other peer is using >> keep- >> alives or not (should you need to know that anyway). >> > > This is a dumb keepalive option (send heartbeat each N seconds, N being > defined by user), right? > > What I had in mind whether there ever been an attempt to define dynamic > keepalive algorithm that adjusts keepalive intervals according to the > observed throughput and roundtrip latency figures (dynamic in the same way > as CC dynamically adjusts throughput). > > Any ideas? > Martin > > > > > > > ---------- Forwarded message ---------- > From: Bob Braden <[email protected]> > To: [email protected] > Date: Fri, 25 Jun 2010 11:13:46 -0700 > Subject: Re: Protocol for TCP heartbeats? > I trust you are familiar with section 4.2.3.6 of RFC 1122. > > Bob Braden > > > On 6/25/2010 10:46 AM, Martin Sustrik wrote: > >> Hi all, >> >> I haven't been able to find it but maybe someone knows here: Have there >> been a protocol defined for checking whether TCP peer is alive or not? >> (I mean one that plays well with networks with various latencies and >> throughputs and won't congest the network even if used on a wide scale.) >> >> Thanks in advance! >> Martin >> _______________________________________________ >> Ietf mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/ietf >> > > > > ---------- Forwarded message ---------- > From: "Rémi Denis-Courmont" <[email protected]> > To: ext Martin Sustrik <[email protected]> > Date: Fri, 25 Jun 2010 21:24:18 +0300 > Subject: Re: Protocol for TCP heartbeats? > On Friday 25 June 2010 21:10:45 ext Martin Sustrik, you wrote: > > Rémi Denis-Courmont wrote: > > > On Friday 25 June 2010 20:46:45 ext Martin Sustrik, you wrote: > > >> I haven't been able to find it but maybe someone knows here: Have > there > > >> been a protocol defined for checking whether TCP peer is alive or not? > > >> (I mean one that plays well with networks with various latencies and > > >> throughputs and won't congest the network even if used on a wide > scale.) > > > > > > On most OSes, you can enable TCP keep-alives. Then your TCP socket will > > > return a time out error if the other end "dies". So yes, there is a way > > > to do this at the TCP protocol level. > > > > > > Unfortunately, there is no standard API to use and configure this > feature > > > of TCP. On Linux, you can adjust all parameter on a per-socket basis > > > (refer to 'man 7 tcp' and look for TCP_KEEP for details) though. > > > > > > There is also no programmatic way to know that the other peer is using > > > keep- alives or not (should you need to know that anyway). > > > > This is a dumb keepalive option (send heartbeat each N seconds, N being > > defined by user), right? > > > > What I had in mind whether there ever been an attempt to define dynamic > > keepalive algorithm that adjusts keepalive intervals according to the > > observed throughput and roundtrip latency figures (dynamic in the same > > way as CC dynamically adjusts throughput). > > > > Any ideas? > > You can probably change the values. But I don't really see the statistical > correlation of throughput and round trip time to the probability that the > peer > will fail within a certain time interval. > > I mean, you can probably establish a weak correlation between them, or at > least between the variation of the bandwidth and RTT to the probability of > failure. But I somehow doubt it will be sufficiently strong a correlation > that > that a very clever algorithm would be significantly better than a plain > dumb > ping-pong at constant or exponential backoff interval. > > -- > Rémi Denis-Courmont > Nokia Devices R&D, Maemo Software, Helsinki > > > > ---------- Forwarded message ---------- > From: Martin Sustrik <[email protected]> > To: Bob Braden <[email protected]> > Date: Fri, 25 Jun 2010 20:32:15 +0200 > Subject: Re: Protocol for TCP heartbeats? > Bob Braden wrote: > >> I trust you are familiar with section 4.2.3.6 of RFC 1122. >> > > Yes. I am aware of it. > > I was just interested in whether the behaviour have been defined for those > who need early failure detection (systems with failover capabilities) and > are willing to pay for the additional bandwidth used (financial sector). > > The wide range of proprietary implementations of the mechanism suggest that > it wasn't but I wanted to make sure about it. > > Martin > > > > > ---------- Forwarded message ---------- > From: Martin Sustrik <[email protected]> > To: "Rémi Denis-Courmont" <[email protected]> > Date: Fri, 25 Jun 2010 20:37:19 +0200 > Subject: Re: Protocol for TCP heartbeats? > Rémi Denis-Courmont wrote: > > What I had in mind whether there ever been an attempt to define dynamic >>> keepalive algorithm that adjusts keepalive intervals according to the >>> observed throughput and roundtrip latency figures (dynamic in the same >>> way as CC dynamically adjusts throughput). >>> >>> Any ideas? >>> >> >> You can probably change the values. But I don't really see the statistical >> correlation of throughput and round trip time to the probability that the >> peer will fail within a certain time interval. >> >> I mean, you can probably establish a weak correlation between them, or at >> least between the variation of the bandwidth and RTT to the probability of >> failure. But I somehow doubt it will be sufficiently strong a correlation >> that that a very clever algorithm would be significantly better than a plain >> dumb ping-pong at constant or exponential backoff interval. >> > > What I meant was that long timespan between consecutive packets can mean > either: > > 1. Sender is sending data sparsely. > 2. There's congestion on the network and packet loss causes decrease in > throughput. > > In both cases you want to increase the heartbeat interval as none of them > means the peer is dead. > > Dead peer or unreachable peer is rather identified by sharp decrease in > throughput -- actually no packets from the peer for unexpectedly long time. > > Martin > > > > > _______________________________________________ > Ietf mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ietf > >
_______________________________________________ Ietf mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf
