> Do you think using another web proxy, which supports outgoing presistent
> connections, between WWWOFFLE and the Internet would help be and make
> browsing faster?
It certainly would. Pipelining would help even more.
> I even thought of trying to find or write some software that would
> consitst of two counterparts - one on my side of the long-RTT link, and
> another on some server on the Internet, and the communications between
> them would be done with some other protocol, maybe UDP based, that would
> make interactive browsing much faster. And taking care of dropped
> packets in some other way. Maybe some knows of any such software? It
> would be strange it was me who would first think of this idea.
The idea is indeed old, and it's known as split-TCP. A web search for
split-TCP will give you quite a few hits; you can also have a look at
RFC 2757.
What you appear to have missed is that you don't need a different
protocol on the Long Fat Network (LFN) -- it is enough to have two TCP
connections, one over the LFN and one over the public Internet.
Assuming there's no congestion over the LFN, the two TCP connections
will have very different internal state -- the one over the LFN will
grow its window very fast, while the one over the general Internet
will be more cautious.
The simplest way to achieve that is to put an HTTP proxy between the
LFN and the Internet. (I do this regularly when browsing over lossy
Wifi links -- not quite LFNs, but they have similar issues --, and it
helps a lot.)
Of course, split-TCP will only make a difference if the TCP instance
over the LFN has enough time to grow its congestion windows -- and
unless your TCP/IP stack is doing black magic behind your back, it
means that the HTTP implementations on both ends of the LFN must
support persistent requests.
Juliusz
