tcp hostcache and ip fastforward for review

From: Andre Oppermann (oppermann_at_pipeline.ch)
Date: 11/09/03

  • Next message: Jonathan Mini: "Re: tcp hostcache and ip fastforward for review" 
    Date: Sun, 09 Nov 2003 17:19:07 +0100
To: freebsd-current@freebsd.org, freebsd-net@freebsd.org

    Hello all,

    this patch contains three things (to be separated for committing):

     tcp_hostcache

      - removes protocol cloning from routing table (IPv4+6)
      - removes rtentry pointer from inpcb and in6pcb
      - removes ip route cache in ip_input.c (locking much easier)
      - removes most (tcp specific) metrics from rtentry metrics
      - adds a hostcache table which carries the metrics for tcp
      - works transparently for IPv4 and IPv6
      - is designed for concurrent access in SMP environments
      - significant reduction of routing table size (no cloning anymore)
      - eases many routing table locking situations in ip/tcp code

     ip_fastforward

      - removes ip_flow forwarding code
      - adds full direct process-to-completion IPv4 forwarding code
      - handles ip fragmentation incl. hw support (ip_flow did not)
      - supports ipfw and ipfilter (ip_flow did not)
      - supports divert and ipfw fwd (ip_flow did not)
      - drops anything it can't handle back to normal ip_input

     tcp bug fixes and MSS DoS attack prevention
      - fixes wrong goto in tcp_input.c which sends two RST packets
        instead of one
      - adds tcp_minmss sysctl which limits the lowest MSS we accept
        during TCP setup and path MTU discovery
      - adds tcp_minmssoverload which disconnects a TCP session if
        it receives too many (1000) packets per second whose average
        segement size is lower than tcp_minmss
      - DoS attack 1: send very low MSS in syn to remote host,
        request large data stream (file) and let other host produce
        maaaany small packets which consumes a lot of CPU
      - DoS attack 2: make MSS very low on local side of connection
        and send maaaany small packet to remote host. For every packet
        (eg. 2 bytes payload) a sowakeup is done to the listening
        process. Consumes a lot of CPU there.

    I'm looking for any comments, testing and bug reports (if any ;-).

    Hajimu-san, I'm looking especially for comments on whether my changes
    to IPv6 are correct wrt IPv6 concepts. (I hope they are).

    Hopefully these things can make it into -CURRENT before 5.2 release.
    Sam Leffler has indicated he is willing to commit it when there are
    no objections to the implementation and the code. I am fully committed
    to fix any bugs that might come up after it's in the tree.

    I am running my machines with these changes for a couple of weeks now
    without any problems. The attached patch obviously doesn't have that
    much exposure because I've had to update it all the time to track
    Sam's locking changes and UME's IPv6 updates.

    The patch is here (relative to -CURRENT as of 2003-11-09):

     http://www.nrg4u.com/freebsd/tcphostcache+ipfastforward-20031109.patch

    I'm grateful for everyone who tries out the patch and reports their
    success and/or other findings. 

    -- 
Andre
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
  • Next message: Jonathan Mini: "Re: tcp hostcache and ip fastforward for review"

    Relevant Pages

    • tcp hostcache and ip fastforward for review
      ... this patch contains three things (to be separated for committing): ... - removes ip route cache in ip_input.c (locking much easier) ... - removes most (tcp specific) metrics from rtentry metrics ... - fixes wrong goto in tcp_input.c which sends two RST packets ...
      (freebsd-current)
    • Re: UPD better than TCP in streaming video/audio ?
      ... > UDP gains speed over TCP because it carries no information that would ... it doesn't even know that packets were lost. ... which is perfect for UDP. ... > Finally, there's the possibility of multicast data - for instance, a live ...
      (microsoft.public.win32.programmer.networks)
    • Re: Simulating smaller MTU? ie sending small packets.
      ... This is due to the fact that TCP ... If you want smaller packets, ... >> set there as the MSS is announced by the receiver during the ... Yes, per connection. ...
      (comp.lang.perl.misc)
    • Re: NTP and Firewall help needed.
      ... >port 123 for udp and tcp. ... Also the idea of combining rules for packets arriving at the local machine ... ACCEPT any and all traffic coming from the localhost interface ...
      (comp.os.linux.setup)
    • Re: 6.x, 4.x ipfw/dummynet pf/altq - network performance issues
      ... I'll be able to run some more basic tests tomorrow to see some results, but want to wrap my head around what's actually logically meant to be happening based on adjustments, etc. [I suspect this'll do nothing for the UDP issue, but at least I might be able to pipe some TCP traffic] ... Little packets with ip lengths of 28-29 bytes seem to do the most damage. ... UDP floods are much better handled - an ipfw block rule for the packet type and the machine responds as if there were no flood at all (until total bandwidth saturation or PPS limits of the hardware, which in this case was around 950Mbps). ...
      (freebsd-performance)