The Great Exchange

Since most of this distance stuff is being calculated by IP address or ASN,
why wouldn't the edge routers have SRC IP, DST IP, and "MY IP." And why
couldn't a collector make any other adjustments necessary?

Neither ASNs nor network prefixes (particularly aggregated prefixes)
correspond to geographical locales. To evaluate cost of end-to-end
transmission one has to collect information about state of the things
along the path. That information is typically totally unavailable
to end-nodes and only partially available to backbones.

Distance-insensitive per-bit charging is certainly feasible and
is being practiced by some ISPs (typically as "burstable" T-1
or T-3 service).

In fact, even those charges aren't likely to stand against close legal
scrunity. Example of a scenario of a rationale for action against
ISP X - they count received and transmitted packets on a user link.
Unfortunalely, they also count packets they didn't deliver due
to some packet loss in their backbone. Bingo - they charge
customers for service not provided. This is fraud, pure and simple.
Sorry if i gave the idea to lawyers...

A lot of people like the word fraud. I am not sure many ISP contracts
guarantee delivery of packets to their final destination, but most seem
to say that the burstable rate is based on how many packets enter your
connection port, or "enter the ISP's backbone." Even service level
agreements are generally based on link loss to the customer and not
end-to-end backbone loss.

There's such thing as implied contract. Delivery of packets to destination
is a primary venue of business for ISPs, and they are reasonably expected
to carry it on. When you provide flat-rate pricing it is understood that
some of them won't be delivered, and customers won't be charged more for
retransmission.

On the other hand, when you explicitly bill for all packets, and then fail
to carry on your service and then proceed to bill for a service not provided
you've got a problem. I didn't see a contract language yet which would
explicitly and clearly state that customers will be charged for arbitrarily high
percentage of non-delivered packets.

It's like a food store which sells boxes of some stuff, and some of those are
empty - but you have to pay for each one and cannot return the bad ones, and
have no way of knowing what your odds are. It may be legal, but not in US.

--vadim

Neither ASNs nor network prefixes (particularly aggregated prefixes)
correspond to geographical locales. To evaluate cost of end-to-end
transmission one has to collect information about state of the things
along the path. That information is typically totally unavailable
to end-nodes and only partially available to backbones.

I understand your point. However, I didn't claim that my analysis
method was based on a perfect understanding of the path each
individual packet took, which I agree is infeasible. Instead, it
simply tries to determine the cost to deliver an average byte to
prefix P.

If for some reason traffic to prefix P took a different path under
conditions that might be correlated with a customer's usage patterns,
the cost might be higher or lower than the average. An example of
this might be if there were an "overflow path" such that when line L1
was full, any additional packets were sent over line L2 instead; this
would be load-dependent and therefore in practice time-dependent, and
if a customer mostly sent data to P in the dead of night, their data
would never transit L2, and therefore would cost less to deliver; but
this cannot be accounted for in my model.

Current routing protocols don't work that way, since they will not
reroute traffic in the absence of a fault. However L1 and L2 might be
not seperate lines balanced by a routing protocol but rather seperate
pricing models on a single line, for example flat-rate up to X usage
and then metered. The cost allocation is probably not worth doing.

Having thought about it some more, I'd be willing to accept that this
problem is intractible for a network large enough to be considering
such a pricing model.