We completely agree on this topic.
The relevant paragraph in my message started with "unless" as can be
seen below. So if you do use HTTP 1.1 and persistent connections, life
over satellite gets a bit easier. However, they break the congestion
behaviors. I still think that a possible solution is sharing the TCP
control blocks among multiple sessions as you had proposed before.
What does WREC stand for?
Thanks
Bora
> > From [email protected] Fri Feb 19 06:36:40 1999
> > From: [email protected]
> > To: Joe Touch <[email protected]>
> > cc: [email protected]
> > Subject: Re: HTTP performance issues
> > Date: Fri, 19 Feb 1999 09:19:55 -0500
> >
> > > > Unless you use http 1.1 and use the persistent TCP connections (forgot
^^^^^^
> > > > the real name, sorry) that do not open a TCP connection for each HTTP
> > > > request then you are pretty much out of luck. With 1.5 sec RTT, you
> > > > will get awful performance for HTTP traffic (on the order of
> > > > 8Kbytes/sec or so). Your best bet is to use one of the available TCP
> > > > spoofing/proxy boxes and break the end-2-end semantics.
> > >
> > > Why? 1.1 and persistent connections doesn't require the spoofing stuff...
> > >
> > > Joe
> > >
> >
> > The reason why I mention 1.1 and persistent connections is not due to
> > the spoofing but due to the fact that most HTTP transactions do not
> > send enough data to fill the pipe in a satellite channel and never get
> > out of slow start.
>
> If you're running persistent connections, the slowstart occurs
> only on the first transaction, in typical implementations.
>
> This is because HTTP (or any request/response) behavior defeats
> the current implementations of slow-start restart. See
> ftp://ftp.isi.edu/internet-drafts/draft-ietf-tcpimpl-restart-00.txt
> for more details on this.
>
> > If you do
> > locate a proxy that sits between the host and the satellite channel
> > and use a version of TCP that is modified, then the so-called spoofing
> > boxes may be helpful.
>
> Is this proxy for caching, or to mux the hosts multiple TCP
> connections into a single, persistent HTTP stream?
>
> If the latter, there is an E2E-compatible equivalent, which involves
> the host saving the window state from the previous connection,
> and using it as the initial window parameters on the new connection
> (see RFC 2140 for more on this).
>
> > However, they still break the end2end semantics unfortunately and may
> > not work with anetwork that uses end2end IPSEC for VPNs or such.
>
> Yup - they have lots of consequences, including breaking network
> diagnostic tools, as well as triggering security monitoring programs.
> We're working on a more comprehensive list of this, to be reviewed
> in the WREC WG (pending its creation)...
>
> Joe
>
This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 16:14:53 EST