Path: utzoo!mnetor!uunet!husc6!bbn!mit-eddie!ll-xn!ames!pasteur!ucbvax!DECWRL.DEC.COM!mogul
From: mogul@DECWRL.DEC.COM (Jeffrey Mogul)
Newsgroups: comp.protocols.tcp-ip
Subject: Re:  Charging and aborted transfers
Message-ID: <8804262306.AA12435@acetes.dec.com>
Date: 26 Apr 88 23:05:00 GMT
References: <8804262206.AA13680@LANAI.MCL.UNISYS.COM>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 53


    Jeffrey, I think you have hit on and important question that is not
    asked very offten, namely, how does policy affect the architecture?

Actually, I was trying to make a slightly different point: that we
are already "paying" for lost packets, even if we aren't actually
mailing in checks.  We should be looking for ways to avoid "wasting"
packets even before we have to pay for them in real money, because
we can't afford the latency/congestion/low bandwidth anyway.  Alas,
charging real money might be the only way to get people to listen.

Thus, if I'm doing a transaction protocol and the network loses a
packet late in the transaction, or I'm running NFS with mobygrams
and the fragmentation demons strike (thanks to JQJ for these examples),
why should I not have to pay for the packets that the network delivered
properly?  Perhaps some sense of "justice" implies that the work
I've lost is the fault of the network, but nowadays when the network
is "free" we still have to deal with those losses, so we might as
well think about making our protocols more robust rather than looking
for someone else to pay.

True, if the phone company gives you a bad connection, you expect them
not to charge when you complain.  If the "network company" doesn't
meet their service guarantees (error rate) then you shouldn't pay them
either.  That doesn't make it any less necessary to make the best
of the situation.

I don't pretend to know how to build a transaction protocol that is
efficient yet responds well to lost packets.  I have, however, trashed
NFS in public before for using fragmentation instead of a real
protocol; there's no excuse for that and I have no sympathy for
people who don't want to pay for the successfully transmitted fragments
if the network drops one.

    For example, suppose we go to pay per packet and the architecture is
    changed to minimize costs.  Now we find that we are in conflict with
    survivability or security or robustness policy issues.  What does the
    DoD do?  does it want to recover cost, or develop technology which will
    survive in a stress environment.
    
    Oh well, in this case it may not matter, because if we get involved in
    a stressed situation, there may not be anyone around to use the net
    anyway.:-)
    
Does too matter, since if the network collapses from stress during
a crisis, we might launch those missiles by accident (or through panic).
I think it's foolish to try to combine both pay-per-packet and serious
real-time constraints; if you want guaranteed service you should pay
for it in advance, where "pay" may mean "assign a high priority" or
"build a VC and reserve the resources".  Datagram networks seems
best if "spreading the pain" is your goal; I'm not sure I would
be a datagram fan if I had to guarantee service through a big hairy
internet.