VALDIS@CLVM.CLARKSON.EDU (Valdis Kletnieks) (04/26/88)
(Forgive me - it *is* 2:30AM here, so I may be a TAD off base, but...)
Ever have this happen to you?
% ftp someplace.faraway.arpa
ftp>get big.manymeg.file
(....)
(....)
(14 meg of the 15 meg file has been transferred)
netinet: net unreachable
ftp>
(Insert typesetting symbol for 'scream of anguish' here)
Who pays for the 14 meg of usage? I sure don't want to - I didn't get the
service I asked for.
Defining 'got requested service' for each service type is left as an exercise
for the student. Don't forget the case of homegrown TCP client programs.
Valdis Kletnieks
P.S. Usual disclaimers apply. Flame me, not my boss...
I'm not a TCP guru, I just use the stuff - a lot.perry@MCL.UNISYS.COM (Dennis Perry) (04/26/88)
I suspect there should be some mechanism to ask for a refund. Isn't this fun? dennis
bzs@BU-CS.BU.EDU (Barry Shein) (04/26/88)
If nothing else this is becoming an object lesson in why AT&T was granted a monopoly, it certainly did simplify a lot of things. Sure, that's been broken up, perhaps around 2080 Judge Greene will see that the internet can be "deregulated" also. There are other examples, I think people on this list are starting to understand what the word "infrastructure" really means. It has a lot to do with services who's very value is based upon their universality (roads that go to other roads, phones that can call all other phones, railroads that can use other tracks, canals that link to other waterways, consistent rules and tariffs etc.) -Barry Shein, Boston University
cire@CLASH.CISCO.COM (04/27/88)
>> Date: Tue, 26 Apr 88 09:05:34 EDT >> From: bzs%bu-cs.bu.edu@bu-it.BU.EDU (Barry Shein) >> To: perry@MCL.UNISYS.COM >> Cc: VALDIS@clvm.clarkson.edu, tcp-ip@sri-nic.ARPA, perry@mcl.unisys.com >> Subject: Another problem with usage charges >> >> If nothing else this is becoming an object lesson in why AT&T was >> granted a monopoly, it certainly did simplify a lot of things. Sure, >> that's been broken up, perhaps around 2080 Judge Greene will see that >> the internet can be "deregulated" also. One of the depressing things about the deregulation of AT&T is that in many ways it may have been better to not deregulate. I haven't seen lower prices or better service. But then again I live in the hinter land of the Santa Clara Valley. There are some things that should perhaps be left as a monopoly or set up that way because the overhead of other structures is too costly. >> >> There are other examples, I think people on this list are starting to >> understand what the word "infrastructure" really means. It has a lot >> to do with services who's very value is based upon their universality >> (roads that go to other roads, phones that can call all other phones, >> railroads that can use other tracks, canals that link to other >> waterways, consistent rules and tariffs etc.) >> Is the infrastructure of networks universal to an Information Age? What ever that is. >> -Barry Shein, Boston University >> -c cire|eric Eric B. Decker cisco Systems Menlo Park, California email: cire@cisco.com uSnail: 1360 Willow Rd., Menlo Park, CA 94025 Phone : (415) 326-1941
braden@VENERA.ISI.EDU (04/28/88)
Valdis, Scream at the implementors who thought FTP Restart was only for sliderule nurds. Bob Braden
rminnich@udel.EDU (Ron Minnich) (04/29/88)
In article <8804260944.AA25473@ucbvax.Berkeley.EDU> VALDIS@CLVM.CLARKSON.EDU (Valdis Kletnieks) writes: >% ftp someplace.faraway.arpa >ftp>get big.manymeg.file >(14 meg of the 15 meg file has been transferred) >netinet: net unreachable >Who pays for the 14 meg of usage? I sure don't want to - I didn't get the >service I asked for. Hmm, this is the second comment on this sort of thing. Is this an argument AGAINST charging or an argument FOR something better than ftp- something that lets you move pieces of things instead of the whole thing, and that would let you pop off that last megabyte or so. After all, it did move 14/15th of the file for you :-). What if that 15 mb were 15 seperate files, and you did an mget, then recovery would be easy. Maybe it is an argument for a different way of storing ftp-able things? -- ron (rminnich@udel.edu)
jbs@fenchurch.MIT.EDU (Jeff Siegal) (04/29/88)
In article <8804260944.AA25473@ucbvax.Berkeley.EDU> VALDIS@CLVM.CLARKSON.EDU (Valdis Kletnieks) writes: >Ever have this happen to you? >% ftp someplace.faraway.arpa >ftp>get big.manymeg.file >(14 meg of the 15 meg file has been transferred) >netinet: net unreachable > >Who pays for the 14 meg of usage? The serial-line file transfer protocol Zmodem supports "crash recovery." This allows you to restart an aborted transfer, and the protocol negotiates the restart point. Charging for your 14 meg would likely inspire the prompt creation of a similar internet protocol. Jeff Siegal
smb@ulysses.homer.nj.att.com (Steven Bellovin) (04/29/88)
In article <8804260944.AA25473@ucbvax.Berkeley.EDU> VALDIS@CLVM.CLARKSON.EDU (Valdis Kletnieks) writes: >Ever have this happen to you? >% ftp someplace.faraway.arpa >ftp>get big.manymeg.file >(14 meg of the 15 meg file has been transferred) >netinet: net unreachable > >Who pays for the 14 meg of usage? Well -- if you read the spec, FTP itself implements checkpoint/restart. Better protocols may be desirable, but for now we should make the most of the ones we already have. Has anyone implemented checkpoint/restart in FTP? --Steve Bellovin ulysses!smb smb@ulysses.att.com
hedrick@athos.rutgers.edu (Charles Hedrick) (04/30/88)
In many cases there are things the local site can do to improve the reliability of long-distance FTP's. The problem of getting 95% of a file and then having the connection break is often due to a bug in your TCP that causes it to interrupt the connection when it gets a transient error message. Newer versions of TCP and gateway code can also make a dramatic difference. I'm not sure that I approve of usage-sensitive charging, at least in the research context. But if we're going to do it, paying for broken connections may not be so bad. At the moment, people don't have much incentive to clean up old, decrepit TCP's.
A024012@RUTVM1.BITNET (Ross Patterson) (05/02/88)
>Well -- if you read the spec, FTP itself implements checkpoint/restart. >Better protocols may be desirable, but for now we should make the most >of the ones we already have. > >Has anyone implemented checkpoint/restart in FTP? Yup. The UCLA TCP/IP for IBM's MVS system, known as the "ARPANET Control Program", or ACP, supports FTP checkpoint/restart. The Unixes we've got around here dont, since they won't accept a "MODE B" command (Sun's responds "Sorry, only stream mode supported" (or something close to that)). ACP is the basis for most, if not all, IBM MVS implementations. It supports restarting of both transmission and reception, as well as allowing the user control over the interval between checkpoints (defaulting to 100K bytes). Are there any other checkpointers out there? Ross Patterson Rutgers University
karn@thumper.bellcore.com (Phil R. Karn) (05/04/88)
The discussion of refunding aborted FTPs reminds me of a common trick among the Cornell RJE terminal operations staff back during my undergrad hacking days. The system (IBM OS/360, batch oriented) charged for each line actually printed. However, since line printers jam from time to time, the RJE operator could command the system to restart a print job from the beginning, canceling the charges for the copy already printed. But it became common practice among those operators whose funny-money accounts were running low to add several pages of unneeded garbage to their job output. When the useful stuff had all been printed, they would restart the job and then kill it, thus costing them NOTHING for the output they did print. Clearly any FTP refund scheme would invite exactly the same sort of abuse. On the other hand, I would like to repeat a quote I saw on the net almost 10 years ago. I wish I could remember who said it. It seems relevant to the subject at hand: "There may be no such thing as a free lunch, but sometimes it costs more to collect money than to give away food". Phil