"Chris Hellberg" <Chris.Hellberg@telecom.co.nz> wrote:
>At Canterbury to differentiate traffic between national and
>international, they could really perform the accounting at any step of
>the datastream. Each ip that you connected to, a reverse lookup was
>performed on it and accounting done on the basis of it having a '.nz'
>tld. There were problems with this, and as more and more New Zealand
>companies decide to have a '.com' namespace, even though the servers are
>housed in New Zealand, it will mislead the accounting process.

That's one problem. The other is that doing reverse lookups can be
slow. Doing them sequentially can mean that a single lookup can take a
long time, as the lookup times out and tries the next of multiple name
servers, let alone some of the more interesting things that can happen
with forwarding name servers and misconfigured delegations.

The unpredictability of reverse lookups means that it's pretty close to
impossible to do in real time, and there is a very high proportion of
broken reverse maps out there.

The alternative is to store the IP addresses you get and look them up
after the fact. This is messy -- it works OK for smallish amounts of
traffic, but it doesn't let you do any real data reduction, and in a
large ISP or carrier environment, the data is coming at you thick and
fast.

Of course you can store the data you get, and make a few assumptions --
if you're just looking at national vs international, then IP address
ranges don't move around much; you can fairly safely assume that one
address in a /24 ("Class C", ie x.y.x.0-x.y.z.255) range is in the same
country as another in the same range, and these things don't move around
the world very quickly. So you could build a table and look that up.

>Aparently there's a doco somewhere which mentions all the ip
>subnets/supernets that have been assigned to New Zealand. I would say
>that instead of performing a reverse name lookup, that a lookup of the
>subnet/supernet table be performed. This could already be what Saturn
>do, no sure :/

Folks that make this distinction usually do it by monitoring the routing
tables at their various peering points, both at public exchanges such as
the APE & WIX, and across bilateral peers between individual
carriers/ISPs. Each major ISP/carrier therefore carries a more or less
complete NZ routing table, punting the rest to the overseas exchanges --
the relatively small number of routes out of the country makes this
possible, just as it makes the distinction between national and
international traffic desirable.

Then it's a matter of -- in real time -- reducing packet header
information -- tens of thousands packets per second or more -- down to
traffic and billing data. This is best done in two stages; first, the
routers have the capability of assigning packets to flows, so instead of
having to trawl through a bunch of packet headers, you get from the
routers data that says, eg, "TCP flow, peers 203.96.144.16 port 2035 and
64.208.34.100 port 80, 5 packets 2987 bytes out, 5 packets, 12974 bytes
in". You may get several reports for the same flow.

This works well for the routers because they usually do this level of
reduction anyway as part of the switching process; it's a relative
no-brainer count the packets and bytes in flow cache entry, and to
shove expiring entries into buffer for export as an accounting packet.
It also doesn't need any external data -- the flow is one way from the
routers to the accounting stuff, and the router needs no knowledge of
"international" vs "national", let alone who the customers are.

The second step is to take this data (coming at you at hundreds or
thousands of flows per second), identify the location of each endpoint
and account accordingly. This second step needs to know what IP
addresses customers are using, and addresses are local, national and
international. Once you have this, you can apply a charge step, and
from there a rate for billing.

Makes for some entertaining code, actually.

Waikato University used to have a list of current IP assignments, but
their interest in this area has, uh, waned. I think some carriers can
provide it, if pushed.

-- don

This message is part of the NZ ADSL mailing list.
see http://unixathome.org/adsl/ for archives, FAQ,
and various documents.
To unsubscribe: send mail to majordomo@unixathome.org
with "unsubscribe adsl" in the body of the message
Received on Fri Dec 15 14:53:30 2000