Correcting the mistake
hostmaster at LAVA.NET
hostmaster at LAVA.NET
Thu Sep 14 15:38:12 EDT 2000
On Thu, Sep 14, 2000 at 02:01:54PM -0400, Dave Stewart wrote:
> At 11:33 AM 9/14/00 -0500, Mury wrote:
> >Absolutely we can find a solution. Today? Next week? In an ideal world
> >ARIN could institute a policy and we could all make it work
> >tomorrow. It's just not reality. Some things are more difficult than
> >others to make work. Maybe web based hosting is more difficult to
> >technologically achieve than other things.
> It's not more difficult to achieve. Certainly it can be done. And easily.
> The problems revolve around the ways to be able to track and bill for
> bandwidth utilization. Even control utilization.
Actually, I think tracking and billing bandwidth utilization, for one
large class of web-hosters - those running a moderately recent Apache
release on UNIX boxes - might prove feasible.
"All it would take" (quotes intended!) is an Apache plug-in log
module to log hits on a particular host into an RRDtool (=round-robin
database) file (like Cricket uses for logging router data, and which
MRTG is converting to.) This wouldn't replace the existing Apache logs,
but would supplement them with the same data web hosters are getting
off the Netflow type IP-based logging. You can pop updates into an RRD
pretty much as they happen and have them averaged into your defined
time interval, as long as you "stroke" it every so often (add a 0 on 5
minute intervals, e.g.) to let it know it's still being updated with
valid data. Then you can make pretty MRTG-style graphs off of it,
analyse it later for peaks/ averages/95%, etc. This does require a
moderate amount of code to be developed, but it has the potential to
actually be a better tool than the current mechanism people are using.
It would be efficient because the RRD code is tuned to operate
efficiently with floating-point math and update its files in place, and
it could be executed directly from within the Apache process without
having to write huge logs and post-process them later.
Comments on this idea?
In general, this discussion has been quite helpful to me, because it
has pointed out that we've been misinterpreting some of the data we'd
collected here about feasibility of name-based hosting. (The HTTP 1.0
vs. HTTP 1.1 issue.)
If ARIN made one of its focuses ISP education - creating some web
resources on how to exploit the existing features of common software,
how to interpret your Browser header info to measure your real
percentage of hits that could be served by name-based hosts - and also
focused on coordinating development of new software, where needed, to
better serve a more efficient use of address space, then I think all
parties (and the Internet at large) would be better served than with
the current style of interaction.
I am seeing from the response by ARIN participants here that ARIN
does not mean to be arbitrary and punitive, but when you're a small ISP
applying for desperately needed address space, ARIN really does seem
that way frequently.
Clifton Royston -- LavaNet Systems Architect -- cliftonr at lava.net
The named which can be named is not the Eternal named.
More information about the ARIN-discuss