All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ben Greear <greearb@candelatech.com>
To: "David S. Miller" <davem@redhat.com>
Cc: john@grabjohn.com, cfriesen@nortelnetworks.com, ahu@ds9a.nl,
	linux-kernel@vger.kernel.org
Subject: Re: problems achieving decent throughput with latency.
Date: Tue, 04 Feb 2003 00:42:02 -0800	[thread overview]
Message-ID: <3E3F7CDA.9020701@candelatech.com> (raw)
In-Reply-To: <20030203.233948.53493107.davem@redhat.com>

David S. Miller wrote:
>    From: Ben Greear <greearb@candelatech.com>
>    Date: Mon, 03 Feb 2003 23:50:05 -0800
>    
>    Why would it use the maximum socket for a connection with low to
>    no acks, ie low to no throughput?
> 
> You open up the congestion window by ACK'ing a few windows
> worth of data, then you stop ACK'ing.

I think I understand, but on my system it seem to take 5-8 seconds for
the bandwidth to get up to ~20Mbps (with my larger buffer settings mentioned
earlier).  This is with 25ms latency. With the default settings I can run about
8Mbps, so it would appear to me that only 3x the current default buffer settings
should get a window size enough to go ~20Mbps at 25ms latency.

Am I correct that if I have 10k clients doing their worst tricks, and
3 * (80k, my default according to the kernel) == 240k, then I have at most
2.4MB denial of service?  Assuming 60k clients, that is only about 15MB
of DoS?  If true, that is a fairly small time DoS considering the RAM available
on today's machines.

You claim for a very large N that the denial of service can happen.  I
am just trying to understand the upper bound of N, and thus the upperbound
of the memory consumption assuming each connection is using it's maximum
buffer size.

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>       <Ben_Greear AT excite.com>
President of Candela Technologies Inc      http://www.candelatech.com
ScryMUD:  http://scry.wanfear.com     http://scry.wanfear.com/~greear



  reply	other threads:[~2003-02-04  8:32 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-02-02  7:38 problems achieving decent throughput with latency Ben Greear
2003-02-02 11:48 ` bert hubert
2003-02-03  5:14   ` David S. Miller
2003-02-03 15:37     ` Chris Friesen
2003-02-03 16:11       ` John Bradford
2003-02-03 16:19         ` bert hubert
2003-02-03 18:03         ` Ben Greear
2003-02-03 19:18           ` Eric Weigle
2003-02-04  5:19           ` David S. Miller
2003-02-04  7:50             ` Ben Greear
2003-02-04  7:39               ` David S. Miller
2003-02-04  8:42                 ` Ben Greear [this message]
2003-02-04  8:41                   ` David S. Miller
2003-02-04  8:51                   ` Ben Greear
  -- strict thread matches above, loose matches on Subject: below --
2003-02-01 22:13 Ben Greear

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3E3F7CDA.9020701@candelatech.com \
    --to=greearb@candelatech.com \
    --cc=ahu@ds9a.nl \
    --cc=cfriesen@nortelnetworks.com \
    --cc=davem@redhat.com \
    --cc=john@grabjohn.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.