Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!pasteur!ucbvax!BU-CS.BU.EDU!bzs
From: bzs@BU-CS.BU.EDU (Barry Shein)
Newsgroups: comp.protocols.tcp-ip
Subject: another thought on packet charging
Message-ID: <8804210408.AA16030@bu-cs.bu.edu>
Date: 21 Apr 88 04:08:41 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 44


[I think this gets more interesting in the second half]

How exactly does packet accounting work? Being as it's so low level
does it just charge the source address? Or do we distinguish between
servers and clients (for example) to direct charges?

Case 1:

You FTP to my system to get a file. You are the client. I guess it
seems clear that you should pay so "charge the client" seems
reasonable.

Case 2:

I connect to your system to deliver mail being forwarded through me. I
am the client. But it seems you should pay for the packets, no? Charge
the client doesn't seem right.

We won't even talk about UDP.

If we just charge on source address then I guess I still end up paying
to give you your mail or expand a mailing list etc.

Does anyone have a proposed set of rules that are better than these?

[SECOND HALF]

About the only thing that comes to my mind is a meta-protocol (ICMP?)
sort of like a WILL YOU/WONT YOU:

	WILL YOU PAY? ->
	<- YES/NO

	I WILL PAY->
	<- GOOD

which occurs on each connection ramp-up.

Hmm, perhaps we can extend the ethernet "cocktail party" metaphor to a
"picking up the check" metaphor. Maybe should add "DUTCH TREAT?".

(does this lead to bistro mathematics?! [see Douglas Adams].)

	-Barry Shein, Boston University