Re: the TCP MSS resource exhaustion commit

From: Andre Oppermann (andre_at_freebsd.org)
Date: 01/09/04

  • Next message: Bernd Walter: "Re: the TCP MSS resource exhaustion commit" 
    Date: Fri, 09 Jan 2004 16:12:34 +0100
To: ticso@cicely.de

    Bernd Walter wrote:
    >
    > On Fri, Jan 09, 2004 at 03:23:53PM +0100, Andre Oppermann wrote:
    > > Thorsten Greiner wrote:
    > > >
    > > > * Andre Oppermann <andre@freebsd.org> [2004-01-09 11:34]:
    > > > > You can simply increase net.inet.tcp.minmssoverload to any
    > > > > higher value. I suggest 2,000 as next step. If set it to
    > > > > 0 the check will be disabled entirely.
    > > >
    > > > Setting net.inet.tcp.minmssoverload to 4000 fixed my problem(s).
    > >
    > > Ok, that's an important information.
    > >
    > > > > This makes we wonder why the Oracle database server is sending
    > > > > so many small packets. Is your JBoss application doing connection
    > > > > pooling (eg. multiplexing multiple SQL sessions over one tcp
    > > > > session)?
    > > >
    > > > It performs connection pooling on the application layer, i.e. it
    > > > opens several connections and pools them to avoid reopening them. As
    > > > far as I understand each Oracle connection is associated with a TCP
    > > > connection - there is no pooling on the TCP level.
    > >
    > > Ok. Might it be that Oracle is setting the TCP_NODELAY option on
    > > its sending socket? I guess it is difficult to find that out...
    > >
    > > > While I have read your commit message thoroughly I am not sure I
    > > > have understood the consequences of the new mechanism. Will the
    > > > exchange of many small packets trigger a connection drop?
    > >
    > > Yes. Once you receive more than 1,000 tcp packets per second whose
    > > average size is below the net.inet.tcp.minmss value, then it will
    > > assume a malicious DoS attack. It appears that the default value
    > > of 1,000 is too low.
    >
    > What about ACKs from a simple TCP device such as a microcontroller?
    > Or slip connects with MTU of 300?
    > Many smaller controllers don't have enough RAM to do delayed acks
    > or run at MTU 1500.
    > Even a hand full public webservers are running on such systems!
    > I'm a bit worried about having such a feature enabled by default to
    > break TCP communication with specialised hardware.

    If the microcontroller doesn't have enough RAM to do delayed ACKs
    I highly doubt that it is capable to generate 1,000 packet per
    second.

    The detection logic only applies to TCP packets containing payload,
    not to ACKs or anything else. 

    -- 
Andre
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
  • Next message: Bernd Walter: "Re: the TCP MSS resource exhaustion commit"

    Relevant Pages

    • Re: the TCP MSS resource exhaustion commit
      ... >> What about ACKs from a simple TCP device such as a microcontroller? ... > If the microcontroller doesn't have enough RAM to do delayed ACKs ... But what I do in one application is modbus protocol, which has a packet ...
      (freebsd-current)
    • Re: [patch 1/4] - Potential performance bottleneck for Linxu TCP
      ... getting a disproportionate share of cycles due to softirq processing! ... unfair advantage. ... other non disk I/O tasks are running, yet for TCP that's seemingly OK ... Not looking at input TCP packets enough to send out the ACKs is the ...
      (Linux-Kernel)
    • Chinese HTTP ACKs
      ... A less random target selection ... is not supposed to exchange TCP packets with the Internet. ... these naked ACKs sail right on past.... ... legitimate session already in progress.) ...
      (Incidents)
    • Re: 2.6.19-rc1: Volanomark slowdown
      ... Send ACKs each 2nd received segment ... reduced Volanomark benchmark throughput by 10%. ... short message on its TCP ... This patch increases the number of ACKs ...
      (Linux-Kernel)
    • TCP Delayed Ack implementation in 6.1
      ... I have a question about the TCP delayed ack implementation in FreeBSD 6.1 ... According to specs, if delayed acks are enabled, the receiver delays transmitting acks for the delack time period or acks every other incoming packet. ...
      (freebsd-net)