bzs@BU-CS.BU.EDU (Barry Shein) (04/21/88)
[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
wbe@bbn.com (Winston B Edmond) (04/22/88)
Barry Shein writes: >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: This (transfer of charges on request) is essentially what I proposed in my previous message. The main difference is that I claim the protocol should be between the hosts and the network (the entity collecting the billing information) and not between the hosts directly. What's important to the host trying to reverse the charges is that the network says billing has been transferred, not that the other host has made a promise to accept the bill. -WBE