backbone transparent proxy / connection hijacking

This is just my take on the issue.

@Home caches. AOL caches. Browsers cache. (does the Direct/PC
service cache?), many, many ISP's cache. Many companies cache.
Caching is a fact of life. From my point of view any advertiser that
does not take caching into account is screwing themselves and their
customers. We cache. I try to configure our cache to err on the side
of fresh content, rather than err on the side of hit rates.

Every once in a while we get a customer complaint about a specific
site and we address the issue on a case by case basis. So far
complaints are fairly uncommon.

We are not a backbone provider. Our cache is only available to
customers that subscribe to our "security" services. (Just a note
most of our customers have less then 300 users and although our
firewall services are not air tight, I think we do a decent job of
protecting our customers. If these customers did not have this
service from us, most of them would have no protection at all. I'm
just amazed at how much smaller business just don't seem to care about
network security.)

Making your site cache friendly is not rocket science. Putting
reasonable expires information on objects is not tough. Telling your
web server to set the expires as a percentage of the age of the
document is supported in some servers. Using client side forms
validation is not really that much tougher than using server side
validation. Many SSI web pages are not really dynamic. We use SSI
extensively on our web sites to create a consistent look and feel. Of
course, some SSI pages are dynamic and should not be cached.

I do think that it's utterly unacceptable for a backbone provider to
force their customers to use their cache. I do, however, wish that
more backbone providers would provide caching services to those people
what want the service.

--Eric Wieling

John Fraizer <John.Fraizer@EnterZone.Net> 6/29/98 6:20:31 PM >>>

<snip>

So, If someone is using site exec, etc in their code, and their
provider/webmaster/mother didn't set up Progma: nocache, they're
effectively screwed...erm...cached, right?

<snip>

Fantastic. So, lets say I'm Joe Banner Advertizer. Company X has
paid me
present their banner. They wanted to limit the amount of money they
spent
so, they had me code my servers to only display their banner X times
per
day since I bill them on impressions. Backbone provider Z installs
one of
your boxes. By default, no matter how many connections on the
limited....erm...client side of the box are initiated to retrieve a
"fresh"
banner from our banner-farm, you send them Company X until the cache
times
out.

I do think that it's utterly unacceptable for a backbone provider to
force their customers to use their cache. I do, however, wish that
more backbone providers would provide caching services to those people
what want the service.

Most backbone providers run Squid in their datacenters and/or POPs and
offer to do ICP with any customer who wants it. I don't like ICP -- see
http://www.vix.com/ietf/htcp.txt for the protocol I proposed to replace
it. But the model is sound, and I would like to see more backbone
providers doing this.

So, If someone is using site exec, etc in their code, and their
provider/webmaster/mother didn't set up Progma: nocache, they're
effectively screwed...erm...cached, right?

No.

Fantastic. So, lets say I'm Joe Banner Advertizer. Company X has paid me
present their banner. They wanted to limit the amount of money they spent
so, they had me code my servers to only display their banner X times per
day since I bill them on impressions. Backbone provider Z installs one of
your boxes. By default, no matter how many connections on the limited..
..erm.. client side of the box are initiated to retrieve a "fresh"
banner from our banner-farm, you send them Company X until the cache
times out.

No. For now, use freshness lifetimes (including pre-expiry for banners) and
correctly behaving caches will at worst do a GET/If-Modified-Since whenever
they are considering reusing the element -- so your origin server can count
the hits and can control when the object can no longer be reused. The HTTP
standard already supports this. It costs a TCP transaction per reuse, but it
avoids the actual transmission of the banner ad whenever reuse is correct.

In the near future, we'll see a different reuse model, based on RFC 2227:

    rfc2227.txt -- Simple Hit-Metering and Usage-Limiting for HTTP.
  J. Mogul, P. Leach. October 1997.
  (Format: TXT=85127 bytes) (Status: PROPOSED STANDARD)

And again, the advertisers will be in full control, the standards will get
followed, and the backbone will have more bits free for Internet Telephony.

Most backbone providers run Squid in their datacenters and/or POPs and
offer to do ICP with any customer who wants it. I don't like ICP -- see
http://www.vix.com/ietf/htcp.txt for the protocol I proposed to replace
it. But the model is sound, and I would like to see more backbone
providers doing this.

I would like to "form" a developer group which forms htcp
into squid allowing "more people" to use a new scheme for that, instead
of using icp for the neighbor queries. I started to look at the code
and will be ready to start in about 1-2 weeks.

how about some comments on the htcp code, paul ? Is it accepted so far
as is or do you receive many comments on this ?

And again, the advertisers will be in full control, the standards will get
followed, and the backbone will have more bits free for Internet Telephony.

... and that shall be the future ... :-((

as i see the internet getting more and more commercial and concentrated
to vbf's (very big firms) the small to medium isps shall work together not
apart. That "energy" of working together formed the internet so far (at
least i could tell this for germany)

no more comments..

Jan

IPF.NET Service Provider GmbH
Senior Network Engineer

btw: a bit off-topic - but: any one of you know a good and cheap csu /dsu
for t1 speeds and ds3 speeds?

btw2: network - providers: we need price quotes for some ds3 lines in the
states (contact me on czmok@ipf.de or phone + 49 69 17084-52 for details)