[Tsvwg] Re: [e2e] e2e principle..where??....
narin at laurelnetworks.com
Tue Jun 5 10:05:47 PDT 2001
:> However, caching proxies do the same thing...they terminate TCP connection
:> from client to them and then build another one from them to server(on cache
:> miss)... therefore they too are not e2e.
In the case of cache misses, the Cache Proxy fetches the objects from the
primary server, caches them, then re-serves the objects to the client. I don't
think that violates the end-to-end transfering of information. In fact, I
think the Cache server becomes the alternate "end," in terms of flow control
and congestion control, for the client. The unit of data transferred between
the Client and the Primary Server, through the Cache, is in "objects"
:> Infact TCP connection splitting is as common in todays networks as caches
:> are...but no one seems to be protesting cache deployment??
Caching objects != caching bytes. Also, the "end," in the case of TCP
spoofing, remains the Primary Server. But, the "end," in the case of
web caching, i think, is the proxy server itself.
I don't care where I get the HTTP "objects" so long as I get them --
and that they are reasonably accurate. If my first attempt to get the
object fails, I don't mind attempting to reload the object. In fact,
I think, HTTP proxy servers probably increase reliability in terms of
making sure the clients receive the "reasonably accurate" objects.
Whereas TCP connection splitting reduces e2e reliability -- because of
the state-full nodes in between.
I care that my TCP connection get to the machine I want it to get to.
I can, if I must *sigh*, tolerate packet losses and rerouting of packets.
However, I cannot tolerate my TCP connection goes away because some
intermediate nodes, I know nothing about, go away.
More information about the end2end-interest