From: Ilpo_Järvinen [EMAIL PROTECTED]
Date: Wed, 5 Sep 2007 22:04:11 +0300 (EEST)
Main obstacle to FRTO use is its deployment as it has to be on the
sender side where as wireless link is often the receiver's access
link but if one can tune tcp_min_rto (or equal) on the sender side,
one could
On Wed, 29 Aug 2007, David Miller wrote:
From: Rick Jones [EMAIL PROTECTED]
Date: Wed, 29 Aug 2007 16:06:27 -0700
I belive the biggest component comes from link-layer retransmissions.
There can also be some short outtages thanks to signal blocking,
tunnels, people with big hats and
John Heffner wrote:
Rick Jones wrote:
Like I said the consumers of this are a triffle well, anxious :)
Just curious, did you or this customer try with F-RTO enabled? Or is
this case you're dealing with truly hopeless?
F-RTO was mentioned to the customer and I'm awaiting their response
David Miller wrote:
From: Rick Jones [EMAIL PROTECTED]
Date: Thu, 30 Aug 2007 18:07:13 -0700
Anyhow, I'll try grubbing around the source code (already doing that to
see about writing a pet tcp cong module) but if pointers to the likely
relevant files were available I could try to help
From: Rick Jones [EMAIL PROTECTED]
Date: Fri, 31 Aug 2007 11:11:37 -0700
At the risk of showing my ignorance (what me worry about that?-) I
presume this is then an interface expecting to take-in jiffies? That
means the user has to know the value of HZ which can be (IIRC) one of
three
I managed to find iproute2 sources (they were debian lenny/testing
2.6.20-1) and applied the patch, and figured-out how to add a host route
back to one of my systems. I then did a change to set rto_min to 300.
I started a tcpdump and then a netperf, and then forces some
retransmissions the
From: Rick Jones [EMAIL PROTECTED]
Date: Fri, 31 Aug 2007 13:59:50 -0700
ip is at tcp_rto_min+0x20/0x40
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 1ee7212..bbad2cd 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -560,7 +560,7 @@ static u32 tcp_rto_min(struct
David Miller wrote:
From: Rick Jones [EMAIL PROTECTED]
Date: Fri, 31 Aug 2007 13:59:50 -0700
ip is at tcp_rto_min+0x20/0x40
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 1ee7212..bbad2cd 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -560,7 +560,7 @@
From: Rick Jones [EMAIL PROTECTED]
Date: Fri, 31 Aug 2007 15:20:52 -0700
I'm going to go ahead and take a look at input vs output units and
differences between those with rto_min vs rtt.
You better because that's one of the last non-trivial emails you'll
get for me over the next few days
Krishna Kumar2 wrote:
Hi Rick,
From: Rick Jones [EMAIL PROTECTED]
The trace I've been sent shows clean RTTs ranging from ~200
milliseconds
to ~7000 milliseconds.
Thanks for the info.
It's pretty easy to generate examples where we might have some sockets
talking over interfaces on
Enable configuration of the minimum TCP Retransmission Timeout via
a new sysctl tcp_rto_min to help those who's networks (eg cellular)
have quite variable RTTs avoid spurrious RTOs.
Signed-off-by: Rick Jones [EMAIL PROTECTED]
Signed-off-by: Lamont Jones [EMAIL PROTECTED]
---
diff -r 06d7322848a3
From: Rick Jones [EMAIL PROTECTED]
Date: Thu, 30 Aug 2007 17:09:04 -0700 (PDT)
Enable configuration of the minimum TCP Retransmission Timeout via
a new sysctl tcp_rto_min to help those who's networks (eg cellular)
have quite variable RTTs avoid spurrious RTOs.
Signed-off-by: Rick Jones
David Miller wrote:
From: Rick Jones [EMAIL PROTECTED]
Date: Thu, 30 Aug 2007 17:09:04 -0700 (PDT)
Enable configuration of the minimum TCP Retransmission Timeout via
a new sysctl tcp_rto_min to help those who's networks (eg cellular)
have quite variable RTTs avoid spurrious RTOs.
Rick Jones wrote:
Like I said the consumers of this are a triffle well,
anxious :)
Just curious, did you or this customer try with F-RTO enabled? Or is
this case you're dealing with truly hopeless?
-John
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a
From: Rick Jones [EMAIL PROTECTED]
Date: Thu, 30 Aug 2007 18:07:13 -0700
Anyhow, I'll try grubbing around the source code (already doing that to
see about writing a pet tcp cong module) but if pointers to the likely
relevant files were available I could try to help thrash-out the routing
Rick Jones a écrit :
Enable configuration of the minimum TCP Retransmission Timeout via
a new sysctl tcp_rto_min to help those who's networks (eg cellular)
have quite variable RTTs avoid spurrious RTOs.
Signed-off-by: Rick Jones [EMAIL PROTECTED]
Signed-off-by: Lamont Jones [EMAIL PROTECTED]
On 8/30/07, Rick Jones [EMAIL PROTECTED] wrote:
Enable configuration of the minimum TCP Retransmission Timeout via
a new sysctl tcp_rto_min to help those who's networks (eg cellular)
have quite variable RTTs avoid spurrious RTOs.
Signed-off-by: Rick Jones [EMAIL PROTECTED]
Signed-off-by:
From: Ian McDonald [EMAIL PROTECTED]
Date: Thu, 30 Aug 2007 09:32:38 +1200
So I'm suspecting that the default should be changed to 1000 to match
the RFC which would solve this issue. I note that the RFC is a SHOULD
rather than a MUST. I had a quick look around and not sure why Linux
overrides
Ian McDonald wrote:
Hmmm... RFC2988 says:
(2.4) Whenever RTO is computed, if it is less than 1 second then the
RTO SHOULD be rounded up to 1 second.
Traditionally, TCP implementations use coarse grain clocks to
measure the RTT and trigger the RTO, which imposes a
On 8/30/07, David Miller [EMAIL PROTECTED] wrote:
From: Ian McDonald [EMAIL PROTECTED]
Date: Thu, 30 Aug 2007 09:32:38 +1200
So I'm suspecting that the default should be changed to 1000 to match
the RFC which would solve this issue. I note that the RFC is a SHOULD
rather than a MUST. I
I am sure you can use CTL_UNNUMBERED instead of adding yet another
sysctl value, as advised in include/linux/sysctl.h
** For new interfaces unless you really need a binary number
** please use CTL_UNNUMBERED.
fair enough. i was just repeating past behaviour :)
rick jones
-
To
On Wed, 29 Aug 2007 14:46:56 -0700 (PDT)
David Miller [EMAIL PROTECTED] wrote:
From: Ian McDonald [EMAIL PROTECTED]
Date: Thu, 30 Aug 2007 09:32:38 +1200
So I'm suspecting that the default should be changed to 1000 to match
the RFC which would solve this issue. I note that the RFC is a
From: Rick Jones [EMAIL PROTECTED]
Date: Wed, 29 Aug 2007 15:09:58 -0700
If nothing else, 200 ms is a principle of least surprise thing since
that is the current value (in MS) for TCP_RTO_MIN.
And Solaris and MacOS-X and...
In fact this is a great example why we don't treat RFCs as
From: Ian McDonald [EMAIL PROTECTED]
Date: Thu, 30 Aug 2007 10:10:37 +1200
Understand what you are saying. That is why I questioned as 200 msecs
makes no sense on a LAN with 1 msec RTT. So if the current is
ridiculous and 1000 is even more so, why do we use? Just because that
is how TCP is
From: Stephen Hemminger [EMAIL PROTECTED]
Date: Wed, 29 Aug 2007 15:13:01 -0700
There was some discussion about implementing TCP NCR (RFC4653)
and Narasimha Reddy said he might have something that could be used.
Although this looks interesting, I'm unsure it will help these
cell folks.
David Miller wrote:
From: Ian McDonald [EMAIL PROTECTED]
Date: Thu, 30 Aug 2007 09:32:38 +1200
So I'm suspecting that the default should be changed to 1000 to match
the RFC which would solve this issue. I note that the RFC is a SHOULD
rather than a MUST. I had a quick look around and not sure
From what I've seen thusfar, the issue isn't so much actual loss, but
very variable RTTs leading to spurrious RTOs.
rick jones
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On 8/30/07, David Miller [EMAIL PROTECTED] wrote:
In fact this is a great example why we don't treat RFCs as dictations
from the gods. They are often wrong, impractical, or full of fatal
flaws.
Correct - they often have flaws in them, just like all documents. If
that is the case we should try
From: Rick Jones [EMAIL PROTECTED]
Date: Wed, 29 Aug 2007 15:29:03 -0700
David Miller wrote:
None of the research folks want to commit to saying a lower value is
OK, even though it's quite clear that on a local 10 gigabit link a
minimum value of even 200 is absolutely and positively
From: Ian McDonald [EMAIL PROTECTED]
Date: Thu, 30 Aug 2007 10:33:32 +1200
Correct - they often have flaws in them, just like all documents. If
that is the case we should try and get the RFCs fixed.
In many cases it is not the wording, but the actual concept or idea
the RFC itself is
David Miller wrote:
From: Rick Jones [EMAIL PROTECTED]
Date: Wed, 29 Aug 2007 15:29:03 -0700
David Miller wrote:
None of the research folks want to commit to saying a lower value is
OK, even though it's quite clear that on a local 10 gigabit link a
minimum value of even 200 is absolutely and
On Wed, 29 Aug 2007 15:28:12 -0700 (PDT)
David Miller [EMAIL PROTECTED] wrote:
From: Stephen Hemminger [EMAIL PROTECTED]
Date: Wed, 29 Aug 2007 15:13:01 -0700
There was some discussion about implementing TCP NCR (RFC4653)
and Narasimha Reddy said he might have something that could be
John Heffner wrote:
What exactly causes such a huge delay? What is the TCP measured RTO
in these circumstances where spurious RTOs happen and a 3 second
minimum RTO makes things better?
I haven't done a lot of work on wireless myself, but my understanding is
that one of the biggest problems
Stephen Hemminger wrote:
On Wed, 29 Aug 2007 15:28:12 -0700 (PDT)
David Miller [EMAIL PROTECTED] wrote:
And reading NCR some more, we already have something similar in the
form of Alexey's reordering detection, in fact it handles exactly the
case NCR supposedly deals with. We do not trigger
From: John Heffner [EMAIL PROTECTED]
Date: Wed, 29 Aug 2007 18:58:12 -0400
I don't believe this was the case. NCR is substantially different, and
came out of work at Texas AM. The original (only) implementation was
in Linux IIRC. Its goal was to do better. Their papers say it does.
It
On Wed, Aug 29, 2007 at 03:35:03PM -0700, David Miller wrote:
From: Rick Jones [EMAIL PROTECTED]
Date: Wed, 29 Aug 2007 15:29:03 -0700
David Miller wrote:
None of the research folks want to commit to saying a lower value is
OK, even though it's quite clear that on a local 10 gigabit
All of this seems to suggest that the RTO calculation is wrong.
That is a possiblity. Or at least could be enhanced.
It seems that packets in this network can be delayed several orders of
magnitude longer than the usual round trip as measured by TCP.
What exactly causes such a huge delay?
From: Rick Jones [EMAIL PROTECTED]
Date: Wed, 29 Aug 2007 16:06:27 -0700
I belive the biggest component comes from link-layer retransmissions.
There can also be some short outtages thanks to signal blocking,
tunnels, people with big hats and whatnot that the link-layer
retransmissions are
David Miller wrote:
From: Rick Jones [EMAIL PROTECTED]
The trace I've been sent shows clean RTTs ranging from ~200 milliseconds
to ~7000 milliseconds.
Thanks for the info.
It's pretty easy to generate examples where we might have some sockets
talking over interfaces on such a network and
David Miller wrote:
From: Rick Jones [EMAIL PROTECTED]
Date: Wed, 29 Aug 2007 16:06:27 -0700
I belive the biggest component comes from link-layer retransmissions.
There can also be some short outtages thanks to signal blocking,
tunnels, people with big hats and whatnot that the link-layer
Hi Rick,
From: Rick Jones [EMAIL PROTECTED]
The trace I've been sent shows clean RTTs ranging from ~200
milliseconds
to ~7000 milliseconds.
Thanks for the info.
It's pretty easy to generate examples where we might have some sockets
talking over interfaces on such a network and
41 matches
Mail list logo
