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
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 h
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 w
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 @@ stat
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(struc
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 old
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
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 thras
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
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 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
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.
Signed-o
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 Jo
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 06d7322
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 s
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 s
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
r
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 o
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
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?
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 1
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 l
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 A&M. The original (only) implementation was
> in Linux IIRC. Its goal was to do better. Their papers say it does.
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 i
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 cou
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
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 desc
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 positivel
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 http://vger.kernel.org/majordom
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 shoul
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 s
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. Act
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
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 dict
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
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 unsubscribe
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 tha
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 la
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
> ov
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-
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
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 1559df8
42 matches
Mail list logo
