TCP Splice alleviates proxy bottleneck

TCP Splice alleviates proxy bottleneck

[lk]

Anyone who's interested in high performance network development on
Linux should take a look at what these folks are doing.  It seems to
be a very clever way to eliminate the drudge work that an application
level proxy performs without significant impact on the application
code.  Looks like a great performance booster.  Very nice.  The paper
says that this is all running on BSDI.  Wish they'd picked Linux.. :-)

     Application Layer Proxy Performance Using TCP Splice. 
     David Maltz, Pravin Bhagwat. IBM Technical Report RC-21139, March
     1998. (submitted for publication).

           TCP Splicing for Application Layer Proxy Performance

                         David Maltz, Pravin Bhagwat

     Application layer proxies already play an important role in today's
     networks, serving as firewalls and HTTP caches --- and their role is
     being expanded to include encryption, compression, and mobility
     support services.  Current application layer proxies suffer major
     performance penalties as they spend most of their time moving data
     back and forth between connections; context switching and crossing
     protection boundaries for each chunk of data they handle.  We present
     a technique called TCP Splice that provides kernel support for data
     relaying operations which runs at near router speeds.  In our lab
     testing, we find SOCKS firewalls using TCP Splice can sustain a data
     throughput twice that of normal firewalls, with an average packet
     forwarding latency 30 times less.
     
     http://www.cs.umd.edu/users/pravin/TR-21139.ps.gz

Here are some other publications by one of the authors:

     http://www.cs.umd.edu/users/pravin/publist.htm

The MSOCKS paper also discusses TCP Splice.

-lda

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

Re: TCP Splice alleviates proxy bottleneck

[Chuck Lever]

On Mon, 18 Jan 1999 lk@winux.com wrote:

> Date: Mon, 18 Jan 1999 23:36:12 -0500 (EST)
> From: lk@winux.com
> To: Alan Cox <alan@lxorguk.ukuu.org.uk>
> Cc: linux-kernel@vger.rutgers.edu
> Subject: Re: TCP Splice alleviates proxy bottleneck
> 
> Alan Cox writes:
> > From:	alan@lxorguk.ukuu.org.uk (Alan Cox)
> > To:	lk@winux.com
> > Cc:	alan@lxorguk.ukuu.org.uk, linux-kernel@vger.rutgers.edu
> > Subject: Re: TCP Splice alleviates proxy bottleneck
> > Date:	Mon, 18 Jan 1999 14:53:14 +0000 (GMT)
> > 
> >> Their work on TCP Splice gives the efficiency of IP masquerading, yea, 
> >> even that of simple IP forwarding, to processes with the capabilities
> >> of application level proxies.
> > 
> > Their ? Having looked at the reference I'd like Larry McVoy's opinion on
> > its originality 8)
> 
> I'm not sure what you mean by this.  Are you referring to Larry McVoy's
> paper "Splice - a push pull I/O model for Unix" dated 6/24/98 [1]?
> 
> If so, the model he presents is a bit different than theirs. A cursory
> reading of his paper indicates to me that his model is intended to be
> more general, i.e. not intended purely for TCP/IP, and as such it (rightly)
> glosses over most of the TCP/IP-specific issues that Pravin and Maltz
> address in their paper dated 3/17/98 [2].  They also have the advantage of
> having implemented their ideas.

Druschel and Pai *have* implemented IO-Lite, which seems similar in spirit
to McVoy's ideas.  see:

  http://www.cs.rice.edu/~vivek/IO-Lite/TR97-294.ps

i think this would be a great starting place for what you have in mind.  a
combination of the general zero-copy I/O semantics and the TCP-specific
improvements could be very slick.

> References:
> 
> [1] http://www.bitmover.com/lm/papers/splice.ps
> [2] http://www.cs.umd.edu/users/pravin/TR-21139.ps.gz

	- Chuck Lever
--
corporate:	<chuckl@netscape.com>
personal:	<chucklever@netscape.net> or <cel@monkey.org>


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/