From detlef.bosau at web.de Mon Sep 1 03:17:39 2014 From: detlef.bosau at web.de (Detlef Bosau) Date: Mon, 01 Sep 2014 12:17:39 +0200 Subject: [ih] why did CC happen at all? In-Reply-To: References: <5401FAF2.8070306@web.de> Message-ID: <540447C3.7060809@web.de> Am 31.08.2014 um 08:24 schrieb Vint Cerf: > ARPANET used an overly constrained system called RFNM (request for > next message). The mechanism was used to reserve space at the > destination IMP ("get a block" "got a block"). > That's what I referred to. > however it was possible to send multiple messages over different > "links" (logical term) and overload the network that way. It was also > possible to overload an intermediate IMP simply by sending traffic > between pairs (source/destination) that happened to pass through the > same intermediate IMP. That's what I missed. And this point is important. > > The Internet protocols did not use these methods and except for the > "congestion encountered" signal, all flow control was end/to/end which > still raised the possibility of intermediate router congestion. And that's my concern. The only compelling reasons for this seem to me: a) A concern about possible head of line blocking, b) a lack of computing power at the nodes. As far as I see, both problems can be overcome. > > The TCP flow control was an attempt to adjust to signals from the > receiver and signals (dropped packet, congestion encountered) from > intermediate nodes. Packet loss was treated as a flow control signal > leading to backoff of the retransmission mechanism of TCP. Slow start > was a crude way of sensing where the limits of capacity lay. However, this approach treated the "line" between sender and receiver, may I say it extremely dense, as a "queueing system where Little's law applies". (Which is a bit a contradiction in terms, because EITHER Little's law applies to a system EXCLUSIVE OR a system suffers from drops.) However, one could take this as an approximation. (Which is sometimes better, sometimes worse. As always in engineering. Basically, the world is a perfect one - unfortunately, what we actually have is only an approximation.) > > your claim that there is no congestion with "proper" implementation > may result in lower resource utilization. Circuit switching dedicates > capacity so there is no congestion, except for the failure to get a > circuit ("all circuits busy" is a congestion signal). But dedicating > capacity removes the implicit statistical multiplexing advantage of > packet switching. That's the very trade off. And I don't advocate circuit switching as an alternative. The strong shortcoming in circuit switching is the "fragmentation loss" of resources: Resources are assigned to users who don't really use them. What I have in mind is basically a flow layer with flow control (in a sense, Ford and Iyengar had something similar in mind in 2009) and - to exploit the flexibility of a packet switched network - an on demand scheduling of resources. > > v > > > > On Sat, Aug 30, 2014 at 12:25 PM, Detlef Bosau > wrote: > > I'm yet to understand the sitch from the ARPAnet to the Internet in > 1983, however, if this happened that way, that an Internet host sent a > message to its peer using the "message switching system" (may I > call it > that way?) in the ARPAnet, CC would be an "impossible fact". > > (Some German readers might enjoy this little text here: > http://ingeb.org/Lieder/palmstre.html) > > In the ARPAnet, congestion was avoided by flow control - and in fact, > actually, there is nothing like "congestion" when networks are > implemented correctly. > > To my understanding, "congestion" is an excuse for missing (or > botched) > flow control. > > So, what was the scenario, VJ describes in the congavoid paper? Up to > know, I always thought, the ARPAnet infrastructure was still in use, > although adopted by the Internet protocol stack, but I thought, IP > datagrams were sent like ARPAnet messages? > > Detlef > > -- > ------------------------------------------------------------------ > Detlef Bosau > Galileistra?e 30 > 70565 Stuttgart Tel.: +49 711 5208031 > > mobile: +49 172 6819937 > > skype: detlef.bosau > ICQ: 566129673 > detlef.bosau at web.de > http://www.detlef-bosau.de > > -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeanjour at comcast.net Mon Sep 1 03:28:03 2014 From: jeanjour at comcast.net (John Day) Date: Mon, 1 Sep 2014 06:28:03 -0400 Subject: [ih] Why did congestion happen at all? Re: why did CC happen at all? In-Reply-To: <5403CC1C.70207@gmail.com> References: <5401FAF2.8070306@web.de> <5402177E.5020403@web.de> <54022677.9050702@meetinghouse.net> <540233F3.5080403@web.de> <5402571F.4030901@web.de> <5402BD4D.1010309@meetinghouse.net> <54033DBE.50803@web.de> <540371C1.9010003@meetinghouse.net> <54038393.5020403@meetinghouse.net> <45357437-B743-4040-ADF5-F33156C1F83C@tony.li> <5403CC1C.70207@gmail.com> Message-ID: I like the analogy. That makes all sorts of sense. They are really separate problems that operate on different time scales. From control theory one knows that mixing time scales is seldom a good idea. ;-) At 1:30 PM +1200 9/1/14, Brian E Carpenter wrote: >On 01/09/2014 09:40, Tony Li wrote: >> On Aug 31, 2014, at 1:20 PM, Miles Fidelman >> wrote: >> >>> Last time I looked, bandwidth and delay were part of the metrics >>>used in at least some routing tables (e.g., Cisco EGIRP) - which >>>are at least indirect measures of congestion. Or am I wrong here? >> >> >> Yes, but that's maximum bandwidth and propagation delay, not >>queueing delay and folks don't actually enable that part of the >>metric anyway. Nothing dynamic here. >> >> Oh, and the last poor soul who did enable all of the dynamic >>features of (E)IGRP ended up with a violently unstable network. > >I vividly recall Ross Callon speaking about why QOS routing doesn't work >at an IETF meeting at least ten years ago, using the analogy of dancing >in your own shadow, with a practical demonstration that it can't be done. > > Brian From jeanjour at comcast.net Mon Sep 1 03:40:32 2014 From: jeanjour at comcast.net (John Day) Date: Mon, 1 Sep 2014 06:40:32 -0400 Subject: [ih] Why did congestion happen at all? Re: why did CC happen at all? In-Reply-To: <5403D953.22155.1256539B@bernie.fantasyfarm.com> References: <5401FAF2.8070306@web.de>, <5403AD94.6040707@dcrocker.net>, <5403C3C5.9020102@meetinghouse.net> <5403D953.22155.1256539B@bernie.fantasyfarm.com> Message-ID: Was it 6-8 am? I thought (and don't know why) that you guys had all night: midnight to 8. ;-) At Illinois because we were at one of the jump off points between the East and West Coast subnets and being only an hour behind you, we tended to see it when things weren't quite back to normal at 8am EST. ;-) There was a "Net's acting funny, must be Tuesday" ;-) saying. The West Coast guys probably didn't see it often since generally by late morning things were back to normal. At 10:26 PM -0400 8/31/14, Bernie Cosell wrote: >On 31 Aug 2014 at 20:54, Miles Fidelman wrote: > >> Dave Crocker wrote: > >> > My other understanding is that the extent of the direct benefit to >> users >> > wasn't quite anticipated, which made it increasingly difficult to >> make >> > changes to the net that could bring it down. So it was a few years >> > before they had to start explicitly scheduling time slots for >> experiments. >> >> I got to BBN a few years later, but my sense is that what was really >> unanticipated was the amount of operational use, by military types, >> which led pretty directly to the DDN. > >Dave's right: there were many "untested" technologies that went into the >ARPAnet and it was expected that there'd be an extended period in which >it'd be flaky, tests would crash it regularly, etc. It was a surprise >that when it was turned on it just kind of worked, which quickly changed >the focus of the work on it. There were still experiments run, but the >emphasis switched to "well, now we've got this damn thing, what are we >going to *do* with it". > >I think the "operational" use came less with military types than with >"business" types -- clerks, secretaries, etc. People were doing real, >routine work over the ARPAnet and very quickly were expecting it just to >"be up", Same thing with experiments being run [distributed OS, >encrypted speech, etc]: the fact of the ARPAnet _just_working_ was almost >taken for granted. > >I can't remember any more [maybe Dave does] but we had something like a >two hour slot once a week in which we could tinker with the IMP code >[something like 6-8AM on Tuesdays??] > > /Bernie\ > >-- >Bernie Cosell Fantasy Farm Fibers >mailto:bernie at fantasyfarm.com Pearisburg, VA > --> Too many people, too few sheep <-- From dave.walden.family at gmail.com Mon Sep 1 04:24:16 2014 From: dave.walden.family at gmail.com (Dave Walden) Date: Mon, 01 Sep 2014 07:24:16 -0400 Subject: [ih] ARPANET, operational/experimental In-Reply-To: References: <5401FAF2.8070306@web.de> <5402177E.5020403@web.de> <54022677.9050702@meetinghouse.net> <540233F3.5080403@web.de> <5402571F.4030901@web.de> <5402BD4D.1010309@meetinghouse.net> <54033DBE.50803@web.de> <5403AD94.6040707@dcrocker.net> Message-ID: <5404576a.e41f8c0a.1c4d.14fe@mx.google.com> At 08:56 PM 8/31/2014, Vint Cerf wrote: >The first time I met Bob Kahn and Dave Walden was on the occasion of >their visit to UCLA in late 1969 or early 1970 to conduct a series >of experiments to generate traffic and observe the way in which the >IMPs and their protocols and algorithms responded. Bob Kahn had >concerns that under certain conditions the network would lock up and >this visit was a first opportunity to use the then 4-node network to >stress its capacity. In the course of a couple of weeks, Bob >designed and I programmed a series of traffic generation and network >measurement experiments that indeed locked the network up multiple >times and in multiple ways. Reassembly lockup and store-and-forward >lockup stand out in my mind in particular. Dave W.: >In my mind the years of the ARPANET were a big experiment in whether >IMP hardware and sofware and host software and hardware and IMP/host >interfaces and host/host protocols and NWG collaboration could be >developed and made to work reliably enough such that the hosts could >talk to each other, experiments could be run (e.g., at the NMC, >trying packet voice, trying internetworkimg, trying improved >routimg, ...), and various users could try ("experiment") using the >net to do their more or less operational work (e.g., using a TIP to >access a mainframe computer rather than havin one's own, using the >net rather than specially leased lines to move seismic data from >Norway to Alexandria, ...). And certainly some of our "operational" >improvements seemed like experiments ("now that we have check summed >the routing packets, I wonder if we will see more of those routing >kind of crashes"). In the case of the lock-ups mentioned by Vint, my memory is that Bob and I could make them happen just using the IMPs' internal traffic generators, and then Vint and Bob did a more systematic series of tests. And then much study, a simulation, and a report done back at BBN eventually led to the IMP code changes that were implemented. See http://xn--brwolff-5wa.de/bbn-arpanet-reports-collection/BBN%20(1971)%20A%20Study%20of%20the%20Arpa%20Network%20Design%20and%20Performance%20(Report%202161).pdf In the meantime while the change was being developed, we asked the hosts to please try to avoid generating traffic of the kind now known to lock up the net, and they did avoid it and the net continued to be used "operationally" for its other work and experiments. We all had our roles in this big experiment. A significant part of the BBN "IMP guys" role was to "keep it running" while continuing to improve it and making changes to facilitate the experiments other groups were doing. I think the experiment of building the ARPANET and improving it for a number of years was a success. Dave (W.) -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave.walden.family at gmail.com Mon Sep 1 04:27:09 2014 From: dave.walden.family at gmail.com (Dave Walden) Date: Mon, 01 Sep 2014 07:27:09 -0400 Subject: [ih] Why did congestion happen at all? Re: why did CC happen at all? In-Reply-To: References: <5401FAF2.8070306@web.de> <5403AD94.6040707@dcrocker.net> <5403C3C5.9020102@meetinghouse.net> <5403D953.22155.1256539B@bernie.fantasyfarm.com> Message-ID: <54045810.43628c0a.030f.1430@mx.google.com> It was two hours in the morning just "before work". At 06:40 AM 9/1/2014, John Day wrote: >Was it 6-8 am? I thought (and don't know why) that you guys had all >night: midnight to 8. ;-) At Illinois because we were at one of >the jump off points between the East and West Coast subnets and >being only an hour behind you, we tended to see it when things >weren't quite back to normal at 8am EST. ;-) > >There was a "Net's acting funny, must be Tuesday" ;-) saying. The >West Coast guys probably didn't see it often since generally by late >morning things were back to normal. > >At 10:26 PM -0400 8/31/14, Bernie Cosell wrote: >>On 31 Aug 2014 at 20:54, Miles Fidelman wrote: >> >>> Dave Crocker wrote: >> >>> > My other understanding is that the extent of the direct benefit to >>> users >>> > wasn't quite anticipated, which made it increasingly difficult to >>> make >>> > changes to the net that could bring it down. So it was a few years >>> > before they had to start explicitly scheduling time slots for >>> experiments. >>> >>> I got to BBN a few years later, but my sense is that what was really >>> unanticipated was the amount of operational use, by military types, >>> which led pretty directly to the DDN. >> >>Dave's right: there were many "untested" technologies that went into the >>ARPAnet and it was expected that there'd be an extended period in which >>it'd be flaky, tests would crash it regularly, etc. It was a surprise >>that when it was turned on it just kind of worked, which quickly changed >>the focus of the work on it. There were still experiments run, but the >>emphasis switched to "well, now we've got this damn thing, what are we >>going to *do* with it". >> >>I think the "operational" use came less with military types than with >>"business" types -- clerks, secretaries, etc. People were doing real, >>routine work over the ARPAnet and very quickly were expecting it just to >>"be up", Same thing with experiments being run [distributed OS, >>encrypted speech, etc]: the fact of the ARPAnet _just_working_ was almost >>taken for granted. >> >>I can't remember any more [maybe Dave does] but we had something like a >>two hour slot once a week in which we could tinker with the IMP code >>[something like 6-8AM on Tuesdays??] >> >> /Bernie\ >> >>-- >>Bernie Cosell Fantasy Farm Fibers >>mailto:bernie at fantasyfarm.com Pearisburg, VA >> --> Too many people, too few sheep <-- -- home address: 12 Linden Rd., E. Sandwich, MA 02537 home ph=508-888-7655; cell ph = 503-757-3137 (often don't carry it) email address: dave at walden-family.com; website: http://www.walden-family.com/ From jeanjour at comcast.net Mon Sep 1 05:30:19 2014 From: jeanjour at comcast.net (John Day) Date: Mon, 1 Sep 2014 08:30:19 -0400 Subject: [ih] why did CC happen at all? In-Reply-To: <540447C3.7060809@web.de> References: <5401FAF2.8070306@web.de> <540447C3.7060809@web.de> Message-ID: Wasn't at least one of the lock up problems that ARPANET Messages could be up to 8 packets, and the IMP would reassemble a full Message before delivering it to the host. Hence, it was possible to get many partially reassembled messages in the destination IMP without enough memory to finish any of them. Since the IMP wouldn't discard anything, it froze. RFNMs made it pretty difficult to over load the IMPs with just packet traffic, right? For what it's worth, many years ago Phil Enslow told me he had reviewed the proposed ARPANET design (before my time) and had said it would lock up, but no one believed him. That is all I know about that. At 12:17 PM +0200 9/1/14, Detlef Bosau wrote: >Am 31.08.2014 um 08:24 schrieb Vint Cerf: > >>ARPANET used an overly constrained system >>called RFNM (request for next message). The >>mechanism was used to reserve space at the >>destination IMP ("get a block" "got a block"). >> > >That's what I referred to. > >>however it was possible to send multiple >>messages over different "links" (logical term) >>and overload the network that way. It was also >>possible to overload an intermediate IMP simply >>by sending traffic between pairs >>(source/destination) that happened to pass >>through the same intermediate IMP. >> > >That's what I missed. And this point is important. > >> >>The Internet protocols did not use these >>methods and except for the "congestion >>encountered" signal, all flow control was >>end/to/end which still raised the possibility >>of intermediate router congestion. >> > >And that's my concern. The only compelling >reasons for this seem to me: a) A concern about >possible head of line blocking, b) a lack of >computing power at the nodes. > >As far as I see, both problems can be overcome. > >> >>The TCP flow control was an attempt to adjust >>to signals from the receiver and signals >>(dropped packet, congestion encountered) from >>intermediate nodes. Packet loss was treated as >>a flow control signal leading to backoff of the >>retransmission mechanism of TCP. Slow start was >>a crude way of sensing where the limits of >>capacity lay. >> > >However, this approach treated the "line" >between sender and receiver, may I say it >extremely dense, as a "queueing system where >Little's law applies". >(Which is a bit a contradiction in terms, >because EITHER Little's law applies to a system >EXCLUSIVE OR a system suffers from drops.) > >However, one could take this as an >approximation. (Which is sometimes better, >sometimes worse. As always in engineering. >Basically, the world is a perfect one - >unfortunately, what we actually have is only an >approximation.) > >> >>your claim that there is no congestion with >>"proper" implementation may result in lower >>resource utilization. Circuit switching >>dedicates capacity so there is no congestion, >>except for the failure to get a circuit ("all >>circuits busy" is a congestion signal). But >>dedicating capacity removes the implicit >>statistical multiplexing advantage of packet >>switching. >> > >That's the very trade off. And I don't advocate >circuit switching as an alternative. The strong >shortcoming in circuit switching is the >"fragmentation loss" of resources: Resources are >assigned to users who don't really use them. >What I have in mind is basically a flow layer >with flow control (in a sense, Ford and Iyengar >had something similar in mind in 2009) and - to >exploit the flexibility of a packet switched >network - an on demand scheduling of resources. > >> >>v >> >> >> >>On Sat, Aug 30, 2014 at 12:25 PM, Detlef Bosau >><detlef.bosau at web.de> >>wrote: >> >>I'm yet to understand the sitch from the ARPAnet to the Internet in >>1983, however, if this happened that way, that an Internet host sent a >>message to its peer using the "message switching system" (may I call it >>that way?) in the ARPAnet, CC would be an "impossible fact". >> >>(Some German readers might enjoy this little text here: >>http://ingeb.org/Lieder/palmstre.html) >> >>In the ARPAnet, congestion was avoided by flow control - and in fact, >>actually, there is nothing like "congestion" when networks are >>implemented correctly. >> >>To my understanding, "congestion" is an excuse for missing (or botched) >>flow control. >> >>So, what was the scenario, VJ describes in the congavoid paper? Up to >>know, I always thought, the ARPAnet infrastructure was still in use, >>although adopted by the Internet protocol stack, but I thought, IP >>datagrams were sent like ARPAnet messages? >> >>Detlef >> >>-- >>------------------------------------------------------------------ >>Detlef Bosau >>Galileistra?e 30 >>70565 Stuttgart >>Tel.: +49 711 >>5208031 >> >> mobile: +49 172 >>6819937 >> skype: detlef.bosau >> ICQ: 566129673 >>detlef.bosau at web.de >> http://www.detlef-bosau.de >> >> > > >-- >------------------------------------------------------------------ >Detlef Bosau >Galileistra?e 30 >70565 Stuttgart Tel.: +49 711 5208031 > mobile: +49 172 6819937 > skype: detlef.bosau > ICQ: 566129673 >detlef.bosau at web.de >http://www.detlef-bosau.de -------------- next part -------------- An HTML attachment was scrubbed... URL: From mfidelman at meetinghouse.net Mon Sep 1 05:31:51 2014 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Mon, 01 Sep 2014 08:31:51 -0400 Subject: [ih] ARPANET, operational/experimental In-Reply-To: <5404576a.e41f8c0a.1c4d.14fe@mx.google.com> References: <5401FAF2.8070306@web.de> <5402177E.5020403@web.de> <54022677.9050702@meetinghouse.net> <540233F3.5080403@web.de> <5402571F.4030901@web.de> <5402BD4D.1010309@meetinghouse.net> <54033DBE.50803@web.de> <5403AD94.6040707@dcrocker.net> <5404576a.e41f8c0a.1c4d.14fe@mx.google.com> Message-ID: <54046737.1070503@meetinghouse.net> Dave, Vint, anybody else who was there at the very beginning: Dave Walden wrote: > At 08:56 PM 8/31/2014, Vint Cerf wrote: >> The first time I met Bob Kahn and Dave Walden was on the occasion of >> their visit to UCLA in late 1969 or early 1970 to conduct a series of >> experiments to generate traffic and observe the way in which the IMPs >> and their protocols and algorithms responded. Bob Kahn had concerns >> that under certain conditions the network would lock up and this >> visit was a first opportunity to use the then 4-node network to >> stress its capacity. In the course of a couple of weeks, Bob >> designed and I programmed a series of traffic generation and network >> measurement experiments that indeed locked the network up multiple >> times and in multiple ways. Reassembly lockup and store-and-forward >> lockup stand out in my mind in particular. > > Dave W.: >> In my mind the years of the ARPANET were a big experiment in whether >> IMP hardware and sofware and host software and hardware and IMP/host >> interfaces and host/host protocols and NWG collaboration could be >> developed and made to work reliably enough such that the hosts could >> talk to each other, experiments could be run (e.g., at the NMC, >> trying packet voice, trying internetworkimg, trying improved routimg, >> ...), and various users could try ("experiment") using the net to do >> their more or less operational work (e.g., using a TIP to access a >> mainframe computer rather than havin one's own, using the net rather >> than specially leased lines to move seismic data from Norway to >> Alexandria, ...). And certainly some of our "operational" >> improvements seemed like experiments ("now that we have check summed >> the routing packets, I wonder if we will see more of those routing >> kind of crashes"). > > In the case of the lock-ups mentioned by Vint, my memory is that Bob > and I could make them happen just using the IMPs' internal traffic > generators, and then Vint and Bob did a more systematic series of > tests. And then much study, a simulation, and a report done back at > BBN eventually led to the IMP code changes that were implemented. See > http://xn--brwolff-5wa.de/bbn-arpanet-reports-collection/BBN%20(1971)%20A%20Study%20of%20the%20Arpa%20Network%20Design%20and%20Performance%20(Report%202161).pdf > In > the meantime while the change was being developed, we asked the hosts > to please try to avoid generating traffic of the kind now known to > lock up the net, and they did avoid it and the net continued to be > used "operationally" for its other work and experiments. > > We all had our roles in this big experiment. A significant part of > the BBN "IMP guys" role was to "keep it running" while continuing to > improve it and making changes to facilitate the experiments other > groups were doing. I think the experiment of building the ARPANET and > improving it for a number of years was a success. > Since this list is all about "internet history...." - let's take this one step further: What do you recall about the "mindset" of the various people and organizations at the time - particularly at the VERY beginning (the RFP and proposal): Did people view this as - an engineering and operational project, with some experimental aspects, or, as Dave puts it, - as a "big experiment" first, framed as an engineering/operational project? Miles -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From jnc at mercury.lcs.mit.edu Mon Sep 1 05:32:37 2014 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 1 Sep 2014 08:32:37 -0400 (EDT) Subject: [ih] Why did congestion happen at all? Re: why did CC happen at all? Message-ID: <20140901123237.44DE418C0F4@mercury.lcs.mit.edu> > From: Brian E Carpenter > I vividly recall Ross Callon speaking about why QOS routing doesn't > work ... using the analogy of dancing in your own shadow, with a > practical demonstration that it can't be done. Err, no. First, 'QoS routing' != 'load-dependent routing' (depending on how you define 'QoS routing'). As John Day says, they are very different time scales. I take 'QoS routing' to mean 'different traffic groups have their paths selected independently, based on some characterics of the traffic _and_ links; and 'characteristics' can be an almost-infinite range, not just bandwidth and delay (which are so over-engineered these days that it's almost not worth thinking about them any more, in path selection). E.g. some traffic might want to keep off links which are in country 'X', whereas other traffic might be OK with going through 'X'. Although I suppose 'low delay' - the main measurable impact of congestion - might be seen as a QoS type, but to bring up John's point again, the time-scale can be different; there's a _big_ difference between _baseline_ high delay (e.g. a satellite hop), which one would approach with classic QoS type mechanisms, versus _dynamic_ (i.e. queuing) delays, which are _so_ dynamic that they almost inevitable will demand a specialized mechanism. Second, it is not at all impossible to do load-dependent path selection. The ARPANET showed it could be done (albeit on a 'smallish' network). TLi has alluded to sophisticated damping. But the best way to approach the instability issue is just to cut the Gordian knot and get rid of the feedback loop. One can do this if one uses a Map-Distribution/Explicit-Path-Selection architecture (one the many charms of that design quadrant). If one picks a path for flow X, and sets it up (doing reservations if needed), and _then doesn't vary it_ (unless a link fails), then by definition there cannot be any oscillation. As a nice side-effect, this also allows one to do 'pull' on the distribution of the load level information - in the setup - not 'push', thereby attacking another of the fundamental issues with large-scale load-dependent routing. This is a 'not enough rooom in this margin' gloss on a very complex issue (the interaction with the nice stat mux property that Vint alluded to is an issue, for example), but since this is the Internet-_History_ list, not the Network-_Design_ list, I'm going to stop there. Although of course, in practice (not theory), this is all irrelevant, since as we all know, routing == BGP, and there is no such thing as non-BGP-based routing. I fear the Internet has reached a stage of ossification, where nothing will change until something entirely new comes along, and does to it what the internal-combustion engine did to buggy whips. Noel From jeanjour at comcast.net Mon Sep 1 05:36:23 2014 From: jeanjour at comcast.net (John Day) Date: Mon, 1 Sep 2014 08:36:23 -0400 Subject: [ih] ARPANET, operational/experimental In-Reply-To: <5404576a.e41f8c0a.1c4d.14fe@mx.google.com> References: <5401FAF2.8070306@web.de> <5402177E.5020403@web.de> <54022677.9050702@meetinghouse.net> <540233F3.5080403@web.de> <5402571F.4030901@web.de> <5402BD4D.1010309@meetinghouse.net> <54033DBE.50803@web.de> <5403AD94.6040707@dcrocker.net> <5404576a.e41f8c0a.1c4d.14fe@mx.google.com> Message-ID: I agree with you, Dave. It *was* a success. And as I said earlier, we use to joke that it was almost too successful! We might have done more experimenting if you guys had gotten more wrong. ;-) To a very large extent, the whole ARPANET was an experiment on whether or not the whole idea was at all feasible. You had to build *one* to have a better idea of what else to look at and to know what was and wasn't important. To some extent, this is an example of my view that the thing about CS is that "we build what we measure." So we often have to build one to know what it is we need to build. ;-) In this case, the first one was pretty damn good! ;-) At 7:24 AM -0400 9/1/14, Dave Walden wrote: >At 08:56 PM 8/31/2014, Vint Cerf wrote: > >>The first time I met Bob Kahn and Dave Walden was on the occasion >>of their visit to UCLA in late 1969 or early 1970 to conduct a >>series of experiments to generate traffic and observe the way in >>which the IMPs and their protocols and algorithms responded. Bob >>Kahn had concerns that under certain conditions the network would >>lock up and this visit was a first opportunity to use the then >>4-node network to stress its capacity. In the course of a couple >>of weeks, Bob designed and I programmed a series of traffic >>generation and network measurement experiments that indeed locked >>the network up multiple times and in multiple ways. Reassembly >>lockup and store-and-forward lockup stand out in my mind in >>particular. >> > >Dave W.: > >>In my mind the years of the ARPANET were a big experiment in >>whether IMP hardware and sofware and host software and hardware and >>IMP/host interfaces and host/host protocols and NWG collaboration >>could be developed and made to work reliably enough such that the >>hosts could talk to each other, experiments could be run (e.g., at >>the NMC, trying packet voice, trying internetworkimg, trying >>improved routimg, ...), and various users could try ("experiment") >>using the net to do their more or less operational work (e.g., >>using a TIP to access a mainframe computer rather than havin one's >>own, using the net rather than specially leased lines to move >>seismic data from Norway to Alexandria, ...). And certainly some >>of our "operational" improvements seemed like experiments ("now >>that we have check summed the routing packets, I wonder if we will >>see more of those routing kind of crashes"). >> > >In the case of the lock-ups mentioned by Vint, my memory is that Bob >and I could make them happen just using the IMPs' internal traffic >generators, and then Vint and Bob did a more systematic series of >tests. And then much study, a simulation, and a report done back at >BBN eventually led to the IMP code changes that were implemented. >See > >http://xn--brwolff-5wa.de/bbn-arpanet-reports-collection/BBN%20(1971)%20A%20Study%20of%20the%20Arpa%20Network%20Design%20and%20Performance%20(Report%202161).pdf >In the meantime while the change was being developed, we asked the >hosts to please try to avoid generating traffic of the kind now >known to lock up the net, and they did avoid it and the net >continued to be used "operationally" for its other work and >experiments. > >We all had our roles in this big experiment. A significant part of >the BBN "IMP guys" role was to "keep it running" while continuing to >improve it and making changes to facilitate the experiments other >groups were doing. I think the experiment of building the ARPANET >and improving it for a number of years was a success. > >Dave (W.) From detlef.bosau at web.de Mon Sep 1 06:17:24 2014 From: detlef.bosau at web.de (Detlef Bosau) Date: Mon, 01 Sep 2014 15:17:24 +0200 Subject: [ih] Why did congestion happen at all? Re: why did CC happen at all? In-Reply-To: <5403956B.8050506@meetinghouse.net> References: <5401FAF2.8070306@web.de> <5402177E.5020403@web.de> <54022677.9050702@meetinghouse.net> <540233F3.5080403@web.de> <5402571F.4030901@web.de> <5402BD4D.1010309@meetinghouse.net> <54033DBE.50803@web.de> <54036D96.9040406@meetinghouse.net> <54038B2A.5010909@web.de> <5403956B.8050506@meetinghouse.net> Message-ID: <540471E4.9030800@web.de> Am 31.08.2014 um 23:36 schrieb Miles Fidelman: > Yes - ARPANET had a flow control mechanism. It also had congestion > control mechanisms. They were different. > Just to get the terminology clear: What is precisely the difference between flow control and congestion control? I think, that's the very question we're talking about., From detlef.bosau at web.de Mon Sep 1 06:17:24 2014 From: detlef.bosau at web.de (Detlef Bosau) Date: Mon, 01 Sep 2014 15:17:24 +0200 Subject: [ih] Why did congestion happen at all? Re: why did CC happen at all? In-Reply-To: <5403956B.8050506@meetinghouse.net> References: <5401FAF2.8070306@web.de> <5402177E.5020403@web.de> <54022677.9050702@meetinghouse.net> <540233F3.5080403@web.de> <5402571F.4030901@web.de> <5402BD4D.1010309@meetinghouse.net> <54033DBE.50803@web.de> <54036D96.9040406@meetinghouse.net> <54038B2A.5010909@web.de> <5403956B.8050506@meetinghouse.net> Message-ID: <540471E4.2060500@web.de> Am 31.08.2014 um 23:36 schrieb Miles Fidelman: > Yes - ARPANET had a flow control mechanism. It also had congestion > control mechanisms. They were different. > Just to get the terminology clear: What is precisely the difference between flow control and congestion control? I think, that's the very question we're talking about., From dave.walden.family at gmail.com Mon Sep 1 06:19:51 2014 From: dave.walden.family at gmail.com (Dave Walden) Date: Mon, 01 Sep 2014 09:19:51 -0400 Subject: [ih] why did CC happen at all? In-Reply-To: References: <5401FAF2.8070306@web.de> <540447C3.7060809@web.de> Message-ID: <54047279.30598c0a.77a2.208d@mx.google.com> i think, john, that you are talking about "reassembly lockup" per vint's message and the kahn-crowther report i referenced. it's described in that report, in a subsequent published paper by them, perhaps in our 1972 imp improvements paper, and perhaps in an NMC paper where Len put some more theory and data around our mistaken idea. At 08:30 AM 9/1/2014, John Day wrote: >Wasn't at least one of the lock up problems that >ARPANET Messages could be up to 8 packets, and >the IMP would reassemble a full Message before >delivering it to the host. Hence, it was >possible to get many partially reassembled >messages in the destination IMP without enough >memory to finish any of them. Since the IMP >wouldn't discard anything, it froze. > >RFNMs made it pretty difficult to over load the >IMPs with just packet traffic, right? > >For what it's worth, many years ago Phil Enslow >told me he had reviewed the proposed ARPANET >design (before my time) and had said it would >lock up, but no one believed him. That is all I know about that. > > >At 12:17 PM +0200 9/1/14, Detlef Bosau wrote: >>Am 31.08.2014 um 08:24 schrieb Vint Cerf: >>>ARPANET used an overly constrained system >>>called RFNM (request for next message). The >>>mechanism was used to reserve space at the >>>destination IMP ("get a block" "got a block"). >> >>That's what I referred to. >>>however it was possible to send multiple >>>messages over different "links" (logical term) >>>and overload the network that way. It was also >>>possible to overload an intermediate IMP >>>simply by sending traffic between pairs >>>(source/destination) that happened to pass through the same intermediate IMP. >> >>That's what I missed. And this point is important. >>> >>>The Internet protocols did not use these >>>methods and except for the "congestion >>>encountered" signal, all flow control was >>>end/to/end which still raised the possibility >>>of intermediate router congestion. >> >>And that's my concern. The only compelling >>reasons for this seem to me: a) A concern about >>possible head of line blocking, b) a lack of computing power at the nodes. >> >>As far as I see, both problems can be overcome. >>> >>>The TCP flow control was an attempt to adjust >>>to signals from the receiver and signals >>>(dropped packet, congestion encountered) from >>>intermediate nodes. Packet loss was treated as >>>a flow control signal leading to backoff of >>>the retransmission mechanism of TCP. Slow >>>start was a crude way of sensing where the limits of capacity lay. >> >>However, this approach treated the "line" >>between sender and receiver, may I say it >>extremely dense, as a "queueing system where Little's law applies". >>(Which is a bit a contradiction in terms, >>because EITHER Little's law applies to a system >>EXCLUSIVE OR a system suffers from drops.) >> >>However, one could take this as an >>approximation. (Which is sometimes better, >>sometimes worse. As always in engineering. >>Basically, the world is a perfect one - >>unfortunately, what we actually have is only an approximation.) >>> >>>your claim that there is no congestion with >>>"proper" implementation may result in lower >>>resource utilization. Circuit switching >>>dedicates capacity so there is no congestion, >>>except for the failure to get a circuit ("all >>>circuits busy" is a congestion signal). But >>>dedicating capacity removes the implicit >>>statistical multiplexing advantage of packet switching. >> >>That's the very trade off. And I don't advocate >>circuit switching as an alternative. The strong >>shortcoming in circuit switching is the >>"fragmentation loss" of resources: Resources >>are assigned to users who don't really use >>them. What I have in mind is basically a flow >>layer with flow control (in a sense, Ford and >>Iyengar had something similar in mind in 2009) >>and - to exploit the flexibility of a packet >>switched network - an on demand scheduling of resources. >>> >>>v >>> >>> >>> >>>On Sat, Aug 30, 2014 at 12:25 PM, Detlef Bosau >>><detlef.bosau at web.de> wrote: >>>I'm yet to understand the sitch from the ARPAnet to the Internet in >>>1983, however, if this happened that way, that an Internet host sent a >>>message to its peer using the "message switching system" (may I call it >>>that way?) in the ARPAnet, CC would be an "impossible fact". >>> >>>(Some German readers might enjoy this little text here: >>> >>>http://ingeb.org/Lieder/palmstre.html) >>> >>>In the ARPAnet, congestion was avoided by flow control - and in fact, >>>actually, there is nothing like "congestion" when networks are >>>implemented correctly. >>> >>>To my understanding, "congestion" is an excuse for missing (or botched) >>>flow control. >>> >>>So, what was the scenario, VJ describes in the congavoid paper? Up to >>>know, I always thought, the ARPAnet infrastructure was still in use, >>>although adopted by the Internet protocol stack, but I thought, IP >>>datagrams were sent like ARPAnet messages? >>> >>>Detlef >>> >>>-- >>>------------------------------------------------------------------ >>>Detlef Bosau >>>Galileistra?e 30 >>>70565 >>>Stuttgart Tel.: >>>+49 711 5208031 >>> >>>mobile: +49 172 6819937 >>> skype: detlef.bosau >>> ICQ: 566129673 >>>detlef.bosau at web.de >>>http://www.detlef-bosau.de >>> >> >> >>-- >>------------------------------------------------------------------ >>Detlef Bosau >>Galileistra?e 30 >>70565 Stuttgart Tel.: +49 711 5208031 >> mobile: +49 172 6819937 >> skype: detlef.bosau >> ICQ: 566129673 >>detlef.bosau at web.de >>http://www.detlef-bosau.de -- home address: 12 Linden Rd., E. Sandwich, MA 02537 home ph=508-888-7655; cell ph = 503-757-3137 (often don't carry it) email address: dave at walden-family.com; website: http://www.walden-family.com/ From detlef.bosau at web.de Mon Sep 1 06:27:27 2014 From: detlef.bosau at web.de (Detlef Bosau) Date: Mon, 01 Sep 2014 15:27:27 +0200 Subject: [ih] why did CC happen at all? In-Reply-To: References: <5401FAF2.8070306@web.de> <540447C3.7060809@web.de> Message-ID: <5404743F.4090102@web.de> Am 01.09.2014 um 14:30 schrieb John Day: > Re: [ih] why did CC happen at all? > Wasn't at least one of the lock up problems that ARPANET Messages > could be up to 8 packets, and the IMP would reassemble a full Message > before delivering it to the host. Hence, it was possible to get many > partially reassembled messages in the destination IMP without enough > memory to finish any of them. Since the IMP wouldn't discard > anything, it froze. But isn't this an implementation error? In a properly implemented flow control, a receiving node must not accept data for parts of a packet as long as he doesn't have the memory to reassemble the whole packet. > > RFNMs made it pretty difficult to over load the IMPs with just packet > traffic, right? > > For what it's worth, many years ago Phil Enslow told me he had > reviewed the proposed ARPANET design (before my time) and had said it > would lock up, but no one believed him. That is all I know about that. > dead locks in reassembly / flow control are a serious concern and must be carefully considered in the protocol design. Actually, this problem is the very reason for the cumulative ACK mechanism in TCP: The sender is made ALWAYS to fill up the receiver's window from the very left to the right by signalling exactly this sequence number to the sender. Otherwise, the receiver's buffer might be fully occupied with data - while there is a gap in the data flow as delivered to the application and the next part residing in the buffer - and no space to fill in the missing pieces. -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at redbarn.org Mon Sep 1 06:36:23 2014 From: paul at redbarn.org (P Vixie) Date: Mon, 01 Sep 2014 06:36:23 -0700 Subject: [ih] Why did congestion happen at all? Re: why did CC happen at all? In-Reply-To: <20140901123237.44DE418C0F4@mercury.lcs.mit.edu> References: <20140901123237.44DE418C0F4@mercury.lcs.mit.edu> Message-ID: <964bb484-1cf2-40e9-b2be-f96d28a5ac65@email.android.com> On September 1, 2014 5:32:37 AM PDT, jnc at mercury.lcs.mit.edu wrote: ... >I fear the Internet has reached a stage of ossification, where nothing >will >change until something entirely new comes along, and does to it what >the >internal-combustion engine did to buggy whips. Sadly, +1. We have seen the last end to end application to be built on something other than TCP/80, and it was the 1987 version of DNS. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. From jeanjour at comcast.net Mon Sep 1 07:01:35 2014 From: jeanjour at comcast.net (John Day) Date: Mon, 1 Sep 2014 10:01:35 -0400 Subject: [ih] why did CC happen at all? In-Reply-To: <5404743F.4090102@web.de> References: <5401FAF2.8070306@web.de> <540447C3.7060809@web.de> <5404743F.4090102@web.de> Message-ID: At 3:27 PM +0200 9/1/14, Detlef Bosau wrote: >Am 01.09.2014 um 14:30 schrieb John Day: > >>Re: [ih] why did CC happen at all? >>Wasn't at least one of the lock up problems that ARPANET Messages >>could be up to 8 packets, and the IMP would reassemble a full >>Message before delivering it to the host. Hence, it was possible to >>get many partially reassembled messages in the destination IMP >>without enough memory to finish any of them. Since the IMP wouldn't >>discard anything, it froze. >> > >But isn't this an implementation error? In a properly implemented >flow control, a receiving node must not accept data for parts of a >packet as long as he doesn't have the memory to reassemble the whole >packet. Well, not entirely. I believe and Vint should chime in here. That it was (at least for us at the time) the work that Vint and Bob did that argued that there was no amount of memory large enough to avoid the problem. At least that is what I remember from reading a paper that was distributed on the Net at the time. > >> >>RFNMs made it pretty difficult to over load the IMPs with just >>packet traffic, right? >> >>For what it's worth, many years ago Phil Enslow told me he had >>reviewed the proposed ARPANET design (before my time) and had said >>it would lock up, but no one believed him. That is all I know about >>that. >> > >dead locks in reassembly / flow control are a serious concern and >must be carefully considered in the protocol design. > >Actually, this problem is the very reason for the cumulative ACK >mechanism in TCP: The sender is made ALWAYS to fill up the >receiver's window from the very left to the right by signalling >exactly this sequence number to the sender. Otherwise, the >receiver's buffer might be fully occupied with data - while there is >a gap in the data flow as delivered to the application and the next >part residing in the buffer - and no space to fill in the missing >pieces. But we didn't have TCP then, and all of this stuff was pretty new. Remember you have to put yourself in the state of knowledge at the time, which wasn't the same everywhere. From jeanjour at comcast.net Mon Sep 1 06:57:53 2014 From: jeanjour at comcast.net (John Day) Date: Mon, 1 Sep 2014 09:57:53 -0400 Subject: [ih] why did CC happen at all? In-Reply-To: <54047279.30598c0a.77a2.208d@mx.google.com> References: <5401FAF2.8070306@web.de> <540447C3.7060809@web.de> <54047279.30598c0a.77a2.208d@mx.google.com> Message-ID: At 9:19 AM -0400 9/1/14, Dave Walden wrote: >i think, john, that you are talking about >"reassembly lockup" per vint's message and the >kahn-crowther report i referenced. it's >described in that report, in a subsequent >published paper by them, perhaps in our 1972 imp >improvements paper, and perhaps in an NMC paper >where Len put some more theory and data around >our mistaken idea. Yea, that was the one! ;-) But I assume that what Vint is talking about is other ways of creating lock ups, right? > > >At 08:30 AM 9/1/2014, John Day wrote: >>Wasn't at least one of the lock up problems >>that ARPANET Messages could be up to 8 packets, >>and the IMP would reassemble a full Message >>before delivering it to the host. Hence, it >>was possible to get many partially reassembled >>messages in the destination IMP without enough >>memory to finish any of them. Since the IMP >>wouldn't discard anything, it froze. >> >>RFNMs made it pretty difficult to over load the >>IMPs with just packet traffic, right? >> >>For what it's worth, many years ago Phil Enslow >>told me he had reviewed the proposed ARPANET >>design (before my time) and had said it would >>lock up, but no one believed him. That is all >>I know about that. >> >> >>At 12:17 PM +0200 9/1/14, Detlef Bosau wrote: >>>Am 31.08.2014 um 08:24 schrieb Vint Cerf: >>>>ARPANET used an overly constrained system >>>>called RFNM (request for next message). The >>>>mechanism was used to reserve space at the >>>>destination IMP ("get a block" "got a block"). >>> >>>That's what I referred to. >>>>however it was possible to send multiple >>>>messages over different "links" (logical >>>>term) and overload the network that way. It >>>>was also possible to overload an intermediate >>>>IMP simply by sending traffic between pairs >>>>(source/destination) that happened to pass >>>>through the same intermediate IMP. >>> >>>That's what I missed. And this point is important. >>>> >>>>The Internet protocols did not use these >>>>methods and except for the "congestion >>>>encountered" signal, all flow control was >>>>end/to/end which still raised the possibility >>>>of intermediate router congestion. >>> >>>And that's my concern. The only compelling >>>reasons for this seem to me: a) A concern >>>about possible head of line blocking, b) a >>>lack of computing power at the nodes. >>> >>>As far as I see, both problems can be overcome. >>>> >>>>The TCP flow control was an attempt to adjust >>>>to signals from the receiver and signals >>>>(dropped packet, congestion encountered) from >>>>intermediate nodes. Packet loss was treated >>>>as a flow control signal leading to backoff >>>>of the retransmission mechanism of TCP. Slow >>>>start was a crude way of sensing where the >>>>limits of capacity lay. >>> >>>However, this approach treated the "line" >>>between sender and receiver, may I say it >>>extremely dense, as a "queueing system where >>>Little's law applies". >>>(Which is a bit a contradiction in terms, >>>because EITHER Little's law applies to a >>>system EXCLUSIVE OR a system suffers from >>>drops.) >>> >>>However, one could take this as an >>>approximation. (Which is sometimes better, >>>sometimes worse. As always in engineering. >>>Basically, the world is a perfect one - >>>unfortunately, what we actually have is only >>>an approximation.) >>>> >>>>your claim that there is no congestion with >>>>"proper" implementation may result in lower >>>>resource utilization. Circuit switching >>>>dedicates capacity so there is no congestion, >>>>except for the failure to get a circuit ("all >>>>circuits busy" is a congestion signal). But >>>>dedicating capacity removes the implicit >>>>statistical multiplexing advantage of packet >>>>switching. >>> >>>That's the very trade off. And I don't >>>advocate circuit switching as an alternative. >>>The strong shortcoming in circuit switching is >>>the "fragmentation loss" of resources: >>>Resources are assigned to users who don't >>>really use them. What I have in mind is >>>basically a flow layer with flow control (in a >>>sense, Ford and Iyengar had something similar >>>in mind in 2009) and - to exploit the >>>flexibility of a packet switched network - an >>>on demand scheduling of resources. >>>> >>>>v >>>> >>>> >>>> >>>>On Sat, Aug 30, 2014 at 12:25 PM, Detlef >>>>Bosau >>>><detlef.bosau at web.de> >>>>wrote: >>>>I'm yet to understand the sitch from the ARPAnet to the Internet in >>>>1983, however, if this happened that way, that an Internet host sent a >>>>message to its peer using the "message switching system" (may I call it >>>>that way?) in the ARPAnet, CC would be an "impossible fact". >>>> >>>>(Some German readers might enjoy this little text here: >>>> >>>>http://ingeb.org/Lieder/palmstre.html) >>>> >>>>In the ARPAnet, congestion was avoided by flow control - and in fact, >>>>actually, there is nothing like "congestion" when networks are >>>>implemented correctly. >>>> >>>>To my understanding, "congestion" is an excuse for missing (or botched) >>>>flow control. >>>> >>>>So, what was the scenario, VJ describes in the congavoid paper? Up to >>>>know, I always thought, the ARPAnet infrastructure was still in use, >>>>although adopted by the Internet protocol stack, but I thought, IP >>>>datagrams were sent like ARPAnet messages? >>>> >>>>Detlef >>>> >>>>-- >>>>------------------------------------------------------------------ >>>>Detlef Bosau >>>>Galileistra?e 30 >>>>70565 Stuttgart >>>>Tel.: +49 711 >>>>5208031 >>>> >>>>mobile: +49 172 6819937 >>>> skype: detlef.bosau >>>> ICQ: 566129673 >>>>detlef.bosau at web.de http://www.detlef-bosau.de >>>> >>> >>> >>>-- >>>------------------------------------------------------------------ >>>Detlef Bosau >>>Galileistra?e 30 >>>70565 Stuttgart Tel.: +49 711 5208031 >>> mobile: +49 172 6819937 >>> skype: detlef.bosau >>> ICQ: 566129673 >>>detlef.bosau at web.de http://www.detlef-bosau.de > > >-- >home address: 12 Linden Rd., E. Sandwich, MA 02537 >home ph=508-888-7655; cell ph = 503-757-3137 (often don't carry it) >email address: dave at walden-family.com; website: >http://www.walden-family.com/ > From dave.walden.family at gmail.com Mon Sep 1 07:05:43 2014 From: dave.walden.family at gmail.com (Dave Walden) Date: Mon, 01 Sep 2014 10:05:43 -0400 Subject: [ih] why did CC happen at all? In-Reply-To: References: <5401FAF2.8070306@web.de> <540447C3.7060809@web.de> <54047279.30598c0a.77a2.208d@mx.google.com> Message-ID: <54047d3f.756b8c0a.2910.2961@mx.google.com> The report mentions more than one kind of lockup. At 09:57 AM 9/1/2014, John Day wrote: >At 9:19 AM -0400 9/1/14, Dave Walden wrote: >>i think, john, that you are talking about >>"reassembly lockup" per vint's message and the >>kahn-crowther report i referenced. it's >>described in that report, in a subsequent >>published paper by them, perhaps in our 1972 >>imp improvements paper, and perhaps in an NMC >>paper where Len put some more theory and data around our mistaken idea. > >Yea, that was the one! ;-) But I assume that >what Vint is talking about is other ways of creating lock ups, right? > > > >> >> >>At 08:30 AM 9/1/2014, John Day wrote: >>>Wasn't at least one of the lock up problems >>>that ARPANET Messages could be up to 8 >>>packets, and the IMP would reassemble a full >>>Message before delivering it to the >>>host. Hence, it was possible to get many >>>partially reassembled messages in the >>>destination IMP without enough memory to >>>finish any of them. Since the IMP wouldn't discard anything, it froze. >>> >>>RFNMs made it pretty difficult to over load >>>the IMPs with just packet traffic, right? >>> >>>For what it's worth, many years ago Phil >>>Enslow told me he had reviewed the proposed >>>ARPANET design (before my time) and had said >>>it would lock up, but no one believed him. That is all I know about that. >>> >>> >>>At 12:17 PM +0200 9/1/14, Detlef Bosau wrote: >>>>Am 31.08.2014 um 08:24 schrieb Vint Cerf: >>>>>ARPANET used an overly constrained system >>>>>called RFNM (request for next message). The >>>>>mechanism was used to reserve space at the >>>>>destination IMP ("get a block" "got a block"). >>>> >>>>That's what I referred to. >>>>>however it was possible to send multiple >>>>>messages over different "links" (logical >>>>>term) and overload the network that way. It >>>>>was also possible to overload an >>>>>intermediate IMP simply by sending traffic >>>>>between pairs (source/destination) that >>>>>happened to pass through the same intermediate IMP. >>>> >>>>That's what I missed. And this point is important. >>>>> >>>>>The Internet protocols did not use these >>>>>methods and except for the "congestion >>>>>encountered" signal, all flow control was >>>>>end/to/end which still raised the >>>>>possibility of intermediate router congestion. >>>> >>>>And that's my concern. The only compelling >>>>reasons for this seem to me: a) A concern >>>>about possible head of line blocking, b) a >>>>lack of computing power at the nodes. >>>> >>>>As far as I see, both problems can be overcome. >>>>> >>>>>The TCP flow control was an attempt to >>>>>adjust to signals from the receiver and >>>>>signals (dropped packet, congestion >>>>>encountered) from intermediate nodes. Packet >>>>>loss was treated as a flow control signal >>>>>leading to backoff of the retransmission >>>>>mechanism of TCP. Slow start was a crude >>>>>way of sensing where the limits of capacity lay. >>>> >>>>However, this approach treated the "line" >>>>between sender and receiver, may I say it >>>>extremely dense, as a "queueing system where Little's law applies". >>>>(Which is a bit a contradiction in terms, >>>>because EITHER Little's law applies to a >>>>system EXCLUSIVE OR a system suffers from drops.) >>>> >>>>However, one could take this as an >>>>approximation. (Which is sometimes better, >>>>sometimes worse. As always in engineering. >>>>Basically, the world is a perfect one - >>>>unfortunately, what we actually have is only an approximation.) >>>>> >>>>>your claim that there is no congestion with >>>>>"proper" implementation may result in lower >>>>>resource utilization. Circuit switching >>>>>dedicates capacity so there is no >>>>>congestion, except for the failure to get a >>>>>circuit ("all circuits busy" is a congestion >>>>>signal). But dedicating capacity removes the >>>>>implicit statistical multiplexing advantage of packet switching. >>>> >>>>That's the very trade off. And I don't >>>>advocate circuit switching as an alternative. >>>>The strong shortcoming in circuit switching >>>>is the "fragmentation loss" of resources: >>>>Resources are assigned to users who don't >>>>really use them. What I have in mind is >>>>basically a flow layer with flow control (in >>>>a sense, Ford and Iyengar had something >>>>similar in mind in 2009) and - to exploit the >>>>flexibility of a packet switched network - an >>>>on demand scheduling of resources. >>>>> >>>>>v >>>>> >>>>> >>>>> >>>>>On Sat, Aug 30, 2014 at 12:25 PM, Detlef >>>>>Bosau <detlef.bosau at web.de> wrote: >>>>>I'm yet to understand the sitch from the ARPAnet to the Internet in >>>>>1983, however, if this happened that way, that an Internet host sent a >>>>>message to its peer using the "message switching system" (may I call it >>>>>that way?) in the ARPAnet, CC would be an "impossible fact". >>>>> >>>>>(Some German readers might enjoy this little text here: >>>>> >>>>>http://ingeb.org/Lieder/palmstre.html) >>>>> >>>>>In the ARPAnet, congestion was avoided by flow control - and in fact, >>>>>actually, there is nothing like "congestion" when networks are >>>>>implemented correctly. >>>>> >>>>>To my understanding, "congestion" is an excuse for missing (or botched) >>>>>flow control. >>>>> >>>>>So, what was the scenario, VJ describes in the congavoid paper? Up to >>>>>know, I always thought, the ARPAnet infrastructure was still in use, >>>>>although adopted by the Internet protocol stack, but I thought, IP >>>>>datagrams were sent like ARPAnet messages? >>>>> >>>>>Detlef >>>>> >>>>>-- >>>>>------------------------------------------------------------------ >>>>>Detlef Bosau >>>>>Galileistra?e 30 >>>>>70565 Stuttgart Tel.: +49 711 5208031 >>>>> >>>>>mobile: +49 172 6819937 >>>>> skype: detlef.bosau >>>>> ICQ: 566129673 >>>>>detlef.bosau at web.de http://www.detlef-bosau.de >>>> >>>> >>>>-- >>>>------------------------------------------------------------------ >>>>Detlef Bosau >>>>Galileistra?e 30 >>>>70565 Stuttgart Tel.: +49 711 5208031 >>>> mobile: +49 172 6819937 >>>> skype: detlef.bosau >>>> ICQ: 566129673 >>>>detlef.bosau at web.de http://www.detlef-bosau.de >> >> >>-- >>home address: 12 Linden Rd., E. Sandwich, MA 02537 >>home ph=508-888-7655; cell ph = 503-757-3137 (often don't carry it) >>email address: dave at walden-family.com; >>website: http://www.walden-family.com/ -- home address: 12 Linden Rd., E. Sandwich, MA 02537 home ph=508-888-7655; cell ph = 503-757-3137 (often don't carry it) email address: dave at walden-family.com; website: http://www.walden-family.com/ From jnc at mercury.lcs.mit.edu Mon Sep 1 07:17:32 2014 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 1 Sep 2014 10:17:32 -0400 (EDT) Subject: [ih] Why did congestion happen at all? Re: why did CC happen at all? Message-ID: <20140901141732.6A66A18C0F4@mercury.lcs.mit.edu> > From: Detlef Bosau > What is precisely the difference between flow control and congestion > control? I think it would be hard to beat the definitions given in Davies' '72 paper: Flow control is about end-to-end control on individual 'connections' (in the generic sense of the term, i.e. not limited to a reliable stream); i.e. for the transmitter to make sure it does not send data faster than the ultimate consumer can deal with it. Congestion control is about too much traffic being offered to _the network_ between them, and often involves the interaction of _multiple_ connections (although a single connection can cause network congestion on its own, if the ends can produce/consume data faster than the network between them can carry it across. Noel From mfidelman at meetinghouse.net Mon Sep 1 07:28:43 2014 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Mon, 01 Sep 2014 10:28:43 -0400 Subject: [ih] Why did congestion happen at all? Re: why did CC happen at all? In-Reply-To: <964bb484-1cf2-40e9-b2be-f96d28a5ac65@email.android.com> References: <20140901123237.44DE418C0F4@mercury.lcs.mit.edu> <964bb484-1cf2-40e9-b2be-f96d28a5ac65@email.android.com> Message-ID: <5404829B.2010302@meetinghouse.net> P Vixie wrote: > > On September 1, 2014 5:32:37 AM PDT, jnc at mercury.lcs.mit.edu wrote: > ... >> I fear the Internet has reached a stage of ossification, where nothing >> will >> change until something entirely new comes along, and does to it what >> the >> internal-combustion engine did to buggy whips. > Sadly, +1. We have seen the last end to end application to be built on something other than TCP/80, and it was the 1987 version of DNS. That's overstating it a bit. Streaming protocols and XMPP come to mind. -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From mfidelman at meetinghouse.net Mon Sep 1 07:29:43 2014 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Mon, 01 Sep 2014 10:29:43 -0400 Subject: [ih] Why did congestion happen at all? Re: why did CC happen at all? In-Reply-To: <540471E4.9030800@web.de> References: <5401FAF2.8070306@web.de> <5402177E.5020403@web.de> <54022677.9050702@meetinghouse.net> <540233F3.5080403@web.de> <5402571F.4030901@web.de> <5402BD4D.1010309@meetinghouse.net> <54033DBE.50803@web.de> <54036D96.9040406@meetinghouse.net> <54038B2A.5010909@web.de> <5403956B.8050506@meetinghouse.net> <540471E4.9030800@web.de> Message-ID: <540482D7.5050605@meetinghouse.net> Detlef Bosau wrote: > Am 31.08.2014 um 23:36 schrieb Miles Fidelman: >> Yes - ARPANET had a flow control mechanism. It also had congestion >> control mechanisms. They were different. >> > Just to get the terminology clear: > > What is precisely the difference between flow control and congestion > control? > > I think, that's the very question we're talking about., Asked and answered, multiple times. Please stop. -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From jeanjour at comcast.net Mon Sep 1 07:44:05 2014 From: jeanjour at comcast.net (John Day) Date: Mon, 1 Sep 2014 10:44:05 -0400 Subject: [ih] Why did congestion happen at all? Re: why did CC happen at all? In-Reply-To: <20140901141732.6A66A18C0F4@mercury.lcs.mit.edu> References: <20140901141732.6A66A18C0F4@mercury.lcs.mit.edu> Message-ID: At 10:17 AM -0400 9/1/14, Noel Chiappa wrote: > > From: Detlef Bosau > > > What is precisely the difference between flow control and congestion > > control? That is in the spirit of what I have been using: Flow control is where feedback is co-located with the resource being controlled. Congestion control is where feedback is not co-located with the resource being controlled. Remove as many specifics about the implementation as possible. John > >I think it would be hard to beat the definitions given in Davies' '72 paper: > >Flow control is about end-to-end control on individual 'connections' (in the >generic sense of the term, i.e. not limited to a reliable stream); i.e. for >the transmitter to make sure it does not send data faster than the ultimate >consumer can deal with it. > >Congestion control is about too much traffic being offered to _the network_ >between them, and often involves the interaction of _multiple_ connections >(although a single connection can cause network congestion on its own, if the >ends can produce/consume data faster than the network between them can carry >it across. > > Noel From jpgs at ittc.ku.edu Mon Sep 1 08:48:55 2014 From: jpgs at ittc.ku.edu (James P.G. Sterbenz) Date: Mon, 1 Sep 2014 17:48:55 +0200 Subject: [ih] Why did congestion happen at all? Re: why did CC happen at all? In-Reply-To: <20140901141732.6A66A18C0F4@mercury.lcs.mit.edu> References: <20140901141732.6A66A18C0F4@mercury.lcs.mit.edu> Message-ID: On 1 Sep 2014, at 16:17, Noel Chiappa wrote: >> From: Detlef Bosau > >> What is precisely the difference between flow control and congestion >> control? > > I think it would be hard to beat the definitions given in Davies' '72 paper: > > Flow control is about end-to-end control on individual 'connections' (in the > generic sense of the term, i.e. not limited to a reliable stream); i.e. for > the transmitter to make sure it does not send data faster than the ultimate > consumer can deal with it. > > Congestion control is about too much traffic being offered to _the network_ > between them, and often involves the interaction of _multiple_ connections > (although a single connection can cause network congestion on its own, if the > ends can produce/consume data faster than the network between them can carry > it across. Exactly. I rephrase slightly when I lecture: Flow control is an (purely) end-to-end mechanism so that the sender does not overwhelm the receiver. Congestion control is a mechanism so that senders do not overwhelm the network, and requires interaction between the network and end systems. I intend to type a longer response to the Autobahn analogy when I?m on the plane back to Europe tomorrow, because it is very interesting and I use analogies such as this when I?m lecturing, but a couple of quick notes now. First, while I expect that Detlef drives on the Autobahnen far more often than I, I?ve experienced congestion on multiple occasions, including multiple times on the A8 near Stuttgart, IIRC. As a sanity check, I find in the Wikipedia (English) article [https://en.wikipedia.org/wiki/Bundesautobahn_8] "In combination with today's traffic this makes the A8 one of the most crowded and dangerous autobahns in Germany.? The pots at [http://www.auguszt.de/english/pics/stau.jpg] and [http://a123.g.akamai.net/f/123/12465/1d/media.canada.com/idl/wist/20130820/wist_20130820_early_d2_01_i001.jpg] also seem to confirm that congestion is possible on the Autobahnen, and there are many hits in Google Scholar for ?Autobahn congestion? papers. And it appears to be systemic: "A Deutsche Bank report says congestion on the autobahn system has reached crisis proportions with 20% of the 12,200km (7580 mile) network is heavily overloaded and chronically congested.? [http://tollroadsnews.com/news/german-toll-concession-closes-on-munich-augsburg-a8-autobahn] (if I were publishing this, I?d look for the original citation, of course). Second, cars are very different from packets in many respects, including physical existence, copies buffered at the source, range of velocities, laminar and sequential flow (vs. turbulent and parallel flow), and time scales of flow- and congestion-control feedback. But I the proper analogue for automobile flow control would be getting destination-based feedback from a *flow* of cars (which rarely exists, because most cars are individual transactions rather than caravans going between the same source-destination). Thus if a convoy (flow) of cars were all going to a carwash, the carwash might have a receive window to make sure that cars wouldn?t arrive faster than could enter the wash pipeline. This is completely orthogonal to the problem of many flows of cars entering the road network and congesting at its intersections and interchanges. This analogy is actually a very interesting case, and would make a good exam topic, as understanding where the analogue holds (and doesn?t) is a good indicator of understanding networking. Cheers, James --------------------------------------------------------------------- James P.G. Sterbenz jpgs@{ittc|eecs}.ku.edu jpgs at comp.lancs.ac.uk www.ittc.ku.edu/~jpgs 154 Nichols ITTC|EECS InfoLab21 Lancaster U +1 508 944 3067 The University of Kansas jpgs at tik.ee.ethz.ch jpgs@{acm|ieee|comsoc|computer|m.ieice}.org jpgsterbenz at gmail.com gplus.to/jpgs www.facebook.com/jpgsterbenz jpgs at ittc.ku.edu From detlef.bosau at web.de Mon Sep 1 09:12:37 2014 From: detlef.bosau at web.de (Detlef Bosau) Date: Mon, 01 Sep 2014 18:12:37 +0200 Subject: [ih] why did CC happen at all? In-Reply-To: References: <5401FAF2.8070306@web.de> <540447C3.7060809@web.de> <5404743F.4090102@web.de> Message-ID: <54049AF5.2070803@web.de> Am 01.09.2014 um 16:01 schrieb John Day: > > >> >> Actually, this problem is the very reason for the cumulative ACK >> mechanism in TCP: The sender is made ALWAYS to fill up the receiver's >> window from the very left to the right by signalling exactly this >> sequence number to the sender. Otherwise, the receiver's buffer might >> be fully occupied with data - while there is a gap in the data flow >> as delivered to the application and the next part residing in the >> buffer - and no space to fill in the missing pieces. > > But we didn't have TCP then, and all of this stuff was pretty new. > > Remember you have to put yourself in the state of knowledge at the > time, which wasn't the same everywhere. John, I did not make my statemtent carelessly. We have pretty the same problem in ARQ protocols in wireless networks and in TCP as well, so if you eventually would like to pursue a PhD in CS: This problem a) can be solved and b) solutions are implemented and available to the market ;-) It is not that rare that we encounter similar problems on more than one layer. However, as you know, I'm not satisfied with VJCC and its offsprings and flavours. I very much appreciate this work as a work around, wich tackled a very annyoing problem with affordable means - and remarkable success. Nevertheless we still have problems in network resource allocation, I sometimes wrote about wireless networks, where it is euphemistic to say VJCC is completely inadequate there. There are concerns with non greedy sources, flows with huge differences in their amount of data, BIC and CUBic are not really convincing, and the more I think about it is that these issues result from a lack in the underlying scheme for scheduling and resource allocation. So I at least want to propose a different way here. Although I frankly have to admit, that my frustration is rather deep here. Particularly as some colleagues have a certain attitude which we call in German "mauern", I don't know the English expression for it, that means that you are unwilling to listen to arguments but hide behind a wall of alleged knowledge, which is in fact a mixture of arrogance and stupidity. And as you know, there have been some colleagues who deeply hurt me VERY personally. Actually, VJCC is such a "mauer". "The Internet works and if you don't belive in VJCC, you are an idiot". Even if the words are somewhat more descent, this is rather offending. But I have to apologize for going very much off topic here. -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From jpgs at ittc.ku.edu Mon Sep 1 09:20:37 2014 From: jpgs at ittc.ku.edu (James P.G. Sterbenz) Date: Mon, 1 Sep 2014 18:20:37 +0200 Subject: [ih] Why did congestion happen at all? Re: why did CC happen at all? In-Reply-To: <540482D7.5050605@meetinghouse.net> References: <5401FAF2.8070306@web.de> <5402177E.5020403@web.de> <54022677.9050702@meetinghouse.net> <540233F3.5080403@web.de> <5402571F.4030901@web.de> <5402BD4D.1010309@meetinghouse.net> <54033DBE.50803@web.de> <54036D96.9040406@meetinghouse.net> <54038B2A.5010909@web.de> <5403956B.8050506@meetinghouse.net> <540471E4.9030800@web.de> <540482D7.5050605@meetinghouse.net> Message-ID: <301DC3CD-CEE8-4706-AEB7-B7B386A27CEF@ittc.ku.edu> On 1 Sep 2014, at 16:29, Miles Fidelman wrote: > Detlef Bosau wrote: >> Am 31.08.2014 um 23:36 schrieb Miles Fidelman: >>> Yes - ARPANET had a flow control mechanism. It also had congestion >>> control mechanisms. They were different. >>> >> Just to get the terminology clear: >> >> What is precisely the difference between flow control and congestion >> control? >> >> I think, that's the very question we're talking about., > > Asked and answered, multiple times. Please stop. This really is Networking 101 and is an exam question every year in my first networking course (as is the difference between routing and forwarding, and the difference between the transport and link layers). Have you read the Kurose and Ross textbook that explains these concepts very well? http://www.pearsonhighered.com/cs-resources/products/product.html#product,isbn=0132856204 Cheers, James --------------------------------------------------------------------- James P.G. Sterbenz jpgs@{ittc|eecs}.ku.edu jpgs at comp.lancs.ac.uk www.ittc.ku.edu/~jpgs 154 Nichols ITTC|EECS InfoLab21 Lancaster U +1 508 944 3067 The University of Kansas jpgs at tik.ee.ethz.ch jpgs@{acm|ieee|comsoc|computer|m.ieice}.org jpgsterbenz at gmail.com gplus.to/jpgs www.facebook.com/jpgsterbenz jpgs at ittc.ku.edu From louie at transsys.com Mon Sep 1 09:34:06 2014 From: louie at transsys.com (Louis Mamakos) Date: Mon, 1 Sep 2014 12:34:06 -0400 Subject: [ih] why did CC happen at all? In-Reply-To: <54049AF5.2070803@web.de> References: <5401FAF2.8070306@web.de> <540447C3.7060809@web.de> <5404743F.4090102@web.de> <54049AF5.2070803@web.de> Message-ID: On Sep 1, 2014, at 12:12 PM, Detlef Bosau wrote: > We have pretty the same problem in ARQ protocols in wireless networks > and in TCP as well, so if you eventually would like to pursue a PhD in CS: > This problem a) can be solved and b) solutions are implemented and > available to the market ;-) So actually, you don't. Perhaps from a theoretical perspective you believe this to be the case, but the real operational, engineering and business realities are different. Some given wireless network is tightly controlled and engineered by some single entity. When you talk about congestion and flow control over the internet, many/most of those flows transit more than one operator's network. And the scaling problems are different, and the revenue models are very different. You might well ask why we don't have end-to-end QoS treatment for traffic over the Internet. It is very much more a business problem than it is turning the knobs on the routers to honor diffserv markings. Since this is about the history of the Internet, you might look at the INTSERV working group history in the IETF that attempts to address end-to-end traffic and enhanced service models. I think the only significant part of this work in operation today is RSVP, used to signal MPLS LSP establishment when doing traffic engineering. But for bulk flows on an ISP backbone, not individual connections/associations. Louis Mamakos From adrian at creative.net.au Mon Sep 1 11:01:54 2014 From: adrian at creative.net.au (Adrian Chadd) Date: Mon, 1 Sep 2014 11:01:54 -0700 Subject: [ih] why did CC happen at all? In-Reply-To: References: <5401FAF2.8070306@web.de> <540447C3.7060809@web.de> <5404743F.4090102@web.de> <54049AF5.2070803@web.de> Message-ID: On 1 September 2014 09:34, Louis Mamakos wrote: > > On Sep 1, 2014, at 12:12 PM, Detlef Bosau wrote: > >> We have pretty the same problem in ARQ protocols in wireless networks >> and in TCP as well, so if you eventually would like to pursue a PhD in CS: >> This problem a) can be solved and b) solutions are implemented and >> available to the market ;-) > > So actually, you don't. Perhaps from a theoretical perspective you > believe this to be the case, but the real operational, engineering and > business realities are different. > > Some given wireless network is tightly controlled and engineered by > some single entity. When you talk about congestion and flow control > over the internet, many/most of those flows transit more than one > operator's network. And the scaling problems are different, and > the revenue models are very different. When you stop thinking about 802.11 as "MAC" and start thinking about it as "RF", it's slightly different. There -are- external entities also doing traffic (802.11 and otherwise) on the same overlapping RF space as you. There are also external (and internal, for completeness) sources of noise. You don't have that tight control. So yes, congestion control and QoS implementations on 802.11 networks end up having to take non-local-entity inputs into account. But yes, the scaling and revenue problems are different. -adrian (I hate to feed the troll, but I also dislike bad assumptions..) From detlef.bosau at web.de Mon Sep 1 11:10:02 2014 From: detlef.bosau at web.de (Detlef Bosau) Date: Mon, 01 Sep 2014 20:10:02 +0200 Subject: [ih] why did CC happen at all? In-Reply-To: References: <5401FAF2.8070306@web.de> <540447C3.7060809@web.de> <5404743F.4090102@web.de> <54049AF5.2070803@web.de> Message-ID: <5404B67A.50709@web.de> Am 01.09.2014 um 18:34 schrieb Louis Mamakos: > On Sep 1, 2014, at 12:12 PM, Detlef Bosau wrote: > >> We have pretty the same problem in ARQ protocols in wireless networks >> and in TCP as well, so if you eventually would like to pursue a PhD in CS: >> This problem a) can be solved and b) solutions are implemented and >> available to the market ;-) > So actually, you don't. Perhaps from a theoretical perspective you > believe this to be the case, but the real operational, engineering and > business realities are different. I did not write, that all implementations are correct. I wrote that the problem is solved. > > Some given wireless network is tightly controlled and engineered by > some single entity. When you talk about congestion and flow control > over the internet, many/most of those flows transit more than one > operator's network. And the scaling problems are different, and > the revenue models are very different. Nasty analogy: Windows exist. So do you think, that writing operating systems is still an unsolved problem? > You might well ask why we don't have end-to-end QoS treatment for > traffic over the Internet. It is very much more a business problem > than it is turning the knobs on the routers to honor diffserv markings. I can write my own assessment here: The success story of TCP/IP is the story of best effort networks. There are dozens of QoS approaches and architectures. And it doesn't matter (for the reasons above) that there are networks which don't support QoS. Actually, best effort networks became widely accepted. Hence, any approach for congestion control and flow control must provide for best effort services. As you mention INTSERV: To the best of my knowlege, INTSERV was, at least, not generally deployed in the whole Internet ;-) > -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From brian.e.carpenter at gmail.com Mon Sep 1 13:04:00 2014 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Tue, 02 Sep 2014 08:04:00 +1200 Subject: [ih] Why did congestion happen at all? Re: why did CC happen at all? In-Reply-To: <20140901123237.44DE418C0F4@mercury.lcs.mit.edu> References: <20140901123237.44DE418C0F4@mercury.lcs.mit.edu> Message-ID: <5404D130.7080608@gmail.com> On 02/09/2014 00:32, Noel Chiappa wrote: > > From: Brian E Carpenter > > > I vividly recall Ross Callon speaking about why QOS routing doesn't > > work ... using the analogy of dancing in your own shadow, with a > > practical demonstration that it can't be done. > > Err, no. Well, nevertheless, he did, at the QOSR BOF at IETF 36 (Montreal). Unfortunately there don't seem to be any slides on line. > > First, 'QoS routing' != 'load-dependent routing' (depending on how you define > 'QoS routing'). Indeed. But that was a BOF, where the distinctions were being clarified. Ross was mainly making the point about timescales (speed of light vs speed of dancing feet). Brian > As John Day says, they are very different time scales. I take > 'QoS routing' to mean 'different traffic groups have their paths selected > independently, based on some characterics of the traffic _and_ links; and > 'characteristics' can be an almost-infinite range, not just bandwidth and > delay (which are so over-engineered these days that it's almost not worth > thinking about them any more, in path selection). E.g. some traffic might > want to keep off links which are in country 'X', whereas other traffic might > be OK with going through 'X'. > > Although I suppose 'low delay' - the main measurable impact of congestion - > might be seen as a QoS type, but to bring up John's point again, the > time-scale can be different; there's a _big_ difference between _baseline_ > high delay (e.g. a satellite hop), which one would approach with classic QoS > type mechanisms, versus _dynamic_ (i.e. queuing) delays, which are _so_ > dynamic that they almost inevitable will demand a specialized mechanism. > > Second, it is not at all impossible to do load-dependent path selection. The > ARPANET showed it could be done (albeit on a 'smallish' network). TLi has > alluded to sophisticated damping. But the best way to approach the > instability issue is just to cut the Gordian knot and get rid of the feedback > loop. > > One can do this if one uses a Map-Distribution/Explicit-Path-Selection > architecture (one the many charms of that design quadrant). If one picks a > path for flow X, and sets it up (doing reservations if needed), and _then > doesn't vary it_ (unless a link fails), then by definition there cannot be > any oscillation. As a nice side-effect, this also allows one to do 'pull' on > the distribution of the load level information - in the setup - not 'push', > thereby attacking another of the fundamental issues with large-scale > load-dependent routing. > > This is a 'not enough rooom in this margin' gloss on a very complex issue > (the interaction with the nice stat mux property that Vint alluded to is an > issue, for example), but since this is the Internet-_History_ list, not the > Network-_Design_ list, I'm going to stop there. > > > Although of course, in practice (not theory), this is all irrelevant, since > as we all know, routing == BGP, and there is no such thing as > non-BGP-based routing. > > I fear the Internet has reached a stage of ossification, where nothing will > change until something entirely new comes along, and does to it what the > internal-combustion engine did to buggy whips. > > Noel > From louie at transsys.com Mon Sep 1 14:53:34 2014 From: louie at transsys.com (Louis Mamakos) Date: Mon, 1 Sep 2014 17:53:34 -0400 Subject: [ih] why did CC happen at all? In-Reply-To: <5404B67A.50709@web.de> References: <5401FAF2.8070306@web.de> <540447C3.7060809@web.de> <5404743F.4090102@web.de> <54049AF5.2070803@web.de> <5404B67A.50709@web.de> Message-ID: <38E11C5C-D2B0-48B3-9E00-3D3F96E8E09F@transsys.com> On Sep 1, 2014, at 2:10 PM, Detlef Bosau wrote: > > As you mention INTSERV: To the best of my knowlege, INTSERV was, at > least, not generally deployed in the whole Internet ;-) Yes, exactly. You might consider why that is the case. From detlef.bosau at web.de Tue Sep 2 08:45:21 2014 From: detlef.bosau at web.de (Detlef Bosau) Date: Tue, 02 Sep 2014 17:45:21 +0200 Subject: [ih] why did CC happen at all? In-Reply-To: <38E11C5C-D2B0-48B3-9E00-3D3F96E8E09F@transsys.com> References: <5401FAF2.8070306@web.de> <540447C3.7060809@web.de> <5404743F.4090102@web.de> <54049AF5.2070803@web.de> <5404B67A.50709@web.de> <38E11C5C-D2B0-48B3-9E00-3D3F96E8E09F@transsys.com> Message-ID: <5405E611.4000604@web.de> Am 01.09.2014 um 23:53 schrieb Louis Mamakos: > On Sep 1, 2014, at 2:10 PM, Detlef Bosau wrote: > >> As you mention INTSERV: To the best of my knowlege, INTSERV was, at >> least, not generally deployed in the whole Internet ;-) > Yes, exactly. You might consider why that is the case. > I already mentioned a reason. The Internet is a "best effort network". And I point to an argument given by Vint (IIRC?): We wanted an alternative to line switching. (The COMCAR project, I worked at years ago was intentionally a multimedia project and so I happened to read quite some of these nonsense PhD theses which pretended to provide something new - and actually reinvented line switching by the means of abused packet switching. The 90s were full of "me too projects" in that manner.) A second reason is, and COMCAR should deal with wireless networks is, that QoS "reservations" are, in the general case, not possible for wireless networks. (So our partner from industry told me not to reserve but to adapt. Being so fond of this nonsense that he was about to hop around and dance around.) Some people blame me for writing that often about an extremely deep frustration here. But when I feel abused for telling lies within the system and I notice, that I'm cheated, I say so. There ARE people who believe scientific results. And when scientists start telling lies - they should stand to this and stop pretend they were doing "science". There are certainly other reasons that INTSERV was not adopted, e.g. scalability. When I may add a sentence about COMCAR. MY lesson learned from this project is, that CS guys only have a hammer, so everything looks like a nail, Or, with respect to networks, they only have packet switching. Anything else is evil. COMCAR attempted multimeda streaming - over packet switcht networks. When you solve the wrong problems using the wrong approaches and the wrong toolks, you will inevitably faill. (These days, I had to think about this funny "UDP light" with checksums only referring to the headers, not to the payloads. Dear readers, there is exactly NOT EVEN ONE wireless PACKET SWITCHING network without link layer checksums, hence, a packet with bit errors is discarded at L2, not at L4. So, when one introduces UDP light, the sad truth is: This dead is died long ago before a packet ever reaches the receiver's access point for "UDP".) Feel free to call me the most arrogant a** in the world. But you cannot call me a liar. The by far most important priniple in science is fidelity and intellectual honesty. Semper fidellis; https://www.youtube.com/watch?v=fzeqTyO5Mbs -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From louie at transsys.com Tue Sep 2 09:23:10 2014 From: louie at transsys.com (Louis Mamakos) Date: Tue, 2 Sep 2014 12:23:10 -0400 Subject: [ih] why did CC happen at all? In-Reply-To: <5405E611.4000604@web.de> References: <5401FAF2.8070306@web.de> <540447C3.7060809@web.de> <5404743F.4090102@web.de> <54049AF5.2070803@web.de> <5404B67A.50709@web.de> <38E11C5C-D2B0-48B3-9E00-3D3F96E8E09F@transsys.com> <5405E611.4000604@web.de> Message-ID: On Sep 2, 2014, at 11:45 AM, Detlef Bosau wrote: > (These days, I had to think about this funny "UDP light" with checksums > only referring to the headers, not to the payloads. Dear readers, there > is exactly NOT EVEN ONE wireless PACKET SWITCHING network without link > layer checksums, hence, a packet with bit errors is discarded at L2, not > at L4. So, when one introduces UDP light, the sad truth is: This dead is > died long ago before a packet ever reaches the receiver's access point > for "UDP".) Having been personally screwed by exactly this assumption more than once, I beg to disagree. End-to-end checksums are used to protect against software and random hardware errors anywhere along, not just corruption in transit over communication links. 1. Early DEC DEUNA UNIBUS ethernet controllers would occasionally screw up the DMA transfers into memory, and corrupt a received packet when one of the transfers went wrong. Fortunately, it didn't randomly spew the payload elsewhere in memory, but the packet was broken. I'm sure fancy new ethernet interfaces with multiple queues would NEVER have this sort of problem. This notion of checksum offload on NICs still gives me the willies. 2. Anyone remember HSSI and ATM DXI interfaces on your routers? This was early in the deployment of ATM, and you could get this external device that was a combination of an DS3 CSU/DSU and an ATM SAR. There was this DXI protocol a router could speak to send and receive frames on ATM virtual circuits. The external ATM frame shredder would do all of the SAR functions because the router interfaces didn't exist yet. Every wonder why IS-IS LSDB entries contain checksums, well this is why.. IS-IS runs on the link layer, assuming that the L1 transport's CRC will protect the payload. Since IS-IS PDUs transit one link directly between neighbors, this seems like reasonable assumption.. In this case, the HSSI interface had a (I think) 32-bit CRC protecting the frames between the router and external equipment. The IS-IS PDU gets sent across the HSSI link, is verified by the CRC. The packet is then chopped up into 53 byte cells, each cell with some CRC. The cells are spewed across the ATM network, and then received by the far device. Each of the cells has the associated CRC validated. The cells are reassembled into packets, and then sent over a HSSI link using DXI encapsulation with a 32-bit CRC. Imagine you have a network of IP routers, using virtual circuits over an L2 ATM network for trunking. They are somewhat richly connected with virtual circuits betwixt all of the routers. You are running IS-IS as your IGP. Consider what happens when the cell reassembly process goes wrong, The packet being reassembled is sitting there in the memory of this device, unprotected by an end-to-end checksum/CRC. Just one cell reassembly goes wrong and you have a corrupted link state update. Turns out, the particular product in question would start corrupting reassembled frames every often if you pushed too hard, like more than about 34Mb/s. Corrupting a link state routing protocol database update is *really* bad news. Because the updated (corrupted) LSDB entry is then flooded to all of the neighbors. Hilarity and disbelief then ensues. An interesting failure mode to ponder, at least if its not happening to your network. And so now there's a checksum option on the LSDB, carried along end-to-end. So that weak 16 bit UDP checksum can help catch this stuff. I wonder how many corrupted files were created with NFS and broken ethernet hardware? Louis Mamakos From craig at aland.bbn.com Tue Sep 2 09:59:27 2014 From: craig at aland.bbn.com (Craig Partridge) Date: Tue, 02 Sep 2014 12:59:27 -0400 Subject: [ih] why did CC happen at all? Message-ID: <20140902165927.091F828E139@aland.bbn.com> > So that weak 16 bit UDP checksum can help catch this stuff. I wonder > how many corrupted files were created with NFS and broken ethernet > hardware? Lots and lots. At one point, a late generation of BBN Butterfly computers had a low voltage problem on a bus that would cause some bytes of a DMA from network adapters to be garbage. Trashed the NFS filesystem, as I recall, about once a week. Thanks! Craig From fergdawgster at mykolab.com Tue Sep 2 09:59:29 2014 From: fergdawgster at mykolab.com (Paul Ferguson) Date: Tue, 02 Sep 2014 09:59:29 -0700 Subject: [ih] why did CC happen at all? In-Reply-To: References: <5401FAF2.8070306@web.de> <540447C3.7060809@web.de> <5404743F.4090102@web.de> <54049AF5.2070803@web.de> <5404B67A.50709@web.de> <38E11C5C-D2B0-48B3-9E00-3D3F96E8E09F@transsys.com> <5405E611.4000604@web.de> Message-ID: <5405F771.4060503@mykolab.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 9/2/2014 9:23 AM, Louis Mamakos wrote: > 2. Anyone remember HSSI and ATM DXI interfaces on your routers? > This was early in the deployment of ATM, and you could get this > external device that was a combination of an DS3 CSU/DSU and an ATM > SAR. There was this DXI protocol a router could speak to send and > receive frames on ATM virtual circuits. The external ATM frame > shredder would do all of the SAR functions because the router > interfaces didn't exist yet. > > Every wonder why IS-IS LSDB entries contain checksums, well this is > why.. Oh yes, I remember well, although I wish I could forget. :-) - - ferg - -- Paul Ferguson VP Threat Intelligence, IID PGP Public Key ID: 0x54DC85B2 Key fingerprint: 19EC 2945 FEE8 D6C8 58A1 CE53 2896 AC75 54DC 85B2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iF4EAREIAAYFAlQF93EACgkQKJasdVTchbKoLAD/SsKziW4JMclaw11+ebk/ILXJ Mk5NMmjy+N7VHoI2P+UBAKHtf03Vqz8U7/hnEqJZiCN+w1czyguFzj7KVk2qYlyV =PKPk -----END PGP SIGNATURE----- From paul at redbarn.org Tue Sep 2 10:19:35 2014 From: paul at redbarn.org (Paul Vixie) Date: Tue, 02 Sep 2014 10:19:35 -0700 Subject: [ih] why did CC happen at all? In-Reply-To: References: <5401FAF2.8070306@web.de> <540447C3.7060809@web.de> <5404743F.4090102@web.de> <54049AF5.2070803@web.de> <5404B67A.50709@web.de> <38E11C5C-D2B0-48B3-9E00-3D3F96E8E09F@transsys.com> <5405E611.4000604@web.de> Message-ID: <5405FC27.9020105@redbarn.org> On Sep 2, 2014, at 11:45 AM, Detlef Bosau wrote: > ... mr. bosau, i've been reading your contributions to this mailing list for a couple of years now, and i've responded to you a couple of times without result. the very clear impression your work creates in my mind is: "internet troll." let me explain. 1. you do not demonstrate "learning behaviour" 2. you do not cite research for outrageous claims 3. you dispute almost everything/everybody the first time i encountered a personality of this type was in the usenet era, and i forget who the troll was but i do recall brian reid's observation that usenet was fully emulating the real world in that we now had our own "bag lady". (that reference may be too u.s. centric for you.) let me challenge you as follows. create a simple mathematical model describing "aggregate state load", where the variables are things like "number of state variables" and "possible state transitions" and "population size of control system instances". apply this to the current internet model where congestion control is edge-managed. then describe your proposed core-based congestion control system using the same model and show why your core-based congestion control model is superior in terms of "aggregate state load" and resultant complexity to the internet's edge-based congestion control model. to lay any confusion to rest, i hope you accept my challenge and i hope you win, even though my gut feeling is that your proposed-but-not-described core-based congestion control model won't even come within three orders of magnitude of the state and complexity cost of the internet's current system. but if you accept and win, i will revise my present interpretation of your long running systematic misunderstanding of just about everything. as a bonus, your proposed core-based congestion control model would then have been actually described by you in detail suitable for others to review. vixie From dhc2 at dcrocker.net Tue Sep 2 10:16:59 2014 From: dhc2 at dcrocker.net (Dave Crocker) Date: Tue, 02 Sep 2014 10:16:59 -0700 Subject: [ih] "Email History through RFCs" blog entry Message-ID: <5405FB8B.402@dcrocker.net> I'm shopping this to a few different lists because I think it's an interesting summary -- concise and reasonable: Email History through RFCs https://wordtothewise.com/2014/09/email-history-rfcs/ d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From paul at redbarn.org Tue Sep 2 10:24:15 2014 From: paul at redbarn.org (Paul Vixie) Date: Tue, 02 Sep 2014 10:24:15 -0700 Subject: [ih] why did CC happen at all? In-Reply-To: <20140902165927.091F828E139@aland.bbn.com> References: <20140902165927.091F828E139@aland.bbn.com> Message-ID: <5405FD3F.9000003@redbarn.org> On 9/2/2014 9:59 AM, Craig Partridge wrote: >> So that weak 16 bit UDP checksum can help catch this stuff. I wonder >> how many corrupted files were created with NFS and broken ethernet >> hardware? > Lots and lots. > > At one point, a late generation of BBN Butterfly computers had a low voltage > problem on a bus that would cause some bytes of a DMA from network adapters > to be garbage. Trashed the NFS filesystem, as I recall, about once a week. at NCD, ted lemon hacked the CVS (concurrent versioning system; based on RCS, similar to SCCS) to do an MD5 checksum on any file after merging, and to repeat the operation if there was a mismatch between the version on the local (committer's) workstation and the remote (NFS based) file server it was committing to. this was after the engineering group had missed more than one deadline due to mysterious 11th hour build failures. so, yes. vixie From dhc2 at dcrocker.net Tue Sep 2 11:59:34 2014 From: dhc2 at dcrocker.net (Dave Crocker) Date: Tue, 02 Sep 2014 11:59:34 -0700 Subject: [ih] why did CC happen at all? In-Reply-To: <20140902165927.091F828E139@aland.bbn.com> References: <20140902165927.091F828E139@aland.bbn.com> Message-ID: <54061396.8070505@dcrocker.net> On 9/2/2014 9:59 AM, Craig Partridge wrote: >> So that weak 16 bit UDP checksum can help catch this stuff. I wonder >> how many corrupted files were created with NFS and broken ethernet >> hardware? > > Lots and lots. > > At one point, a late generation of BBN Butterfly computers had a low voltage > problem on a bus that would cause some bytes of a DMA from network adapters > to be garbage. Trashed the NFS filesystem, as I recall, about once a week. Yup. We had an essentially identical type of customer problem at Ungermann-Bass -- circa 1987 -- which used a variant of the XNS protocol, lacking an e2e checksum. Long history of undetected faulty X.25/LAN router interface bug, which meant a long history of corrupted file data. We were developing an Internet stack for the various UB platforms and it happens that some of the same team was working on a new X.25 box, which we quickly installed. We ruefully noted that if we'd been running TCP or UDP (with checksums) there would have been no file corruption and just some retransmit counters incremented. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From detlef.bosau at web.de Tue Sep 2 12:17:05 2014 From: detlef.bosau at web.de (Detlef Bosau) Date: Tue, 02 Sep 2014 21:17:05 +0200 Subject: [ih] why did CC happen at all? In-Reply-To: References: <5401FAF2.8070306@web.de> <540447C3.7060809@web.de> <5404743F.4090102@web.de> <54049AF5.2070803@web.de> <5404B67A.50709@web.de> <38E11C5C-D2B0-48B3-9E00-3D3F96E8E09F@transsys.com> <5405E611.4000604@web.de> Message-ID: <540617B1.2030004@web.de> Am 02.09.2014 um 18:23 schrieb Louis Mamakos: > On Sep 2, 2014, at 11:45 AM, Detlef Bosau wrote: > >> (These days, I had to think about this funny "UDP light" with checksums >> only referring to the headers, not to the payloads. Dear readers, there >> is exactly NOT EVEN ONE wireless PACKET SWITCHING network without link >> layer checksums, hence, a packet with bit errors is discarded at L2, not >> at L4. So, when one introduces UDP light, the sad truth is: This dead is >> died long ago before a packet ever reaches the receiver's access point >> for "UDP".) > Having been personally screwed by exactly this assumption more than once, > I beg to disagree. > > End-to-end checksums are used to protect against software and random hardware > errors anywhere along, not just corruption in transit over communication > links. We're talking a bit at cross purposes. My perspective is a scientific one, not a UHD perspective. So, the main purpose of my remark is to discuss "UDP lite" as some kind of related work. My basic assumption is always that hardware works as designed. > > 1. Early DEC DEUNA UNIBUS ethernet controllers would occasionally screw up > the DMA transfers into memory, and corrupt a received packet when one of > the transfers went wrong. Fortunately, it didn't randomly spew the > payload elsewhere in memory, but the packet was broken. I'm sure fancy > new ethernet interfaces with multiple queues would NEVER have this sort of > problem. This notion of checksum offload on NICs still gives me the willies. > > 2. Anyone remember HSSI and ATM DXI interfaces on your routers? This was > early in the deployment of ATM, and you could get this external device > that was a combination of an DS3 CSU/DSU and an ATM SAR. There was this > DXI protocol a router could speak to send and receive frames on ATM virtual > circuits. The external ATM frame shredder would do all of the SAR functions > because the router interfaces didn't exist yet. May be. But this is implementation. When I started this discussion, I wanted to discuss the history of congestion control, -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From craig at aland.bbn.com Tue Sep 2 12:47:14 2014 From: craig at aland.bbn.com (Craig Partridge) Date: Tue, 02 Sep 2014 15:47:14 -0400 Subject: [ih] why did CC happen at all? Message-ID: <20140902194714.ECDB628E139@aland.bbn.com> > My basic assumption is always that hardware works as designed. I think the examples you've been given should cause you to realize that assumption is false. If not, I'm sure many many many more examples can be provided. Thanks! Craig From brian.e.carpenter at gmail.com Tue Sep 2 13:02:08 2014 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Wed, 03 Sep 2014 08:02:08 +1200 Subject: [ih] why did CC happen at all? In-Reply-To: <20140902165927.091F828E139@aland.bbn.com> References: <20140902165927.091F828E139@aland.bbn.com> Message-ID: <54062240.8070700@gmail.com> On 03/09/2014 04:59, Craig Partridge wrote: >> So that weak 16 bit UDP checksum can help catch this stuff. I wonder >> how many corrupted files were created with NFS and broken ethernet >> hardware? > > Lots and lots. > > At one point, a late generation of BBN Butterfly computers had a low voltage > problem on a bus that would cause some bytes of a DMA from network adapters > to be garbage. Trashed the NFS filesystem, as I recall, about once a week. Yes, it really wasn't (isn't?) an uncommon problem. I think I first saw it in CAMAC crates in the 1970s. All PCs have error-correcting redundancy in their RAM, right? Er, wrong. Bit corruption in PCs really happens. The decision was taken in IPv6 to remove the header checksum but make the UDP checksum mandatory, because people felt the tradeoffs had changed since IPv4 was designed. But nobody suggested trusting layer 2 and/or DMA, because they weren't and aren't trustworthy. Brian From dhc2 at dcrocker.net Tue Sep 2 13:35:41 2014 From: dhc2 at dcrocker.net (Dave Crocker) Date: Tue, 02 Sep 2014 13:35:41 -0700 Subject: [ih] why did CC happen at all? In-Reply-To: <20140902194714.ECDB628E139@aland.bbn.com> References: <20140902194714.ECDB628E139@aland.bbn.com> Message-ID: <54062A1D.1030109@dcrocker.net> On 9/2/2014 12:47 PM, Craig Partridge wrote: >> My basic assumption is always that hardware works as designed. > I think the examples you've been given should cause you to realize that > assumption is false. If not, I'm sure many many many more examples can > be provided. Cars break down. Airplanes malfunction. Computers don't. You should know that by now. In other words, Craig, when one finds it necessary to post the kind of note you've just sent, there is a deeper problem with the exchange, and it's not likely to get solved... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dot at dotat.at Wed Sep 3 06:22:05 2014 From: dot at dotat.at (Tony Finch) Date: Wed, 3 Sep 2014 14:22:05 +0100 Subject: [ih] why did CC happen at all? In-Reply-To: <54062240.8070700@gmail.com> References: <20140902165927.091F828E139@aland.bbn.com> <54062240.8070700@gmail.com> Message-ID: Brian E Carpenter wrote: > > Yes, it really wasn't (isn't?) an uncommon problem. Some more recent examples: Amazon S3 outage due to single bit corruption. (Unclear whether the corruption occurred in memory or during transmission, but the cascade failure is reminiscent of the LSDB corruption that Louis Mamakos described.) http://status.aws.amazon.com/s3-20080720.html Bitsquatting: it can be proftable to register domain names that are one bit different from popular domain names - like typosquatting but relying on data corruption rather than typing errors. http://dinaburg.org/bitsquatting.html Tony. -- f.anthony.n.finch http://dotat.at/ Trafalgar: Cyclonic in northwest, otherwise mainly northerly or northwesterly 5 or 6. Slight or moderate. Showers in northwest. Good. From detlef.bosau at web.de Wed Sep 3 13:16:21 2014 From: detlef.bosau at web.de (Detlef Bosau) Date: Wed, 03 Sep 2014 22:16:21 +0200 Subject: [ih] why did CC happen at all? In-Reply-To: <5405FC27.9020105@redbarn.org> References: <5401FAF2.8070306@web.de> <540447C3.7060809@web.de> <5404743F.4090102@web.de> <54049AF5.2070803@web.de> <5404B67A.50709@web.de> <38E11C5C-D2B0-48B3-9E00-3D3F96E8E09F@transsys.com> <5405E611.4000604@web.de> <5405FC27.9020105@redbarn.org> Message-ID: <54077715.6060706@web.de> Am 02.09.2014 um 19:19 schrieb Paul Vixie: > On Sep 2, 2014, at 11:45 AM, Detlef Bosau wrote: > > >> ... > > mr. bosau, i've been reading your contributions to this mailing list for > a couple of years now, and i've responded to you a couple of times > without result. the very clear impression your work creates in my mind > is: "internet troll." let me explain. > > 1. you do not demonstrate "learning behaviour" > 2. you do not cite research for outrageous claims > 3. you dispute almost everything/everybody > > the first time i encountered a personality of this type was in the > usenet era, and i forget who the troll was but i do recall brian reid's > observation that usenet was fully emulating the real world in that we > now had our own "bag lady". (that reference may be too u.s. centric for > you.) > > let me challenge you as follows. When your attitude is to offend me with invectives, I don't intend to listen to that. Obviously, you don't know, what learning behaviour is. I do. O.k. Put me in your filter, in case that I read your name a second time in my life, I'm free to report this offense to the police. I don't know, where you're living, but in Germany, your "behaviour" is considered as a crime. From detlef.bosau at web.de Wed Sep 3 13:20:37 2014 From: detlef.bosau at web.de (Detlef Bosau) Date: Wed, 03 Sep 2014 22:20:37 +0200 Subject: [ih] why did CC happen at all? In-Reply-To: <20140902194714.ECDB628E139@aland.bbn.com> References: <20140902194714.ECDB628E139@aland.bbn.com> Message-ID: <54077815.7000604@web.de> Am 02.09.2014 um 21:47 schrieb Craig Partridge: >> My basic assumption is always that hardware works as designed. > I think the examples you've been given should cause you to realize that > assumption is false. If not, I'm sure many many many more examples can > be provided. > > Thanks! > > Craig I wanted to understand a rational in a scientific discussion. Defective hardware is not a scientific problem but something for the waste basket. "Pi is about 3.14" "You are wrong, there are enough counterexamples for defective circles." And yes, I dealt with defecitve hardware several years in my life. For years, I worked at user helpdesks. So I know defective hardware very, very well. -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From detlef.bosau at web.de Wed Sep 3 13:31:40 2014 From: detlef.bosau at web.de (Detlef Bosau) Date: Wed, 03 Sep 2014 22:31:40 +0200 Subject: [ih] *off list* In-Reply-To: <20140902194714.ECDB628E139@aland.bbn.com> References: <20140902194714.ECDB628E139@aland.bbn.com> Message-ID: <54077AAC.2050501@web.de> Am 02.09.2014 um 21:47 schrieb Craig Partridge: >> My basic assumption is always that hardware works as designed. > I think the examples you've been given should cause you to realize that > assumption is false. If not, I'm sure many many many more examples can > be provided. > > Thanks! > > Craig I'm not comfortable with this kind of debabe, particularly not with this comment by Paul Vixie. Although, you won't believe me, I want to conduct research. And i research, we use models and assumptions. And I really wonder, not to say I'm appalled, that we do not put in question the most ludicrous assumptions, e.g. in the context of Little's theorem and even more nonsense - and build PhD theses and research projects upon them, while at the same time we throw red herrings with defective Ethernet interfaces. As I said, I worked in user support for quite some years, so I'm not unlikely to have seen (and replaced) much more defective network interfaces in my life than you all together ;-) However, when I try to understand TCP congestion algorithms, I have to make reasonable and decent assumptions. Amongst these are intact interfaces. -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From detlef.bosau at web.de Wed Sep 3 13:34:02 2014 From: detlef.bosau at web.de (Detlef Bosau) Date: Wed, 03 Sep 2014 22:34:02 +0200 Subject: [ih] why did CC happen at all? In-Reply-To: <54077715.6060706@web.de> References: <5401FAF2.8070306@web.de> <540447C3.7060809@web.de> <5404743F.4090102@web.de> <54049AF5.2070803@web.de> <5404B67A.50709@web.de> <38E11C5C-D2B0-48B3-9E00-3D3F96E8E09F@transsys.com> <5405E611.4000604@web.de> <5405FC27.9020105@redbarn.org> <54077715.6060706@web.de> Message-ID: <54077B3A.1010803@web.de> I see that my tone was not very decent here. However, I felt deeply hurt by this comment. I herewith apologize to the readers of this list. Perhaps it will be possible to clear matters with Paul Vixie in a more private context. -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From agmalis at gmail.com Wed Sep 3 14:02:47 2014 From: agmalis at gmail.com (Andrew G. Malis) Date: Wed, 3 Sep 2014 17:02:47 -0400 Subject: [ih] why did CC happen at all? In-Reply-To: <54077815.7000604@web.de> References: <20140902194714.ECDB628E139@aland.bbn.com> <54077815.7000604@web.de> Message-ID: Detlef, I disagree with "Defective hardware is not a scientific problem but something for the waste basket." Well, it may not be a scientific problem, but it certainly is an engineering problem. Nothing in this life is perfect, and that especially includes anything manufactured. Unless you take every precaution in the HW to protect it against cosmic rays, any possible manufacturing defect, or so on, ignoring the fact that HW may be defective (if even just momentarily) is just hiding your head in the sand. And even if you could guarantee perfect HW that was hardened against any possible failure, it would probably be much too expensive to be practical. It's much more cost-effective from a system point of view to anticipate possible HW failures with such mechanisms as end-to-end checksums, retransmission timeouts, soft state, and outage resiliency. Cheers, Andy On Wed, Sep 3, 2014 at 4:20 PM, Detlef Bosau wrote: > Am 02.09.2014 um 21:47 schrieb Craig Partridge: > >> My basic assumption is always that hardware works as designed. > > I think the examples you've been given should cause you to realize that > > assumption is false. If not, I'm sure many many many more examples can > > be provided. > > > > Thanks! > > > > Craig > > > I wanted to understand a rational in a scientific discussion. > > Defective hardware is not a scientific problem but something for the > waste basket. > > "Pi is about 3.14" > "You are wrong, there are enough counterexamples for defective circles." > > And yes, I dealt with defecitve hardware several years in my life. For > years, I worked at user helpdesks. So I know defective hardware very, > very well. > > -- > ------------------------------------------------------------------ > Detlef Bosau > Galileistra?e 30 > 70565 Stuttgart Tel.: +49 711 5208031 > mobile: +49 172 6819937 > skype: detlef.bosau > ICQ: 566129673 > detlef.bosau at web.de http://www.detlef-bosau.de > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From detlef.bosau at web.de Wed Sep 3 14:30:48 2014 From: detlef.bosau at web.de (Detlef Bosau) Date: Wed, 03 Sep 2014 23:30:48 +0200 Subject: [ih] why did CC happen at all? In-Reply-To: References: <20140902194714.ECDB628E139@aland.bbn.com> <54077815.7000604@web.de> Message-ID: <54078888.6090904@web.de> Am 03.09.2014 um 23:02 schrieb Andrew G. Malis: > Detlef, > > I disagree with "Defective hardware is not a scientific problem but > something for the waste basket." Well, it may not be a scientific > problem, but it certainly is an engineering problem. Yes. The problem is perhaps the discussion itself. Including my typo, I wanted to write "why did congestion happen at all?" and pressed the enter key to early. What I want to discuss is congestion and congestion control - intentionally with a clean slate approach in mind. For this purpose, you necessarily need assumptions. The question is: Which assumptions are reasonable and decent? And which aren't? When we forget the term "history" at the moment, the assumption "intact interface" is much more reasonable than much other assumptions we make. Particularly for this very discussion, I think it is reasonable to assume working hardware. However, particularly after Paul Vixie's rant, I would appreciate a pointer to a more suitable venue for this discussion. I'm not willing to discuss scientific questions in that manner. And yes, it MUST be possible to put in question approaches which are broadly used, we cannot learn without asking questions. But Paul's kind of yelling is simply not acceptable for me. Particularly as he did not bring arguments but very personal invectives. (And did not really read what I wrote, I never proposed a "core based" congestion control scheme, what is "core based"? So when someone think, a statement or a claim of mine were wrong, I would appreciated at least being quoted correctly.) -------------- next part -------------- An HTML attachment was scrubbed... URL: From detlef.bosau at web.de Wed Sep 3 16:19:19 2014 From: detlef.bosau at web.de (Detlef Bosau) Date: Thu, 04 Sep 2014 01:19:19 +0200 Subject: [ih] why did CC happen at all? In-Reply-To: <54078888.6090904@web.de> References: <20140902194714.ECDB628E139@aland.bbn.com> <54077815.7000604@web.de> <54078888.6090904@web.de> Message-ID: <5407A1F7.5040303@web.de> Am 03.09.2014 um 23:30 schrieb Detlef Bosau: > But Paul's kind of yelling is simply not acceptable for me. > Particularly as he did not bring arguments but very personal > invectives. (And did not really read what I wrote, I never proposed a > "core based" congestion control scheme, what is "core based"? So when > someone think, a statement or a claim of mine were wrong, I would > appreciated at least being quoted correctly.) > > Perhaps one addition: In his rant, Paul advocated an endpoint controlled system. This is basically the status quo. The extreme contrast, and this topic was mentioned in the discussion, is INTSERV or, with particular respect to complexity, the control theoretic approach by Srinivasan Keshav. Vint pointed to the importance of flexibility, which is provided by packet switching. However, I'm curious why we always see only these two alternatives: Either a more or less chaotic system, which the Internet actually is, or a strictly controlled system like the telephone system. I sincerely think that the best way is somewhere in between. Basically, I think this is the very best way to revive Salzer's paper. Salzer, Reed, Clark don't say that anything must be done at the end points. But they say basically, things should be done where they belong to. Concrete example. For years I was trapped in the idea, retransmissions should not been done locally but by the endpoints. This is, in that black and white way of thinking, simply nonsense. In case of a link failure, a retransmitted packet will fail - no matter whether sent locally or by the original sender. However, from a TCP's perspective, we have the network layer between link layer and transport layer, hence when a link fails, the network layer may e.g. change the routing, hence when a packet is resent by its original sender, it will take the corrected route then and eventually reach its destination. Where did this trap come from? Precisely: I did not really consider all alternatives. Let me stay here for a moment. What about WiFi? In WiFi, we have NO collision detection, we cannot distinguish collision from corruption. (This is a very important difference to mobile networking technologies.) As a consequence, we must not restrict the number of retransmissions to hard - otherweise a WiFi net may fail completely under heavy load. And of course, the end points will not bother with local load in a WiFi segment along the path. In contrast to that, local retransmissions in mobile networks should be restricted very hard. When you look at a mobile links block corruption probability in mobile networks, this drops from 1 to 0 in an SNR range of about 1 db or so. There is hardly a real "range" in between. Hence, either a block is successfully sent in one, at most two, attempts, or the link (at least in its current configuration) is not suited to convey the block. It's that simple. So these two cases should be treated differently. Which actually isn't done by and end to end approach. However, I often see papers which restrict themselves to an end to end view, while others take an INTSERV like perspective. Both positions exclude approaches which may be somewhere in between. And I admittedly take the position, that we cannot reasonably control the Internet's resource assignment and flow/congestion control only from the end points. -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From paul at redbarn.org Wed Sep 3 23:47:54 2014 From: paul at redbarn.org (Paul Vixie) Date: Wed, 03 Sep 2014 23:47:54 -0700 Subject: [ih] why did CC happen at all? In-Reply-To: <5405FC27.9020105@redbarn.org> References: <5401FAF2.8070306@web.de> <540447C3.7060809@web.de> <5404743F.4090102@web.de> <54049AF5.2070803@web.de> <5404B67A.50709@web.de> <38E11C5C-D2B0-48B3-9E00-3D3F96E8E09F@transsys.com> <5405E611.4000604@web.de> <5405FC27.9020105@redbarn.org> Message-ID: <54080B1A.4070001@redbarn.org> mr. bosau, i consider your answer completely non-responsive. to reduce stress, i'm going to add you to my mail filter now. for your possible self-reference, i received several "thank you paul for saying what you said" notes from our colleagues here. this may indicate a benefit you would receive if you constrained your speech here to discussions of history itself, rather than to alternate histories or proposed new approaches. i hereby request that the operator of this mailing list step up their moderation efforts. --vixie From detlef.bosau at web.de Thu Sep 4 09:19:28 2014 From: detlef.bosau at web.de (Detlef Bosau) Date: Thu, 04 Sep 2014 18:19:28 +0200 Subject: [ih] why did CC happen at all? In-Reply-To: <54080B1A.4070001@redbarn.org> References: <5401FAF2.8070306@web.de> <540447C3.7060809@web.de> <5404743F.4090102@web.de> <54049AF5.2070803@web.de> <5404B67A.50709@web.de> <38E11C5C-D2B0-48B3-9E00-3D3F96E8E09F@transsys.com> <5405E611.4000604@web.de> <5405FC27.9020105@redbarn.org> <54080B1A.4070001@redbarn.org> Message-ID: <54089110.5060308@web.de> Am 04.09.2014 um 08:47 schrieb Paul Vixie: > mr. bosau, i consider your answer completely non-responsive. to reduce > stress, i'm going to add you to my mail filter now. for your possible > self-reference, i received several "thank you paul for saying what you > said" notes from our colleagues here. First: Feel free to add me to your filter. Second: Stop telling lies. When persons want to criticize me, they are free to tell this to me - and not to you. Boasting with actions done by others is an absolute No Go in any academic context. And a reliable means to break any contact with me. So when people have a problem with me, these people either have a name and can speak for themselves, or they have problems, most likely not only with me. And please don't call me a troll. The only person who behaves like a troll, and as a very childish one, are you in this context. I never got in touch with you. I have no idea who you are, we don't know each other. And you come here without any reason, offend me, blame me, without any rationale reason. This is simply bad behaviour. Who are you to do that? God? The President of the United States? And what should my response have been? Think about that for yourself. (And when statements of me are wrong, give rationale to prove them wrong. "I received mails..." or "I received phone calls..." are certainly no rationales.) However, I think we should close this dispute here. I don't think that the other readers are interested in that childish arguments. Detlef From detlef.bosau at web.de Thu Sep 4 09:34:22 2014 From: detlef.bosau at web.de (Detlef Bosau) Date: Thu, 04 Sep 2014 18:34:22 +0200 Subject: [ih] A technical response,. Re: why did CC happen at all? In-Reply-To: <5405FC27.9020105@redbarn.org> References: <5401FAF2.8070306@web.de> <540447C3.7060809@web.de> <5404743F.4090102@web.de> <54049AF5.2070803@web.de> <5404B67A.50709@web.de> <38E11C5C-D2B0-48B3-9E00-3D3F96E8E09F@transsys.com> <5405E611.4000604@web.de> <5405FC27.9020105@redbarn.org> Message-ID: <5408948E.40305@web.de> Am 02.09.2014 um 19:19 schrieb Paul Vixie: > On Sep 2, 2014, at 11:45 AM, Detlef Bosau wrote: > > >> ... > > > > let me challenge you as follows. create a simple mathematical model > describing "aggregate state load", where the variables are things like > "number of state variables" and "possible state transitions" and > "population size of control system instances". I would greatly appreciate an answer by a system theorist here. Alternatively, we may have physicists here (Jon? I think, you are?) who may roughly explain, what state variables are all about. Particularly in physical models. And last but not least, and that's the very reason why I write this response at all (and spent the whole day in pleasant anticipation): Exactly, precisely and with no exception ALL (i.e. there is no single exception) reasonable models in system theory include models for signal sources, or with particular respect to the Internet, models of user behaviour. (Even though you only use a Dirac pulse or a Heaviside step. Even these are, though very particular ones, models of user behaviour.) The only problem here is: Good models for user behaviour are extremely hard to find. (And even my beloved Little's theorem simply requires the arrival process to be metrically transitive, and as far as I see, this is anything else than a weak requirement.) ;-) Detlef From amyzing at talsever.com Thu Sep 4 10:05:03 2014 From: amyzing at talsever.com (Amelia A Lewis) Date: Thu, 4 Sep 2014 13:05:03 -0400 Subject: [ih] why did CC happen at all? In-Reply-To: <54089110.5060308@web.de> References: <5401FAF2.8070306@web.de> <540447C3.7060809@web.de> <5404743F.4090102@web.de> <54049AF5.2070803@web.de> <5404B67A.50709@web.de> <38E11C5C-D2B0-48B3-9E00-3D3F96E8E09F@transsys.com> <5405E611.4000604@web.de> <5405FC27.9020105@redbarn.org> <54080B1A.4070001@redbarn.org> <54089110.5060308@web.de> Message-ID: <20140904130503179847.1c158d15@talsever.com> If it's necessary to post publicly, then I'll do so. I'd like to second Paul Vixie's call for moderation. Herr Bosau, if your concerns have nothing to do with internet history, beyond asserting that you know more than the folks who were involved in designing internet protocols, and demanding that they admit that they were wrong, then you should take your insults and your attempts to derail the internet-history discussion list *somewhere else*. Also, you owe Paul Vixie an apology, and more apologies to the others on this list who have shown, in my opinion, remarkable tolerance of your anger, insults, and distractions from the topics of the mailing list. It is possible that, if (as it seems) english is your second language, you're not aware of the hostile and vicious tone that has suffused your posts from about the dozenth in this outrageously long series. The folks involved in discussions of congestion control at various periods in the development of the internet have graciously discussed this history here. That's all that ever belonged here. Stop. Amy! On Thu, 04 Sep 2014 18:19:28 +0200, Detlef Bosau wrote: > Am 04.09.2014 um 08:47 schrieb Paul Vixie: >> mr. bosau, i consider your answer completely non-responsive. to reduce >> stress, i'm going to add you to my mail filter now. for your possible >> self-reference, i received several "thank you paul for saying what you >> said" notes from our colleagues here. > > First: Feel free to add me to your filter. > > Second: Stop telling lies. > > When persons want to criticize me, they are free to tell this to me - > and not to you. Boasting with actions done by others is an absolute No > Go in any academic context. And a reliable means to break any contact > with me. So when people have a problem with me, these people either have > a name and can speak for themselves, or they have problems, most likely > not only with me. > > > And please don't call me a troll. The only person who behaves like a > troll, and as a very childish one, are you in this context. > I never got in touch with you. I have no idea who you are, we don't know > each other. And you come here without any reason, offend me, blame me, > without any rationale reason. This is simply bad behaviour. > > Who are you to do that? > > God? The President of the United States? > > And what should my response have been? > > Think about that for yourself. > > (And when statements of me are wrong, give rationale to prove them > wrong. "I received mails..." or "I received phone calls..." are > certainly no rationales.) > > However, I think we should close this dispute here. I don't think that > the other readers are interested in that childish arguments. > > Detlef > > From el at lisse.na Thu Sep 4 10:38:28 2014 From: el at lisse.na (Dr Eberhard W Lisse) Date: Thu, 4 Sep 2014 18:38:28 +0100 Subject: [ih] why did CC happen at all? In-Reply-To: <20140904130503179847.1c158d15@talsever.com> References: <5401FAF2.8070306@web.de> <540447C3.7060809@web.de> <5404743F.4090102@web.de> <54049AF5.2070803@web.de> <5404B67A.50709@web.de> <38E11C5C-D2B0-48B3-9E00-3D3F96E8E09F@transsys.com> <5405E611.4000604@web.de> <5405FC27.9020105@redbarn.org> <54080B1A.4070001@redbarn.org> <54089110.5060308@web.de> <20140904130503179847.1c158d15@talsever.com> Message-ID: He has his own FAQ [URL REMOVED BY LIST ADMIN] unfortunately in German, but Google translate makes a reasonable job of it :-)-O Maybe non-response to off-topic posts is best. Greetings, el Sent from Dr Lisse's iPad mini > On Sep 4, 2014, at 18:05, Amelia A Lewis wrote: > > If it's necessary to post publicly, then I'll do so. > > I'd like to second Paul Vixie's call for moderation. Herr Bosau, if > your concerns have nothing to do with internet history, beyond > asserting that you know more than the folks who were involved in > designing internet protocols, and demanding that they admit that they > were wrong, then you should take your insults and your attempts to > derail the internet-history discussion list *somewhere else*. > > Also, you owe Paul Vixie an apology, and more apologies to the others > on this list who have shown, in my opinion, remarkable tolerance of > your anger, insults, and distractions from the topics of the mailing > list. It is possible that, if (as it seems) english is your second > language, you're not aware of the hostile and vicious tone that has > suffused your posts from about the dozenth in this outrageously long > series. > > The folks involved in discussions of congestion control at various > periods in the development of the internet have graciously discussed > this history here. That's all that ever belonged here. > > Stop. > > Amy! >> On Thu, 04 Sep 2014 18:19:28 +0200, Detlef Bosau wrote: >>> Am 04.09.2014 um 08:47 schrieb Paul Vixie: >>> mr. bosau, i consider your answer completely non-responsive. to reduce >>> stress, i'm going to add you to my mail filter now. for your possible >>> self-reference, i received several "thank you paul for saying what you >>> said" notes from our colleagues here. >> >> First: Feel free to add me to your filter. >> >> Second: Stop telling lies. >> >> When persons want to criticize me, they are free to tell this to me - >> and not to you. Boasting with actions done by others is an absolute No >> Go in any academic context. And a reliable means to break any contact >> with me. So when people have a problem with me, these people either have >> a name and can speak for themselves, or they have problems, most likely >> not only with me. >> >> >> And please don't call me a troll. The only person who behaves like a >> troll, and as a very childish one, are you in this context. >> I never got in touch with you. I have no idea who you are, we don't know >> each other. And you come here without any reason, offend me, blame me, >> without any rationale reason. This is simply bad behaviour. >> >> Who are you to do that? >> >> God? The President of the United States? >> >> And what should my response have been? >> >> Think about that for yourself. >> >> (And when statements of me are wrong, give rationale to prove them >> wrong. "I received mails..." or "I received phone calls..." are >> certainly no rationales.) >> >> However, I think we should close this dispute here. I don't think that >> the other readers are interested in that childish arguments. >> >> Detlef >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From detlef.bosau at web.de Thu Sep 4 10:47:00 2014 From: detlef.bosau at web.de (Detlef Bosau) Date: Thu, 04 Sep 2014 19:47:00 +0200 Subject: [ih] why did CC happen at all? In-Reply-To: <20140904130503179847.1c158d15@talsever.com> References: <5401FAF2.8070306@web.de> <540447C3.7060809@web.de> <5404743F.4090102@web.de> <54049AF5.2070803@web.de> <5404B67A.50709@web.de> <38E11C5C-D2B0-48B3-9E00-3D3F96E8E09F@transsys.com> <5405E611.4000604@web.de> <5405FC27.9020105@redbarn.org> <54080B1A.4070001@redbarn.org> <54089110.5060308@web.de> <20140904130503179847.1c158d15@talsever.com> Message-ID: <5408A594.60307@web.de> Am 04.09.2014 um 19:05 schrieb Amelia A Lewis: > If it's necessary to post publicly, then I'll do so. > > I'd like to second Paul Vixie's call for moderation. Herr Bosau, if > your concerns have nothing to do with internet history, beyond > asserting that you know more than the folks who were involved in > designing internet protocols, and demanding that they admit that they > were wrong, then you should take your insults and your attempts to > derail the internet-history discussion list *somewhere else*. I did not want to insult anyone. When you can point me to a more appropriate venue, I would a appreciate a hint. > Also, you owe Paul Vixie an apology, Why? > and more apologies to the others > on this list who have shown, in my opinion, remarkable tolerance of > your anger, insults, and distractions from the topics of the mailing > list. It is possible that, if (as it seems) english is your second > language, you're not aware of the hostile and vicious tone that has > suffused your posts from about the dozenth in this outrageously long > series. ?? Is it forbidden to ask questions? O.k., I would like to return to list related discussions. For other comments, feel free to contact me via pm. -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From amckenzie3 at yahoo.com Thu Sep 4 10:59:04 2014 From: amckenzie3 at yahoo.com (Alex McKenzie) Date: Thu, 4 Sep 2014 10:59:04 -0700 Subject: [ih] Mr Bosau In-Reply-To: References: <5401FAF2.8070306@web.de> <540447C3.7060809@web.de> <5404743F.4090102@web.de> <54049AF5.2070803@web.de> <5404B67A.50709@web.de> <38E11C5C-D2B0-48B3-9E00-3D3F96E8E09F@transsys.com> <5405E611.4000604@web.de> <5405FC27.9020105@redbarn.org> <54080B1A.4070001@redbarn.org> <54089110.5060308@web.de> <20140904130503179847.1c158d15@talsever.com> Message-ID: <1409853544.391.YahooMailNeo@web163803.mail.gq1.yahoo.com> Thank you for this post. I was growing confused. Alex McKenzie ________________________________ From: Dr Eberhard W Lisse To: Amelia A Lewis Cc: "internet-history at postel.org" Sent: Thursday, September 4, 2014 1:38 PM Subject: Re: [ih] why did CC happen at all? He has his own FAQ [URL REMOVED BY LIST ADMIN] unfortunately in German, but Google translate makes a reasonable job of it :-)-O Maybe non-response to off-topic posts is best. Greetings, el -------------- next part -------------- An HTML attachment was scrubbed... URL: From detlef.bosau at web.de Thu Sep 4 11:23:17 2014 From: detlef.bosau at web.de (Detlef Bosau) Date: Thu, 04 Sep 2014 20:23:17 +0200 Subject: [ih] Mr Bosau In-Reply-To: <1409853544.391.YahooMailNeo@web163803.mail.gq1.yahoo.com> References: <5401FAF2.8070306@web.de> <540447C3.7060809@web.de> <5404743F.4090102@web.de> <54049AF5.2070803@web.de> <5404B67A.50709@web.de> <38E11C5C-D2B0-48B3-9E00-3D3F96E8E09F@transsys.com> <5405E611.4000604@web.de> <5405FC27.9020105@redbarn.org> <54080B1A.4070001@redbarn.org> <54089110.5060308@web.de> <20140904130503179847.1c158d15@talsever.com> <1409853544.391.YahooMailNeo@web163803.mail.gq1.yahoo.com> Message-ID: <5408AE15.6040103@web.de> Am 04.09.2014 um 19:59 schrieb Alex McKenzie: > Thank you for this post. I was growing confused. > Are you? So yo believe a "FAQ" on my person? Sorry. There is no such thing like FAQ on my person. detlef -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.gade at gmail.com Thu Sep 4 11:43:35 2014 From: eric.gade at gmail.com (Eric Gade) Date: Thu, 4 Sep 2014 14:43:35 -0400 Subject: [ih] why did CC happen at all? In-Reply-To: <5408A594.60307@web.de> References: <5401FAF2.8070306@web.de> <540447C3.7060809@web.de> <5404743F.4090102@web.de> <54049AF5.2070803@web.de> <5404B67A.50709@web.de> <38E11C5C-D2B0-48B3-9E00-3D3F96E8E09F@transsys.com> <5405E611.4000604@web.de> <5405FC27.9020105@redbarn.org> <54080B1A.4070001@redbarn.org> <54089110.5060308@web.de> <20140904130503179847.1c158d15@talsever.com> <5408A594.60307@web.de> Message-ID: Thank you everyone for providing me with a whole new chapter for my book on the History of Flaming. On Thu, Sep 4, 2014 at 1:47 PM, Detlef Bosau wrote: > Am 04.09.2014 um 19:05 schrieb Amelia A Lewis: > > If it's necessary to post publicly, then I'll do so. > > > > I'd like to second Paul Vixie's call for moderation. Herr Bosau, if > > your concerns have nothing to do with internet history, beyond > > asserting that you know more than the folks who were involved in > > designing internet protocols, and demanding that they admit that they > > were wrong, then you should take your insults and your attempts to > > derail the internet-history discussion list *somewhere else*. > > I did not want to insult anyone. When you can point me to a more > appropriate venue, I would a appreciate a hint. > > > Also, you owe Paul Vixie an apology, > > Why? > > > and more apologies to the others > > on this list who have shown, in my opinion, remarkable tolerance of > > your anger, insults, and distractions from the topics of the mailing > > list. It is possible that, if (as it seems) english is your second > > language, you're not aware of the hostile and vicious tone that has > > suffused your posts from about the dozenth in this outrageously long > > series. > > ?? > > > Is it forbidden to ask questions? > > O.k., I would like to return to list related discussions. > > For other comments, feel free to contact me via pm. > > -- > ------------------------------------------------------------------ > Detlef Bosau > Galileistra?e 30 > 70565 Stuttgart Tel.: +49 711 5208031 > mobile: +49 172 6819937 > skype: detlef.bosau > ICQ: 566129673 > detlef.bosau at web.de http://www.detlef-bosau.de > > -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From nigel at channelisles.net Thu Sep 4 11:57:28 2014 From: nigel at channelisles.net (Nigel Roberts) Date: Thu, 04 Sep 2014 19:57:28 +0100 Subject: [ih] Mr Bosau In-Reply-To: <1409853544.391.YahooMailNeo@web163803.mail.gq1.yahoo.com> References: <5401FAF2.8070306@web.de> <540447C3.7060809@web.de> <5404743F.4090102@web.de> <54049AF5.2070803@web.de> <5404B67A.50709@web.de> <38E11C5C-D2B0-48B3-9E00-3D3F96E8E09F@transsys.com> <5405E611.4000604@web.de> <5405FC27.9020105@redbarn.org> <54080B1A.4070001@redbarn.org> <54089110.5060308@web.de> <20140904130503179847.1c158d15@talsever.com> <1409853544.391.YahooMailNeo@web163803.mail.gq1.yahoo.com> Message-ID: <5408B618.9080900@channelisles.net> I remain confused by his advice. On 09/04/2014 06:59 PM, Alex McKenzie wrote: > Thank you for this post. I was growing confused. > > Alex McKenzie > > > > ------------------------------------------------------------------------ > *From:* Dr Eberhard W Lisse > *To:* Amelia A Lewis > *Cc:* "internet-history at postel.org" > *Sent:* Thursday, September 4, 2014 1:38 PM > *Subject:* Re: [ih] why did CC happen at all? > > He has his own FAQ > > [URL REMOVED BY LIST ADMIN] > > unfortunately in German, but Google translate makes a reasonable job > of it :-)-O > > Maybe non-response to off-topic posts is best. > > Greetings, el -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnl at iecc.com Thu Sep 4 12:05:12 2014 From: johnl at iecc.com (John Levine) Date: 4 Sep 2014 19:05:12 -0000 Subject: [ih] metadiscussion suggestion In-Reply-To: <1409853544.391.YahooMailNeo@web163803.mail.gq1.yahoo.com> Message-ID: <20140904190512.91731.qmail@joyce.lan> In article <1409853544.391.YahooMailNeo at web163803.mail.gq1.yahoo.com> you write: >Thank you for this post. I was growing confused. It's now egregiously obvious that we're being trolled. You know what (not) to do. From brian.e.carpenter at gmail.com Thu Sep 4 12:41:10 2014 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Fri, 05 Sep 2014 07:41:10 +1200 Subject: [ih] Impact of history on today's technology [was: why did CC happen at all?] In-Reply-To: References: <5401FAF2.8070306@web.de> <540447C3.7060809@web.de> <5404743F.4090102@web.de> <54049AF5.2070803@web.de> <5404B67A.50709@web.de> <38E11C5C-D2B0-48B3-9E00-3D3F96E8E09F@transsys.com> <5405E611.4000604@web.de> <5405FC27.9020105@redbarn.org> <54080B1A.4070001@redbarn.org> <54089110.5060308@web.de> <20140904130503179847.1c158d15@talsever.com> <5408A594.60307@web.de> Message-ID: <5408C056.6040906@gmail.com> I think there is a rather philosophical history question here, all the same. What, in general, is the impact of historical technological issues on current protocols and practices? To take a completely different example, there was a considerable period when handling larger than 16 bit quantities in minicomputers was awkward and slow, so there was a tendency to design stuff around that constraint. Or consider the cost of electronics and cabling in the token ring vs Ethernet argument. I'm sure there are a dozen examples of tech issues from the 1960s and 1970s that still have significant impact today. Regards Brian Carpenter From touch at isi.edu Thu Sep 4 13:19:41 2014 From: touch at isi.edu (Joe Touch) Date: Thu, 04 Sep 2014 13:19:41 -0700 Subject: [ih] A note about this list and contacting the list admin Message-ID: <5408C95D.5060304@isi.edu> Hi, all, If you have any comments or concerns for the list admin, that is me. Because I run a large number of active lists, I do not monitor list postings, nor do I regularly even read most of them. If you have a concern about the list - regarding archives, posts, or conduct of list members, please make sure to contact me directly at: internet-history-admin at postel.org If you prefer, I can also be reached at touch at isi.edu. Joe IH list administrator From eric.gade at gmail.com Thu Sep 4 13:21:47 2014 From: eric.gade at gmail.com (Eric Gade) Date: Thu, 4 Sep 2014 16:21:47 -0400 Subject: [ih] Impact of history on today's technology [was: why did CC happen at all?] In-Reply-To: <5408C056.6040906@gmail.com> References: <5401FAF2.8070306@web.de> <540447C3.7060809@web.de> <5404743F.4090102@web.de> <54049AF5.2070803@web.de> <5404B67A.50709@web.de> <38E11C5C-D2B0-48B3-9E00-3D3F96E8E09F@transsys.com> <5405E611.4000604@web.de> <5405FC27.9020105@redbarn.org> <54080B1A.4070001@redbarn.org> <54089110.5060308@web.de> <20140904130503179847.1c158d15@talsever.com> <5408A594.60307@web.de> <5408C056.6040906@gmail.com> Message-ID: > > > *What, in general, is the impact of historical technological**issues on > current protocols and practices?* Based on my own research and work in this field, there's a real disconnect between what's observed and what people discuss on this list. What I mean is that all technical decisions are in their own way political, and are influenced by a kind of internal politics surrounding their engineering. Those politics change over time, as they are used and adjusted, as do the ways people think about the given technology. The example I will use is DNS and domain names, because that's what I've written about. While in the early 80s there was a need for a naming system do deal with several pressing issues (email header nightmares, for one), the system that was eventually put in place was neither obvious nor inevitable. There are ccTLDs and gTLDs. They both exist in the system because some people thought that recognizing international domains would be important not just from a basic geographic standpoint, but because OSI would eventually subsume or operate on top of whatever ARPA implemented, and so might as well have ccTLDs for that forthcoming future. On the opposite end, gTLDs were intended to be a fixed set containing everything else, a set with global (in the geographic sense) applicability. It wasn't some logical or semantic epiphany, for example, that led Canadian universities to abandon .edu en masse later in the 1980s. Instead, it was the perception that the gTLDs were for US based entities because the NIC was funded by the US government. And they weren't alone -- this became a widespread perception and then pretty much a reality. Of course, the strong cyber-libertarian strain that runs through a lot of the culture eventually helped contribute to a situation where domains are put to the free-market. As we all know this has manifested itself in the "innovations" of ICANN and the ability to pay to create new TLDs (which is contrary to the original idea of a limited, fixed set that are "semantically neutral"). Similarly, ccTLDs don't really mean much. They certainly weren't subsumed by OSI to any great extent, as we all know. You can buy space under a lot of them. I'm sure the tech companies buying .io and .co subdomains have little official contact with the governments of Colombia or the British Indian Territories. So to get back to your original question, the ways people perceive a given technical problem influence the design of the solution. But then perceptions of that solution can also change over time. On Thu, Sep 4, 2014 at 3:41 PM, Brian E Carpenter < brian.e.carpenter at gmail.com> wrote: > I think there is a rather philosophical history question here, > all the same. > > What, in general, is the impact of historical technological > issues on current protocols and practices? To take a completely > different example, there was a considerable period when handling > larger than 16 bit quantities in minicomputers was awkward and > slow, so there was a tendency to design stuff around that constraint. > Or consider the cost of electronics and cabling in the token ring vs > Ethernet argument. I'm sure there are a dozen examples of tech issues > from the 1960s and 1970s that still have significant impact today. > > Regards > Brian Carpenter > -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From touch at isi.edu Thu Sep 4 13:25:19 2014 From: touch at isi.edu (Joe Touch) Date: Thu, 04 Sep 2014 13:25:19 -0700 Subject: [ih] list member inappropriate behavior Message-ID: <5408CAAF.4020109@isi.edu> Hi, all, Reviewing the posts of the past few days, I've seen some very clear behaviors of list members that are inappropriate. I will be posting a policy that applies to all lists I operate, which for now you can consider similar in spirit to the policy for the end2end-interest list, which can be found here: http://www.postel.org/e2e.htm In particular, I noted a few ad-hominem attacks and discussions that were off-topic. I will be contacting the list members involved directly, off-list with a warning. In the future, such behavior may result in being blocked from participating in the list. I urge everyone to return to the focus of this list in a collegial manner. Joe IH list administrator From touch at isi.edu Thu Sep 4 14:54:39 2014 From: touch at isi.edu (Joe Touch) Date: Thu, 04 Sep 2014 14:54:39 -0700 Subject: [ih] why did CC happen at all? In-Reply-To: References: <5401FAF2.8070306@web.de> <540447C3.7060809@web.de> <5404743F.4090102@web.de> <54049AF5.2070803@web.de> <5404B67A.50709@web.de> <38E11C5C-D2B0-48B3-9E00-3D3F96E8E09F@transsys.com> <5405E611.4000604@web.de> <5405FC27.9020105@redbarn.org> <54080B1A.4070001@redbarn.org> <54089110.5060308@web.de> <20140904130503179847.1c158d15@talsever.com> Message-ID: <5408DF9F.4000802@isi.edu> Hi, all, In the interest of protecting the list archive, I am removing the following post from the archive, as well as any post that quotes the URL it includes. This may require a few days to take effect. (I have not mentioned it, but I will indicate any such modifications of the archive in the future as well) Joe IH list admin On 9/4/2014 10:38 AM, Dr Eberhard W Lisse wrote: > He has his own FAQ > [URL REMOVED] > > unfortunately in German, but Google translate makes a reasonable job > of it :-)-O > > Maybe non-response to off-topic posts is best. > > Greetings, el > > Sent from Dr Lisse's iPad mini > > On Sep 4, 2014, at 18:05, Amelia A Lewis > wrote: > >> If it's necessary to post publicly, then I'll do so. >> >> I'd like to second Paul Vixie's call for moderation. Herr Bosau, if >> your concerns have nothing to do with internet history, beyond >> asserting that you know more than the folks who were involved in >> designing internet protocols, and demanding that they admit that they >> were wrong, then you should take your insults and your attempts to >> derail the internet-history discussion list *somewhere else*. >> >> Also, you owe Paul Vixie an apology, and more apologies to the others >> on this list who have shown, in my opinion, remarkable tolerance of >> your anger, insults, and distractions from the topics of the mailing >> list. It is possible that, if (as it seems) english is your second >> language, you're not aware of the hostile and vicious tone that has >> suffused your posts from about the dozenth in this outrageously long >> series. >> >> The folks involved in discussions of congestion control at various >> periods in the development of the internet have graciously discussed >> this history here. That's all that ever belonged here. >> >> Stop. >> >> Amy! >> On Thu, 04 Sep 2014 18:19:28 +0200, Detlef Bosau wrote: >>> Am 04.09.2014 um 08:47 schrieb Paul Vixie: >>>> mr. bosau, i consider your answer completely non-responsive. to reduce >>>> stress, i'm going to add you to my mail filter now. for your possible >>>> self-reference, i received several "thank you paul for saying what you >>>> said" notes from our colleagues here. >>> >>> First: Feel free to add me to your filter. >>> >>> Second: Stop telling lies. >>> >>> When persons want to criticize me, they are free to tell this to me - >>> and not to you. Boasting with actions done by others is an absolute No >>> Go in any academic context. And a reliable means to break any contact >>> with me. So when people have a problem with me, these people either have >>> a name and can speak for themselves, or they have problems, most likely >>> not only with me. >>> >>> >>> And please don't call me a troll. The only person who behaves like a >>> troll, and as a very childish one, are you in this context. >>> I never got in touch with you. I have no idea who you are, we don't know >>> each other. And you come here without any reason, offend me, blame me, >>> without any rationale reason. This is simply bad behaviour. >>> >>> Who are you to do that? >>> >>> God? The President of the United States? >>> >>> And what should my response have been? >>> >>> Think about that for yourself. >>> >>> (And when statements of me are wrong, give rationale to prove them >>> wrong. "I received mails..." or "I received phone calls..." are >>> certainly no rationales.) >>> >>> However, I think we should close this dispute here. I don't think that >>> the other readers are interested in that childish arguments. >>> >>> Detlef >>> >>> From dhc2 at dcrocker.net Thu Sep 4 15:49:04 2014 From: dhc2 at dcrocker.net (Dave Crocker) Date: Thu, 04 Sep 2014 15:49:04 -0700 Subject: [ih] Impact of history on today's technology [was: why did CC happen at all?] In-Reply-To: References: <5401FAF2.8070306@web.de> <540447C3.7060809@web.de> <5404743F.4090102@web.de> <54049AF5.2070803@web.de> <5404B67A.50709@web.de> <38E11C5C-D2B0-48B3-9E00-3D3F96E8E09F@transsys.com> <5405E611.4000604@web.de> <5405FC27.9020105@redbarn.org> <54080B1A.4070001@redbarn.org> <54089110.5060308@web.de> <20140904130503179847.1c158d15@talsever.com> <5408A594.60307@web.de> <5408C056.6040906@gmail.com> Message-ID: <5408EC60.1010500@dcrocker.net> On 9/4/2014 1:21 PM, Eric Gade wrote: > Based on my own research and work in this field, there's a real > disconnect between what's observed and what people discuss on this list. > What I mean is that all technical decisions are in their own way > political, In the abstract, that's probably true. In the concrete, it often is not. Of course, often is not the same as never, of course. When engineers acquire a relatively well-defined problem to solve and work in a relatively collaborative manner to solve it, it is difficult to discern forces or processes that can reasonably be called "political" in any practical sense. Such situations do occur. > The example I will use is DNS and domain names, because that's what I've > written about. While in the early 80s there was a need for a naming > system do deal with several pressing issues (email header nightmares, > for one), the system that was eventually put in place was neither > obvious nor inevitable. There are ccTLDs and gTLDs. They both exist in > the system because some people thought that recognizing international > domains would be important not just from a basic geographic standpoint, > but because OSI would eventually subsume or operate on top of whatever > ARPA implemented, and so might as well have ccTLDs for that forthcoming > future. I wasn't in the middle of the decision to create ccTLDs but my understanding is that it had nothing to do with OSI. For name administration, the DNS' prime directive is delegation. That creates the task of figuring out who to delegate to, and how to make a model -- or in the case of TLDs model/s/ -- that scale. It did not take much DNS growth before countries became an obvious delegation model. Trying to figure out things like what is a country motivated Postel to look for an acceptable list maintained by someone else. That was his basis for landing on the ISO table. But that had nothing to do with OSI. > On the opposite end, gTLDs were intended to be a fixed set > containing everything else, a set with global (in the geographic sense) > applicability. Intended? "Fixed"? Wherever did you get that idea from? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dhc2 at dcrocker.net Thu Sep 4 15:56:01 2014 From: dhc2 at dcrocker.net (Dave Crocker) Date: Thu, 04 Sep 2014 15:56:01 -0700 Subject: [ih] Impact of history on today's technology [was: why did CC happen at all?] In-Reply-To: <5408C056.6040906@gmail.com> References: <5401FAF2.8070306@web.de> <540447C3.7060809@web.de> <5404743F.4090102@web.de> <54049AF5.2070803@web.de> <5404B67A.50709@web.de> <38E11C5C-D2B0-48B3-9E00-3D3F96E8E09F@transsys.com> <5405E611.4000604@web.de> <5405FC27.9020105@redbarn.org> <54080B1A.4070001@redbarn.org> <54089110.5060308@web.de> <20140904130503179847.1c158d15@talsever.com> <5408A594.60307@web.de> <5408C056.6040906@gmail.com> Message-ID: <5408EE01.3010205@dcrocker.net> On 9/4/2014 12:41 PM, Brian E Carpenter wrote: > What, in general, is the impact of historical technological > issues on current protocols and practices? As many times as I've re-read your query, I can't quite get enough of a sense of what it means, in terms of actual substance. The example of token ring vs. ethernet helps, but not quite enough, for me at least. (1/4 of the real estate on the original Irvine ring was the token recover mechanism, which used a contention system, thereby suggesting that a contention model would be cheaper and smaller, if you didn't need the guarantees of the token discipline.) Perhaps you have in mind something like the technological issue of typewriter keys getting stuck against each other if the typist went to fast, thereby motivating the qwerty layout? Or the politics of trying to get along with the OSI folk, thereby sticking is with continuing painful use of ASN.1? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From eric.gade at gmail.com Thu Sep 4 16:27:32 2014 From: eric.gade at gmail.com (Eric Gade) Date: Thu, 4 Sep 2014 19:27:32 -0400 Subject: [ih] Impact of history on today's technology [was: why did CC happen at all?] In-Reply-To: <5408EC60.1010500@dcrocker.net> References: <5401FAF2.8070306@web.de> <540447C3.7060809@web.de> <5404743F.4090102@web.de> <54049AF5.2070803@web.de> <5404B67A.50709@web.de> <38E11C5C-D2B0-48B3-9E00-3D3F96E8E09F@transsys.com> <5405E611.4000604@web.de> <5405FC27.9020105@redbarn.org> <54080B1A.4070001@redbarn.org> <54089110.5060308@web.de> <20140904130503179847.1c158d15@talsever.com> <5408A594.60307@web.de> <5408C056.6040906@gmail.com> <5408EC60.1010500@dcrocker.net> Message-ID: > > > *When engineers acquire a relatively well-defined problem to solve and* > *work in a relatively collaborative manner to solve it, it is difficult* > *to discern forces or processes that can reasonably be called "political"**in > any practical sense.* This might better apply to the technical implementation, I suppose. For example, there was a lot of collaboration on drafting the technical specification for DNS that became Paul Mockapetris' RFCs. The way the servers work, the data structures, and the different records fall in this category. Maybe we're talking past each other here, but that's not the part I'm referring to. I would call the intellectual climate of ARPA-Internet and OSI a political one. By that I mean politics internal to the community. In the archives I found meeting notes etc which indicate quite explicitly that countries should be TLDs because the system being developed by IFIP (which was doing pre-standards work for naming/addressing for OSI) would have countries at the top. In fact, there was a lot of clamor for countries at the top from people who were either affiliated with other OSI work or working on IFIP itself. I found only a couple of cases where people argued for a geographical structure on its own merits. There was an assumption by many non-Americans, and some Americans too, that OSI would subsume whatever standards ARPA developed. This assumption is to my mind a reflection of the internal politics I'm talking about, and it influenced how people argued for a certain naming structure. So while it's absolutely true that no one was looking at the relevant OSI parts (x.400/x.500) and thinking of making domains, it is true that the existence of these looming, assumed (by some) standards had a big influence on domains. One other example I can give happened in the late 80s with the UK's JANET network (bare with me here). As many of you may recall, their Name Recognition Scheme (NRS) appeared like domain names, but backwards (UK.AC.CAM, for example). This became an issue after the Velvet Revolution, when the Czechs applied for a ccTLD (.CS). Now all of the sudden the mail exchangers would have a hell of a time parsing cs.edu.university.cs coming from or through JANET -- should an email to to Czechoslovakia or to the computer science department? The Joint Network Team in the UK got a lot of head, particularly from ARPA people, for not reversing their name order. They refused to do so for three reasons. The first was that NRS predated domains. The second was that they were terribly underfunded and it would require a lot of work (they were suing one of their contractors at the time and had budget problems). The third, and most telling, is that they'd spent all of their time on X.400 work and didn't want to make any drastic changes "because OSI will replace everything anyway" (paraphrased). *Intended? "Fixed"? Wherever did you get that idea from?* I can't tell if this is tongue-in-cheek. In case it isn't, this comes also from meeting notes, emails, and reports that are all archived at the Feinler collection at the Computer History Museum. "Fixed" is of course a fluid term here, but I've used it because it was used multiple times in the archival materials. The idea was that there would be a small set that would be enough for a person to remember. Sorry for the long message, just wanted to get the list back on track. On Thu, Sep 4, 2014 at 6:49 PM, Dave Crocker wrote: > On 9/4/2014 1:21 PM, Eric Gade wrote: > > Based on my own research and work in this field, there's a real > > disconnect between what's observed and what people discuss on this list. > > What I mean is that all technical decisions are in their own way > > political, > > In the abstract, that's probably true. In the concrete, it often is > not. Of course, often is not the same as never, of course. > > When engineers acquire a relatively well-defined problem to solve and > work in a relatively collaborative manner to solve it, it is difficult > to discern forces or processes that can reasonably be called "political" > in any practical sense. Such situations do occur. > > > > The example I will use is DNS and domain names, because that's what I've > > written about. While in the early 80s there was a need for a naming > > system do deal with several pressing issues (email header nightmares, > > for one), the system that was eventually put in place was neither > > obvious nor inevitable. There are ccTLDs and gTLDs. They both exist in > > the system because some people thought that recognizing international > > domains would be important not just from a basic geographic standpoint, > > but because OSI would eventually subsume or operate on top of whatever > > ARPA implemented, and so might as well have ccTLDs for that forthcoming > > future. > > I wasn't in the middle of the decision to create ccTLDs but my > understanding is that it had nothing to do with OSI. > > For name administration, the DNS' prime directive is delegation. That > creates the task of figuring out who to delegate to, and how to make a > model -- or in the case of TLDs model/s/ -- that scale. > > It did not take much DNS growth before countries became an obvious > delegation model. Trying to figure out things like what is a country > motivated Postel to look for an acceptable list maintained by someone > else. That was his basis for landing on the ISO table. > > But that had nothing to do with OSI. > > > > On the opposite end, gTLDs were intended to be a fixed set > > containing everything else, a set with global (in the geographic sense) > > applicability. > > Intended? "Fixed"? Wherever did you get that idea from? > > d/ > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From dhc2 at dcrocker.net Thu Sep 4 16:53:15 2014 From: dhc2 at dcrocker.net (Dave Crocker) Date: Thu, 04 Sep 2014 16:53:15 -0700 Subject: [ih] Impact of history on today's technology [was: why did CC happen at all?] In-Reply-To: References: <5401FAF2.8070306@web.de> <540447C3.7060809@web.de> <5404743F.4090102@web.de> <54049AF5.2070803@web.de> <5404B67A.50709@web.de> <38E11C5C-D2B0-48B3-9E00-3D3F96E8E09F@transsys.com> <5405E611.4000604@web.de> <5405FC27.9020105@redbarn.org> <54080B1A.4070001@redbarn.org> <54089110.5060308@web.de> <20140904130503179847.1c158d15@talsever.com> <5408A594.60307@web.de> <5408C056.6040906@gmail.com> <5408EC60.1010500@dcrocker.net> Message-ID: <5408FB6B.4030202@dcrocker.net> On 9/4/2014 4:27 PM, Eric Gade wrote: > /When engineers acquire a relatively well-defined problem to solve and > //work in a relatively collaborative manner to solve it, it is difficult > //to discern forces or processes that can reasonably be called > "political" > //in any practical sense./ > > > This might better apply to the technical implementation, I suppose. For You said "all technical decisions" and so I was focusing on... technical decisions of the DNS. Design, specification, and the like. I believe the closest one could come to 'politics' for that early design effort was "the host table is to big and we need something with better scaling properties." > I would call the intellectual climate of ARPA-Internet and OSI a > political one. By that I mean politics internal to the community. And that's why I said "in theory" one can call all sorts of things political. The problem is that that word politics often gets used quite generically and even quite politically. So I wanted to get to a very pragmatic point about technical decision environments in which there is no meaningful overtone or undertone of politics internal to the community doing the work. > In the archives I found meeting notes etc which indicate quite > explicitly that countries should be TLDs because the system being > developed by IFIP (which was doing pre-standards work for > naming/addressing for OSI) would have countries at the top. In fact, I'm so glad I included the caveat that I wasn't in the middle of that. On the other hand, I did participate a few of the x.500 discussions, which I assume is what you are referring to? Do you have a pointer to those minutes? > There was an assumption by many non-Americans, and some Americans too, > that OSI would subsume whatever standards ARPA developed. This Different issue. Yes, OSI was assumed by most to be what would become the international standard. And there certainly was massive politics and finance and organization commitment to it. This goes to show that with enough effort, even a guaranteed success can be made to fail. In the case of X.400 the critical error -- besides the overall excessive complexity -- was entirely political, namely that telecom companies would be central switching services for all email; that's what comes of hosting the effort in a telecoms regulatory agency... X.500 made similar errors in pragmatics. > /Intended? "Fixed"? Wherever did you get that idea from?/ > > I can't tell if this is tongue-in-cheek. In case it isn't, this comes > also from meeting notes, emails, and reports that are all archived at > the Feinler collection at the Computer History Museum. "Fixed" is of > course a fluid term here, but I've used it because it was used multiple > times in the archival materials. The idea was that there would be a > small set that would be enough for a person to remember. ack. hmmm. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From larrysheldon at cox.net Thu Sep 4 17:20:31 2014 From: larrysheldon at cox.net (Larry Sheldon) Date: Thu, 04 Sep 2014 19:20:31 -0500 Subject: [ih] why did CC happen at all? In-Reply-To: References: <5401FAF2.8070306@web.de> <540447C3.7060809@web.de> <5404743F.4090102@web.de> <54049AF5.2070803@web.de> <5404B67A.50709@web.de> <38E11C5C-D2B0-48B3-9E00-3D3F96E8E09F@transsys.com> <5405E611.4000604@web.de> <5405FC27.9020105@redbarn.org> <54080B1A.4070001@redbarn.org> Message-ID: <540901CF.2090302@cox.net> On 9/4/2014 11:19, Detlef Bosau wrote: > First: Feel free to add me to your filter. Done -- The unique Characteristics of System Administrators: The fact that they are infallible; and, The fact that they learn from their mistakes. From larrysheldon at cox.net Thu Sep 4 17:46:23 2014 From: larrysheldon at cox.net (Larry Sheldon) Date: Thu, 04 Sep 2014 19:46:23 -0500 Subject: [ih] Impact of history on today's technology [was: why did CC happen at all?] In-Reply-To: References: <5401FAF2.8070306@web.de> <540447C3.7060809@web.de> <5404743F.4090102@web.de> <54049AF5.2070803@web.de> <5404B67A.50709@web.de> <38E11C5C-D2B0-48B3-9E00-3D3F96E8E09F@transsys.com> <5405E611.4000604@web.de> <5405FC27.9020105@redbarn.org> <54080B1A.4070001@redbarn.org> <54089110.5060308@web.de> <20140904130503179847.1c158d15@talsever.com> <5408A594.60307@web.de> Message-ID: <540907DF.6030508@cox.net> On 9/4/2014 14:41, Brian E Carpenter wrote: > I think there is a rather philosophical history question here, > all the same. > > What, in general, is the impact of historical technological > issues on current protocols and practices? To take a completely > different example, there was a considerable period when handling > larger than 16 bit quantities in minicomputers was awkward and > slow, so there was a tendency to design stuff around that constraint. > Or consider the cost of electronics and cabling in the token ring vs > Ethernet argument. I'm sure there are a dozen examples of tech issues > from the 1960s and 1970s that still have significant impact today. I was not a part of the network-development world except as a "consumer" of sorts. It appears to me, from what was a UNIVAC 1100-centric view of the world the the emerging networks stuff--like a lot of earlier telecommunications stuff--had a a strong IBM coloration, flavor, and odor. For example, when the realization dawned that 4, 8, and 16 were not natural limits on word size and 8 bits was the only sub-division possible, 32 bits (and 8 bits) took over, leaving us who lived in an 8-bit-36-bit world with some awkward arithmetic. -- The unique Characteristics of System Administrators: The fact that they are infallible; and, The fact that they learn from their mistakes. From jeanjour at comcast.net Thu Sep 4 19:31:31 2014 From: jeanjour at comcast.net (John Day) Date: Thu, 4 Sep 2014 22:31:31 -0400 Subject: [ih] Impact of history on today's technology [was: why did CC happen at all?] In-Reply-To: <540907DF.6030508@cox.net> References: <5401FAF2.8070306@web.de> <540447C3.7060809@web.de> <5404743F.4090102@web.de> <54049AF5.2070803@web.de> <5404B67A.50709@web.de> <38E11C5C-D2B0-48B3-9E00-3D3F96E8E09F@transsys.com> <5405E611.4000604@web.de> <5405FC27.9020105@redbarn.org> <54080B1A.4070001@redbarn.org> <54089110.5060308@web.de> <20140904130503179847.1c158d15@talsever.com> <5408A594.60307@web.de> <540907DF.6030508@cox.net> Message-ID: In all areas, the IBM influence was minimal if any. In the ARPANET, EBCDIC was tolerated because of Multics and the UCLA 360/91, half-duplex terminals were tolerated for the same reason. The nature of the protocols in the ARPANET, the Internet, and OSI had very little IBM influence. Any influence IBM might have had was more in terms of what they couldn't do, that everyone else could. Probably mostly limited to HDLC as coming from SDLC, but that work was really unrelated. IBM's primary strategy was not so much to contribute to the standards but ensure that they moved as slowly as possible. Take care, John At 7:46 PM -0500 9/4/14, Larry Sheldon wrote: >On 9/4/2014 14:41, Brian E Carpenter wrote: >>I think there is a rather philosophical history question here, >>all the same. >> >>What, in general, is the impact of historical technological >>issues on current protocols and practices? To take a completely >>different example, there was a considerable period when handling >>larger than 16 bit quantities in minicomputers was awkward and >>slow, so there was a tendency to design stuff around that constraint. >>Or consider the cost of electronics and cabling in the token ring vs >>Ethernet argument. I'm sure there are a dozen examples of tech issues >>from the 1960s and 1970s that still have significant impact today. > >I was not a part of the network-development world except as a >"consumer" of sorts. > >It appears to me, from what was a UNIVAC 1100-centric view of the >world the the emerging networks stuff--like a lot of earlier >telecommunications stuff--had a a strong IBM coloration, flavor, and >odor. > >For example, when the realization dawned that 4, 8, and 16 were not >natural limits on word size and 8 bits was the only sub-division >possible, 32 bits (and 8 bits) took over, leaving us who lived in an >8-bit-36-bit world with some awkward arithmetic. > > >-- >The unique Characteristics of System Administrators: > >The fact that they are infallible; and, > >The fact that they learn from their mistakes. From jeanjour at comcast.net Thu Sep 4 20:08:00 2014 From: jeanjour at comcast.net (John Day) Date: Thu, 4 Sep 2014 23:08:00 -0400 Subject: [ih] Impact of history on today's technology [was: why did CC happen at all?] In-Reply-To: <5408FB6B.4030202@dcrocker.net> References: <5401FAF2.8070306@web.de> <540447C3.7060809@web.de> <5404743F.4090102@web.de> <54049AF5.2070803@web.de> <5404B67A.50709@web.de> <38E11C5C-D2B0-48B3-9E00-3D3F96E8E09F@transsys.com> <5405E611.4000604@web.de> <5405FC27.9020105@redbarn.org> <54080B1A.4070001@redbarn.org> <54089110.5060308@web.de> <20140904130503179847.1c158d15@talsever.com> <5408A594.60307@web.de> <5408C056.6040906@gmail.com> <5408EC60.1010500@dcrocker.net> <5408FB6B.4030202@dcrocker.net> Message-ID: There is really no relation between the OSI naming and addressing work and DNS. DNS is concerned with developing a naming scheme for hosts. Taking its cue from the early ARPANET discussions and the work on XNS, OSI was focused on naming Application Processes (to be location-independent, a research topic of late) and Network Entities (to be location-dependent but route-independent). By 1982, the naming and addressing work in OSI had figured out that naming hosts was irrelevant to the problem and it was a very bad idea to embed an (N-1)-address in an (N)-address. To some degree, X.500 had realized that a single naming hierarchy was both not necessary and probably not workable in the long term, but what they produce was probably too far in advance of the market. The problem was that X.500 rather than limiting itself to mapping of application-process-names to network addresses tried to be the "yellow pages" or even Google (although hadn't realized that was what they were doing). It had become clear that there was a very fine line between an X.500 name and a database query. Some would say a line so fine it was invisible. X.400 was captured by the phone companies and internal naming schemes. The X.400 naming scheme was internal to that application, and was not part of the OSI architecture per se. OSI was nothing but politics, but it had nothing to do with the Internet. The Internet being an internal DoD network represented no market (or not a market of sufficient size) that any of the major computer businesses or phone companies cared about or took much notice of, i.e. it was not even a minor part of their revenue. At least that was the view of the companies participating in OSI. To say "OSI had a view on this" would make no sense. There was no "OSI view." (This is not to say there was not a flock of small start ups competing for the Internet market such as it was in the early to mid 1980s.) Of course once the Internet became a public network that changed very quickly. The primary political issues within OSI were the computer companies vs the phone companies, Europe vs the US vs Japan, and everyone against IBM. The technical manifestation of that politics revolved primarily around connection/connectionless debate and starting in 1975, the phone companies contention that a transport layer was unnecessary. Although, there was a general opposition to most anything the phone companies proposed. (They were always so short-sighted.) If you want an example of politics affecting actual protocol, look at OSI Transport. When the PTTs found they couldn't stop it, they did the next best thing by confusing the issue with 5 classes. The first 3 for different ITU committees, and only one that was really needed. My favorite part of that was the PTTs saying one should use Class 0 Transport (which did nothing) and then use RTSE in the Application Layer, which was a full Transport Protocol! ;-) Really funny! But it allowed them to draw lines the way they wanted. I was always amazed at how the Europeans were taken in by that ruse. Maybe more tomorrow when I am less tired. John Day Rapporteur of the OSI Reference Model 1980-1990 or thereabouts Rapporteur for OSI Naming and Addressing (same) >On 9/4/2014 4:27 PM, Eric Gade wrote: >> /When engineers acquire a relatively well-defined problem to solve and >> //work in a relatively collaborative manner to solve it, it is difficult >> //to discern forces or processes that can reasonably be called >> "political" >> //in any practical sense./ >> >> >> This might better apply to the technical implementation, I suppose. For > >You said "all technical decisions" and so I was focusing on... technical >decisions of the DNS. Design, specification, and the like. > >I believe the closest one could come to 'politics' for that early design >effort was "the host table is to big and we need something with better >scaling properties." > > >> I would call the intellectual climate of ARPA-Internet and OSI a >> political one. By that I mean politics internal to the community. > >And that's why I said "in theory" one can call all sorts of things >political. > >The problem is that that word politics often gets used quite generically >and even quite politically. So I wanted to get to a very pragmatic >point about technical decision environments in which there is no >meaningful overtone or undertone of politics internal to the community >doing the work. > > >> In the archives I found meeting notes etc which indicate quite >> explicitly that countries should be TLDs because the system being >> developed by IFIP (which was doing pre-standards work for >> naming/addressing for OSI) would have countries at the top. In fact, > >I'm so glad I included the caveat that I wasn't in the middle of that. > >On the other hand, I did participate a few of the x.500 discussions, >which I assume is what you are referring to? > >Do you have a pointer to those minutes? > > >> There was an assumption by many non-Americans, and some Americans too, >> that OSI would subsume whatever standards ARPA developed. This > >Different issue. Yes, OSI was assumed by most to be what would become >the international standard. And there certainly was massive politics >and finance and organization commitment to it. This goes to show that >with enough effort, even a guaranteed success can be made to fail. > >In the case of X.400 the critical error -- besides the overall excessive >complexity -- was entirely political, namely that telecom companies >would be central switching services for all email; that's what comes of >hosting the effort in a telecoms regulatory agency... > >X.500 made similar errors in pragmatics. > > >> /Intended? "Fixed"? Wherever did you get that idea from?/ >> >> I can't tell if this is tongue-in-cheek. In case it isn't, this comes >> also from meeting notes, emails, and reports that are all archived at >> the Feinler collection at the Computer History Museum. "Fixed" is of >> course a fluid term here, but I've used it because it was used multiple >> times in the archival materials. The idea was that there would be a >> small set that would be enough for a person to remember. > >ack. hmmm. > > >d/ >-- >Dave Crocker >Brandenburg InternetWorking >bbiw.net From jeanjour at comcast.net Thu Sep 4 20:23:59 2014 From: jeanjour at comcast.net (John Day) Date: Thu, 4 Sep 2014 23:23:59 -0400 Subject: [ih] Impact of history on today's technology [was: why did CC happen at all?] In-Reply-To: References: <5401FAF2.8070306@web.de> " <540447C3.7060809@web.de>" " <5404743F.4090102@web.de>" <54049AF5.2070803@web.de> <5404B67A.50709@web.de> <38E11C5C-D2B0-48B3-9E00-3D3F96E8E09F@transsys.com> <5405E611.4000604@web.de> " <5405FC27.9020105@redbarn.org>" <54080B1A.4070001@redbarn.org> " <54089110.5060308@web.de>" <20140904130503179847.1c158d15@talsever.com> <5408A594.60307@web.de> <540907DF.6030508@cox.net> Message-ID: All Multics terminals were half duplex IBM Selectrix and it was programmed in PL/1 that used EBCDIC. But I will defer to Pogran on this one. ASCII was 7- bits. In fact, there was a "crisis" one morning when BBN deployed new ASCII/EBCDIC tables in the TIPs and the guys logging into Multics from a TIP couldn't generate the line delete or character delete characters. At 11:16 PM -0400 9/4/14, Michael Greenwald wrote: >On 2014-09-04 22:31, John Day wrote: >>In all areas, the IBM influence was minimal if any. In the ARPANET, >>EBCDIC was tolerated because of Multics > >?? Perhaps I'm misremembering but Multics used ASCII (9-bit >characters, but still >ASCII as far as I remember). Multics had (library?) routines to >write and read >EBCDIC if needed -- is this why you mention Multics when talking about EBCDIC? >Either way, I don't think that would be enough to cause people to tolerate >EBCDIC. > >I'm just curious how multics may have caused EBCDIC to be "tolerated"? > >>and the UCLA 360/91, >>half-duplex terminals were tolerated for the same reason. The nature >>of the protocols in the ARPANET, the Internet, and OSI had very little >>IBM influence. Any influence IBM might have had was more in terms of >>what they couldn't do, that everyone else could. >> >>Probably mostly limited to HDLC as coming from SDLC, but that work was >>really unrelated. >> >>IBM's primary strategy was not so much to contribute to the standards >>but ensure that they moved as slowly as possible. >> >>Take care, >>John >> >>At 7:46 PM -0500 9/4/14, Larry Sheldon wrote: >>>On 9/4/2014 14:41, Brian E Carpenter wrote: >>>>I think there is a rather philosophical history question here, >>>>all the same. >>>> >>>>What, in general, is the impact of historical technological >>>>issues on current protocols and practices? To take a completely >>>>different example, there was a considerable period when handling >>>>larger than 16 bit quantities in minicomputers was awkward and >>>>slow, so there was a tendency to design stuff around that constraint. >>>>Or consider the cost of electronics and cabling in the token ring vs >>>>Ethernet argument. I'm sure there are a dozen examples of tech issues >>>>from the 1960s and 1970s that still have significant impact today. >>> >>>I was not a part of the network-development world except as a >>>"consumer" of sorts. >>> >>>It appears to me, from what was a UNIVAC 1100-centric view of the >>>world the the emerging networks stuff--like a lot of earlier >>>telecommunications stuff--had a a strong IBM coloration, flavor, >>>and odor. >>> >>>For example, when the realization dawned that 4, 8, and 16 were >>>not natural limits on word size and 8 bits was the only >>>sub-division possible, 32 bits (and 8 bits) took over, leaving us >>>who lived in an 8-bit-36-bit world with some awkward arithmetic. >>> >>> >>>-- >>>The unique Characteristics of System Administrators: >>> >>>The fact that they are infallible; and, >>> >>>The fact that they learn from their mistakes. From eric.gade at gmail.com Thu Sep 4 21:31:31 2014 From: eric.gade at gmail.com (Eric Gade) Date: Fri, 5 Sep 2014 00:31:31 -0400 Subject: [ih] Impact of history on today's technology [was: why did CC happen at all?] In-Reply-To: <5408FB6B.4030202@dcrocker.net> References: <5401FAF2.8070306@web.de> <540447C3.7060809@web.de> <5404743F.4090102@web.de> <54049AF5.2070803@web.de> <5404B67A.50709@web.de> <38E11C5C-D2B0-48B3-9E00-3D3F96E8E09F@transsys.com> <5405E611.4000604@web.de> <5405FC27.9020105@redbarn.org> <54080B1A.4070001@redbarn.org> <54089110.5060308@web.de> <20140904130503179847.1c158d15@talsever.com> <5408A594.60307@web.de> <5408C056.6040906@gmail.com> <5408EC60.1010500@dcrocker.net> <5408FB6B.4030202@dcrocker.net> Message-ID: > > > *You said "all technical decisions" and so I was focusing on... technical **decisions > of the DNS. Design, specification, and the like.* I yield. Bad choice of words. > *Different issue. Yes, OSI was assumed by most to be what would become * > *the international standard. And there certainly was massive politics* > *and finance and organization commitment to it. This goes to show that **with > enough effort, even a guaranteed success can be made to fail.* Having looked extensively at the conversations about what naming structure should be in place, I can't entirely agree that OSI is a different issue. There were strong cases made, for example, for a DNS structure that reflected network topology -- with UUCP and the like as TLDs. I think we look back now and assume that political geography is an obvious choice, but a lot of debate went into it and it probably wasn't that obvious compared to others. It became obvious once people started mentioning the importance of countries in the IFIP scheme. In saying that OSI affected this or that, I'm not referring to some specific technical feature therein. I'm referring precisely to this assumption by many that it would become a widely used international standard. That assumption affected to a certain degree -- I argue a large degree in the case of TLDs -- the decisions people made about structure. Had people not been affected by OSI concerns, it might very well be the case that networks would be TLDs (even early draft RFCs had these). This is what I mean by a connection, an influence. Clearly they had different technical features and concerns. Of course, I'm willing to accept that I'm completely off base, but I haven't seen any archival evidence to the contrary, nor have I seen works that make use of such evidence. *Do you have a pointer to those minutes?* I'll have to go digging around through my own photos of the files again. I don't have anything from meetings about X500 itself, as I wasn't really concerned with it. Some of the meeting notes I'm talking about are hand-written notes, mostly from Jake Feinler, that are kept at the Computer History Museum. It's really an impressive archival collection. A lot of the other source material includes drafts of various standards including RFCs, printed (believe it or not) versions of all kinds of emails, and messages on the *Namedroppers* list. There are some interesting published papers too (including one by Mockapetris and Postel in which they compare IFIP to DNS). I believe it's in one of those papers that Postel says, "Naming is a uniquely political act." On Thu, Sep 4, 2014 at 7:53 PM, Dave Crocker wrote: > On 9/4/2014 4:27 PM, Eric Gade wrote: > > /When engineers acquire a relatively well-defined problem to solve > and > > //work in a relatively collaborative manner to solve it, it is > difficult > > //to discern forces or processes that can reasonably be called > > "political" > > //in any practical sense./ > > > > > > This might better apply to the technical implementation, I suppose. For > > You said "all technical decisions" and so I was focusing on... technical > decisions of the DNS. Design, specification, and the like. > > I believe the closest one could come to 'politics' for that early design > effort was "the host table is to big and we need something with better > scaling properties." > > > > I would call the intellectual climate of ARPA-Internet and OSI a > > political one. By that I mean politics internal to the community. > > And that's why I said "in theory" one can call all sorts of things > political. > > The problem is that that word politics often gets used quite generically > and even quite politically. So I wanted to get to a very pragmatic > point about technical decision environments in which there is no > meaningful overtone or undertone of politics internal to the community > doing the work. > > > > In the archives I found meeting notes etc which indicate quite > > explicitly that countries should be TLDs because the system being > > developed by IFIP (which was doing pre-standards work for > > naming/addressing for OSI) would have countries at the top. In fact, > > I'm so glad I included the caveat that I wasn't in the middle of that. > > On the other hand, I did participate a few of the x.500 discussions, > which I assume is what you are referring to? > > Do you have a pointer to those minutes? > > > > There was an assumption by many non-Americans, and some Americans too, > > that OSI would subsume whatever standards ARPA developed. This > > Different issue. Yes, OSI was assumed by most to be what would become > the international standard. And there certainly was massive politics > and finance and organization commitment to it. This goes to show that > with enough effort, even a guaranteed success can be made to fail. > > In the case of X.400 the critical error -- besides the overall excessive > complexity -- was entirely political, namely that telecom companies > would be central switching services for all email; that's what comes of > hosting the effort in a telecoms regulatory agency... > > X.500 made similar errors in pragmatics. > > > > /Intended? "Fixed"? Wherever did you get that idea from?/ > > > > I can't tell if this is tongue-in-cheek. In case it isn't, this comes > > also from meeting notes, emails, and reports that are all archived at > > the Feinler collection at the Computer History Museum. "Fixed" is of > > course a fluid term here, but I've used it because it was used multiple > > times in the archival materials. The idea was that there would be a > > small set that would be enough for a person to remember. > > ack. hmmm. > > > d/ > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeanjour at comcast.net Fri Sep 5 03:46:25 2014 From: jeanjour at comcast.net (John Day) Date: Fri, 5 Sep 2014 06:46:25 -0400 Subject: [ih] Impact of history on today's technology [was: why did CC happen at all?] In-Reply-To: References: <5401FAF2.8070306@web.de> " <540447C3.7060809@web.de>" " <5404743F.4090102@web.de>" <54049AF5.2070803@web.de> <5404B67A.50709@web.de> <38E11C5C-D2B0-48B3-9E00-3D3F96E8E09F@transsys.com> <5405E611.4000604@web.de> " <5405FC27.9020105@redbarn.org>" <54080B1A.4070001@redbarn.org> " <54089110.5060308@web.de>" <20140904130503179847.1c158d15@talsever.com> <5408A594.60307@web.de> <540907DF.6030508@cox.net> Message-ID: Michael, I think I was wrong and you were right. After I went downstairs last night, it slowly came back to me ;-) that Pogran and I had discussed this before and my story of the translate tables was wrong. Pogran and I had come across another situation where the mapping between the conventions was not the isomorphic. We were doing a File Access Protocol (1973) and used a byte-indexed file pointer and realized it wouldn't be as simple as we thought, because the ASCII/ARPANET convention for "end of record" was CRLF and the Multics convention was NL (New Line), which I thought was EBCDIC not ASCII. John At 11:16 PM -0400 9/4/14, Michael Greenwald wrote: >On 2014-09-04 22:31, John Day wrote: >>In all areas, the IBM influence was minimal if any. In the ARPANET, >>EBCDIC was tolerated because of Multics > >?? Perhaps I'm misremembering but Multics used ASCII (9-bit >characters, but still >ASCII as far as I remember). Multics had (library?) routines to >write and read >EBCDIC if needed -- is this why you mention Multics when talking about EBCDIC? >Either way, I don't think that would be enough to cause people to tolerate >EBCDIC. > >I'm just curious how multics may have caused EBCDIC to be "tolerated"? > >>and the UCLA 360/91, >>half-duplex terminals were tolerated for the same reason. The nature >>of the protocols in the ARPANET, the Internet, and OSI had very little >>IBM influence. Any influence IBM might have had was more in terms of >>what they couldn't do, that everyone else could. >> >>Probably mostly limited to HDLC as coming from SDLC, but that work was >>really unrelated. >> >>IBM's primary strategy was not so much to contribute to the standards >>but ensure that they moved as slowly as possible. >> >>Take care, >>John >> >>At 7:46 PM -0500 9/4/14, Larry Sheldon wrote: >>>On 9/4/2014 14:41, Brian E Carpenter wrote: >>>>I think there is a rather philosophical history question here, >>>>all the same. >>>> >>>>What, in general, is the impact of historical technological >>>>issues on current protocols and practices? To take a completely >>>>different example, there was a considerable period when handling >>>>larger than 16 bit quantities in minicomputers was awkward and >>>>slow, so there was a tendency to design stuff around that constraint. >>>>Or consider the cost of electronics and cabling in the token ring vs >>>>Ethernet argument. I'm sure there are a dozen examples of tech issues >>>>from the 1960s and 1970s that still have significant impact today. >>> >>>I was not a part of the network-development world except as a >>>"consumer" of sorts. >>> >>>It appears to me, from what was a UNIVAC 1100-centric view of the >>>world the the emerging networks stuff--like a lot of earlier >>>telecommunications stuff--had a a strong IBM coloration, flavor, >>>and odor. >>> >>>For example, when the realization dawned that 4, 8, and 16 were >>>not natural limits on word size and 8 bits was the only >>>sub-division possible, 32 bits (and 8 bits) took over, leaving us >>>who lived in an 8-bit-36-bit world with some awkward arithmetic. >>> >>> >>>-- >>>The unique Characteristics of System Administrators: >>> >>>The fact that they are infallible; and, >>> >>>The fact that they learn from their mistakes. From jeanjour at comcast.net Fri Sep 5 04:04:07 2014 From: jeanjour at comcast.net (John Day) Date: Fri, 5 Sep 2014 07:04:07 -0400 Subject: [ih] Impact of history on today's technology [was: why did CC happen at all?] In-Reply-To: References: <5401FAF2.8070306@web.de> " <540447C3.7060809@web.de>" " <5404743F.4090102@web.de>" <54049AF5.2070803@web.de> <5404B67A.50709@web.de> <38E11C5C-D2B0-48B3-9E00-3D3F96E8E09F@transsys.com> <5405E611.4000604@web.de> " <5405FC27.9020105@redbarn.org>" <54080B1A.4070001@redbarn.org> " <54089110.5060308@web.de>" <20140904130503179847.1c158d15@talsever.com> <5408A594.60307@web.de> <540907DF.6030508@cox.net> Message-ID: At 6:55 AM -0400 9/5/14, Michael Greenwald wrote: >On 2014-09-05 06:46, John Day wrote: >>Michael, >>I think I was wrong and you were right. After I went downstairs last >>night, it slowly came back to me ;-) that Pogran and I had discussed >>this before and my story of the translate tables was wrong. > >I was pretty sure that by 1977 or so Multics used ASCII. I wasn't >sure if you may have been referring to earlier days. O, I was definitely referring to before 1977! ;-) > >> >>Pogran and I had come across another situation where the mapping >>between the conventions was not the isomorphic. We were doing a File >>Access Protocol (1973) and used a byte-indexed file pointer and >>realized it wouldn't be as simple as we thought, because the >>ASCII/ARPANET convention for "end of record" was CRLF and the Multics >>convention was NL (New Line), which I thought was EBCDIC not ASCII. >> >>John >> >>At 11:16 PM -0400 9/4/14, Michael Greenwald wrote: >>>On 2014-09-04 22:31, John Day wrote: >>>>In all areas, the IBM influence was minimal if any. In the ARPANET, >>>>EBCDIC was tolerated because of Multics >>> >>>?? Perhaps I'm misremembering but Multics used ASCII (9-bit >>>characters, but still >>>ASCII as far as I remember). Multics had (library?) routines to >>>write and read >>>EBCDIC if needed -- is this why you mention Multics when talking >>>about EBCDIC? >>>Either way, I don't think that would be enough to cause people to tolerate >>>EBCDIC. >>> >>>I'm just curious how multics may have caused EBCDIC to be "tolerated"? >>> >>>>and the UCLA 360/91, >>>>half-duplex terminals were tolerated for the same reason. The nature >>>>of the protocols in the ARPANET, the Internet, and OSI had very little >>>>IBM influence. Any influence IBM might have had was more in terms of >>>>what they couldn't do, that everyone else could. >>>> >>>>Probably mostly limited to HDLC as coming from SDLC, but that work was >>>>really unrelated. >>>> >>>>IBM's primary strategy was not so much to contribute to the standards >>>>but ensure that they moved as slowly as possible. >>>> >>>>Take care, >>>>John >>>> >>>>At 7:46 PM -0500 9/4/14, Larry Sheldon wrote: >>>>>On 9/4/2014 14:41, Brian E Carpenter wrote: >>>>>>I think there is a rather philosophical history question here, >>>>>>all the same. >>>>>> >>>>>>What, in general, is the impact of historical technological >>>>>>issues on current protocols and practices? To take a completely >>>>>>different example, there was a considerable period when handling >>>>>>larger than 16 bit quantities in minicomputers was awkward and >>>>>>slow, so there was a tendency to design stuff around that constraint. >>>>>>Or consider the cost of electronics and cabling in the token ring vs >>>>>>Ethernet argument. I'm sure there are a dozen examples of tech issues >>>>>>from the 1960s and 1970s that still have significant impact today. >>>>> >>>>>I was not a part of the network-development world except as a >>>>>"consumer" of sorts. >>>>> >>>>>It appears to me, from what was a UNIVAC 1100-centric view of >>>>>the world the the emerging networks stuff--like a lot of earlier >>>>>telecommunications stuff--had a a strong IBM coloration, flavor, >>>>>and odor. >>>>> >>>>>For example, when the realization dawned that 4, 8, and 16 were >>>>>not natural limits on word size and 8 bits was the only >>>>>sub-division possible, 32 bits (and 8 bits) took over, leaving >>>>>us who lived in an 8-bit-36-bit world with some awkward >>>>>arithmetic. >>>>> >>>>> >>>>>-- >>>>>The unique Characteristics of System Administrators: >>>>> >>>>>The fact that they are infallible; and, >>>>> >>>>>The fact that they learn from their mistakes. From bernie at fantasyfarm.com Fri Sep 5 05:12:48 2014 From: bernie at fantasyfarm.com (Bernie Cosell) Date: Fri, 05 Sep 2014 08:12:48 -0400 Subject: [ih] Impact of history on today's technology [was: why did CC happen at all?] In-Reply-To: References: <5401FAF2.8070306@web.de>, , Message-ID: <5409A8C0.21342.290892D4@bernie.fantasyfarm.com> On 4 Sep 2014 at 23:23, John Day wrote: > All Multics terminals were half duplex IBM Selectrix and it was > programmed in PL/1 that used EBCDIC. But I will defer to Pogran on > this one. You're referring to the IBM 2741. I don't remember a lot but I once knew it VERY intimately because I hacked the code into the TIP to make it talk over the ARPAnet as if it were a regular full duplex ASCII terminal. It was, indeed, a half-duplex, line-at-a-time Selectric. When you typed a line of text and hit RETURN, it locked the keyboard until the other end sent something back and unlocked the keyboard. It had interesting characters like circle-C and circle-D. I think all the documentation on that stuff is long gone, alas. There was some magic sequence you could send it that could unlock the keyboard, and so the overall sequence of events was something like get line of text, translate to ASCII, send out the connection, send the unlock the kbd sequence. Something comes in from the other end: translate to EBCDIC, send the magic sequence to lock the keyboard, send the text out. I believe that the ultimate test of that software [which wasn't real easy] was when I was able to log into TENEX from a 2741..... :o) /Bernie\ -- Bernie Cosell Fantasy Farm Fibers mailto:bernie at fantasyfarm.com Pearisburg, VA --> Too many people, too few sheep <-- From craig at aland.bbn.com Fri Sep 5 05:23:57 2014 From: craig at aland.bbn.com (Craig Partridge) Date: Fri, 05 Sep 2014 08:23:57 -0400 Subject: [ih] Impact of history on today's technology [was: why did CC happen at all?] Message-ID: <20140905122357.D71F528E137@aland.bbn.com> > This might better apply to the technical implementation, I suppose. For > example, there was a lot of collaboration on drafting the technical > specification for DNS that became Paul Mockapetris' RFCs. The way the > servers work, the data structures, and the different records fall in this > category. Maybe we're talking past each other here, but that's not the part > I'm referring to. > > I would call the intellectual climate of ARPA-Internet and OSI a political > one. By that I mean politics internal to the community. > > In the archives I found meeting notes etc which indicate quite explicitly > that countries should be TLDs because the system being developed by IFIP > (which was doing pre-standards work for naming/addressing for OSI) would > have countries at the top. In fact, there was a lot of clamor for countries > at the top from people who were either affiliated with other OSI work or > working on IFIP itself. I found only a couple of cases where people argued > for a geographical structure on its own merits. > > There was an assumption by many non-Americans, and some Americans too, that > OSI would subsume whatever standards ARPA developed. This assumption is to > my mind a reflection of the internal politics I'm talking about, and it > influenced how people argued for a certain naming structure. So while it's > absolutely true that no one was looking at the relevant OSI parts > (x.400/x.500) and thinking of making domains, it is true that the existence > of these looming, assumed (by some) standards had a big influence on > domains. This account matches my recollections and what I found when writing up the email history. There was at least an official stance that OSI was the future. It also highlights why Jon Postel set up .us the way he did (to spike easy OSI transition). I am not sure I would term this aspect namespace creation "technical". We were not solving technical problems when we populated the namespace -- indeed, that's part of what made that process more painful. (Side note: the one counter argument I can think to use to say namespace creation was technical is that the decision to support country codes meant we had to have a namespace with greater than two labels. In the earliest DNS thinking, there was a notion that we'd have two level names such as VENERA.ISI -- I believe it was clear pretty fast that two levels was probably too limiting -- but once you add ccTLDs, you clearly need at least three levels and there's an rule of thumb that one counts 1, 2, many...). Craig From scott.brim at gmail.com Fri Sep 5 05:41:51 2014 From: scott.brim at gmail.com (Scott Brim) Date: Fri, 5 Sep 2014 08:41:51 -0400 Subject: [ih] Impact of history on today's technology [was: why did CC happen at all?] In-Reply-To: <5408C056.6040906@gmail.com> References: <5401FAF2.8070306@web.de> <540447C3.7060809@web.de> <5404743F.4090102@web.de> <54049AF5.2070803@web.de> <5404B67A.50709@web.de> <38E11C5C-D2B0-48B3-9E00-3D3F96E8E09F@transsys.com> <5405E611.4000604@web.de> <5405FC27.9020105@redbarn.org> <54080B1A.4070001@redbarn.org> <54089110.5060308@web.de> <20140904130503179847.1c158d15@talsever.com> <5408A594.60307@web.de> <5408C056.6040906@gmail.com> Message-ID: I believe I understand exactly what you mean. Grand vision is limited by what's possible at the time, and future grand vision is limited by what is in place. Consider MIBs (and SGMP/SNMP), and what it's been like trying to get rid of them. Scott On Sep 4, 2014 3:54 PM, "Brian E Carpenter" wrote: > I think there is a rather philosophical history question here, > all the same. > > What, in general, is the impact of historical technological > issues on current protocols and practices? To take a completely > different example, there was a considerable period when handling > larger than 16 bit quantities in minicomputers was awkward and > slow, so there was a tendency to design stuff around that constraint. > Or consider the cost of electronics and cabling in the token ring vs > Ethernet argument. I'm sure there are a dozen examples of tech issues > from the 1960s and 1970s that still have significant impact today. > > Regards > Brian Carpenter > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave.walden.family at gmail.com Fri Sep 5 05:50:40 2014 From: dave.walden.family at gmail.com (dave.walden.family at gmail.com) Date: Fri, 5 Sep 2014 08:50:40 -0400 Subject: [ih] Impact of history on today's technology [was: why did CC happen at all?] In-Reply-To: <5409A8C0.21342.290892D4@bernie.fantasyfarm.com> References: <5401FAF2.8070306@web.de> <5409A8C0.21342.290892D4@bernie.fantasyfarm.com> Message-ID: On Sep 5, 2014, at 8:12 AM, "Bernie Cosell" wrote: I think all the documentation on > that stuff is long gone, alas. There was some magic sequence you could > send it that could unlock the keyboard, and so the overall sequence of > events was something like get line of text, translate to ASCII, send out > the connection, send the unlock the kbd sequence. see section 6 at https://ia902508.us.archive.org/9/items/bitsavers_bbntipADA0eTerminalIMPAug75_2157363/ADA014398_Users_Guide_to_the_Terminal_IMP_Aug75.pdf around pdf page 38. I bet BBN has a copy of the flowchart-of-the-code docunent we did for the TIP. From jeanjour at comcast.net Fri Sep 5 05:50:07 2014 From: jeanjour at comcast.net (John Day) Date: Fri, 5 Sep 2014 08:50:07 -0400 Subject: [ih] Impact of history on today's technology [was: why did CC happen at all?] In-Reply-To: <5409A8C0.21342.290892D4@bernie.fantasyfarm.com> References: <5401FAF2.8070306@web.de>, , <5409A8C0.21342.290892D4@bernie.fantasyfarm.com> Message-ID: O my !! THAT was a good test! ;-) At 8:12 AM -0400 9/5/14, Bernie Cosell wrote: >On 4 Sep 2014 at 23:23, John Day wrote: > >> All Multics terminals were half duplex IBM Selectrix and it was >> programmed in PL/1 that used EBCDIC. But I will defer to Pogran on >> this one. > >You're referring to the IBM 2741. I don't remember a lot but I once knew >it VERY intimately because I hacked the code into the TIP to make it talk >over the ARPAnet as if it were a regular full duplex ASCII terminal. > >It was, indeed, a half-duplex, line-at-a-time Selectric. When you typed >a line of text and hit RETURN, it locked the keyboard until the other end >sent something back and unlocked the keyboard. It had interesting >characters like circle-C and circle-D. I think all the documentation on >that stuff is long gone, alas. There was some magic sequence you could >send it that could unlock the keyboard, and so the overall sequence of >events was something like get line of text, translate to ASCII, send out >the connection, send the unlock the kbd sequence. Something comes in >from the other end: translate to EBCDIC, send the magic sequence to lock >the keyboard, send the text out. > >I believe that the ultimate test of that software [which wasn't real >easy] was when I was able to log into TENEX from a 2741..... :o) > > /Bernie\ > >-- >Bernie Cosell Fantasy Farm Fibers >mailto:bernie at fantasyfarm.com Pearisburg, VA > --> Too many people, too few sheep <-- From dhc2 at dcrocker.net Fri Sep 5 06:48:28 2014 From: dhc2 at dcrocker.net (Dave Crocker) Date: Fri, 05 Sep 2014 06:48:28 -0700 Subject: [ih] Impact of history on today's technology [was: why did CC happen at all?] In-Reply-To: References: <5401FAF2.8070306@web.de> <540447C3.7060809@web.de> <5404743F.4090102@web.de> <54049AF5.2070803@web.de> <5404B67A.50709@web.de> <38E11C5C-D2B0-48B3-9E00-3D3F96E8E09F@transsys.com> <5405E611.4000604@web.de> <5405FC27.9020105@redbarn.org> <54080B1A.4070001@redbarn.org> <54089110.5060308@web.de> <20140904130503179847.1c158d15@talsever.com> <5408A594.60307@web.de> <5408C056.6040906@gmail.com> Message-ID: <5409BF2C.1060804@dcrocker.net> On 9/5/2014 5:41 AM, Scott Brim wrote: > I believe I understand exactly what you mean. Grand vision is limited by > what's possible at the time, and future grand vision is limited by what > is in place. Consider MIBs (and SGMP/SNMP), and what it's been like > trying to get rid of them. I remember hearing Kleinrock once comment on the cycle of relative costs, between memory (and maybe cpu) vs. communications. Expensive comms lines bias design one way. Expensive computering bias in another. Having both be expensive at the same time probably has yet another effect. We've similarly had cycles for centralized vs. widely distributed (computing arrangements. PCs made distribution feasible at scale. Beyond the technical point of rapidly-varying scale that the term 'cloud computing' originally meant, it's come to be nothing more than classic remote computing. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From brian.e.carpenter at gmail.com Fri Sep 5 12:55:46 2014 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Sat, 06 Sep 2014 07:55:46 +1200 Subject: [ih] Impact of history on today's technology [was: why did CC happen at all?] In-Reply-To: References: <5401FAF2.8070306@web.de> <540447C3.7060809@web.de> <5404743F.4090102@web.de> <54049AF5.2070803@web.de> <5404B67A.50709@web.de> <38E11C5C-D2B0-48B3-9E00-3D3F96E8E09F@transsys.com> <5405E611.4000604@web.de> <5405FC27.9020105@redbarn.org> <54080B1A.4070001@redbarn.org> <54089110.5060308@web.de> <20140904130503179847.1c158d15@talsever.com> <5408A594.60307@web.de> <5408C056.6040906@gmail.com> <5408EC60.1010500@dcrocker.net> <5408FB6B.4030202@dcrocker.net> Message-ID: <540A1542.6000302@gmail.com> On 05/09/2014 16:31, Eric Gade wrote: ... > I believe it's in one of those papers that Postel says, "Naming is a > uniquely political act." Which reminds me that at some very early stage, we at CERN were somewhat concerned not to locate CERN in any one country in cyberspace, so we asked Jon to let us have "cern" as a TLD ("int" did not exist then). He kindly explained why that wasn't going to happen, and in the end we registered cern.ch since CERN's legal "seat" is in Switzerland. But I also insisted that we registered cern.fr, because we didn't want to encourage the idea that the Swiss Telecom monopoly applied to us, and the computer centre including the mail servers was on French soil anyway. Definitely a political act at that time (~1986). We never used cern.fr and it seems to be cybersquatted these days. Brian From brian.e.carpenter at gmail.com Fri Sep 5 13:20:58 2014 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Sat, 06 Sep 2014 08:20:58 +1200 Subject: [ih] Impact of history on today's technology [was: why did CC happen at all?] In-Reply-To: <5409BF2C.1060804@dcrocker.net> References: <5401FAF2.8070306@web.de> <540447C3.7060809@web.de> <5404743F.4090102@web.de> <54049AF5.2070803@web.de> <5404B67A.50709@web.de> <38E11C5C-D2B0-48B3-9E00-3D3F96E8E09F@transsys.com> <5405E611.4000604@web.de> <5405FC27.9020105@redbarn.org> <54080B1A.4070001@redbarn.org> <54089110.5060308@web.de> <20140904130503179847.1c158d15@talsever.com> <5408A594.60307@web.de> <5408C056.6040906@gmail.com> <5409BF2C.1060804@dcrocker.net> Message-ID: <540A1B2A.4090409@gmail.com> On 06/09/2014 01:48, Dave Crocker wrote: > On 9/5/2014 5:41 AM, Scott Brim wrote: >> I believe I understand exactly what you mean. Grand vision is limited by >> what's possible at the time, and future grand vision is limited by what >> is in place. Consider MIBs (and SGMP/SNMP), and what it's been like >> trying to get rid of them. > > > I remember hearing Kleinrock once comment on the cycle of relative > costs, between memory (and maybe cpu) vs. communications. Expensive > comms lines bias design one way. Expensive computering bias in another. > Having both be expensive at the same time probably has yet another effect. > > We've similarly had cycles for centralized vs. widely distributed > (computing arrangements. PCs made distribution feasible at scale. > Beyond the technical point of rapidly-varying scale that the term 'cloud > computing' originally meant, it's come to be nothing more than classic > remote computing. Getting back to Dave's question yesterday: > Perhaps you have in mind something like the technological issue of > typewriter keys getting stuck against each other if the typist went to > fast, thereby motivating the qwerty layout? It could be almost anything that has enduring effects. Another one is that whatever design compromise led to 1500 bytes for Ethernet in 1983 affects every discussion today about IPv6 PMTUD and fragmentation. However much the technical constraint is obsolete, we can't get rid of it. Brian From leo at vegoda.org Fri Sep 5 13:25:06 2014 From: leo at vegoda.org (Leo Vegoda) Date: Fri, 5 Sep 2014 21:25:06 +0100 Subject: [ih] Impact of history on today's technology [was: why did CC happen at all?] In-Reply-To: <20140905122357.D71F528E137@aland.bbn.com> References: <20140905122357.D71F528E137@aland.bbn.com> Message-ID: <20140905202506.GD11418@vegoda.org> On Fri, Sep 05, 2014 at 08:23:57AM -0400, Craig Partridge wrote: [...] > (Side note: the one counter argument I can think to use to say namespace > creation was technical is that the decision to support country codes meant > we had to have a namespace with greater than two labels. In the earliest > DNS thinking, there was a notion that we'd have two level names such > as VENERA.ISI -- I believe it was clear pretty fast that two levels > was probably too limiting -- but once you add ccTLDs, you clearly need > at least three levels and there's an rule of thumb that one > counts 1, 2, many...). Can you please expand on this? Are you referring to system name labels or including usernames as well? How is a ccTLD different from a non-ccTLD in this respect? If I might be user at example.com, I could presumably be user at example.cctld if the ccTLD allows registration in the second level, rather than creating additional structure. Some ccTLDs did create extra structure, such as uk, jp, and nz. Others, like cn, de, nl allowed registration at the second level. Thanks, Leo From touch at isi.edu Fri Sep 5 13:32:02 2014 From: touch at isi.edu (Joe Touch) Date: Fri, 05 Sep 2014 13:32:02 -0700 Subject: [ih] archives updated In-Reply-To: <5408DF9F.4000802@isi.edu> References: <5401FAF2.8070306@web.de> <540447C3.7060809@web.de> <5404743F.4090102@web.de> <54049AF5.2070803@web.de> <5404B67A.50709@web.de> <38E11C5C-D2B0-48B3-9E00-3D3F96E8E09F@transsys.com> <5405E611.4000604@web.de> <5405FC27.9020105@redbarn.org> <54080B1A.4070001@redbarn.org> <54089110.5060308@web.de> <20140904130503179847.1c158d15@talsever.com> <5408DF9F.4000802@isi.edu> Message-ID: <540A1DC2.3010904@isi.edu> Hi, all, The archives have been updated. The posts have not changed except to remove the offending URL. List members are reminded that the contents of their posts are archived, and that the archive will not be modified except in compliance with applicable laws. Joe IH list admin On 9/4/2014 2:54 PM, Joe Touch wrote: > Hi, all, > > In the interest of protecting the list archive, I am removing the > following post from the archive, as well as any post that quotes the URL > it includes. This may require a few days to take effect. > > (I have not mentioned it, but I will indicate any such modifications of > the archive in the future as well) > > Joe > IH list admin > > On 9/4/2014 10:38 AM, Dr Eberhard W Lisse wrote: >> He has his own FAQ >> > [URL REMOVED] >> >> unfortunately in German, but Google translate makes a reasonable job >> of it :-)-O >> >> Maybe non-response to off-topic posts is best. >> >> Greetings, el >> >> Sent from Dr Lisse's iPad mini >> >> On Sep 4, 2014, at 18:05, Amelia A Lewis > > wrote: >> >>> If it's necessary to post publicly, then I'll do so. >>> >>> I'd like to second Paul Vixie's call for moderation. Herr Bosau, if >>> your concerns have nothing to do with internet history, beyond >>> asserting that you know more than the folks who were involved in >>> designing internet protocols, and demanding that they admit that they >>> were wrong, then you should take your insults and your attempts to >>> derail the internet-history discussion list *somewhere else*. >>> >>> Also, you owe Paul Vixie an apology, and more apologies to the others >>> on this list who have shown, in my opinion, remarkable tolerance of >>> your anger, insults, and distractions from the topics of the mailing >>> list. It is possible that, if (as it seems) english is your second >>> language, you're not aware of the hostile and vicious tone that has >>> suffused your posts from about the dozenth in this outrageously long >>> series. >>> >>> The folks involved in discussions of congestion control at various >>> periods in the development of the internet have graciously discussed >>> this history here. That's all that ever belonged here. >>> >>> Stop. >>> >>> Amy! >>> On Thu, 04 Sep 2014 18:19:28 +0200, Detlef Bosau wrote: >>>> Am 04.09.2014 um 08:47 schrieb Paul Vixie: >>>>> mr. bosau, i consider your answer completely non-responsive. to reduce >>>>> stress, i'm going to add you to my mail filter now. for your possible >>>>> self-reference, i received several "thank you paul for saying what you >>>>> said" notes from our colleagues here. >>>> >>>> First: Feel free to add me to your filter. >>>> >>>> Second: Stop telling lies. >>>> >>>> When persons want to criticize me, they are free to tell this to me - >>>> and not to you. Boasting with actions done by others is an absolute No >>>> Go in any academic context. And a reliable means to break any contact >>>> with me. So when people have a problem with me, these people either >>>> have >>>> a name and can speak for themselves, or they have problems, most likely >>>> not only with me. >>>> >>>> >>>> And please don't call me a troll. The only person who behaves like a >>>> troll, and as a very childish one, are you in this context. >>>> I never got in touch with you. I have no idea who you are, we don't >>>> know >>>> each other. And you come here without any reason, offend me, blame me, >>>> without any rationale reason. This is simply bad behaviour. >>>> >>>> Who are you to do that? >>>> >>>> God? The President of the United States? >>>> >>>> And what should my response have been? >>>> >>>> Think about that for yourself. >>>> >>>> (And when statements of me are wrong, give rationale to prove them >>>> wrong. "I received mails..." or "I received phone calls..." are >>>> certainly no rationales.) >>>> >>>> However, I think we should close this dispute here. I don't think that >>>> the other readers are interested in that childish arguments. >>>> >>>> Detlef >>>> >>>> From craig at aland.bbn.com Fri Sep 5 13:37:11 2014 From: craig at aland.bbn.com (Craig Partridge) Date: Fri, 05 Sep 2014 16:37:11 -0400 Subject: [ih] Impact of history on today's technology [was: why did CC happen at all?] Message-ID: <20140905203711.F320C28E137@aland.bbn.com> > On Fri, Sep 05, 2014 at 08:23:57AM -0400, Craig Partridge wrote: > > [...] > > > (Side note: the one counter argument I can think to use to say namespace > > creation was technical is that the decision to support country codes meant > > we had to have a namespace with greater than two labels. In the earliest > > DNS thinking, there was a notion that we'd have two level names such > > as VENERA.ISI -- I believe it was clear pretty fast that two levels > > was probably too limiting -- but once you add ccTLDs, you clearly need > > at least three levels and there's an rule of thumb that one > > counts 1, 2, many...). > > Can you please expand on this? Are you referring to system name > labels or including usernames as well? How is a ccTLD different from > a non-ccTLD in this respect? If I might be user at example.com, I could > presumably be user at example.cctld if the ccTLD allows registration > in the second level, rather than creating additional structure. Some > ccTLDs did create extra structure, such as uk, jp, and nz. Others, > like cn, de, nl allowed registration at the second level. Sure. I'm not talking about usernames but simply domain names. At the time, we generally had to name each host (MX records came to the party late). So, if you were an organization, you needed to have your organization name and a host name -- such as VENERA.ISI. But if we had ccTLDs, folks in the ccTLD needed at least three levels -- so VENERA.ISI.US. And once you did that, it was clear that four levels probably needed to be supported (esp. since the UK was clear from early on that it would divide up .UK into CO.UK and AC.UK, which meant that CSL.CAM.AC.UK was clearly desirable). And at that point, you might as well have no (few) limits. Thanks! Craig From paul at redbarn.org Fri Sep 5 13:56:31 2014 From: paul at redbarn.org (Paul Vixie) Date: Fri, 05 Sep 2014 13:56:31 -0700 Subject: [ih] Impact of history on today's technology [was: why did CC happen at all?] In-Reply-To: <540A1B2A.4090409@gmail.com> References: <5401FAF2.8070306@web.de> <540447C3.7060809@web.de> <5404743F.4090102@web.de> <54049AF5.2070803@web.de> <5404B67A.50709@web.de> <38E11C5C-D2B0-48B3-9E00-3D3F96E8E09F@transsys.com> <5405E611.4000604@web.de> <5405FC27.9020105@redbarn.org> <54080B1A.4070001@redbarn.org> <54089110.5060308@web.de> <20140904130503179847.1c158d15@talsever.com> <5408A594.60307@web.de> <5408C056.6040906@gmail.com> <5409BF2C.1060804@dcrocker.net> <540A1B2A.4090409@gmail.com> Message-ID: <540A237F.1030901@redbarn.org> On 9/5/2014 1:20 PM, Brian E Carpenter wrote: > On 06/09/2014 01:48, Dave Crocker wrote: > >> Perhaps you have in mind something like the technological issue of >> typewriter keys getting stuck against each other if the typist went to >> fast, thereby motivating the qwerty layout? > It could be almost anything that has enduring effects. Another one is that > whatever design compromise led to 1500 bytes for Ethernet in 1983 affects > every discussion today about IPv6 PMTUD and fragmentation. the way david boggs explained "1500" to me, it sounded like a design balancer moreso than a compromise. > However much the technical constraint is obsolete, we can't get rid of it. the "1500" problem is still with us because each new generation of ethernet begins by being bridged or repeated from the prior generation of ethernet. i remember once having the idea in mind that we'd use 1500 for our Fast-E (100MBit) networks until the last 10MBit device was upgraded. sadly, that was easier to imagine than to plan for. the same thing happened with "512" as a DNS payload maximum when carried in UDP. the original idea was that the smallest reassembly buffer that an IP4 receiver was allowed to have and still interoperate was 568 octets, which with IP and UDP headers and extensions, left 512 octets. so when we moved from IP4 to IP6 and got a new and higher guaranteed minimum maximum of 1280, we should ideally have been able to relax that constraint. however, a lot of IP4->IP6 and IP6->IP4 transition technologies came about, including ALG (UDP proxies), and so we had to send no more than 512 octets of DNS payload even when speaking to what we thought was an IP6 destination. and let me assure everybody, EDNS (RFC 2671) as a signalling method to increase this, has taken 15 years to reach less than 50% of the installed base. so, what's a protocol designer to do? granted most new protocols are carried on TCP/80 and there's rarely a length constraint, the question remains: how to future-proof a protocol without excessively burdening the early adopters? (DNS could not have taken off had it been a TCP-only protocol, for example.) vixie From dhc2 at dcrocker.net Fri Sep 5 13:59:22 2014 From: dhc2 at dcrocker.net (Dave Crocker) Date: Fri, 05 Sep 2014 13:59:22 -0700 Subject: [ih] Impact of history on today's technology [was: why did CC happen at all?] In-Reply-To: <540A237F.1030901@redbarn.org> References: <5401FAF2.8070306@web.de> <540447C3.7060809@web.de> <5404743F.4090102@web.de> <54049AF5.2070803@web.de> <5404B67A.50709@web.de> <38E11C5C-D2B0-48B3-9E00-3D3F96E8E09F@transsys.com> <5405E611.4000604@web.de> <5405FC27.9020105@redbarn.org> <54080B1A.4070001@redbarn.org> <54089110.5060308@web.de> <20140904130503179847.1c158d15@talsever.com> <5408A594.60307@web.de> <5408C056.6040906@gmail.com> <5409BF2C.1060804@dcrocker.net> <540A1B2A.4090409@gmail.com> <540A237F.1030901@redbarn.org> Message-ID: <540A242A.8090404@dcrocker.net> On 9/5/2014 1:56 PM, Paul Vixie wrote: > the way david boggs explained "1500" to me, it sounded like a design > balancer moreso than a compromise. A choices get made either from some basic technical limitation or from some balancing act. The difference is important, but which ever drove the choice, that choice becomes entrenched. So I see the exercise Brian is requesting as being one of identifying choices that were made that probably would not be the choice made today, but which has too much history/momentum to change easily. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From touch at isi.edu Mon Sep 8 11:49:42 2014 From: touch at isi.edu (Joe Touch) Date: Mon, 08 Sep 2014 11:49:42 -0700 Subject: [ih] testing - please ignore Message-ID: <540DFA46.5000303@isi.edu> Please ignore this message. Joe IH list admin From jklensin at gmail.com Wed Sep 10 09:12:11 2014 From: jklensin at gmail.com (John Klensin) Date: Wed, 10 Sep 2014 12:12:11 -0400 Subject: [ih] Impact of history on today's technology [was: why did CC happen at all?] In-Reply-To: References: <5401FAF2.8070306@web.de> <540447C3.7060809@web.de> <5404743F.4090102@web.de> <54049AF5.2070803@web.de> <5404B67A.50709@web.de> <38E11C5C-D2B0-48B3-9E00-3D3F96E8E09F@transsys.com> <5405E611.4000604@web.de> <5405FC27.9020105@redbarn.org> <54080B1A.4070001@redbarn.org> <54089110.5060308@web.de> <20140904130503179847.1c158d15@talsever.com> <5408A594.60307@web.de> <540907DF.6030508@cox.net> Message-ID: Wow. Time to adjust a few small misconceptions since subsequent postings seem to have not caught them... On Thu, Sep 4, 2014 at 11:23 PM, John Day wrote: > All Multics terminals were half duplex IBM Selectrix As others have noted, you are probably referring to the IBM 2741 and maybe the earlier 1050, which I think we also used on Multics. But "all Multics terminals" is a bit of a stretch: In my shop alone, we had, over time, an assortment of TTY 37s, VT100s and their descendants, assorted "glass TTYs", some Imlac PDS-1Ds (primarily programmed to imitate an ARDS but sometimes other things), a DEC GT40, some TI "Silent 700s", some sort of Xerox device with a daisywheel , and probably some others that I've forgotten. IIR, all of those were ASCII devices, many of them conforming to the post-VT100 ANSI control sequence standard. Some of those devices were "full duplex", some "half" and line at a time, some half but still character at a time. IIR, someone even had IBM TN5250-class devices hooks up to it. The 2741 natively took input in shift and rotate codes (for the typeball). I don't recall it knowing anything about EBCDIC internally but may not have known or have forgotten. Incidentally, coming back to lessons from history, the 2741 had no way to know which typeball was installed, much less how to tell a remote print driver about it, and, since some of them had character repertoires that were very different from undecorated Latin characters (think APL and national language forms among many others), a lot of us got our first significant lessons in the importance of labeling character codings, lessons that are still being discussed today (in spite of Unicode). > and it was programmed in PL/1 that used EBCDIC. First, since I'm a little sensitive on the subject, while the Multics command that invoked the compiler was "pl1" (note case-sensitivity, another important historical issue), the name of that programming language was PL/I (capital P, capital L, slash, Roman numeral (capital) one), not pl/i, pli, pl/1, or anything else. Second and more important to this discussion, the Multics PL/I compiler never "used EBCDIC" nor did the ANSI and ISO standards for PL/I that were influenced by it and to which the later generations of that compiler confirmed. The basic language character set specified in the standards is ASCII compatible but the standards go to some length to stress that the character set used in the standards are an abstraction and that no mapping to specific graphics or coding is specified (see, e.g., ISO/IEC 6522:1992 Sections 1.5.1.5 and 2.6 for details). One of Multics's very important features in this area --one of many we seem to have forgotten as we make "progress"-- was the use of a single canonical form internally coupled with very powerful and selective device drivers adapted to particular i/o devices and their idiosyncrasies, rather than an implicit assumption that all terminal devices were basically the same modulo what could be specified in a table with lots of options. That canonical form was enforced (or converted to) almost everywhere and included canonical string ordering and ways to handle overlaid characters and strings. > But I will defer to Pogran on this one. He will certainly know more about the terminal device drivers than I do. > ASCII was 7- bits. In fact, there was a "crisis" one morning when BBN > deployed new ASCII/EBCDIC tables in the TIPs and the guys logging into > Multics from a TIP couldn't generate the line delete or character delete > characters. I vaguely remember that, but the problem wasn't that Multics was using EBCDIC because it wasn't. In any event, the "normal" Multics character and line delete characters were, respectively, "#" and "@". They caused other problems, but, fwiw, both are in the EBCIDIC repertoire. I remember three other issues that I believe were more significant: -- When TENEX (and several other systems) represented ASCII on 36-bit word hardware, they did so with five 7bit characters per word (and one bit left over). Multics used four ASCII characters in a 36 bit word, with each one occupying 9 bits with the leading two set to zero. If one did a binary transfer (e.g., with FTP) of a file containing ASCII strings, one could get fully as much of a problem as with binary transfer of EBCDIC. It was not an accident that FTP ended up with a "TYPE" command that could differentiate between network-standard ("NVT") ASCII, EBCDIC, and image (binary) forms for transfer with the sending system responsible for getting things into the right form. -- The "new line" problem that continues to plague us had it origins at that time with Multics (conforming to the original version of ASCII, btw) using LF only internally, a number of DEC systems using CR only, and so on. -- IBM's original System/360 spec specified ASCII as an alternative to EBCDIC, but their coding of ASCII put the seven bit code into an eight bit byte, not with a leading zero but with a parity bit in the middle. I don't have firsthand experience with an installation that turned that coding on, but imagine it would have made other things worse. > > At 11:16 PM -0400 9/4/14, Michael Greenwald wrote: >> >> On 2014-09-04 22:31, John Day wrote: >>> >>> In all areas, the IBM influence was minimal if any. In the ARPANET, >>> EBCDIC was tolerated because of Multics EBCDIC "was tolerated" because there were a number of important IBM mainframes that used it, IIR UCLA included. As discussed in more detail above, it had nothing to do with Multics. >... >> Multics had (library?) routines to write and >> read EBCDIC if needed Fancy device drivers. One certainly could have figured out how to process and use EBCDIC internally on Multics if necessary but, in general, the character codings used by external devices were invisible to a Multics applicaiton. >>> IBM's primary strategy was not so much to contribute to the standards >>> but ensure that they moved as slowly as possible. Probably not good as a blanket statement either. With PL/I, IBM's representatives actually came to the standards committees and said things equivalent to "our language design got the following features wrong, please fix". best, john From dot at dotat.at Thu Sep 11 02:52:32 2014 From: dot at dotat.at (Tony Finch) Date: Thu, 11 Sep 2014 10:52:32 +0100 Subject: [ih] IBM ASCII, was Re: Impact of history on today's technology [was: why did CC happen at all?] In-Reply-To: References: <5401FAF2.8070306@web.de> <540447C3.7060809@web.de> <5404743F.4090102@web.de> <54049AF5.2070803@web.de> <5404B67A.50709@web.de> <38E11C5C-D2B0-48B3-9E00-3D3F96E8E09F@transsys.com> <5405E611.4000604@web.de> <5405FC27.9020105@redbarn.org> <54080B1A.4070001@redbarn.org> <54089110.5060308@web.de> <20140904130503179847.1c158d15@talsever.com> <5408A594.60307@web.de> <540907DF.6030508@cox.net> Message-ID: John Klensin wrote: > > -- IBM's original System/360 spec specified ASCII as an alternative to > EBCDIC, but their coding of ASCII put the seven bit code into an eight > bit byte, not with a leading zero but with a parity bit in the middle. That's loony, but reality seems to be even weirder! From the article below it looks like they shifted the top two bits up one and put a copy of the top bit in the gap. http://www6.in.tum.de/pub/Main/TeachingWs2010Echtzeitsysteme/IBM360-Amdahl_april64.pdf > I don't have firsthand experience with an installation that turned > that coding on, but imagine it would have made other things worse. I get the impression from http://www.bobbemer.com/P-BIT.HTM that it mostly would not have worked. Tony. -- f.anthony.n.finch http://dotat.at/ Trafalgar: Cyclonic in northwest, otherwise mainly northerly or northwesterly 5 or 6. Slight or moderate. Showers in northwest. Good. From randy at psg.com Thu Sep 11 03:50:32 2014 From: randy at psg.com (Randy Bush) Date: Thu, 11 Sep 2014 19:50:32 +0900 Subject: [ih] IBM ASCII, was Re: Impact of history on today's technology [was: why did CC happen at all?] In-Reply-To: References: <5401FAF2.8070306@web.de> <540447C3.7060809@web.de> <5404743F.4090102@web.de> <54049AF5.2070803@web.de> <5404B67A.50709@web.de> <38E11C5C-D2B0-48B3-9E00-3D3F96E8E09F@transsys.com> <5405E611.4000604@web.de> <5405FC27.9020105@redbarn.org> <54080B1A.4070001@redbarn.org> <54089110.5060308@web.de> <20140904130503179847.1c158d15@talsever.com> <5408A594.60307@web.de> <540907DF.6030508@cox.net> Message-ID: [ tales from a memory with no ecc or parity ] in about '66, i had to get (medical monitoring) data from a pdp/8 over in the hospitals to the 360/40 at the comp center. the ibm 2701 serial controller reversed the bits in each byte of the ascii to/from the pdp. luckily, the 360 had a cute translate instruction. randy From johnl at iecc.com Thu Sep 11 08:16:38 2014 From: johnl at iecc.com (John Levine) Date: 11 Sep 2014 15:16:38 -0000 Subject: [ih] IBM ASCII, was Re: Impact of history on today's technology [was: why did CC happen at all?] In-Reply-To: Message-ID: <20140911151638.2014.qmail@joyce.lan> >That's loony, but reality seems to be even weirder! From the article below >it looks like they shifted the top two bits up one and put a copy of the >top bit in the gap. It's all documented in the IBM 360 Principles of Operation. And yes, it's loony. >I get the impression from http://www.bobbemer.com/P-BIT.HTM that it mostly >would not have worked. I'm not aware of any software, ever, that used the 360's ASCII mode bit other than diagnostics. The 370 reused the bit to turn on virtual memory, which in view of how carefully they preserved upward compatibility everywhere else, strongly suggests that literally nobody used it. In the late 1960s when IBM supported ASCII labeled mag tapes (ANSI X3.27) they were normal 7 bit ASCII and the system translated as necessary to and from EBCDIC. R's, John From touch at isi.edu Thu Sep 25 11:46:40 2014 From: touch at isi.edu (Joe Touch) Date: Thu, 25 Sep 2014 11:46:40 -0700 Subject: [ih] Updated list posting policies Message-ID: <54246310.2090300@isi.edu> Hi, all, The posting policies for this and all lists hosted at postel.org have been updated. They now include the basic policies of the end2end-interest list, which have been copied here: http://www.postel.org/mail-faq.html That info describes: - appropriate list use - possible ways posts may be held or discarded - limits to posting job and meeting announcements This link is now included on the info page for this list at postel.org. Please review the policies and let me know if you have any questions. Joe Touch (list admin)