From mbaer at cs.tu-berlin.de Mon Jan 26 12:39:37 2009 From: mbaer at cs.tu-berlin.de (=?ISO-8859-1?Q?Matthias_B=E4rwolff?=) Date: Mon, 26 Jan 2009 15:39:37 -0500 Subject: [ih] Secret precedence schemes back then Message-ID: <497E1F89.6040006@cs.tu-berlin.de> Hi, I have come across two sources briefly pointing to the secret precedence scheme implemented with NSFNET's Fuzzball routers aimed at giving priority to telnet over other less time sensitive apps. (Mills: http://doi.acm.org/10.1145/52324.52337, and also: Bohn et al, 1994, Mitigating the Coming Internet Crunch: Multiple Service Levels Via Precedence) Does anyone know of further literature sources dealing with those schemes and, specifically, how they developed in time and beyond NSFNET. What about the practices of private ISPs up until today, maybe there are some scholarly accounts out there about the general picture and history. I appreciate your help. Thanks Matthias From mills at udel.edu Tue Jan 27 08:17:21 2009 From: mills at udel.edu (David Mills) Date: Tue, 27 Jan 2009 16:17:21 +0000 Subject: [ih] Secret precedence schemes back then In-Reply-To: <497E1F89.6040006@cs.tu-berlin.de> References: <497E1F89.6040006@cs.tu-berlin.de> Message-ID: <497F3391.2000702@udel.edu> Mathias, Busted after all these years. In the bad old NSFnet days the interactive customers were being crushed by other traffic, so I modifed the scheduling algorithm to implement a classic precedence scheme using the IP header TOS field. Then, I changed NTP to use the highest priority and telnet to use the next highest. Steve Wolff and I agreed to do thes as an emergency measure and to keep it a secret ftom the Cornell operators. I never told anybody and I don't think Steve did either, so somebody else figured it out. If you look closely at my SIGCOMM paper you can probably figure it out, too. 23 years after the crime, it is past the statute of limitations. Dave Matthias B?rwolff wrote: >Hi, > >I have come across two sources briefly pointing to the secret precedence >scheme implemented with NSFNET's Fuzzball routers aimed at giving >priority to telnet over other less time sensitive apps. (Mills: >http://doi.acm.org/10.1145/52324.52337, and also: Bohn et al, 1994, >Mitigating the Coming Internet Crunch: Multiple Service Levels Via >Precedence) > >Does anyone know of further literature sources dealing with those >schemes and, specifically, how they developed in time and beyond NSFNET. >What about the practices of private ISPs up until today, maybe there are >some scholarly accounts out there about the general picture and history. > >I appreciate your help. > >Thanks >Matthias > > From sbrim at cisco.com Tue Jan 27 08:42:28 2009 From: sbrim at cisco.com (Scott Brim) Date: Tue, 27 Jan 2009 11:42:28 -0500 Subject: [ih] Secret precedence schemes back then In-Reply-To: <497F3391.2000702@udel.edu> References: <497E1F89.6040006@cs.tu-berlin.de> <497F3391.2000702@udel.edu> Message-ID: <20090127164228.GJ39727@cisco.com> Excerpts from David Mills on Tue, Jan 27, 2009 04:17:21PM +0000: > Mathias, > > Busted after all these years. In the bad old NSFnet days the interactive > customers were being crushed by other traffic, so I modifed the > scheduling algorithm to implement a classic precedence scheme using the > IP header TOS field. Then, I changed NTP to use the highest priority and > telnet to use the next highest. Steve Wolff and I agreed to do thes as > an emergency measure and to keep it a secret ftom the Cornell operators. > I never told anybody and I don't think Steve did either, so somebody > else figured it out. If you look closely at my SIGCOMM paper you can > probably figure it out, too. > > 23 years after the crime, it is past the statute of limitations. > > Dave Dave, we at Cornell learned it from you when the fuzzballs were still in operation (but I didn't tell anyone else). I couldn't understand why you thought it needed to be kept secret. Scott From sbrim at cisco.com Tue Jan 27 08:43:38 2009 From: sbrim at cisco.com (Scott Brim) Date: Tue, 27 Jan 2009 11:43:38 -0500 Subject: [ih] Secret precedence schemes back then In-Reply-To: <20090127164228.GJ39727@cisco.com> References: <497E1F89.6040006@cs.tu-berlin.de> <497F3391.2000702@udel.edu> <20090127164228.GJ39727@cisco.com> Message-ID: <20090127164338.GK39727@cisco.com> Excerpts from Scott Brim on Tue, Jan 27, 2009 11:42:28AM -0500: > Dave, we at Cornell learned it from you when the fuzzballs were still > in operation (but I didn't tell anyone else). I couldn't understand > why you thought it needed to be kept secret. Come to think of it, maybe the fuzzballs had been taken out already. From jnc at mercury.lcs.mit.edu Tue Jan 27 11:04:40 2009 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Tue, 27 Jan 2009 14:04:40 -0500 (EST) Subject: [ih] Secret precedence schemes back then Message-ID: <20090127190440.1F8026BE5ED@mercury.lcs.mit.edu> > From: David Mills > Steve Wolff and I agreed to do thes as an emergency measure and to keep > it a secret ftom the Cornell operators. I never told anybody and I > don't think Steve did either You sure? I seem to recall hearing about it contemporaneously - or maybe I'm just confused, and I read about it later? But I'm pretty sure I'd heard about it before the recent email. It's not like it would have been terribly controversial - putting interactive traffic in a queue in front of email, etc, is entirely reasonable, so I'm not sure it would have need to have been held closely. Noel From mills at udel.edu Tue Jan 27 13:14:56 2009 From: mills at udel.edu (David Mills) Date: Tue, 27 Jan 2009 21:14:56 +0000 Subject: [ih] Secret precedence schemes back then In-Reply-To: <20090127164228.GJ39727@cisco.com> References: <497E1F89.6040006@cs.tu-berlin.de> <497F3391.2000702@udel.edu> <20090127164228.GJ39727@cisco.com> Message-ID: <497F7950.3080200@udel.edu> Scott, There were three reasons for the secret. First, Steve and I felt that the emergency provions would be provoke controversy and and pit one side of the community against the other. Second, I had a rather poor reputation with Cornell for fiddling with the critters without extensive testing, which was really hard to do as we had no backroom equivalent network. Third, I was sleeping next to a telephone for most of two years and getting weary of tiny pipes flooded with nine-ton gorillas. I have to admit to a couple of other crimes as well, incluiding a nasty scheme that the telcos call "call gapp". The scheme was designed according to a fairness principle bassed on the total amount of queued data for each IP source address. This determined whether a new packet was dropped or an old one was preempted. It was intended to get even more nasty should the perp fail to moderate traffic when confronted with an ICMP source quench, but so far as I knew, nobody but the Fuzzballs actuall responded to source quencn. I bet nobody even now responods to a source quence. Scott Brim wrote: >Excerpts from David Mills on Tue, Jan 27, 2009 04:17:21PM +0000: > > >>Mathias, >> >>Busted after all these years. In the bad old NSFnet days the interactive >>customers were being crushed by other traffic, so I modifed the >>scheduling algorithm to implement a classic precedence scheme using the >>IP header TOS field. Then, I changed NTP to use the highest priority and >>telnet to use the next highest. Steve Wolff and I agreed to do thes as >>an emergency measure and to keep it a secret ftom the Cornell operators. >>I never told anybody and I don't think Steve did either, so somebody >>else figured it out. If you look closely at my SIGCOMM paper you can >>probably figure it out, too. >> >>23 years after the crime, it is past the statute of limitations. >> >>Dave >> >> > >Dave, we at Cornell learned it from you when the fuzzballs were still >in operation (but I didn't tell anyone else). I couldn't understand >why you thought it needed to be kept secret. > >Scott > > From jack at 3kitty.org Tue Jan 27 19:53:14 2009 From: jack at 3kitty.org (Jack Haverty) Date: Tue, 27 Jan 2009 19:53:14 -0800 Subject: [ih] Secret precedence schemes back then In-Reply-To: <497F7950.3080200@udel.edu> References: <497E1F89.6040006@cs.tu-berlin.de> <497F3391.2000702@udel.edu> <20090127164228.GJ39727@cisco.com> <497F7950.3080200@udel.edu> Message-ID: <1233114794.3375.67.camel@localhost> On Tue, 2009-01-27 at 21:14 +0000, David Mills wrote: > but so far as I knew, nobody but the Fuzzballs > actuall responded to source quencn. Errr, ummm, well...depends on what you mean by "respond". Since Source Quench was sent by a receiver when it had gotten so overwhelmed that it threw away your packet, the obvious response from the Sender was to re-send the packet immediately, since you had just been told that it had been discarded. I can't remember exactly what the various TCP implementations did that I was involved in. Or I could take the fifth amendment... Of course, the spec might have said something a bit different about what a well-behaved TCP should do when you received a Source Quench. But I don't recall there ever being any "certification" or the like that any particular implementation was behaving correctly. As I remember, the spec wasn't very specific. E.G., If you send one packet and get a Source Quench back, what does it mean to "throttle back". And of course I can't remember whether the core gateways put such "control" traffic at the front of the queue (it's important stuff!), or discarded it (gaaak, more whining and noise from that complainer host...). Or whether they looked at all. Possibly all three schemes, over time. Of course, this whole Internet thing was a research project that was supposed to go away and be replaced by the "real" system using ISO and CCITT technology. Good thing it's been 23+ years Dave! /Jack From jack at 3kitty.org Tue Jan 27 20:04:05 2009 From: jack at 3kitty.org (Jack Haverty) Date: Tue, 27 Jan 2009 20:04:05 -0800 Subject: [ih] Secret precedence schemes back then In-Reply-To: <497E1F89.6040006@cs.tu-berlin.de> References: <497E1F89.6040006@cs.tu-berlin.de> Message-ID: <1233115445.3375.68.camel@localhost> On Mon, 2009-01-26 at 15:39 -0500, Matthias B?rwolff wrote: > Hi, > > I have come across two sources briefly pointing to the secret precedence > scheme implemented with NSFNET's Fuzzball routers aimed at giving > priority to telnet over other less time sensitive apps. (Mills: > http://doi.acm.org/10.1145/52324.52337, and also: Bohn et al, 1994, > Mitigating the Coming Internet Crunch: Multiple Service Levels Via > Precedence) > > Does anyone know of further literature sources dealing with those > schemes and, specifically, how they developed in time and beyond NSFNET. > What about the practices of private ISPs up until today, maybe there are > some scholarly accounts out there about the general picture and history. > > I appreciate your help. > > Thanks > Matthias > Matthias et al, I think it's important to note that, as far as I can remember, there was never any mandatory specification of how a router (then called gateway) was required to handle traffic. The role of a router was to exert "best efforts" to move the traffic along, given its knowledge of the state of the world - info in the packet headers, info from the routers' own measurements, and info about the characteristics of the particular networks to which the router was attached. So we tried all sorts of things, some of which exhibited bizarre and unexpected behavior. Maybe most. My group at BBN implemented and operated the "core gateways" - mainly the ones that interconnected between Arpanet, Satnet, WidebandNet, and other major installations. Lots of different schemes were tried to see what worked best. This was mostly occurring through the very late 1970s and 1980s. Also, hardware was severely limited. I remember one router, connecting ArpaNet and Satnet, which at one point had only enough memory to buffer exactly ONE packet. So there wasn't much question of how to handle priority in the "queue". Sometimes it just saved the "next" packet and discarded everything that came in afterwards until the output buffer was free again. Sometimes it discarded every incoming packet until the buffer was free, and then allowed the next incoming packet to get through. So the queue-management approaches were severely affected by the realities of the hardware, modem speeds, etc. at the time. TOS was viewed as a piece of advisory information about the packet, just like other info such as TTL. Routers also could use knowledge of the underlying network to which they were connected. For example, the Arpanet had a "RFNM" scheme that essentially applied flow control to specific destinations. So at any time it might be possible to send packets out to that net to certain destinations, but not to other destinations. Such details were all fodder for the thinking about how to manage the queue. Sometimes, if TOS indicated that the packet needed fast service (real-time voice), but the appropriate output queue was clogged, the "high-priority" packet was discarded - the theory being that it wouldn't get there in time to be useful anyway, so it was better to drop it early and avoid wasting bandwidth downstream. The same kind of argument applied to TTL - "if this packet is so old it's likely not going to be useful when it finally gets there, so let's drop it now." Most of this kind of behavior and experimentation was unfortunately never documented anywhere except maybe in the code and in email traffic. I don't think it was particularly "secret" - it's just that back then writing code took precedence over writing documentation or papers. Dave was particularly prolific in experimenting with all those Fuzzballs, and wasn't particularly secretive it! Whenever we saw weird new behavior in the "core gateways", one of the first things to look at was what the fuzzballs were sending our way. While I was at BBN, we created the notion of "Exterior Gateway Protocol" or EGP in response to Bob Kahn's request (while hanging on a subway strap in some city at some Internet meeting, if I remember correctly). This EGP was intended to provide a way to interface two gateways of different provenance - different manufacturers, or different owners, who were not entirely trusting of each other. So that permitted the "core gateways" and the "fuzzballs" to coexist peacefully. Well, mostly... In contrast to EGP, within a set of cooperating gateways/routers, an IGP (Internal Gateway Protocol) was used, and it was up to the owners of those particular systems to pick and configure an IGP as it suited their own needs. GGP became popular as an IGP, but it wasn't mandatory. Any router manufacturer could create whatever scheme that worked best for their situation. It was this architecture that enabled the coexistence of different implementations and approaches to form the composite Internet. I don't know exactly what IGP was used within the Fuzzball world - but that was exactly the point. You didn't have to know in order to interconnect. So, the overall architecture had EGP as the interface between any number of sub-internets, each possibly using it's own hardware, software, and internal protocols and algorithms, implementing it's own ideas of precedence, priority, queuing approaches, routing algorithms, and the like. All of the above occurred in the 80s - someone else is better equipped to talk about the 90s and beyond (I left BBN and went "up the stack" at Oracle). But as far as I know, "private ISPs" still have the same environment - when they connect "outside" they have to follow certain rules, but inside their own system they can use whatever hardware and software they like that has the behavior they desire. Of course, all of this relates to purely technical constraints. Legal ones are a whole new issue. I hope this has provided a bit of the "general history", at least from the very early days. /Jack Haverty ex-BBN Chief Network Architect ex-IAB (ICCB) member from way back when... Point Arena, CA From the.map at alum.mit.edu Wed Jan 28 00:04:12 2009 From: the.map at alum.mit.edu (Mike Padlipsky) Date: Wed, 28 Jan 2009 00:04:12 -0800 Subject: [ih] Secret precedence schemes back then In-Reply-To: <1233115445.3375.68.camel@localhost> References: <497E1F89.6040006@cs.tu-berlin.de> <1233115445.3375.68.camel@localhost> Message-ID: <200901280806.n0S869hB034040@zoom.lafn.org> At 08:04 PM 1/27/2009, Jack Haverty wrote: >Also, hardware was severely limited. I remember one router, connecting >ArpaNet and Satnet, which at one point had only enough memory to buffer >exactly ONE packet. So there wasn't much question of how to handle >priority in the "queue". this point deserves particular emphasis. while i didn't know your gateways were that minimal, i was keenly aware of the hardware limitations of the 'fuzzball' [and it might be nice if dave gave a rundown on just what the fuzzballs were for the benefit of newcomers ... and oldtimers who've forgotten], and any analogy between them and contemporary 'ISPs' must founder on precisely that point: today's hardware is so much more capable than 'yesterday's' that any attempt to reason by analogy to what used to be licit is, i submit, a flagrantly false analogy. in a sense, if you've got enough processing power, to say nothing of buffering, to be able to play nasty favoritism games with traffic in the first place, as you do nowadays, you can't use what used to be done in response to severe limitations on both processing power and buffering as an excuse for playing said nasty favoritism games. [in my humble but dogmatic opinion, of course.] not that i think the original question was intended to imply a connection between way back when and now, just that i'd like to try to head off any of the apparently unscrupulous big-money bit-pushers who want to play nasty favoritism games from inferring such a connection.... cheers, map [whose shoulder problems caused him to break down some time ago and create a 'signature' file to apologize for the lack of his formerly customary e-volubility -- and who's been employing shiftless typing for a long time now to spare his wristsnfingers, in case you didn't know ... and who's further broken down and done http://www.lafn.org/~ba213/mapstuff.html , rather grudgingly] From louie at transsys.com Wed Jan 28 06:52:47 2009 From: louie at transsys.com (Louis Mamakos) Date: Wed, 28 Jan 2009 09:52:47 -0500 Subject: [ih] Secret precedence schemes back then In-Reply-To: <200901280806.n0S869hB034040@zoom.lafn.org> References: <497E1F89.6040006@cs.tu-berlin.de> <1233115445.3375.68.camel@localhost> <200901280806.n0S869hB034040@zoom.lafn.org> Message-ID: <20090128145247.GA3184@ringworld.transsys.com> On Wed, Jan 28, 2009 at 12:04:12AM -0800, Mike Padlipsky wrote: > At 08:04 PM 1/27/2009, Jack Haverty wrote: > >Also, hardware was severely limited. I remember one router, connecting > >ArpaNet and Satnet, which at one point had only enough memory to buffer > >exactly ONE packet. So there wasn't much question of how to handle > >priority in the "queue". > > this point deserves particular emphasis. > > while i didn't know your gateways were that minimal, i was keenly > aware of the hardware limitations of the 'fuzzball' [and it might be > nice if dave gave a rundown on just what the fuzzballs were for the > benefit of newcomers ... and oldtimers who've forgotten], and any > analogy between them and contemporary 'ISPs' must founder on > precisely that point: today's hardware is so much more capable than > 'yesterday's' that any attempt to reason by analogy to what used to > be licit is, i submit, a flagrantly false analogy. While at the University of Maryland in this era, we had few (herd? gaggle?) of fuzzballs and they probably were more capable than some of the BBN LSI-11 routers between the ARPANET and MILNET at the time. It's probably a little hard to imagine, but budgets and process were difficult at the time, and the community took up a collection to replace the LSI-11/23 CPU boards in those BBN routers with the fancy new LSI-11/73 CPUs! I know that we at UMD "lent" a CPU board or two, as did some others at the time. Never got 'em back, but that's OK. The inventory tags were on the outside of the chassis :-) I'm sure Dave will chime in, but as I recall there's a couple of very nice papers floating around on the Fuzzball system. These days, you could have your very own, running inside a PDP-11 emulator at well over native speed. Back in the day, we had fuzzballs running on LSI-11/2, LSI-11/23 and LSI-11/73 (floating point, and everything!) Q-bus systems. The fuzzballs used the "HELLO" protocol for their internal routing, which was a distance-vector protocol based on delay. It also had the side-effect of being able to synchronize clocks and was the first step down the road to NTP, which consumed Dr. Mills for a couple of decades to come. While at UMD, Mike Petry and I built a HELLO implemention for a couple of differnet platforms. Mike did the original implementation in GATED I believe, and I included one in the UNIVAC 1100 TCP/IP implementation that we had built. Later, you could use HELLO in your Cisco routers. Of course, the fuzzballs were the first to tick NTP. An interesting contrast to what you typically see today is that fuzzballs had IP addresses associated with logical hosts (and there could be one or more nesting inside any given fuzzball). Network interfaces didn't have a strong notion of an IP address of their own, at least in the sense of what you see today. At UMD, we did a really early Ethernet implementation for the fuzzballs, with an InterLAN ethernet controller and building an ARP subnetwork driver. Because of the Fuzzball's notion of logical host addressing, the ARP implementation sort of naturally did proxy-ARP, though I didn't really recognize the novelty of that at the time. Louis Mamakos From mills at udel.edu Wed Jan 28 07:24:31 2009 From: mills at udel.edu (David Mills) Date: Wed, 28 Jan 2009 15:24:31 +0000 Subject: [ih] Secret precedence schemes back then In-Reply-To: <1233114794.3375.67.camel@localhost> References: <497E1F89.6040006@cs.tu-berlin.de> <497F3391.2000702@udel.edu> <20090127164228.GJ39727@cisco.com> <497F7950.3080200@udel.edu> <1233114794.3375.67.camel@localhost> Message-ID: <498078AF.2050405@udel.edu> Jack, The fuzzies had two throttles, one the current window size, the other the number of outstanding packets. That number was monitored not to exceed eight in view of the limited number of packet buffers in Ginny's gateways. When a source quench arrived, that number was reduced on the expectaion that Ginny or the fuzzies would hurl a source quench. So far as I remember, Ginny never did, but the fuzzaies did. It was an interesting time. Ginny was stuck with a real resource hog (Elf?) with a maximum throughtput of 10 pkt/s, but the fuzzies had much more memory and a throughput of 300 pkt/s. Jack Haverty wrote: >On Tue, 2009-01-27 at 21:14 +0000, David Mills wrote: > > >>but so far as I knew, nobody but the Fuzzballs >>actuall responded to source quencn. >> >> > >Errr, ummm, well...depends on what you mean by "respond". > >Since Source Quench was sent by a receiver when it had gotten so >overwhelmed that it threw away your packet, the obvious response from >the Sender was to re-send the packet immediately, since you had just >been told that it had been discarded. > >I can't remember exactly what the various TCP implementations did that I >was involved in. Or I could take the fifth amendment... > >Of course, the spec might have said something a bit different about what >a well-behaved TCP should do when you received a Source Quench. But I >don't recall there ever being any "certification" or the like that any >particular implementation was behaving correctly. As I remember, the >spec wasn't very specific. E.G., If you send one packet and get a >Source Quench back, what does it mean to "throttle back". > >And of course I can't remember whether the core gateways put such >"control" traffic at the front of the queue (it's important stuff!), or >discarded it (gaaak, more whining and noise from that complainer >host...). Or whether they looked at all. Possibly all three schemes, >over time. > >Of course, this whole Internet thing was a research project that was >supposed to go away and be replaced by the "real" system using ISO and >CCITT technology. > >Good thing it's been 23+ years Dave! > >/Jack > > > > From sbrim at cisco.com Wed Jan 28 07:30:20 2009 From: sbrim at cisco.com (Scott Brim) Date: Wed, 28 Jan 2009 10:30:20 -0500 Subject: [ih] Secret precedence schemes back then In-Reply-To: <20090128145247.GA3184@ringworld.transsys.com> References: <497E1F89.6040006@cs.tu-berlin.de> <1233115445.3375.68.camel@localhost> <200901280806.n0S869hB034040@zoom.lafn.org> <20090128145247.GA3184@ringworld.transsys.com> Message-ID: <20090128153020.GD389@cisco.com> Excerpts from Louis Mamakos on Wed, Jan 28, 2009 09:52:47AM -0500: > It's probably a little hard to imagine, but budgets and process were > difficult at the time, and the community took up a collection to > replace the LSI-11/23 CPU boards in those BBN routers with the fancy > new LSI-11/73 CPUs! I know that we at UMD "lent" a CPU board or two, > as did some others at the time. Was that when we crossed the 108 routes boundary? From mills at udel.edu Wed Jan 28 07:38:36 2009 From: mills at udel.edu (David Mills) Date: Wed, 28 Jan 2009 15:38:36 +0000 Subject: [ih] Secret precedence schemes back then In-Reply-To: <200901280806.n0S869hB034040@zoom.lafn.org> References: <497E1F89.6040006@cs.tu-berlin.de> <1233115445.3375.68.camel@localhost> <200901280806.n0S869hB034040@zoom.lafn.org> Message-ID: <49807BFC.4070302@udel.edu> Mike, I expected a honk from you. What made the difference was that the fuzzies enjoyed up to a megabyte of buffere mapped in multiple segments in an LSI-11/73 processor. The operating system implemented a virtual RS-11 system that had very little overhead., so was much faster than the BBN implementation. In fact, the network code was later incorporated in the US Postal service fax network. There are two SIGCOM papers in the 1986-1988 era, one describing the fuzzball, the other the NSFnet. There is a page about the fuzzies in the NSF archives. The technical history of the internet presentation at SIGCOM 99 is at www.eecis.udel.edu/~mills/colloq.httml. Dave Mike Padlipsky wrote: > At 08:04 PM 1/27/2009, Jack Haverty wrote: > >> Also, hardware was severely limited. I remember one router, connecting >> ArpaNet and Satnet, which at one point had only enough memory to buffer >> exactly ONE packet. So there wasn't much question of how to handle >> priority in the "queue". > > > this point deserves particular emphasis. > > while i didn't know your gateways were that minimal, i was keenly > aware of the hardware limitations of the 'fuzzball' [and it might be > nice if dave gave a rundown on just what the fuzzballs were for the > benefit of newcomers ... and oldtimers who've forgotten], and any > analogy between them and contemporary 'ISPs' must founder on precisely > that point: today's hardware is so much more capable than > 'yesterday's' that any attempt to reason by analogy to what used to be > licit is, i submit, a flagrantly false analogy. > > in a sense, if you've got enough processing power, to say nothing of > buffering, to be able to play nasty favoritism games with traffic in > the first place, as you do nowadays, you can't use what used to be > done in response to severe limitations on both processing power and > buffering as an excuse for playing said nasty favoritism games. [in > my humble but dogmatic opinion, of course.] > > not that i think the original question was intended to imply a > connection between way back when and now, just that i'd like to try to > head off any of the apparently unscrupulous big-money bit-pushers who > want to play nasty favoritism games from inferring such a connection.... > > > cheers, map > > [whose shoulder problems caused him to break down some time ago and > create a 'signature' file to apologize for the lack of his formerly > customary e-volubility -- and who's been employing shiftless typing > for a long time now to spare his wristsnfingers, in case you didn't > know ... and who's further broken down and done > http://www.lafn.org/~ba213/mapstuff.html , rather grudgingly] > From mills at udel.edu Wed Jan 28 08:00:12 2009 From: mills at udel.edu (David Mills) Date: Wed, 28 Jan 2009 16:00:12 +0000 Subject: [ih] Secret precedence schemes back then In-Reply-To: <20090128145247.GA3184@ringworld.transsys.com> References: <497E1F89.6040006@cs.tu-berlin.de> <1233115445.3375.68.camel@localhost> <200901280806.n0S869hB034040@zoom.lafn.org> <20090128145247.GA3184@ringworld.transsys.com> Message-ID: <4980810C.3070808@udel.edu> Louie, Geeze, nice to know somebody was watching. The fuzzies could do encapsulation, too, which is how HW and I had ARPAnet adresses at home. I was something liek host 2 on net 29 via the Mitre IMP and a foreign exchange line to Maryland. One of the first things I said to Steve Wolff on accepting the NSFnet job was that NSF specifically fund the gated project, as I viewed that as crucial to the success of the project, and so he did. You might have notices a scurry back then about mapping RIP metric to and from Hello metric. Somewhere there is a postion paper on that and the issue of avoiding loops. There should have been a paper on that. The ARP gimmick you mentioned was used at UDel to launch UDel traffic and fuzzie traffic on the same wire. The Ethernet interface at the time was a monster $3000 board. The IMP interface was almost as much. The last remaing fuzzball is in my basement. The original PDP11 code yet spins on a disk here. Someday somebody migh enjoy lighing it up in simulation. Meanwhile, I am having too much fun becoming a serious space nut and launching NTP on NASA space missions. See www.eecis.udel.edu/~mills/proximity.html. More to come, as my contract has just been renewed. Oh yeah, I have a contract for the second edition of my book. Suchis life in retirement. Dave Louis Mamakos wrote: >On Wed, Jan 28, 2009 at 12:04:12AM -0800, Mike Padlipsky wrote: > > >>At 08:04 PM 1/27/2009, Jack Haverty wrote: >> >> >>>Also, hardware was severely limited. I remember one router, connecting >>>ArpaNet and Satnet, which at one point had only enough memory to buffer >>>exactly ONE packet. So there wasn't much question of how to handle >>>priority in the "queue". >>> >>> >>this point deserves particular emphasis. >> >>while i didn't know your gateways were that minimal, i was keenly >>aware of the hardware limitations of the 'fuzzball' [and it might be >>nice if dave gave a rundown on just what the fuzzballs were for the >>benefit of newcomers ... and oldtimers who've forgotten], and any >>analogy between them and contemporary 'ISPs' must founder on >>precisely that point: today's hardware is so much more capable than >>'yesterday's' that any attempt to reason by analogy to what used to >>be licit is, i submit, a flagrantly false analogy. >> >> > >While at the University of Maryland in this era, we had few (herd? >gaggle?) of fuzzballs and they probably were more capable than some of >the BBN LSI-11 routers between the ARPANET and MILNET at the time. > >It's probably a little hard to imagine, but budgets and process were >difficult at the time, and the community took up a collection to >replace the LSI-11/23 CPU boards in those BBN routers with the fancy >new LSI-11/73 CPUs! I know that we at UMD "lent" a CPU board or two, >as did some others at the time. > >Never got 'em back, but that's OK. The inventory tags were on the >outside of the chassis :-) > >I'm sure Dave will chime in, but as I recall there's a couple of very >nice papers floating around on the Fuzzball system. These days, you >could have your very own, running inside a PDP-11 emulator at well >over native speed. Back in the day, we had fuzzballs running on >LSI-11/2, LSI-11/23 and LSI-11/73 (floating point, and everything!) >Q-bus systems. > >The fuzzballs used the "HELLO" protocol for their internal routing, >which was a distance-vector protocol based on delay. It also had the >side-effect of being able to synchronize clocks and was the first step >down the road to NTP, which consumed Dr. Mills for a couple of decades >to come. While at UMD, Mike Petry and I built a HELLO implemention >for a couple of differnet platforms. Mike did the original >implementation in GATED I believe, and I included one in the UNIVAC >1100 TCP/IP implementation that we had built. Later, you could use >HELLO in your Cisco routers. > >Of course, the fuzzballs were the first to tick NTP. > >An interesting contrast to what you typically see today is that >fuzzballs had IP addresses associated with logical hosts (and there >could be one or more nesting inside any given fuzzball). Network >interfaces didn't have a strong notion of an IP address of their own, >at least in the sense of what you see today. > >At UMD, we did a really early Ethernet implementation for the >fuzzballs, with an InterLAN ethernet controller and building an ARP >subnetwork driver. Because of the Fuzzball's notion of logical host >addressing, the ARP implementation sort of naturally did proxy-ARP, >though I didn't really recognize the novelty of that at the time. > >Louis Mamakos > > > From mills at udel.edu Wed Jan 28 08:06:15 2009 From: mills at udel.edu (David Mills) Date: Wed, 28 Jan 2009 16:06:15 +0000 Subject: [ih] Secret precedence schemes back then In-Reply-To: <20090128153020.GD389@cisco.com> References: <497E1F89.6040006@cs.tu-berlin.de> <1233115445.3375.68.camel@localhost> <200901280806.n0S869hB034040@zoom.lafn.org> <20090128145247.GA3184@ringworld.transsys.com> <20090128153020.GD389@cisco.com> Message-ID: <49808277.7070703@udel.edu> Scot, I'm not aware of the 108-router boundary; I was afraid that the EGP packet would grow to become fragmented and the unfuzzies would croak. Having been victims of SATnet, the fuzzies could fragment and reassemble, but not every other critter could. The dropdead packet size was 1500 octets in respect the then Ethernet max. However, the fuzzies died before that happend and the IBM/MCI era ensued with BGP.. Dave Scott Brim wrote: >Excerpts from Louis Mamakos on Wed, Jan 28, 2009 09:52:47AM -0500: > > >>It's probably a little hard to imagine, but budgets and process were >>difficult at the time, and the community took up a collection to >>replace the LSI-11/23 CPU boards in those BBN routers with the fancy >>new LSI-11/73 CPUs! I know that we at UMD "lent" a CPU board or two, >>as did some others at the time. >> >> > >Was that when we crossed the 108 routes boundary? > > > From sbrim at cisco.com Wed Jan 28 08:53:31 2009 From: sbrim at cisco.com (Scott Brim) Date: Wed, 28 Jan 2009 11:53:31 -0500 Subject: [ih] Secret precedence schemes back then In-Reply-To: <49808277.7070703@udel.edu> References: <497E1F89.6040006@cs.tu-berlin.de> <1233115445.3375.68.camel@localhost> <200901280806.n0S869hB034040@zoom.lafn.org> <20090128145247.GA3184@ringworld.transsys.com> <20090128153020.GD389@cisco.com> <49808277.7070703@udel.edu> Message-ID: <20090128165331.GA2498@cisco.com> Excerpts from David Mills on Wed, Jan 28, 2009 04:06:15PM +0000: > Scot, > > I'm not aware of the 108-router boundary; I was afraid that the EGP > packet would grow to become fragmented and the unfuzzies would croak. > Having been victims of SATnet, the fuzzies could fragment and > reassemble, but not every other critter could. The dropdead packet size > was 1500 octets in respect the then Ethernet max. However, the fuzzies > died before that happend and the IBM/MCI era ensued with BGP.. > > Dave What I'm remembering was when the mail gateways ran out of memory to hold routes. It was somewhere around 108. > > Scott Brim wrote: > >> Excerpts from Louis Mamakos on Wed, Jan 28, 2009 09:52:47AM -0500: >> >> >>> It's probably a little hard to imagine, but budgets and process were >>> difficult at the time, and the community took up a collection to >>> replace the LSI-11/23 CPU boards in those BBN routers with the fancy >>> new LSI-11/73 CPUs! I know that we at UMD "lent" a CPU board or two, >>> as did some others at the time. >>> >>> >> >> Was that when we crossed the 108 routes boundary? >> >> >> From jack at 3kitty.org Wed Jan 28 09:39:32 2009 From: jack at 3kitty.org (Jack Haverty) Date: Wed, 28 Jan 2009 09:39:32 -0800 Subject: [ih] Secret precedence schemes back then In-Reply-To: <200901280806.n0S869hB034040@zoom.lafn.org> References: <497E1F89.6040006@cs.tu-berlin.de> <1233115445.3375.68.camel@localhost> <200901280806.n0S869hB034040@zoom.lafn.org> Message-ID: <1233164372.22182.46.camel@localhost> On Wed, 2009-01-28 at 00:04 -0800, Mike Padlipsky wrote: > any > analogy between them and contemporary 'ISPs' must founder on > precisely that point: today's hardware is so much more capable than > 'yesterday's' that any attempt to reason by analogy to what used to > be licit is, i submit, a flagrantly false analogy. I'm not (yet) convinced. There's no doubt that today's hardware is vastly more capable than that of the 80s. But today's users are also vastly more demanding than those of the 80s. And cost needs to be in the analysis too. Our old favorites Telnet and Ftp are buried in the shadows. High-def streaming video, voice telephony, Bittorrent, and graphics-rich auto-refreshing websites are all over the place. Multiply that kind of traffic by 10s or 100s of millions of users and you've got some pretty heavy demands. My gut feel is that demand grows to consume available capacity, whether its networking or just plain computing. Kind of like Moore's Law, this principle has longevity. Sometimes my 2009 multi-core, multi-gigahertz, multi-gigabyte desktop computer seems slower than my 1970s 1-CPU, 1-megahertz, 0.001-gigabyte system was way back when. Same with my gigabit LAN versus my old 9.6kb lines. So, as long as you operate near the edge of resources, there's a need for some kind of policy to decide how to allocate limited resources. Getting back to the original question about what current ISPs do... I live in a very rural area, so the only viable Internet connection is via satellite, which can achieve download rates of about 800 kb/sec. My current ISP (HughesNet) has a policy for allocating limited bandwidth. If, in any given day, you download more than about 150MB of data, your service is clamped to a maximum of several 10s of kb/sec for the next 24 hours. It's like suddenly being on a slow dialup link, going to the "penalty box" for the next 24 hours. As long as you're doing "telnet-like" stuff, you can do it forever. If you insist on watching TV shows by streaming video, you won't do it for very long before being shut down for 24 hours. Lest you think this isn't so bad.... I bought a new Imac recently. It took about 5 minutes to unpack it, plug it in to the LAN, and find the power switch. It came up fine, and I worked through the setup - user name, etc. A little later that day, the Internet went dead. After some investigating, I discovered that my satellite connection had been throttled down due to hitting the threshold. I can't prove it, but I think that the Imac, fresh out of the box, of course was quite a bit behind the current release of system software. So when it found it had Internet access it simply "phoned home" and got the latest and greatest. What's a few hundred megabytes after all. Some types of traffic seem to be always shut off completely, e.g., BitTorrent. I've never been able to get a detailed spec of exactly what the policy is though. So, this ISP's current policy apparently has two classes of traffic: 1) things that are simply never allowed, and 2) everything else, which is allowed as long as it doesn't consume too much resource. Other satellite ISPs have different policies. E.G., Wildblue has a similar threshold scheme, but the "window" is 30 days instead of 24 hours. When I was at Oracle in the early 90s, part of my job involved deploying and managing the worldwide corporate network. This was a bunch (about a hundred) of commercial Cisco routers scattered all over the world - basically a private Internet with a single interconnect to the public Internet. It was a "private ISP", and there were quite a few similar networks in many corporations through the 90s at least. We struggled with the users' demands, moving stuff around the world. Database files are *big*. So are massive multimedia Powerpoint presentations and PDF documents. These were multiprotocol routers (IP, DECNET, Appletalk, etc) -- before TCP/IP beat all its competitors to dust. Some users decided it was convenient to have all their digital world with them as they went from place to place. The easiest way to do that was to simply drag this icon from here to there -- moving an entire disk image from one continent to another. We had to disable AppleTalk on transoceanic links to stop it. In that corporate world, policies were basically constrained to whatever the commercial routers could do. So you could probably get a good idea of the range of current policies by looking at the manuals for current commercial routers to see what's possible. Chance are, if something is possible in the router products, some ISP somewhere is doing it. So, although modern hardware is very capable, modern users are very demanding. And it still costs real money to deploy hardware and lease fiber-optic lines or satellite channels. Money enters into policy - I can get a larger "threshold" for my satellite service - just pay more money every month. It would be fascinating to see a comprehensive survey of ISP policies if someone had the time and interest to do the legwork. Or maybe people here can simply describe the policy that they see from their own Internet perspective. /Jack /Jack From jack at 3kitty.org Wed Jan 28 10:15:30 2009 From: jack at 3kitty.org (Jack Haverty) Date: Wed, 28 Jan 2009 10:15:30 -0800 Subject: [ih] Secret precedence schemes back then In-Reply-To: <498078AF.2050405@udel.edu> References: <497E1F89.6040006@cs.tu-berlin.de> <497F3391.2000702@udel.edu> <20090127164228.GJ39727@cisco.com> <497F7950.3080200@udel.edu> <1233114794.3375.67.camel@localhost> <498078AF.2050405@udel.edu> Message-ID: <1233166530.22182.63.camel@localhost> Wow, you have a good memory. I still have a copy of the TCP code that I wrote (first Unix TCP, on a PDP-11/40). I'll have to look and see what it did with Source Quench. When I first got that TCP running, it didn't have enough throughput to keep a model 33 TTY busy. I think it achieved the blinding speed of about 4 bytes/second! It turned out that 99% of the time was spent in the Unix kernel. So, that's when I became a Unix kernel hacker, to fix the O/S so the TCP could run. Talk about hardware limitations - the Unix system had 32 KB (yes, K) of memory. Adding code required first finding some error message to shorten; every character gone freed up a byte for code, and made the kernel output logs slightly more inscrutable. Needless to say, there wasn't a whole lot of flexibility to add much sophistication. Yes, it was an interesting time. The ELF implementation preceded me by a bit. As I remember, ELF made a good platform for a research project - where performance wasn't much of an issue. Part of the reason for moving the project internally within BBN was to get a more "operational" perspective. So it moved into the group where I was, along with all of the Arpanet crew. Much of the innards of the ensuing gateways were inspired, or at least influenced, by the Arpanet experience - the gateway crew was literally down the hall from the Arpanet crew. /Jack On Wed, 2009-01-28 at 15:24 +0000, David Mills wrote: > Jack, > > The fuzzies had two throttles, one the current window size, the other > the number of outstanding packets. That number was monitored not to > exceed eight in view of the limited number of packet buffers in Ginny's > gateways. When a source quench arrived, that number was reduced on the > expectaion that Ginny or the fuzzies would hurl a source quench. So far > as I remember, Ginny never did, but the fuzzaies did. > > It was an interesting time. Ginny was stuck with a real resource hog > (Elf?) with a maximum throughtput of 10 pkt/s, but the fuzzies had much > more memory and a throughput of 300 pkt/s. > > Jack Haverty wrote: > > >On Tue, 2009-01-27 at 21:14 +0000, David Mills wrote: > > > > > >>but so far as I knew, nobody but the Fuzzballs > >>actuall responded to source quencn. > >> > >> > > > >Errr, ummm, well...depends on what you mean by "respond". > > > >Since Source Quench was sent by a receiver when it had gotten so > >overwhelmed that it threw away your packet, the obvious response from > >the Sender was to re-send the packet immediately, since you had just > >been told that it had been discarded. > > > >I can't remember exactly what the various TCP implementations did that I > >was involved in. Or I could take the fifth amendment... > > > >Of course, the spec might have said something a bit different about what > >a well-behaved TCP should do when you received a Source Quench. But I > >don't recall there ever being any "certification" or the like that any > >particular implementation was behaving correctly. As I remember, the > >spec wasn't very specific. E.G., If you send one packet and get a > >Source Quench back, what does it mean to "throttle back". > > > >And of course I can't remember whether the core gateways put such > >"control" traffic at the front of the queue (it's important stuff!), or > >discarded it (gaaak, more whining and noise from that complainer > >host...). Or whether they looked at all. Possibly all three schemes, > >over time. > > > >Of course, this whole Internet thing was a research project that was > >supposed to go away and be replaced by the "real" system using ISO and > >CCITT technology. > > > >Good thing it's been 23+ years Dave! > > > >/Jack > > > > > > > > > > From the.map at alum.mit.edu Wed Jan 28 14:16:11 2009 From: the.map at alum.mit.edu (Mike Padlipsky) Date: Wed, 28 Jan 2009 14:16:11 -0800 Subject: [ih] Secret precedence schemes back then In-Reply-To: <1233164372.22182.46.camel@localhost> References: <497E1F89.6040006@cs.tu-berlin.de> <1233115445.3375.68.camel@localhost> <200901280806.n0S869hB034040@zoom.lafn.org> <1233164372.22182.46.camel@localhost> Message-ID: <4980D92B.30907@alum.mit.edu> Jack Haverty wrote: > My gut feel is that demand grows to consume available capacity, whether > its networking or just plain computing. Kind of like Moore's Law, this > principle has longevity. Sometimes my 2009 multi-core, multi-gigahertz, > multi-gigabyte desktop computer seems slower than my 1970s 1-CPU, > 1-megahertz, 0.001-gigabyte system was way back when. Same with my > gigabit LAN versus my old 9.6kb lines. > > So, as long as you operate near the edge of resources, there's a need > for some kind of policy to decide how to allocate limited resources. fair enough. but appealing to 'well, fuzzballs played favorites with telnet traffic' to [pretend to] justify contemporary self-serving policies desinged to enhance revenue or even do competitors down is, imhbdo, beyond the pale. b/t/w [1], the more relevant Law to cite is parkinson's. for the lazy, what i found in dear old wikipoodia seems to what's left of my memory to be close enough to 'right' that i decided not to make an exhaustive search for my copy of one or the other of his books on the topic: Work expands so as to fill the time available for its completion. A more succinct phrasing also commonly used is: Work expands to fill the time available. it may or may not be canonical, but i've long re-cast it as 'available resources get consumed' -- which may or may not even be original to me. shucks, for all i know it might well be in that book of his i know i've got around here somewhere.... b/t/w [2], there is a Padlipsky's Corollary to parkinson's law, to the effect that any available op code, however obscure, on/in a given processor will be used in at least one important program. [as far as i recall, he never admitted it, but i always suspected the late, intensely lamented noel morris of having consciously set out to use every available op code on the ge->honeywell 645 in at least one multics system program.] come to think of it, it's probably just a Padlipsky's Conjecture, tho; even if noel had admitted it, one instance does not a corollary make. b/t/w [3], while refreshing what's left of my memory on parkinson, dear old wikipoo led me to wirth's law, which explains your situation w/r/t your current whizbang iron's performing less well than your old lsi 11: Software is getting slower more rapidly than hardware becomes faster. [i'd almost arrived at that one independently whle thinking about your message, but didn't quite come up with so crisp a phrasing before i plinked the plinkable to wirth's law.] b/t/w [4], seemingly unrelated, but particularly charming, another bit of wikipoodinous serendippedinit is: Hofstadter's Law.... It always takes longer than you expect, even when you take Hofstadter's Law into account. [too early to tell whether it's a corollary, but it does occur to me that hofstadter's law is truer in californicatia than anywhere else.] and an i can't resist mentioning one to conclude with: either imacs' operating systems have gotten obscenely large or your satellite provider's limit is obscenely low or the problem you encountered after hooking up the new imac was a glitch, not a feature. 'a few hundred meagbytes' certainly seems to me to be a modest demand to make on an isp this century. ]gee, i wonder if you could get a dsl line to l.a. free-net, their geographical span is surprisingly large these years; presumably not, tho, since i'd imagine you'dve checked out such things before getting saddled with what i now think of as your saddleunlite isp....] cheers, map [whose shoulder problems caused him to break down some time ago and create a 'signature' file to apologize for the lack of his formerly customary e-volubility -- and who's been employing shiftless typing for a long time now to spare his wristsnfingers, in case you didn't know ... and who's further broken down and done http://www.lafn.org/~ba213/mapstuff.html, rather grudgingly] From LarrySheldon at cox.net Wed Jan 28 15:04:04 2009 From: LarrySheldon at cox.net (Larry Sheldon) Date: Wed, 28 Jan 2009 17:04:04 -0600 Subject: [ih] Secret precedence schemes back then In-Reply-To: <4980D92B.30907@alum.mit.edu> References: <497E1F89.6040006@cs.tu-berlin.de> <1233115445.3375.68.camel@localhost> <200901280806.n0S869hB034040@zoom.lafn.org> <1233164372.22182.46.camel@localhost> <4980D92B.30907@alum.mit.edu> Message-ID: <4980E464.7050408@cox.net> Mike Padlipsky wrote: > Hofstadter's Law.... It always takes longer than you expect, even when > you take Hofstadter's Law into account. Sheldon's Law speak to the general case: Things take longer than they take. How long will it take to get that job done? That will take two weeks. Better to add 10 per cent to the two weeks, then double it. Corollary: Things cost more than they cost. And I don't have robust evidence for this, but it seemed apparent to me that at least through the age of the 1100/90's, the third or fourth most commonly used instruction in the instruction set will not be provided in the follow-on models. From spencer at mcsr-labs.org Wed Jan 28 15:40:52 2009 From: spencer at mcsr-labs.org (Spencer Dawkins) Date: Wed, 28 Jan 2009 17:40:52 -0600 Subject: [ih] Secret precedence schemes back then References: <497E1F89.6040006@cs.tu-berlin.de> <1233115445.3375.68.camel@localhost> <200901280806.n0S869hB034040@zoom.lafn.org> <1233164372.22182.46.camel@localhost><4980D92B.30907@alum.mit.edu> <4980E464.7050408@cox.net> Message-ID: <35E95F42F9094D5CB13F98A41F70F0A3@china.huawei.com> I'm thinking (without finding my copy) that "The Mythical Man-Month" was the last book I read before identifying a slight variation of Sheldon's law... > Sheldon's Law speak to the general case: Things take longer than they > take. > > How long will it take to get that job done? That will take two weeks. > > Better to add 10 per cent to the two weeks, then double it. "... and then bump the units" - so when you double, you also slide "weeks" to "months". This worked better than it should have when I was still estimating software completion. Thanks for sharing, Spencer From jack at 3kitty.org Wed Jan 28 16:47:57 2009 From: jack at 3kitty.org (Jack Haverty) Date: Wed, 28 Jan 2009 16:47:57 -0800 Subject: [ih] Secret precedence schemes back then In-Reply-To: <4980D92B.30907@alum.mit.edu> References: <497E1F89.6040006@cs.tu-berlin.de> <1233115445.3375.68.camel@localhost> <200901280806.n0S869hB034040@zoom.lafn.org> <1233164372.22182.46.camel@localhost> <4980D92B.30907@alum.mit.edu> Message-ID: <1233190077.22182.96.camel@localhost> On Wed, 2009-01-28 at 14:16 -0800, Mike Padlipsky wrote: > 'a few hundred > meagbytes' certainly seems to me to be a modest demand to make on an > isp > this century You can get any capacity you want -- as long as you want to pay the monthly fee. Well, almost - it tops out at 1250MB/day for the "Business service". The 21st century version of SneakerNet is sending 4GB+ flash drives; with 3 day postal service you get the same throughput - 1250MB/day, at a total cost of less than $0.20/day. Sad. I have the "home" (lowest) level of service, which allows 200MB per day (sorry, used to be 150, they increased it I guess). See http://www.hughes.com/HUGHES/rooms/displaypages/layoutinitial?pageid=fairaccess if you're curious. I'm actually comparatively well off with 200MB/day and 800 kb/sec download at the cost of a few hundred up front for the equipment and $60/month. Many people here are on dialup, and the phone lines are bad enough that you get 24 kb/sec on a good (i.e., dry) day. If your house is in the trees, satellite doesn't work. So, this ISP uses cost as the means for dealing with different types of traffic. You can send anything you like, but some kinds of traffic will cost you more. The "precedence" is set by the user, making the decision of what kind of stuff to send. Send too much and *all* your traffic gets steerage-class service for the next 24 hours. Wildblue's policy is interesting. They have a similar threshold scheme, but implemented using a rolling 30 day window. When you exceed the cap, you're throttled down until that 30-day window sum drops below the threshold. So, if you (or your brand new computer) downloads enough stuff to exceed the threshold today, your service might be throttled for *a month* - until that big download number falls out of the rolling window. >From a user's perspective, it's mandatory to find every piece of software on all your computers or Internet-connected devices that has any "automatic update" feature and disable it. Also turn off any automatic multimedia features, which seem to be increasingly popular on web sites these days. Not always easy. Imagine in The Old Days -- if you FTPed a large enough file, the Internet would shut your host off for the next 24 hours, sending Source Quench packets of course. It would have been fascinating to implement that in the core gateways and watch the fur fly (from a distance...) We never thought of it. It wouldn't have been all that difficult after we got the gateways all talking to a NOC. Hmmm, Dave probably tried it in the Fuzzies...more secrets perhaps. It will be interesting to see what the new (US) administration's "rural broadband" thrust does to make this situation better. I'll volunteer as a beta tester! /Jack From the.map at alum.mit.edu Wed Jan 28 18:32:34 2009 From: the.map at alum.mit.edu (Mike Padlipsky) Date: Wed, 28 Jan 2009 18:32:34 -0800 Subject: [ih] Secret precedence schemes back then In-Reply-To: <1233190077.22182.96.camel@localhost> References: <497E1F89.6040006@cs.tu-berlin.de> <1233115445.3375.68.camel@localhost> <200901280806.n0S869hB034040@zoom.lafn.org> <1233164372.22182.46.camel@localhost> <4980D92B.30907@alum.mit.edu> <1233190077.22182.96.camel@localhost> Message-ID: <49811542.9060809@alum.mit.edu> Jack Haverty wrote: > See > http://www.hughes.com/HUGHES/rooms/displaypages/layoutinitial?pageid=fairaccess > if you're curious. ok, i was curious. now i'm furious. "The Fair Access Policy is straightforward. Based on an analysis of customer usage data, Hughes has established a download threshold for each of the HughesNet service plans that is well above the typical usage rates. Subscribers who exceed that threshold will experience reduced download speeds for approximately 24 hours." in the first place, even if They wanted to do an honest analysis, which one doubts, a priori, it's not clear they can, since the built-in ceilings foul the sample-space ... unless the analysis was done so long ago that the ceilings weren't in play, but then the typical usage patterns would've been different too. so that pious Policy paragraph strikes me as bigbizweasly. why should i/we take Their word for it that They've even performed the exercise rather than just setting some limits that They figure will reap them the most profit. but more strinkingly, i thought you said you were dead in the water after the new imac grabbed too many bits, yet here They're saying that you were just going to experience reduced download speeds. either you misspoke, i misread, or They lie. guess which one i think is right. [perhaps the tactic is an application of the redmond ratfinks' ploy of saying that if you don't 'activate' you'll get reduced functionality, and when you decide to see what that means, whenever you boot up you're told that if you don't 'activate' you'll get reduced functionality. period. hmmm. apparently no functionality is reduced functionality by the ratfinks.] if 'equity' were a concern and the realities of usage patterns [such as system upgrades, or even big patch batches or the occasional new version of open office, say] were taken into account, the least They could do would be to have a once a week or once a month 'hey, today i need more than your arbitrary limit's worth of bits so give me a once-in-a-while exemption, please'. > So, this ISP uses cost as the means for dealing with different types of > traffic. You can send anything you like, but some kinds of traffic will > cost you more. not at all clear to me. quantity of traffic appears to be the only determinant in play; types/kinds of traffic don't matter, simple bitcounts do ... unless there are some other factors behind the scenes of the plinkable you offered above, anyway. > The "precedence" is set by the user, making the decision > of what kind of stuff to send. Send too much and *all* your traffic > gets steerage-class service for the next 24 hours. huh? 'send'? thought we were talking about receiving. and then there's > From a user's perspective, it's mandatory to find every piece of > software on all your computers or Internet-connected devices that has > any "automatic update" feature and disable it. Also turn off any > automatic multimedia features, which seem to be increasingly popular on > web sites these days. Not always easy. not always easy for you, and probably damn near impossible for the technolaity. again, smells like profiteering on the part of the bigbiz weasels to mr. ah, but what a pleasant reminder of the nominally good, painfully old days: here we are again, arguing ... even if it is over matters of far less moment than whether bbn is obligated to send user/pass commands when doing netmail via ftp... the funny thing about this one is that i'm trying to stick up for what i think ought to be your rights as a consumer and you seem to be happy you can even get ripped off by the saddleunlite isp[s] because you live somewhere where you can't even get half the rated speed on the phonelines. still, i can't bring myself to say that you deserve to be ripped off just because you choose to live 'out there' somewhere. but as a probable sign of advancing years [sigh], as long as you're happy or content or not infuriated with your conectivity circumstances, fine by me. [and sure, i do realize that saddleunlite service is likely to be justifiably more expensive than dsl or cable, it's just that i think it's too much more expensive. but whatthehell, mehitabel, i also think dsl and cable are more expensive than they ought to be too. and much good will any of my fine fairness in pricing notions do me, you, or the lamp post.] cheers, map [whose shoulder problems caused him to break down some time ago and create a 'signature' file to apologize for the lack of his formerly customary e-volubility -- and who's been employing shiftless typing for a long time now to spare his wristsnfingers, in case you didn't know ... and who's further broken down and done http://www.lafn.org/~ba213/mapstuff.html, rather grudgingly] From bernie at fantasyfarm.com Wed Jan 28 21:18:27 2009 From: bernie at fantasyfarm.com (Bernie Cosell) Date: Thu, 29 Jan 2009 00:18:27 -0500 Subject: [ih] Secret precedence schemes back then In-Reply-To: <49811542.9060809@alum.mit.edu> References: <497E1F89.6040006@cs.tu-berlin.de>, <1233190077.22182.96.camel@localhost>, <49811542.9060809@alum.mit.edu> Message-ID: <4980F5D3.22378.8626BE3@bernie.fantasyfarm.com> On 28 Jan 2009 at 18:32, Mike Padlipsky wrote: > Jack Haverty wrote: > > > See > > http://www.hughes.com/HUGHES/rooms/displaypages/layoutinitial?pageid=fairaccess > > if you're curious. > > ok, i was curious. now i'm furious. > > "The Fair Access Policy is straightforward. .... > > in the first place, even if They wanted to do an honest analysis, which > one doubts, a priori, it's not clear they can, since the built-in > ceilings foul the sample-space Of course, but then they don't need to justify the usage limits at all, do they? They could just say "Here are the service plans, pick what you want to pay for". I looked at the plans and decided that the pro-plus plan was the 'sweet spot' [such as they are: the next bigger plan was a LOT more expensive [like $50/month] for not much more speed; Jack picked the Home plan [$20/month less than mine for about 1/2 the speed and throughtput]. You pays your money and you takes your choice. > but more strinkingly, i thought you said you were dead in the water > after the new imac grabbed too many bits, yet here They're saying that > you were just going to experience reduced download speeds. either you > misspoke, i misread, or They lie. guess which one i think is right. You're *effectively* dead in the water. For 24 hrs your speed is reduced to something in between 14.4 and 19K. Just loading the Hughesnet web page [to figure out how/why you've been FAPed] takes a minute or two. But it is definitely still up: I can/have managed to get all my email done and ssh'ing and running vi and doing low-bandwidth stuff like IMing all are pretty much unperturbed. > if 'equity' were a concern and the realities of usage patterns [such as > system upgrades, or even big patch batches or the occasional new version > of open office, say] were taken into account, the least They could do > would be to have a once a week or once a month 'hey, today i need more > than your arbitrary limit's worth of bits so give me a once-in-a-while > exemption, please'. Oh, they do. Jack left out that there's a "FAP free zone" **EVERY*DAY**. It used to be 3-5AM and for my plan it is 2-6AM [I have the pro-plus plan; I don't know if the "Home" plan has the expanded FAP-free times or not], and so with a decent download manager you can pull down a LOT of bits, all without any FAP problems or considerations. > not at all clear to me. quantity of traffic appears to be the only > determinant in play; types/kinds of traffic don't matter, simple > bitcounts do ... unless there are some other factors behind the scenes > of the plinkable you offered above, anyway. And by and large I think that's just right. If you're soaking down all the available bandwidth [and not being a good "sharing citizen"] I don't see why it should make a difference to the carrier if you're doing streaming HDTV, or multi-connection FTP, or P2P or whatever... You're chewing up the bandwidth and screwing up their statistics and slowing down everyone else, regardless of why. And contrary to what Jack said, I'm not sure I've ever encountered any "content-specific" limiting or filtering. I don't do P2P stuff much but I have run BitTorrent to pull stuff down and never noticed any problem [does BT count as a P2P app?] > and then there's > > > From a user's perspective, it's mandatory to find every piece of > > software on all your computers or Internet-connected devices that has > > any "automatic update" feature and disable it. Also turn off any > > automatic multimedia features, which seem to be increasingly popular on > > web sites these days. Not always easy. > > not always easy for you, and probably damn near impossible for the > technolaity. again, smells like profiteering on the part of the bigbiz > weasels to mr. Perhaps, and I don't know what it is like in Mac-land but there's very little that does that kind of thing in windows-land. The biggest offender was Windows Update, which is why they put in the 3AM grace- period originally. Most other programs *ask* you if you want to do updates and it is easy enough to say "no", then use a download manager to pull all of it in the next morning at 3AM. I have a LOT of crap on my assorted systems here and never once have had a FAP problem because of a renegade-automatic-update by anything. And yes, setting up Firefox *NOT* to autoload all the multimedia stuff helps a lot [although with pro-plus that's not as much of a problem.. I can even do YouTube a bit [if I don't overdo it..:o)]] > the funny thing about this one is that i'm trying to stick up for what i > think ought to be your rights as a consumer and you seem to be happy you > can even get ripped off by the saddleunlite isp[s] because you live > somewhere where you can't even get half the rated speed on the > phonelines. I don't think that consumers have any "rights" in this regard. Hughesnet invested the money to put up the satellite and they run the operation pretty well [aside from *VERY* few hiccups it mostly just hums along 24/7; I'm constantly amazed that a technology as tricky as that works as smoothly as it does] and they can charge what they please. As long as their conditions, services and fees are clear, what "rights" do I have other than to choose to do business with them or not? I can switch to NetZero any time I please... If you're pissed that one of the side effects of having Internet access in the US all be done by private outfits is that folks in the sticks can/will get ignored while the providers trip over themselves for the city-folks to get 1meg, 5meg, 10meg, 20meg connections... that's just the way it is. There's no cell phone coverage here, either, because it just isn't worth the cost for a carrier to put up towers (and I mean zero bars on your cell phone so you can't make a call, don't even ask about that fancy 3G stuff you city folk have). > ... still, i can't bring myself to say that you deserve to be > ripped off just because you choose to live 'out there' somewhere. I can't see any way for things to be much different, unless Obama can push through some Internet equivalent of the REA. There's just no financial incentive to "connect" us middle-of-nowhere folk. > .. but > as a probable sign of advancing years [sigh], as long as you're happy or > content or not infuriated with your conectivity circumstances, fine by me. I'm absoltely infuriated about it; so what? In fact, I told the county supervisors that if we had it to do over again we probably wouldn't have moved here, and if we do move again it *certainly* will not be to a place that isn't "connected". The supervisors listened, commiserated, and then went on to other business, like trying to figure out how to pay for getting the bridges repaired. They understand that the county is hurting because businesses that could bring jobs and money to the county won't relocate here because of the absence of broadband access, but there's not much that they can do about it. > [and sure, i do realize that saddleunlite service is likely to be > justifiably more expensive than dsl or cable, it's just that i think > it's too much more expensive. Ah, if you believe that AND you're a fan of capitalism, you would perceive that as an opportunity rather than an outrage. :o) /Bernie\ -- Bernie Cosell Fantasy Farm Fibers mailto:bernie at fantasyfarm.com Pearisburg, VA --> Too many people, too few sheep <-- From jack at 3kitty.org Wed Jan 28 23:11:36 2009 From: jack at 3kitty.org (Jack Haverty) Date: Thu, 29 Jan 2009 07:11:36 +0000 Subject: [ih] Secret precedence schemes back then In-Reply-To: <4980F5D3.22378.8626BE3@bernie.fantasyfarm.com> References: <497E1F89.6040006@cs.tu-berlin.de> , <1233190077.22182.96.camel@localhost>, <49811542.9060809@alum.mit.edu> <4980F5D3.22378.8626BE3@bernie.fantasyfarm.com> Message-ID: <1233213096.22182.124.camel@localhost> On Thu, 2009-01-29 at 00:18 -0500, Bernie Cosell wrote: ...pretty much exactly what I would have said. Thanks Bernie! Two clarifications: 1) Yes, my plan has a FAP-free time, from local midnite to 3 am. That's when I trigger software updates. Most mere mortals don't know how to do that though. Home plan was good enough for me - after retirement other toys compete with network-time. 2) My point about the ISP restricting types of traffic was simply that, by imposing constraints based on amount of data, they effectively discriminate against bandwidth-intense data types without actually having to make it an explicit policy. Yes, you can use a little bit of rich multimedia, but then you head to the penalty box. Delay-sensitive traffic types, such as VOIP or most gaming, pretty much never work just because of the physics of satellites and the speed of light. You can use some types of applications (i.e., some types of data), but not others, either due to the effect of ISP policy decisions or laws of physics. As you say, if you don't like the service, shop elsewhere. ========== We don't have cell service either, or cable TV, and barely have landline phones, so satellite Internet feels pretty good. On a hill nearby there's a curiously large but blank "billboard". It turns out that it's a reflector that bounces the microwave beam from the local Telco office over the mountain range to the rest of the world - at least when there aren't any flocks of birds in the way. DSL? Hah! There are some places where you can get a cell signal. Locals know where they are. We thought about painting large X's on the hotspots so they'd be easier to find. Then to make it more comfortable, maybe putting a little shed up to keep you out of the rain. About 2 feet square would do, maybe with a door to keep out the wind. You could simply take your cell phone into the shed and use it in comfort. We'd call them "phone booths". Since I used to be involved in running these kinds of IP networks, I understand what the ISPs are going through with the costs and user demands, so I guess I'm sympathetic. Satellite does work amazingly well most of the time. It's ironic that I'm just a few miles from the place where major transpacific cables come ashore, so a significant fraction of the world bandwidth is right beneath my feet (almost literally), but it's not accessible locally. The County wasn't very clever when negotiating to issue the permits they needed to trench miles along the middle of a main county road to bring all that fiber inland to the rest of the country. Hmmm, maybe there's another project for the backhoe.... /Jack From the.map at alum.mit.edu Thu Jan 29 00:10:07 2009 From: the.map at alum.mit.edu (Mike Padlipsky) Date: Thu, 29 Jan 2009 00:10:07 -0800 Subject: [ih] Secret precedence schemes back then In-Reply-To: <4980F5D3.22378.8626BE3@bernie.fantasyfarm.com> References: <497E1F89.6040006@cs.tu-berlin.de> <1233190077.22182.96.camel@localhost> <49811542.9060809@alum.mit.edu> <4980F5D3.22378.8626BE3@bernie.fantasyfarm.com> Message-ID: <200901290811.n0T8B03e082867@zoom.lafn.org> At 09:18 PM 1/28/2009, Bernie Cosell wrote: > > [and sure, i do realize that saddleunlite service is likely to be > > justifiably more expensive than dsl or cable, it's just that i think > > it's too much more expensive. > >Ah, if you believe that AND you're a fan of capitalism, you would >perceive that as an opportunity rather than an outrage. :o) i was going to let it go since jack seemed happy/content/unhostile enough, but if you must be so inconsiderate as to make me think deepish thoughts at my age, i guess i'm a fan of 'enlightened capitalism', which i just coined because i know i'd never get away with 'rational socialism'. not that i can define it rigorously, of course, which is just as well since it spares me the rigors of a trip to sweden [or is it norway for the econ one?], but it has something to do with distinguishing between 'more' and 'enough' and opting for the latter. what's particularly amusing about that, b/t/w, is that i became aware of the importance of distinguishing between more and enough because when i was on 'sound crew' in high school i must have seen half a dozen times the once-famous newsreel of the once-famous sam gompers [a big time labor leader in his time; not that i remember for sure when, nor that i care to bother to look it up; probably pre-ww ii, tho, and maybe even pre-original Great Depression] being asked 'mr. gompers, what does labor want?' and he chomped on his cigar and said/snarled: 'more.' even then, it occurred to me that that was a dumb thing to say, when what he/labor really needed and should have wanted was.... glad you enlightened me/us about the 'fap', i might add. rotten old jack got me all upset on his behalf, making think he was being hideously ripped off by the evil saddleunlite monsters and causing me to waste all that sympathy. ah, well, at least it did lead to the invention of enlightened capitalism. now to hope nobody else rattles my cage. the wrists are starting to hurt. cheers, map [whose shoulder problems caused him to break down some time ago and create a 'signature' file to apologize for the lack of his formerly customary e-volubility -- and who's been employing shiftless typing for a long time now to spare his wristsnfingers, in case you didn't know ... and who's further broken down and done http://www.lafn.org/~ba213/mapstuff.html , rather grudgingly]