On Sun, 30 Dec 2007, Ilpo Järvinen wrote:
> I guess the non-minimum TSO delays are only significant in case there was
> something unexpectional happening and in such case we definately want to
> have some measurements taken.
Broadly speaking, delay-based schemes need as much information about t
Hi,
On Sat, 29 Dec 2007, David Miller wrote:
> Never mind about making the relative patch, I didn't want to have
> to wait for you to send me that and have it block my merge of
> fixes with Linus this evening.
Ah, sorry for the inconvenience. I didn't realise you had merged it yet.
> The follo
which (where
delayed acking is in use) should probably be 1 if the alarm went off or
greater if the ACK was triggered by a packet.
Signed-off-by: Gavin McCullagh <[EMAIL PROTECTED]>
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 889c893..cbba288 100644
--- a/net/ipv4/tcp_input
Hi,
On Fri, 21 Dec 2007, Ilpo Järvinen wrote:
> > I need to re-read properly, but I think the same problem affects the
> > microsecond 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_
need to re-read properly, but I think the same problem affects the
microsecond 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
Sig
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
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
>
ilable 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,
ned-off-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_
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 re
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 fr
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 192.168.3
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
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 int
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 o
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_
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_
17 matches
Mail list logo
