values where TCP_CONG_RTT_STAMP is set (used by vegas, veno,
yeah, illinois). I might follow up with another patch which changes the
behaviour where TCP_CONG_RTT_STAMP when I'm more sure of that.
Thanks,
Gavin
Signed-off-by: Gavin McCullagh [EMAIL PROTECTED]
diff --git a/net/ipv4/tcp_input.c b/net
Hi,
On Tue, 18 Dec 2007, Gavin McCullagh wrote:
The last attempt didn't take account of the situation where a timestamp
wasn't available and tcp_clean_rtx_queue() has to feed both the RTO and the
congestion avoidance. This updated patch stores both RTTs, making the
delayed one available
Hi,
On Wed, 19 Dec 2007, Ilpo Järvinen wrote:
Isn't it also much better this way in a case where ACK losses happened,
taking the longest RTT in that case is clearly questionable as it
may over-estimate considerably.
Quite so.
However, another thing to consider is the possibility of this
for
congestion control.
Signed-off-by: Gavin McCullagh [EMAIL PROTECTED]
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 889c893..6fb7989 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -2651,6 +2651,7 @@ static int tcp_clean_rtx_queue(struct sock *sk, s32
*seq_rtt_p
-by: Gavin McCullagh [EMAIL PROTECTED]
--- a/net/ipv4/tcp_input.c 2007-12-15 00:22:23.0 +
+++ b/net/ipv4/tcp_input.c 2007-12-17 13:35:16.0 +
@@ -2691,11 +2691,9 @@ static int tcp_clean_rtx_queue(struct so
(packets_acked 1
Hi,
thanks for the swift reply.
On Thu, 13 Dec 2007, David Miller wrote:
I'm trying to hack together something which will run through the
retransmit queue looking at the tcp headers.
The packets in the retransmit queue are headerless, the
header only gets added to clones of the
Hi,
I'm using linux v2.6.22.6 and tcp_probe with a couple of small
modifications[1].
Even with moderately large numbers of flows (16 on the one machine) and
increasingly as I monitor more flows than that, I get strange overflow
problems such as this one:
74.259589763 192.168.2.1 36988
Hi Sangtae,
On Tue, 13 Nov 2007, SANGTAE HA wrote:
This is fixed in the current version of tcp_probe by Stephen. Please
see the below.
You can copy the current version of tcp_probe to your kernel version
and it should work.
Many thanks, I'll give this a try,
Gavin
-
To unsubscribe from
Hi,
On Sat, 10 Feb 2007, Matthew Garrett wrote:
On Sat, Feb 10, 2007 at 06:55:50AM +0100, Michael Buesch wrote:
It's likely that old cards still work with v4 firmware, but we don't know
and
it has to be tested.
Care to do so?
I'll check the revision of my 4306, but I think it's
Hi,
[ moving this to netdev as requested ]
On Tue, 09 Jan 2007, Stephen Hemminger wrote:
Actually, this paper seems to be a zombified version of:
http://www.cs.ucsd.edu/~savage/papers/CCR99.pdf
Thanks. In fairness to them, the emphasis is slightly different, Savage et
al are more
Hi,
recently, a few of us came up with a novel (or so we thought) DoS attack
against TCP. We spent some time implementing and testing it and found it
to work worryingly well.
It turns out that we are not the first to come across this attack. Rob
Sherwood and colleagues in Maryland were a year
When using H-TCP with a single flow on a 500Mbit connection (or less
actually), alpha can exceed 65000, so alpha needs to be a u32.
Signed-off-by: Gavin McCullagh [EMAIL PROTECTED]
Signed-off-by: Doug Leith [EMAIL PROTECTED]
diff --git a/net/ipv4/tcp_htcp.c b/net/ipv4/tcp_htcp.c
index 6edfe5e
When using H-TCP with a single flow on a 500Mbit connection (or less
actually), alpha can exceed 65000, so alpha needs to be a u32.
Signed-off-by: Gavin McCullagh [EMAIL PROTECTED]
Signed-off-by: Doug Leith [EMAIL PROTECTED]
diff --git a/net/ipv4/tcp_htcp.c b/net/ipv4/tcp_htcp.c
index 6edfe5e
13 matches
Mail list logo
