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
ietf(_at_)ietf(_dot_)org
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
ietf-request(_at_)ietf(_dot_)org
You can reach the person managing the list at
ietf-owner(_at_)ietf(_dot_)org
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 <sustrik(_at_)250bpm(_dot_)com>
To: "Rémi Denis-Courmont" <remi(_dot_)denis-courmont(_at_)nokia(_dot_)com>
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 <braden(_at_)isi(_dot_)edu>
To: ietf(_at_)ietf(_dot_)org
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
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
---------- Forwarded message ----------
From: "Rémi Denis-Courmont" <remi(_dot_)denis-courmont(_at_)nokia(_dot_)com>
To: ext Martin Sustrik <sustrik(_at_)250bpm(_dot_)com>
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 <sustrik(_at_)250bpm(_dot_)com>
To: Bob Braden <braden(_at_)isi(_dot_)edu>
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 <sustrik(_at_)250bpm(_dot_)com>
To: "Rémi Denis-Courmont" <remi(_dot_)denis-courmont(_at_)nokia(_dot_)com>
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
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf