[e2e] Can we revive T/TCP ? => persistent connections

Michael Welzl michael.welzl at uibk.ac.at
Mon Dec 26 12:00:41 PST 2005

First of all, thanks a lot for your fast and detailed answer; it's
really helpful. You actually settled the issue for me - but a point
you raise up lead me to ANOTHER thing that's been on my mind
for a while:

> > I don't understand why a web browser of someone doing telebanking
> > with IPSec (not in tunnel mode) needs to set up a new connection
> > whenever a link is clicked. There is a similar problem in the Grid,
> It doesn't.  Most links are clicked within the same site, and most  
> servers and browsers support persistent connections.  The connection  
> is only torn down after an idle period or some maximum number of  
> requests.

In practice, this doesn't seem to be the case. In all the tests my
students did (not a thorough measurement study, just some
experiments), the server closed the connection after sending a page.

I think this is due to the (quasi-)stateless operation that a HTTP server
can achieve this way - I mean, it's much more difficult to keep
connections open for a longer period, and close them only after a
timer expired, count the number of connections that should be cached,
etc. etc. ... if poorly implemented, this might also not scale so well.

> (I'm sure there are scenarios where it will, of course.)  In the Grid  
> context, if you're talking about a not-huge set of trusted nodes,  
> they can cache those TCP connections for quite a long time.

But they don't - neither in the smaller nor in the larger Grids that I
know of; I think it's because the notion of a "connection" is lost
in the (vertical) communication across layers.

Grid Services are usually implemented on top of SOAP, which is
stateless. How should SOAP tell HTTP to maintain a connection
when it can't know whether a Grid Service will be called again? The
decision to do so is up to the programmer, who however can't provide
the remote SOAP instance with the necessary information because
the notion of a "session" isn't part of SOAP.

Could connections be cached in a transparent manner in such a
scenario (e.g. by tweaking something at the HTTP level, but not
above)? I think so, but I'm not 100% sure. Also, if it's possible,
why isn't it done? In a Grid, this would surely make sense.

> An interesting example of this is the 'rex' system by Kaminsky and  
> Mazieres.  It's a remote execution tool much like ssh, but more  
> flexible.  It supports connection caching under the hood, so you  
> don't have to pay the setup time if you're using remote command  
> execution.  It's worth noting that the major delay they're avoiding  
> in the local area is the public key crypto processing time, but in  
> the wide-area, both can add significantly to the total delay.

Thanks a lot for the pointer!
By "under the hood", you don't mean it's transparent to upper
layers, do you? How could it... I mean, if a web server decides
to close a connection, there's nothing any system underneath it
could do about it, I guess.

I heard the term "connection caching" before, and followed it, which
led to a few papers on the subject and problems with this type of
caching, but no standards. It doesn't seem to be an easy issue, but
it looks like it's solvable. If I'm right and common web servers don't
implement this (one could of course carry out a larger measurement
study for this... perhaps it has already been done), wouldn't an
Informational RFC which provides an overview of connection caching
methods and suggests an implementation do the trick?

I'd be thankful for some pointers to the key papers about connection
caching - e.g., where was it introduced?


More information about the end2end-interest mailing list