BBN/GTEI

Mailman List Mirror (Read Only)
1

From: Michael Dillon <michael@memra.com>

> Sure, but only the assymetry that results from BBN customers ASKING for more
> than they OFFER.

Or is it the asymmetry that results from Exodus customers OFFERING more
than they ASK FOR?

I don't think one of these views has any claim to precedence over the
other. Just because long distance phone calling introduced the purely
artificial concept that the initiator of the transaction pays for it does
not mean we should analyze IP traffic in the same way.

In the past, on other topics, Michael often has had thoughtful
responses, but this time he has gone off the deep end (and is drowning).

Long distance carriers charge the initiator, even when the initiator
merely sits and listens to the content coming toward them, using little
or no bandwidth the other direction. 800 number services charge the
terminator, instead. Both models are in vogue. But they depend upon:
  1) the initiator and terminator being obvious,
  2) a setup time,
  3) total circuit time much greater then the setup time.

IP traffic has none of these characteristics. Who is the "initiator"
for the FTP data PORT? PASV? What setup time? What circuit time?

We are "packet" oriented, not "circuit" oriented.

In the past we have
considered the initiator of IP transactions to be irrelevant and had
no-charge peering for networks that basically send a similar number of
bytes to what they receive.

So what do we do when that is no longer the case?

Those of us who have been around longer then most, remember that this
has _NEVER_ been the case.

My simple telnet to a host (circa '78...) delivered far more to the screen
than my typed commands, even with an old teletype or decwriter.

My FTPs from Simtel20 to Umich to MSU (circa '84-92) usually were
asymmetric, except when I was making a submission.

My POP{2,3} (circa '86, '88) was (and still is) asymmetric!

WSimpson@UMich.edu
    Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32

2

In the past, on other topics, Michael often has had thoughtful
responses, but this time he has gone off the deep end (and is drowning).

*gurgle*

IP traffic has none of these characteristics. Who is the "initiator"
for the FTP data PORT? PASV? What setup time? What circuit time?

I don't care who is the initiator and the terminator because both are
customers of the backbone operators who are peering and are therefore
irrelevant to the peering relationship. I am attempting to factor the
customers out of this scenario and see where it takes us.

We are "packet" oriented, not "circuit" oriented.

I'm not even looking at packets to figure out what the balance point is.
Just octets in and octets out.

> no-charge peering for networks that basically send a similar number of
> bytes to what they receive.
>
> So what do we do when that is no longer the case?
>
Those of us who have been around longer then most, remember that this
has _NEVER_ been the case.

My simple telnet to a host (circa '78...) delivered far more to the screen
than my typed commands, even with an old teletype or decwriter.

Meanwhile someone on the host's network could have ben telnetting to a
host on your network. This is what I mean by balance. I'm talking about
the aggregate of all the flows passing through an exchange point.

3

In the past we have considered the initiator of IP transactions to
be irrelevant and had no-charge peering for networks that basically
send a similar number of bytes to what they receive.

Historically, customers chose backbone networks based either on
geographic area or political convenience, but not the type of traffic
they generated. As a result, traffic at peering points tended to even
out since everyone had a mix of customer types.

So what do we do when that is no longer the case?

It's pretty clear to me that you figure out whose customers are most
eager to get to what resources, and you set the price accordingly. In
the BBN/Exodus case, BBN has a bunch of dialup customers who want
access to Exodus' web site, and Exodus has a bunch of advertisers who
want access to BBN's dialup users. At this point I'd guess that BBN's
dialup users would be more upset at losing Exodus' well-known web
sites than Exodus' advertisers would be at losing BBN's random dialup
users, but I could imagine that it could go either way.

Lest anyone think this "pay for value" approach is too complex to be
used in the real world, consider the relationship between your local
CATV provider and its programming sources. The provider pays for HBO,
takes local broadcast for free, and gets paid for infomercial
channels.