From braden at ISI.EDU Thu Oct 15 13:05:04 2009 From: braden at ISI.EDU (Bob Braden) Date: Thu, 15 Oct 2009 13:05:04 -0700 Subject: [e2e] draft-d-sec-udt-00.txt Message-ID: <4AD78070.3080509@isi.edu> I am writing this with my Independent Stream Editor hat on. The draft "Security Requirements for UDT" has been submitted. It is deeply confused as a document, but it is building on apparently legitimate (if not necessary worthy) academic publications on a reliable transport protocol to run over UDP, called UDT. UDT seems to have its own congestion control algorithm. If there is someone on this list who is feeling particularly jagged today and would like to write a short review of this document, it would be a help. I am always nagged by the fear that there is really something hidden beneath the confusion that deserves to be teased out, and in any case authors deserve good reasons for rejecting their work. Any takers? BTW, the document is ~ 6 pages. Bob Braden From mateosj at tcd.ie Fri Oct 23 03:26:54 2009 From: mateosj at tcd.ie (Jaime Mateos) Date: Fri, 23 Oct 2009 11:26:54 +0100 Subject: [e2e] Protocols breaking the end-to-end argument Message-ID: <4AE184EE.5040800@tcd.ie> Hi, I'm working on a project about the current challenges the Internet is presenting to the end-to-end argument. I'd be interested to know about any protocols, currently in use, that break the end-to-end principle and the context where they are used. So far the only one I've found is TCP PEP that seems to be in use in satellite networks (Internetworking and computing over satellite networks, Yongguang Zhang - http://books.google.ie/books?id=3pkI6OWUsRAC&pg=PA170&lpg=PA170&dq=criticisms+of+end+to+end+principle&source=bl&ots=OVbMYc5Iso&sig=Tir1Xi4vxRG5HG2ieGCgl2STWcA&hl=en&ei=vL7TSor9Bs2z4QbW8_H_Ag&sa=X&oi=book_result&ct=result&resnum=5&ved=0CBQQ6AEwBA#v=onepage&q=criticisms%20of%20end%20to%20end%20principle&f=false) There also seems to be a number of research projects such as Split TCP and LTP-T that I've come across. I'm also interested in these but not to the same degree as in protocols that are currently in use today. Thanks, Jaime Mateos From jeroen at unfix.org Fri Oct 23 03:58:59 2009 From: jeroen at unfix.org (Jeroen Massar) Date: Fri, 23 Oct 2009 12:58:59 +0200 Subject: [e2e] Protocols breaking the end-to-end argument In-Reply-To: <4AE184EE.5040800@tcd.ie> References: <4AE184EE.5040800@tcd.ie> Message-ID: <4AE18C73.7000208@spaghetti.zurich.ibm.com> Jaime Mateos wrote: > Hi, > I'm working on a project about the current challenges the Internet is > presenting to the end-to-end argument. I'd be interested to know about > any protocols, currently in use, that break the end-to-end principle and > the context where they are used. Everything that needs an NAT helper, thus any protocol that embeds addresses or ports, thus most games, everything that has a listening port where the listening port is not on a public IP or firewalled away. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 196 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20091023/514f1076/signature.bin From L.Wood at surrey.ac.uk Fri Oct 23 04:47:00 2009 From: L.Wood at surrey.ac.uk (L.Wood@surrey.ac.uk) Date: Fri, 23 Oct 2009 12:47:00 +0100 Subject: [e2e] Protocols breaking the end-to-end argument References: <4AE184EE.5040800@tcd.ie> Message-ID: <4835AFD53A246A40A3B8DA85D658C4BE01368B07@EVS-EC1-NODE4.surrey.ac.uk> Hey, I wrote a chapter of that book... Do look into the Bundle Protocol, which ignore the end-to-end principle and control loops in its design. See our 'Bundle of Problems' paper for more on this: http://www.ee.surrey.ac.uk/Personal/L.Wood/publications/ The Bundle Protocol has similar problems/oversights as LTP-T. Carlo Caini's group has drawn parallels between DTN work and TCP PEPs, pointing out that what TCP PEPs do on the quiet (break the end-to-end control loop into separate loops) is what things like bundle hops + convergence layers or http proxy caches do more explicitly and visibly. See e.g. his IWSSC'09 paper: "TCP, PEP and DTN Performance on Disruptive Satellite Channels." L. -----Original Message----- From: end2end-interest-bounces at postel.org on behalf of Jaime Mateos Sent: Fri 2009-10-23 11:26 To: end2end-interest at postel.org Subject: [e2e] Protocols breaking the end-to-end argument Hi, I'm working on a project about the current challenges the Internet is presenting to the end-to-end argument. I'd be interested to know about any protocols, currently in use, that break the end-to-end principle and the context where they are used. So far the only one I've found is TCP PEP that seems to be in use in satellite networks (Internetworking and computing over satellite networks, Yongguang Zhang - http://books.google.ie/books?id=3pkI6OWUsRAC&pg=PA170&lpg=PA170&dq=criticisms+of+end+to+end+principle&source=bl&ots=OVbMYc5Iso&sig=Tir1Xi4vxRG5HG2ieGCgl2STWcA&hl=en&ei=vL7TSor9Bs2z4QbW8_H_Ag&sa=X&oi=book_result&ct=result&resnum=5&ved=0CBQQ6AEwBA#v=onepage&q=criticisms%20of%20end%20to%20end%20principle&f=false) There also seems to be a number of research projects such as Split TCP and LTP-T that I've come across. I'm also interested in these but not to the same degree as in protocols that are currently in use today. Thanks, Jaime Mateos -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20091023/13283de1/attachment.html From william.allen.simpson at gmail.com Fri Oct 23 05:39:48 2009 From: william.allen.simpson at gmail.com (William Allen Simpson) Date: Fri, 23 Oct 2009 08:39:48 -0400 Subject: [e2e] Protocols breaking the end-to-end argument In-Reply-To: <4AE184EE.5040800@tcd.ie> References: <4AE184EE.5040800@tcd.ie> Message-ID: <4AE1A414.4090302@gmail.com> Jaime Mateos wrote: > I'm working on a project about the current challenges the Internet is > presenting to the end-to-end argument. I'd be interested to know about > any protocols, currently in use, that break the end-to-end principle and > the context where they are used. You could add the Broadcom chip sets to your list. Not a protocol per se, but they inexplicably "handle" TCP segmentation. Usually used in a host (bad enough in my opinion), but could create utter havoc in a router. So far, I've noticed: NetXtreme II 1 Gigabit Tigon 3 When I recently proposed actually checking for correct TCP option sizes, the Linux driver's author says: You're being way too anal here, and adding these checks to drivers would be just a lot of rediculious bloat. [sic] From dpreed at reed.com Fri Oct 23 07:20:47 2009 From: dpreed at reed.com (David P. Reed) Date: Fri, 23 Oct 2009 10:20:47 -0400 Subject: [e2e] Protocols breaking the end-to-end argument In-Reply-To: <4835AFD53A246A40A3B8DA85D658C4BE01368B07@EVS-EC1-NODE4.surrey.ac.uk> References: <4AE184EE.5040800@tcd.ie> <4835AFD53A246A40A3B8DA85D658C4BE01368B07@EVS-EC1-NODE4.surrey.ac.uk> Message-ID: <4AE1BBBF.2090109@reed.com> I'd reframe the statement, just because I would actually like the term "end-to-end argument" to continue to mean what we defined it to mean, rather than what some people have extended it to mean. So I think what you are looking for is a set of examples that demonstrate functions that are "best done inside the network". If you read the original paper, there is no claim whatever that says either: 1) that all functions should be done at the edges. (this radical proposition, however, is one that guides some of my personal interests in researching how far one can go. But that's a "Reed research guideline" not an architecture argument.) 2) that one should never include optimizations of functions that must (to be correct) be done at the edges, in the network. Yet each interpretation above (and some others) are used occasionally. Here's an example that challenges 2) and 1) but not the original argument: where should congestion measurement be done, in order to support congestion control? Congestion *exists* only inside the network, by definition. So it must be measured in the network. However, where should *control* of congestion happen? That's a very different story. It can't happen at the places where it is measured... because congestion is an emergent phenomenon that depends on details at the edges, AND on routing decisions (and traffic engineering and investment decisions, as well, at slower rates of change). The answer would be easy if there were one perfect place to do it. Of course, the network itself makes that hard. Today's Internet offers a variety of measures of congestion: measured changes of RTT end-to-end at each of the hosts that share a bottleneck subpath for active traffic, packet drops, packet-pair tests, marks such as ECN, SNMP-if-it-had-a-MIB, ... It also offers a variety of ways to mitigate congestion: get one or more senders to slow down, get the sender to recode using more compression, force some of the traffic to an alternate path, etc. Choices of how to implement the congestion management function (which includes traffic engineering as a subroutine) can be informed by the "end-to-end argument" if you break the function down into subfunctions. But this is not a problem with the "end-to-end argument". It is a problem with TCP RTP and other protocols over IP, and routers that we have today. We have, for example, ECN as a tool implemented by routers. Turning it on probably would help a reasonable amount. ECN itself is a solution to congestion *measurement*, not mitigation. Measurement in the router, communicated by ECN to all who share the bottleneck path, is clearly a function "in the network". And yet it satisfies the end-to-end argument! Lest we think that congestion control is the only area where *careful thinking* is informed by end-to-end arguments about function placement, there are many that fit the original argument. Blocking hostile DDOS attacks is another. It's hard to imagine that anyone could argue that DDOS against a target could be prevented solely outside the network. However, *prosecution* of the offenders is clearly not a function that can be done inside the network. Similarly, it would be silly to burden a router with the job of collecting evidence for the prosecutor. There are actually two kinds of DDOS attacks: 1) against the network itself, 2) against a particular end host (or hosts). The former can be detected reliably by the network elements involved. The latter must be defined by the host itself... since it is the host who desires or doesn't desire a lot of traffic aimed at it. Let's look at the latter, only. It would be silly for the operator of the network to have to look at packets flowing to a web server to detect that many SYNs are sent, but the 3rd step of the handshake is uncompleted. The server is the only reliable place to verify that its time is being wasted by many open connnections. Yet responding to the DDOS attack may be helped by disconnecting the sources. This has to be a network function on a large scale. And tracing back to the source may be a network function. On 10/23/2009 07:47 AM, L.Wood at surrey.ac.uk wrote: > > Hey, I wrote a chapter of that book... > > Do look into the Bundle Protocol, which ignore the end-to-end > principle and control loops in its design. See our 'Bundle of > Problems' paper for more on this: > http://www.ee.surrey.ac.uk/Personal/L.Wood/publications/ > The Bundle Protocol has similar problems/oversights as LTP-T. > > Carlo Caini's group has drawn parallels between > DTN work and TCP PEPs, pointing out that what TCP PEPs do > on the quiet (break the end-to-end control loop into separate > loops) is what things like bundle hops + convergence layers > or http proxy caches do more explicitly and visibly. See e.g. > his IWSSC'09 paper: > "TCP, PEP and DTN Performance on Disruptive Satellite Channels." > > L. > > > > > > -----Original Message----- > From: end2end-interest-bounces at postel.org on behalf of Jaime Mateos > Sent: Fri 2009-10-23 11:26 > To: end2end-interest at postel.org > Subject: [e2e] Protocols breaking the end-to-end argument > > Hi, > I'm working on a project about the current challenges the Internet is > presenting to the end-to-end argument. I'd be interested to know about > any protocols, currently in use, that break the end-to-end principle and > the context where they are used. So far the only one I've found is TCP > PEP that seems to be in use in satellite networks (Internetworking and > computing over satellite networks, Yongguang Zhang - > http://books.google.ie/books?id=3pkI6OWUsRAC&pg=PA170&lpg=PA170&dq=criticisms+of+end+to+end+principle&source=bl&ots=OVbMYc5Iso&sig=Tir1Xi4vxRG5HG2ieGCgl2STWcA&hl=en&ei=vL7TSor9Bs2z4QbW8_H_Ag&sa=X&oi=book_result&ct=result&resnum=5&ved=0CBQQ6AEwBA#v=onepage&q=criticisms%20of%20end%20to%20end%20principle&f=false) > > > There also seems to be a number of research projects such as Split TCP > and LTP-T that I've come across. I'm also interested in these but not to > the same degree as in protocols that are currently in use today. > > Thanks, > Jaime Mateos > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20091023/ff9b5e78/attachment-0001.html From dhc2 at dcrocker.net Fri Oct 23 08:28:22 2009 From: dhc2 at dcrocker.net (Dave CROCKER) Date: Fri, 23 Oct 2009 08:28:22 -0700 Subject: [e2e] Protocols breaking the end-to-end argument In-Reply-To: <4AE1BBBF.2090109@reed.com> References: <4AE184EE.5040800@tcd.ie> <4835AFD53A246A40A3B8DA85D658C4BE01368B07@EVS-EC1-NODE4.surrey.ac.uk> <4AE1BBBF.2090109@reed.com> Message-ID: <4AE1CB96.3020203@dcrocker.net> David P. Reed wrote: > I'd reframe the statement, just because I would actually like the term > "end-to-end argument" to continue to mean what we defined it to mean, > rather than what some people have extended it to mean. Interesting. My sense of things is that the term is not actually defined all that concretely or consistently and that this has made it difficult to use the term constructively. Can you or anyone else point to a definition that a) gives meaningful technical definition of "end to end", sufficient to make differential conformance assessments reasonable. b) provide any basis for believing that that definition has broad use within the technical community? Absent the ability to satisfy this query, we ought to consider an effort to move towards being able to. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dpreed at reed.com Fri Oct 23 08:38:09 2009 From: dpreed at reed.com (David P. Reed) Date: Fri, 23 Oct 2009 11:38:09 -0400 Subject: [e2e] Protocols breaking the end-to-end argument In-Reply-To: <4AE1A414.4090302@gmail.com> References: <4AE184EE.5040800@tcd.ie> <4AE1A414.4090302@gmail.com> Message-ID: <4AE1CDE1.5070205@reed.com> On 10/23/2009 08:39 AM, William Allen Simpson wrote: > You could add the Broadcom chip sets to your list. Not a protocol per > se, > but they inexplicably "handle" TCP segmentation. Usually used in a host > (bad enough in my opinion), but could create utter havoc in a router. > > So far, I've noticed: > > NetXtreme II 1 Gigabit > Tigon 3 This is an interesting observation, but I don't understand what you mean. Explain "handling TCP segmentation" please? Exactly what chips do that? What exactly do they do in the chip? The chips might do IP fragmentation, but I find it hard to see how they could do TCP segmentation, unless of course they are acting as a host. Nothing wrong with a chipset being a host, too (perhaps to present a web, ssh or SNMP interface). -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20091023/e5f8784a/attachment.html From dpreed at reed.com Fri Oct 23 08:41:57 2009 From: dpreed at reed.com (David P. Reed) Date: Fri, 23 Oct 2009 11:41:57 -0400 Subject: [e2e] Protocols breaking the end-to-end argument In-Reply-To: <4AE1CB96.3020203@dcrocker.net> References: <4AE184EE.5040800@tcd.ie> <4835AFD53A246A40A3B8DA85D658C4BE01368B07@EVS-EC1-NODE4.surrey.ac.uk> <4AE1BBBF.2090109@reed.com> <4AE1CB96.3020203@dcrocker.net> Message-ID: <4AE1CEC5.4000306@reed.com> I'd suggest reading the paper where it was originally defined. Given that the three authors AND a crew of peer reviewers touched every word of the definition, it's pretty darned specific. On 10/23/2009 11:28 AM, Dave CROCKER wrote: > > > David P. Reed wrote: >> I'd reframe the statement, just because I would actually like the >> term "end-to-end argument" to continue to mean what we defined it to >> mean, rather than what some people have extended it to mean. > > > Interesting. My sense of things is that the term is not actually > defined all that concretely or consistently and that this has made it > difficult to use the term constructively. > > Can you or anyone else point to a definition that > > a) gives meaningful technical definition of "end to end", > sufficient to make differential conformance assessments reasonable. > > b) provide any basis for believing that that definition has broad > use within the technical community? > > Absent the ability to satisfy this query, we ought to consider an > effort to move towards being able to. > > d/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20091023/eec35888/attachment.html From jnc at mercury.lcs.mit.edu Fri Oct 23 09:58:35 2009 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Fri, 23 Oct 2009 12:58:35 -0400 (EDT) Subject: [e2e] Protocols breaking the end-to-end argument Message-ID: <20091023165835.1D4E66BE5F8@mercury.lcs.mit.edu> > From: Dave CROCKER > My sense of things is that the term is not actually defined all that > concretely or consistently Sorry, I disagree. The original Saltzer/Clark/Reed paper does a pretty good job, I think - as well as one can do with a broad architectural concept, which is inherently not as susceptible to precise definition as, say, an algorithm. > this has made it difficult to use the term constructively. No, people being bozos and not using the term _as it wss originally defined_ are what has made its use problematic. Noel From dpreed at reed.com Fri Oct 23 10:52:57 2009 From: dpreed at reed.com (David P. Reed) Date: Fri, 23 Oct 2009 13:52:57 -0400 Subject: [e2e] Protocols breaking the end-to-end argument In-Reply-To: <4AE1D4E6.2010105@bbiw.net> References: <4AE184EE.5040800@tcd.ie> <4835AFD53A246A40A3B8DA85D658C4BE01368B07@EVS-EC1-NODE4.surrey.ac.uk> <4AE1BBBF.2090109@reed.com> <4AE1CB96.3020203@dcrocker.net> <4AE1CEC5.4000306@reed.com> <4AE1D4E6.2010105@bbiw.net> Message-ID: <4AE1ED79.2010604@reed.com> Sorry - I figured everyone on this list knew the paper itself, since it's cited all over the place, so I was being a little bit terse. Anyway, one place you can get the original paper text is online at http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf . We also wrote a followup paper in the "active networks" era that tries to carefully explain how the same approach can be helpful in thinking about "active networks": http://web.mit.edu/Saltzer/www/publications/endtoend/ANe2ecomment.html (this was published in IEEE Networking, or some other IEEE pub, as I recall). Some will remember that "active networking" was viewed as an idea that made the end-to-end argument "obsolete" - I personally think that that was a conclusion based on a misunderstanding about what we meant - and this second paper refines the point we made in the first paper. Saltzer, Clark, and I have separately extended and adapted the original ideas. Perhaps the most interesting recent idea is Dave Clark's unpublished talk and note which focuses on a "Trust-to-Trust principle" that I have urged him to write up. I don't think it is published yet. Dave and Marjorie Blumenthal have also written a paper on a range of areas where policy functions might best be done in the network. I don't have a link to it, but here's a citation. M. Blumenthal, D. Clark,/Rethinking the Design of the Internet: The End-to-end Arguments vs. the Brave New World/, ACM Transactions on Internet Technology, 1(1):70-109, August 2001 . I can't help adding: Of course there are lots of people who use the word "end-to-end" when they mean, for example, "TCP is perfect". (I'm not one of them: I have about 40,000 complaints with TCP and IP, so it's especially galling to be accused of claiming that TCP is the best of all possible protocols - often as a straw man. TCP's merely good enough, IMHO, to apply a different and older argument: if it ain't broke, don't fix it. But by all means experiment with improvements and alternatives). On 10/23/2009 12:08 PM, Dave CROCKER wrote: > David, > > I'm asking to explore this carefully and inclusively. > > Since you are putting a reference forward, what is the citation to it? > > d/ > > > David P. Reed wrote: >> I'd suggest reading the paper where it was originally defined. Given >> that the three authors AND a crew of peer reviewers touched every >> word of the definition, it's pretty darned specific. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20091023/f057ce7b/attachment.html From L.Wood at surrey.ac.uk Fri Oct 23 12:02:59 2009 From: L.Wood at surrey.ac.uk (Lloyd Wood) Date: Fri, 23 Oct 2009 20:02:59 +0100 Subject: [e2e] Protocols breaking the end-to-end argument In-Reply-To: <4AE1ED79.2010604@reed.com> References: <4AE184EE.5040800@tcd.ie> <4835AFD53A246A40A3B8DA85D658C4BE01368B07@EVS-EC1-NODE4.surrey.ac.uk> <4AE1BBBF.2090109@reed.com> <4AE1CB96.3020203@dcrocker.net> <4AE1CEC5.4000306@reed.com> <4AE1D4E6.2010105@bbiw.net> <4AE1ED79.2010604@reed.com> Message-ID: On 23 Oct 2009, at 18:52, David P. Reed wrote: > Sorry - I figured everyone on this list knew the paper itself, > since it's cited all over the place, so I was being a little bit > terse. Anyway, one place you can get the original paper text is > online at http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf > . Worth stressing that there are actually multiple revisions of that paper. J. Saltzer, D. Reed and D. Clark, ?End-to-End Arguments in System Design?, Second International Conference on Distributed Computing Systems (April 1981) pages 509-512. J. Saltzer, D. Reed and D. Clark, ?End-to-End Arguments in System Design?, ACM Transactions in Computer Systems, pp. 277-288, November 1984. http://doi.acm.org/10.1145/357401.357402 The version at Saltzer's webpages above is a third version, with page numbering 1-10, but its footnote on the first page is helpful at pointing out different versions. http://en.wikipedia.org/wiki/End-to-end_principle could be better... L. DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/ From dpreed at reed.com Fri Oct 23 14:33:43 2009 From: dpreed at reed.com (David P. Reed) Date: Fri, 23 Oct 2009 17:33:43 -0400 Subject: [e2e] Protocols breaking the end-to-end argument In-Reply-To: References: <4AE184EE.5040800@tcd.ie> <4835AFD53A246A40A3B8DA85D658C4BE01368B07@EVS-EC1-NODE4.surrey.ac.uk> <4AE1BBBF.2090109@reed.com> <4AE1CB96.3020203@dcrocker.net> <4AE1CEC5.4000306@reed.com> <4AE1D4E6.2010105@bbiw.net> <4AE1ED79.2010604@reed.com> Message-ID: <4AE22137.10909@reed.com> Wikipedia article is not definitive. In particular, none of the 3 authors wrote the wikipedia article. In general, wikipedia does well at some things, but I wouldn't trust it to read authors' words more clearly than the authors themselves. In particular: there was never an "end-to-end principle". So if you get the title wrong, why should we trust you to get the details right? Indeed the original paper was presented at a conference, selected for ACM TOCS (and revised to their standards), and the last, online version is slightly different. There was also a version that was circulated prior to the 1981 conference among peers and friends - as was the convention in the computer systems community - some of the examples in the 1981 version were suggested during that phase. On 10/23/2009 03:02 PM, Lloyd Wood wrote: > > On 23 Oct 2009, at 18:52, David P. Reed wrote: > >> Sorry - I figured everyone on this list knew the paper itself, since >> it's cited all over the place, so I was being a little bit terse. >> Anyway, one place you can get the original paper text is online at >> http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf . > > Worth stressing that there are actually multiple revisions of that paper. > > J. Saltzer, D. Reed and D. Clark, ?End-to-End Arguments in System > Design?, Second International Conference on Distributed Computing > Systems (April 1981) pages 509-512. > > J. Saltzer, D. Reed and D. Clark, ?End-to-End Arguments in System > Design?, ACM Transactions in Computer Systems, pp. 277-288, November > 1984. > http://doi.acm.org/10.1145/357401.357402 > > The version at Saltzer's webpages above is a third version, with page > numbering 1-10, but its footnote > on the first page is helpful at pointing out different versions. > > http://en.wikipedia.org/wiki/End-to-end_principle > could be better... > > L. > > DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/ > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20091023/5f15c7f9/attachment.html From L.Wood at surrey.ac.uk Fri Oct 23 16:20:27 2009 From: L.Wood at surrey.ac.uk (Lloyd Wood) Date: Sat, 24 Oct 2009 00:20:27 +0100 Subject: [e2e] Protocols breaking the end-to-end argument In-Reply-To: <4AE22137.10909@reed.com> References: <4AE184EE.5040800@tcd.ie> <4835AFD53A246A40A3B8DA85D658C4BE01368B07@EVS-EC1-NODE4.surrey.ac.uk> <4AE1BBBF.2090109@reed.com> <4AE1CB96.3020203@dcrocker.net> <4AE1CEC5.4000306@reed.com> <4AE1D4E6.2010105@bbiw.net> <4AE1ED79.2010604@reed.com> <4AE22137.10909@reed.com> Message-ID: <84E34418-0098-485A-8E33-500498DF4067@surrey.ac.uk> On 23 Oct 2009, at 22:33, David P. Reed wrote: > In particular: there was never an "end-to-end principle". So if you > get the title wrong, why should we trust you to get the details right? because "end-to-end argument principle" is appalling grammar. The word "principle" appears multiple times in the paper, including the abstract and conclusions. "No one gets angry at a mathematician or a physicist whom he or she doesn't understand, or at someone who speaks a foreign language, but rather at someone who tampers with your own language." -- Jacques Derrida http://mercury.lcs.mit.edu/~jnc/tech/end_end.html DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/ From perfgeek at mac.com Fri Oct 23 18:47:52 2009 From: perfgeek at mac.com (rick jones) Date: Fri, 23 Oct 2009 18:47:52 -0700 Subject: [e2e] Protocols breaking the end-to-end argument In-Reply-To: <4AE1CDE1.5070205@reed.com> References: <4AE184EE.5040800@tcd.ie> <4AE1A414.4090302@gmail.com> <4AE1CDE1.5070205@reed.com> Message-ID: <070399CF-B67C-41E0-95A3-A528A931A1E6@mac.com> On Oct 23, 2009, at 8:38 AM, David P. Reed wrote: > On 10/23/2009 08:39 AM, William Allen Simpson wrote: >> >> You could add the Broadcom chip sets to your list. Not a protocol >> per se, >> but they inexplicably "handle" TCP segmentation. Usually used in a >> host >> (bad enough in my opinion), but could create utter havoc in a router. >> >> So far, I've noticed: >> >> NetXtreme II 1 Gigabit >> Tigon 3 > This is an interesting observation, but I don't understand what you > mean. > > Explain "handling TCP segmentation" please? Exactly what chips do > that? What exactly do they do in the chip? > > The chips might do IP fragmentation, but I find it hard to see how > they could do TCP segmentation, unless of course they are acting as > a host. Nothing wrong with a chipset being a host, too (perhaps to > present a web, ssh or SNMP interface). Perhaps he is referring to chips which provide TCP/Transport Segmentation Offload - aka TSO - the functionality that allows the stack to hand the chip a chunk of data > the MTU, along with the initial TCP/IP headers and the connection's on the wire MSS, and then have the chip otherwise statelessly segment that larger chunk of data into MSS-sized segments for transmission on the wire/fibre/etc. If that is the functionality of which he speaks, it is in virtually every contemporary 1GbE card I can think of (but my thoughts cannot span the entirety of the space I suspect). Also, virtually every 10G NIC out there offers the same functionality. And if that upsets him, we better not tell him about the 10G NICs also doing receive offload... :) rick jones BTW, I do not believe that any router actually has TSO happen to TCP segments contained within the IP datagrams passing through it - although there have been issues in Linux with LRO (Large Receive Offload, distinct from General Receive Offload) when the system was acting as either a router or a bridge - because TSO doesn't happen in that path :) http://homepage.mac.com/perfgeek From perfgeek at mac.com Fri Oct 23 18:49:12 2009 From: perfgeek at mac.com (rick jones) Date: Fri, 23 Oct 2009 18:49:12 -0700 Subject: [e2e] Protocols breaking the end-to-end argument In-Reply-To: <4AE18C73.7000208@spaghetti.zurich.ibm.com> References: <4AE184EE.5040800@tcd.ie> <4AE18C73.7000208@spaghetti.zurich.ibm.com> Message-ID: On Oct 23, 2009, at 3:58 AM, Jeroen Massar wrote: > Jaime Mateos wrote: >> Hi, >> I'm working on a project about the current challenges the Internet is >> presenting to the end-to-end argument. I'd be interested to know >> about >> any protocols, currently in use, that break the end-to-end >> principle and >> the context where they are used. > > Everything that needs an NAT helper, thus any protocol that embeds > addresses or ports, thus most games, everything that has a listening > port where the listening port is not on a public IP or firewalled > away. Isn't the sense incorrect there? I always thought it was the NAT itself, and its need for helpers that was in opposition to the quasi- mythical end-to-end principle? rick jones Wisdom teeth are impacted, people are affected by the effects of events From richard at bennett.com Fri Oct 23 20:23:21 2009 From: richard at bennett.com (Richard Bennett) Date: Fri, 23 Oct 2009 20:23:21 -0700 Subject: [e2e] Protocols breaking the end-to-end argument In-Reply-To: References: <4AE184EE.5040800@tcd.ie> <4AE18C73.7000208@spaghetti.zurich.ibm.com> Message-ID: <4AE27329.3040801@bennett.com> People who are interested in the evolution, refinement, application, and re-definition of end-to-end arguments, principles, doctrines, dogmas, and guidelines may enjoy my paper, "Designed for Change: End-to-End Arguments, Internet Innovation, and the Net Neutrality Debate", available at http://www.itif.org/index.php?id=294 along with a video of a nice discussion of the stagnation of Internet protocol development with Dave Farber, John Day, Chris Yoo, Bill Lehr, and yours truly. I think Jaime's usage, "breaking end-to-end", is common in today's IETF, where people tend to regard end system function placement as a default, and the caveats of the Arguments are pretty much ignored. This kind of reduction is to be expected, given the way that complex ideas tend to be simplified by time. The best discussion I've seen of function placement in a datagram network to this day is found in Louis Pouzin's mongraph on the CYCLADES network, _Cyclades Computer Network: Towards Layered Network Applications_, Elsevier Science Ltd (September 1982). The book is out of print, but it's available through interlibrary loan from several institutions in the US. Pouzin takes a very pragmatic and empirical approach to function placement, where later engineers tended to come from first principles. The worst treatment is David Isenberg's second "stupid network" paper, "Dawn of the Stupid Network"; it's much more doctrinaire than "Rise of the Stupid Network" by the same dude. A couple of great critiques of "End-to-End Args" are RFC 1958 and Tim Moors' "A Critical Review of End-to-End Arguments in System Design", http://www.ee.unsw.edu.au/~timm/pubs/02icc/published.pdf. Moors shows that the Saltzer, Reed, and Clark argument for end-to-end placement is both circular and inconsistent with the FTP example that is supposed to demonstrate it. But the tres amigos of e2e were writing in 1981 when network engineering was mostly a matter of intuition, so what do you expect? One of the more interesting unresolved questions about "End-to-End Args" is why it was written in the first place. Some people see it as a salvo in the ISO protocol wars, others as an attack in BBN's ARPANET, some as an attempt to criss the divide between engineering and policy, and there are probably other theories as well. The Blumenthal and Clark "Brave New World" paper was very influential because it lit the fire under Larry Lessig that got him storming around about "protecting the Internet" from all the threats to stagnation and freedom. There's a fairly clear path from Lessig's reaction to "Brave New World" and the immoderate regulatory climate in the US today that's so hostile to Internet progress. RB rick jones wrote: > > On Oct 23, 2009, at 3:58 AM, Jeroen Massar wrote: > >> Jaime Mateos wrote: >>> Hi, >>> I'm working on a project about the current challenges the Internet is >>> presenting to the end-to-end argument. I'd be interested to know about >>> any protocols, currently in use, that break the end-to-end principle >>> and >>> the context where they are used. >> >> Everything that needs an NAT helper, thus any protocol that embeds >> addresses or ports, thus most games, everything that has a listening >> port where the listening port is not on a public IP or firewalled away. > > Isn't the sense incorrect there? I always thought it was the NAT > itself, and its need for helpers that was in opposition to the > quasi-mythical end-to-end principle? > > rick jones > Wisdom teeth are impacted, people are affected by the effects of events > -- Richard Bennett Research Fellow Information Technology and Innovation Foundation Washington, DC From mbaer at cs.tu-berlin.de Fri Oct 23 22:46:05 2009 From: mbaer at cs.tu-berlin.de (=?ISO-8859-1?Q?Matthias_B=E4rwolff?=) Date: Sat, 24 Oct 2009 07:46:05 +0200 Subject: [e2e] Protocols breaking the end-to-end argument In-Reply-To: <84E34418-0098-485A-8E33-500498DF4067@surrey.ac.uk> References: <4AE184EE.5040800@tcd.ie> <4835AFD53A246A40A3B8DA85D658C4BE01368B07@EVS-EC1-NODE4.surrey.ac.uk> <4AE1BBBF.2090109@reed.com> <4AE1CB96.3020203@dcrocker.net> <4AE1CEC5.4000306@reed.com> <4AE1D4E6.2010105@bbiw.net> <4AE1ED79.2010604@reed.com> <4AE22137.10909@reed.com> <84E34418-0098-485A-8E33-500498DF4067@surrey.ac.uk> Message-ID: <4AE2949D.5070200@cs.tu-berlin.de> Lloyd Wood wrote: > > On 23 Oct 2009, at 22:33, David P. Reed wrote: >> In particular: there was never an "end-to-end principle". So if you >> get the title wrong, why should we trust you to get the details right? > > because "end-to-end argument principle" is appalling grammar. The word > "principle" appears multiple times in the paper, including the > abstract and conclusions. The word "principle" appears *only* in the abstract, plus in the second and the penultimate sentence of the 1984 paper. The content of the paper, however, is very much about arguments (as in debate), not principle (as in strict and not to argue with), maybe not even so much about argument (as in "one logical conclusion to an irrefutable reasoning"). With all respect for the authors, we all know how abstracts are typically written: It is often the very last thing on one's mind, even though it should be the very first (although or possibly just because written at the end of the process). Often, they are either totally redundant (just repeating phrases from the content), or they exaggerate things in a bid to draw the reader to the content. Rarely do they capture precisely the essence of a paper. An aside: I'd be interested to see the the 1981 version, and whether it is much different from the 1984 one. Does anyone have it? Matthias -- Matthias B?rwolff www.b?rwolff.de From richard at bennett.com Fri Oct 23 23:17:03 2009 From: richard at bennett.com (Richard Bennett) Date: Sat, 24 Oct 2009 02:17:03 -0400 Subject: [e2e] Protocols breaking the end-to-end argument In-Reply-To: <4AE2949D.5070200@cs.tu-berlin.de> References: <4AE184EE.5040800@tcd.ie> <4835AFD53A246A40A3B8DA85D658C4BE01368B07@EVS-EC1-NODE4.surrey.ac.uk> <4AE1BBBF.2090109@reed.com> <4AE1CB96.3020203@dcrocker.net> <4AE1CEC5.4000306@reed.com> <4AE1D4E6.2010105@bbiw.net> <4AE1ED79.2010604@reed.com> <4AE22137.10909@reed.com> <84E34418-0098-485A-8E33-500498DF4067@surrey.ac.uk> <4AE2949D.5070200@cs.tu-berlin.de> Message-ID: <4AE29BDF.7020103@bennett.com> An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20091024/518d68b4/attachment.html From Jon.Crowcroft at cl.cam.ac.uk Sat Oct 24 01:41:01 2009 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Sat, 24 Oct 2009 09:41:01 +0100 Subject: [e2e] Protocols breaking the end-to-end argument In-Reply-To: <20091023165835.1D4E66BE5F8@mercury.lcs.mit.edu> References: <20091023165835.1D4E66BE5F8@mercury.lcs.mit.edu> Message-ID: one of the problems is language evolution/erosion for some people an end-to-end _argument_ is an argument for everything being in the end point as opposed to the more nuanced meaning of the aforesaid paper(s) in which it is a set of dynamic debates which set a tension between whether you put something in the end, in the end, or not (i.e. in the intermediate). the "argument" then is not a polemic but a method or process (or dialectic) that can and should be dynamically reapplied as technology and the environment evolve. In missive <20091023165835.1D4E66BE5F8 at mercury.lcs.mit.edu>, Noel Chia ppa typed: >> > From: Dave CROCKER >> >> > My sense of things is that the term is not actually defined all that >> > concretely or consistently >> >>Sorry, I disagree. The original Saltzer/Clark/Reed paper does a pretty >>good job, I think - as well as one can do with a broad architectural >>concept, which is inherently not as susceptible to precise definition as, >>say, an algorithm. >> >> > this has made it difficult to use the term constructively. >> >>No, people being bozos and not using the term _as it wss originally >>defined_ are what has made its use problematic. >> >> Noel cheers jon From william.allen.simpson at gmail.com Sat Oct 24 05:06:08 2009 From: william.allen.simpson at gmail.com (William Allen Simpson) Date: Sat, 24 Oct 2009 08:06:08 -0400 Subject: [e2e] Protocols breaking the end-to-end argument In-Reply-To: <070399CF-B67C-41E0-95A3-A528A931A1E6@mac.com> References: <4AE184EE.5040800@tcd.ie> <4AE1A414.4090302@gmail.com> <4AE1CDE1.5070205@reed.com> <070399CF-B67C-41E0-95A3-A528A931A1E6@mac.com> Message-ID: <4AE2EDB0.3010406@gmail.com> rick jones wrote: > Perhaps he is referring to chips which provide TCP/Transport > Segmentation Offload - aka TSO - the functionality that allows the stack > to hand the chip a chunk of data > the MTU, along with the initial > TCP/IP headers and the connection's on the wire MSS, and then have the > chip otherwise statelessly segment that larger chunk of data into > MSS-sized segments for transmission on the wire/fibre/etc. > It is indeed. Since the hardware driver is unaware of many things, such as path MTU, this is one of its serious impediments. Sure, there are measurements that show several percentage points less CPU, but in most cases we're not CPU bound. I'm not sure what problem it's solving, other than a checkbox to differentiate commodity products. Worst of all, this stuff is all implemented in unmodifiable, proprietary firmware. > If that is the functionality of which he speaks, it is in virtually > every contemporary 1GbE card I can think of (but my thoughts cannot span > the entirety of the space I suspect). Also, virtually every 10G NIC out > there offers the same functionality. > Gaah! I only knew about the Broadcom chips, as discussed on the NetBSD lists a few years back, and didn't know this disease had spread. > And if that upsets him, we better not tell him about the 10G NICs also > doing receive offload... :) > I'd heard of it, but thought that was pretty uniformly rejected. Heck, the most basic TCP decision points would be impossible to implement, revise, or test. > BTW, I do not believe that any router actually has TSO happen to TCP > segments contained within the IP datagrams passing through it - although Only recently trying to decipher the Linux stack, but it all appears to go through the same queue, routed packets included. If the box receives a jumbogram on one interface, it can be re-segmented out another, and I've not found any support for PMTUD or ECN or anything. > there have been issues in Linux with LRO (Large Receive Offload, > distinct from General Receive Offload) when the system was acting as > either a router or a bridge - because TSO doesn't happen in that path :) > Again, I'm not as familiar with Linux-only terminology. A quick Google turns up "Generic Receive Offload", and that appears to be explicitly designed to merge segments in routers, and re-segment out the other side: http://lwn.net/Articles/311357/ I'm pretty sure this is contrary to the end-to-end [argument, principle, what-have-you].... And covered by a passel of patents. From dpreed at reed.com Sat Oct 24 07:12:24 2009 From: dpreed at reed.com (David P. Reed) Date: Sat, 24 Oct 2009 10:12:24 -0400 Subject: [e2e] Protocols breaking the end-to-end argument In-Reply-To: <4AE27329.3040801@bennett.com> References: <4AE184EE.5040800@tcd.ie> <4AE18C73.7000208@spaghetti.zurich.ibm.com> <4AE27329.3040801@bennett.com> Message-ID: <4AE30B48.9090405@reed.com> Since the moderator did not find a problem with Bennett's posting, I will request his leave to address Bennett's ouvre and in particular this particular posting in a more direct manner, since he has walked into this *technical* forum with a variety of outrageous claims directed at the motives of me and my co-authors. On 10/23/2009 11:23 PM, Richard Bennett wrote: > One of the more interesting unresolved questions about "End-to-End > Args" is why it was written in the first place. Some people see it as > a salvo in the ISO protocol wars, others as an attack in BBN's > ARPANET, some as an attempt to criss the divide between engineering > and policy, and there are probably other theories as well. Richard Bennett spends a fair amount of his writing imputing motives to people, and then using those motives to somehow impugn their credibility. The above paragraph is such an example. (Please note that I am just stating a fact about his writing style. You can read the paper he submitted for lots of examples. He has also imputed that Vint Cerf and Bob Kahn "stole" the ideas for the Internet from Pouzin without proper credit. Now I don't know if he can read the minds of Jerry Saltzer, Dave Clark, or myself in writing the original paper. However the paragraph quoted above is about the most ridiculous claim I have ever heard. We wrote the paper as an attempt to contribute to the art of architecting the Internet, as I believe most of the people on this list would understand. However, Bennett has no shame. He does, however act as a troll. > > From dpreed at reed.com Sat Oct 24 07:34:14 2009 From: dpreed at reed.com (David P. Reed) Date: Sat, 24 Oct 2009 10:34:14 -0400 Subject: [e2e] TCP offload (was part of Protocols breaking the end-to-end argument) In-Reply-To: <4AE2EDB0.3010406@gmail.com> References: <4AE184EE.5040800@tcd.ie> <4AE1A414.4090302@gmail.com> <4AE1CDE1.5070205@reed.com> <070399CF-B67C-41E0-95A3-A528A931A1E6@mac.com> <4AE2EDB0.3010406@gmail.com> Message-ID: <4AE31066.8010109@reed.com> Because I sense this thread might be interesting, and should be separated from the trolling going on in the original thread, I changed the title. TCP offload is interesting. We actually addressed this kind of thing is the "Active Networks" vs. end-to-end paper. Function placement at the architectural level actually can be discussed with regard to "design time" and "implementation time" versions of the arguments. For example, if I am an "end host" but I do some of my functions on "attached support processors" (excuse the "I" as metaphor for the main OS and CPU), that may be quite clean architecturally - IF the communication between me and the attached support processor is one that makes it act as part of "me". So one could consider it part of the "end", even if it is in a middlebox: the distinction is that it is under my sole control (so it acts as a fully controlled module). The end-to-end argument in the paper says that such acceleration can be in the network, if indeed it merely accelerates a function that is in all endpoints. However, the argument asks that we consider whether the improvement overall is really worth it. I leave it to the community of architects (not the chip designers, who have a bias to believe that every "feature" is a differentiating advantage) to decide whether the benefit of this particular thing is really worth the potential inflexibility it creates - in particular the risk that the chip will do the wrong thing on the forwarding path, and the risk that the TCP spec will change in a way that makes the chip's popularity a barrier to innovation. It sounds as if there is a chance that, due to how one of the TOS chips works, the portion of TCP that it implements is not strictly an "agent" of the host TCP stack running on the host processor, but instead based on "pattern recognition" that cannot be turned off. (I haven't read the spec, so maybe it is more subtle than that). That would result in a serious bug - if the chip is used by a low-level forwarding path, perhaps an ethernet bridge or an IP routing layer, the "optimization" would by accident be applied to TCP segments having nothing to do with the host. This clearly makes using such chips in general boxes like Linux boxes, that can perform ethernet bridging, IP forwarding, etc. QUITE problematic! So perhaps they need to be marked as *inappropriate* for general use. But that is because they really are buggy for that use. (again, I haven't read the spec). From perfgeek at mac.com Sat Oct 24 09:24:23 2009 From: perfgeek at mac.com (rick jones) Date: Sat, 24 Oct 2009 09:24:23 -0700 Subject: [e2e] Protocols breaking the end-to-end argument In-Reply-To: <4AE2EDB0.3010406@gmail.com> References: <4AE184EE.5040800@tcd.ie> <4AE1A414.4090302@gmail.com> <4AE1CDE1.5070205@reed.com> <070399CF-B67C-41E0-95A3-A528A931A1E6@mac.com> <4AE2EDB0.3010406@gmail.com> Message-ID: <84DEEF1B-057D-4C08-AE2B-EFB525A53BE5@mac.com> On Oct 24, 2009, at 5:06 AM, William Allen Simpson wrote: > rick jones wrote: >> Perhaps he is referring to chips which provide TCP/Transport >> Segmentation Offload - aka TSO - the functionality that allows the >> stack to hand the chip a chunk of data > the MTU, along with the >> initial TCP/IP headers and the connection's on the wire MSS, and >> then have the chip otherwise statelessly segment that larger chunk >> of data into MSS-sized segments for transmission on the wire/fibre/ >> etc. > It is indeed. Since the hardware driver is unaware of many things, > such as path MTU, this is one of its serious impediments. WRT PathMTU, the implementations with which I am familiar have the stack telling the NIC the on-the-wire size (what I tend to call the effective MSS) to use on each "large send" where that effective MSS is updated based on PathMTU information as/if it arrives. > Sure, there are measurements that show several percentage points less > CPU, but in most cases we're not CPU bound. I'm not sure what problem > it's solving, other than a checkbox to differentiate commodity > products. When the functionality was introduced in the 1GbE NICs it was to allow them to be driven at link-rate with the then-contemporary CPUs, not only for easily dismissed (well, not IMO :) things like netperf TCP_STREAM, but also for items customers actually did like file transfers, or clustered database traffic, etc. (ie if you can't get there with netperf, you ain't going to get there with FTP) Now, this may be a place where my world starts to diverge from the rest of the end2end community's - indeed many of my employer's customers do things across the big-I Internet, but they do far more across their corporate LANs and intranets. I can see where being CPU bound talking across the big-I Internet is perhaps rare, but being CPU bound when talking across the corporate 1 Gig LAN was not rare. And essentially we have One Protocol to Rule Them All... Yes, CPUs today are "faster" than at the dawn of 1 Gig Ethernet. We are also at the dawn (perhaps a little past, depends I suppose on one's deployment longitude) of 10 Gig Ethernet. Bless their hearts, when a customer upgrades their network from one speed to the next, they care little about Amdahl's Law etc and get quite agitated when one cannot achieve link-rate on the next higher speed. Well, they might give you a generation's worth of lee-way, but by the time the second generation of the NIC arrives, their expectations are pretty firm. If your solution cannot achieve link-rate, your solution is not selected. TSO and GRO, like Jumbo Frames, can be thought of as the inevitable "inter-reaction" between customer expectations and a de jure network MTU size that has remained unchanged since the dawn of Ethernet. Or, put another way, we have begun treating the Ethernet MTU as damaged and routed around it. >> And if that upsets him, we better not tell him about the 10G NICs >> also doing receive offload... :) > I'd heard of it, but thought that was pretty uniformly rejected. > Heck, > the most basic TCP decision points would be impossible to implement, > revise, or test. "LRO" (multiple segment coalescing done in the chip and an uber frame hitting the host with the intermediate headers stripped) has been rejected in Linux-land in favor of GRO, which preserves the arriving segment boundaries via some clever linking of buffers (and perhaps some header-data split but I'm fuzzy there). >> BTW, I do not believe that any router actually has TSO happen to >> TCP segments contained within the IP datagrams passing through it - >> although > > Only recently trying to decipher the Linux stack, but it all appears > to > go through the same queue, routed packets included. If the box > receives > a jumbogram on one interface, it can be re-segmented out another, and > I've not found any support for PMTUD or ECN or anything. > > >> there have been issues in Linux with LRO (Large Receive Offload, >> distinct from General Receive Offload) when the system was acting >> as either a router or a bridge - because TSO doesn't happen in that >> path :) > Again, I'm not as familiar with Linux-only terminology. A quick > Google > turns up "Generic Receive Offload", and that appears to be explicitly > designed to merge segments in routers, and re-segment out the other > side: > > http://lwn.net/Articles/311357/ > > I'm pretty sure this is contrary to the end-to-end [argument, > principle, > what-have-you].... You are supposed to be ignoring the code-path behind the curtain :) rick jones http://homepage.mac.com/perfgeek From jnc at mercury.lcs.mit.edu Sat Oct 24 11:00:15 2009 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sat, 24 Oct 2009 14:00:15 -0400 (EDT) Subject: [e2e] Protocols breaking the end-to-end argument Message-ID: <20091024180015.91FF16BE55B@mercury.lcs.mit.edu> > From: Richard Bennett > The best discussion I've seen of function placement in a datagram > network to this day is found in Louis Pouzin's mongraph on the CYCLADES > network, _Cyclades Computer Network: Towards Layered Network > Applications_, Elsevier Science Ltd (September 1982). I'm not sure I'm totally on board with that "best" attribute, but the work of Pouzin et al was an _extremely_ important step in the evolution of networking, and often does't get the credit it deserves (e.g. one of the papers I read in preparing to respond to this email didn't mention it, in reviewing the philosophical development of the architecture of TCP/IP). > Tim Moors' "A Critical Review of End-to-End Arguments in System > Design", http://www.ee.unsw.edu.au/~timm/pubs/02icc/published.pdf. A good and interesting paper; thanks for bring it to my attention. I do think it goes off the beam in a couple of places, though. For one, NATs became widespread mostly a result of flaws in the original engineering (too small an address space) and architecture (too few namespaces, leading to difficulty in supporting things like provider independence). NATs are not inherently desirable, and would not, I think, have evolved/proliferated had TCP/IP avoided those (in hindsight, now obvious) mistakes. For another, the current routing architecture has been driven much more by factors such as technical hysteresis (both personnel familiarity with the existing distributed computation model, as well as 'if it isn't broken, don't fix it') and 'alligator' syndrome (as in 'when you're up to your you-know-what in alligators [growing the network, in this case], you don't go looking for more not-immediately-important fights'). Still, those are nits in the overall sweep of the paper. > Moors shows that the Saltzer, Reed, and Clark argument for end-to-end > placement is both circular and inconsistent with the FTP example that > is supposed to demonstrate it. I didn't see that at all. > One of the more interesting unresolved questions about "End-to-End > Args" is why it was written in the first place. Some people see it as a > salvo in the ISO protocol wars, others as an attack in BBN's ARPANET, > some as an attempt to criss the divide between engineering and policy I don't know whether to be amused or outraged by this nonsense. I will settle for observing that you probably haven't interacted much with Jerry - because had you done so, it would have been utterly obvious to you that overwhelmingly his most important motivation in writing the paper was his deep commitment to improving the art of system architecture. Dave Reed is here to defend himself, and as to Dave Clark, I would be prepared to bet pretty much any stakes that he'd be in the front rank in acclaiming the ARPANet as a huge step forward in information networking. The reference to the "ISO protocol wars" is completely mystifying, as the architecture of the ISO stack (at least, the CLNP/TP4 flavour, which was the subset which gave TCP/IP the best 'run for their money') is basically identical to that of TCP/IP (modulo disagreements on certain arcane points, such as exactly what kind of abstract entities the names at the various levels refer to - a subject wholly unrelated to the end-end debate). Noel From richard at bennett.com Sat Oct 24 12:54:22 2009 From: richard at bennett.com (Richard Bennett) Date: Sat, 24 Oct 2009 12:54:22 -0700 Subject: [e2e] Protocols breaking the end-to-end argument In-Reply-To: <20091024180015.91FF16BE55B@mercury.lcs.mit.edu> References: <20091024180015.91FF16BE55B@mercury.lcs.mit.edu> Message-ID: <4AE35B6E.1080801@bennett.com> Noel Chiappa wrote: > > From: Richard Bennett > > > Moors shows that the Saltzer, Reed, and Clark argument for end-to-end > > placement is both circular and inconsistent with the FTP example that > > is supposed to demonstrate it. > > I didn't see that at all. > Moors points out that TCP error detection and recovery is an end-system function, but not really an endpoint function in the file transfer example. The file transfer *application* is the endpoint, so placing the error detection and recovery function in TCP is actually putting it in an intermediate system level. This becomes clear when we recognize that TCP is often implemented in hardware or in firmware running on a CPU that lives on an interface card. The paper goes to great lengths to show that host-based TCP is immune to problem induced at MIT by a bad 1822 interface card, but it was very common engineering practice in the mid-80s to implement TCP on an interface card that had the same vulnerability as the 1822 card. Excelan and Ungermann-Bass built these systems and they were very popular. They designed in a competent level of data integrity at the bus interface, so it wasn't necessary to rely on software to detect bus problems. So it's at least ironic that the end-to-end argument on the data integrity basis was mooted by practice by the time the 1984 version of the paper was published. Because the file transfer program doesn't do its own data integrity checking but relies on TCP to do it, it's not really an example of endpoint placement at all; in fact, it's a "partial implementation". > > > One of the more interesting unresolved questions about "End-to-End > > Args" is why it was written in the first place. Some people see it as a > > salvo in the ISO protocol wars, others as an attack in BBN's ARPANET, > > some as an attempt to criss the divide between engineering and policy > > I don't know whether to be amused or outraged by this nonsense. > I don't know why this question should get anybody upset, it's just a question about the context and motivation of the paper in the first place. None of the authors was part of the inner circle of the Internet protocol design at the time the paper was written, although Clark was either the Chief Architect of the Internet or on his way to becoming same. I would have expected Cerf and Kahn to write something explaining the architectural decisions they made in adapting the framework to their system, but their failure to do so meant someone else had to do it. Why these three people and why this particular time? It's never been explained. > I will settle for observing that you probably haven't interacted much with > Jerry - because had you done so, it would have been utterly obvious to you > that overwhelmingly his most important motivation in writing the paper was > his deep commitment to improving the art of system architecture. > > Dave Reed is here to defend himself, and as to Dave Clark, I would be prepared > to bet pretty much any stakes that he'd be in the front rank in acclaiming the > ARPANet as a huge step forward in information networking. > > The reference to the "ISO protocol wars" is completely mystifying, as the > architecture of the ISO stack (at least, the CLNP/TP4 flavour, which was the > subset which gave TCP/IP the best 'run for their money') is basically > identical to that of TCP/IP (modulo disagreements on certain arcane points, > such as exactly what kind of abstract entities the names at the various levels > refer to - a subject wholly unrelated to the end-end debate). The "ISO protocol wars" I am referring to took place within the context of the ISO development community between the CLNP that the datagram people wanted and CONS, the connection-oriented service that was proposed by the European PTTs. CONS was an extension of the line of development that went from ARPANET to X.25, which CLNP was on the line that went from CYCLADES through DECnet. The naming and addressing logic in CLNP and its predecessors was very different from TCP/IP but consistent with these others. The reasons that ISO didn't succeed are well-documented in John Day's "Patterns in Network Architecture." Like it or not, Noel, there was a lot of friction between the Network Working Group and BBN over the control BBN had over the ARPANET protocols inside the IMP. The interesting problems of the day in protocol design were all behind the curtain to the people who used the ARPANET, and that's frustrating to engineers. Nobody disagrees that ARPANET was a huge first step in packet switching; but by 1981, people were well into the second step, and the closed implementation of the lower three layers was a problem. > Noel > -- Richard Bennett Research Fellow Information Technology and Innovation Foundation Washington, DC From richard at bennett.com Sat Oct 24 13:01:41 2009 From: richard at bennett.com (Richard Bennett) Date: Sat, 24 Oct 2009 13:01:41 -0700 Subject: [e2e] Protocols breaking the end-to-end argument In-Reply-To: <4AE30B48.9090405@reed.com> References: <4AE184EE.5040800@tcd.ie> <4AE18C73.7000208@spaghetti.zurich.ibm.com> <4AE27329.3040801@bennett.com> <4AE30B48.9090405@reed.com> Message-ID: <4AE35D25.4000509@bennett.com> Don't get so emotional David, it doesn't make you look good. I never said that Cerf and Kahn stole CYCLADES without proper credit; I give examples of the credit they did give in order to prove the line of influence from CYCLADES to TCP/IP, and quoted Cerf on the help that Gerard LeLann provided to the Stanford team. I note that *your* paper doesn't cite Pouzin, which is something that certainly miffed at least one of your co-authors; my sentence is something like "the E2E Args authors didn't seem to have been aware of CYCLADES" which is based on a failure to reference. I think it's unfortunate that the Internet community was already trying to erase Pouzin from history in 1981, when his contribution was so monumental. Let's give credit where it's due. And as I've said already, I think the question of motivation and timing is interesting, and don't claim to know the answer. Seems like this is a good place to ask the question is all. RB David P. Reed wrote: > Since the moderator did not find a problem with Bennett's posting, I > will request his leave to address Bennett's ouvre and in particular > this particular posting in a more direct manner, since he has walked > into this *technical* forum with a variety of outrageous claims > directed at the motives of me and my co-authors. > > On 10/23/2009 11:23 PM, Richard Bennett wrote: >> One of the more interesting unresolved questions about "End-to-End >> Args" is why it was written in the first place. Some people see it as >> a salvo in the ISO protocol wars, others as an attack in BBN's >> ARPANET, some as an attempt to criss the divide between engineering >> and policy, and there are probably other theories as well. > Richard Bennett spends a fair amount of his writing imputing motives > to people, and then using those motives to somehow impugn their > credibility. > The above paragraph is such an example. (Please note that I am just > stating a fact about his writing style. You can read the paper he > submitted for lots of examples. He has also imputed that Vint Cerf > and Bob Kahn "stole" the ideas for the Internet from Pouzin without > proper credit. > > Now I don't know if he can read the minds of Jerry Saltzer, Dave > Clark, or myself in writing the original paper. However the > paragraph quoted above is about the most ridiculous claim I have ever > heard. We wrote the paper as an attempt to contribute to the art of > architecting the Internet, as I believe most of the people on this > list would understand. However, Bennett has no shame. He does, > however act as a troll. >> >> -- Richard Bennett Research Fellow Information Technology and Innovation Foundation Washington, DC From dpreed at reed.com Sat Oct 24 15:39:28 2009 From: dpreed at reed.com (David P. Reed) Date: Sat, 24 Oct 2009 18:39:28 -0400 Subject: [e2e] Protocols breaking the end-to-end argument In-Reply-To: <4AE35B6E.1080801@bennett.com> References: <20091024180015.91FF16BE55B@mercury.lcs.mit.edu> <4AE35B6E.1080801@bennett.com> Message-ID: <4AE38220.7010202@reed.com> I don't know why I waste my time explaining to Richard Bennett what he misreads, but here goes: On 10/24/2009 03:54 PM, Richard Bennett wrote: > > > Noel Chiappa wrote: >> > From: Richard Bennett >> >> > Moors shows that the Saltzer, Reed, and Clark argument for end-to-end >> > placement is both circular and inconsistent with the FTP example that >> > is supposed to demonstrate it. >> >> I didn't see that at all. > Moors points out that TCP error detection and recovery is an > end-system function, but not really an endpoint function in the file > transfer example. The file transfer *application* is the endpoint, so > placing the error detection and recovery function in TCP is actually > putting it in an intermediate system level. This becomes clear when we > recognize that TCP is often implemented in hardware or in firmware > running on a CPU that lives on an interface card. The paper goes to > great lengths to show that host-based TCP is immune to problem induced > at MIT by a bad 1822 interface card, but it was very common > engineering practice in the mid-80s to implement TCP on an interface > card that had the same vulnerability as the 1822 card. Excelan and > Ungermann-Bass built these systems and they were very popular. They > designed in a competent level of data integrity at the bus interface, > so it wasn't necessary to rely on software to detect bus problems. So > it's at least ironic that the end-to-end argument on the data > integrity basis was mooted by practice by the time the 1984 version of > the paper was published. > > Because the file transfer program doesn't do its own data integrity > checking but relies on TCP to do it, it's not really an example of > endpoint placement at all; in fact, it's a "partial implementation". > OK. This is incredibly simple to understand. In the end-to-end argument paper, we describe a program called "careful file transfer", whose goal is to ensure that the file received is a proper copy of the source. We use this "careful file transfer" example as a pedagogical device. The paper carefully does not claim that TCP or FTP over TCP satisfy the end-to-end argument required for the function "careful file transfer". There was a reason: FTP/TCP does not do so. Now, RB claims that Moors's paper somehow says the argument is inconsistent with the FTP example. Well, no. It is consistent with the actual example we use, which is not FTP/TCP. Bennett may have joined late this particular discussion. If so, he missed my earlier posting that said that the end-to-end argument did not say "TCP is best". It was not a defense of TCP at all (unless you accept his mind-reading of the authors' intent to somehow write the paper to be part of some fight that Bennett imagines was going on). The end-to-end argument paper was not a paper about TCP or IP or any particular implementation of any protocol, except insofar as it was inspired by architectural discussions in the design, and was cited quite frequently by IETF architects later as they considered designs happening afterwards. It was about a way to think about architectural questions - one that was used frequently and heavily in the original TCP and IP design process, and as noted in the paper, in a number of other processes we were aware of and had been involved in. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20091024/47ab6aab/attachment.html From dpreed at reed.com Sat Oct 24 15:45:23 2009 From: dpreed at reed.com (David P. Reed) Date: Sat, 24 Oct 2009 18:45:23 -0400 Subject: [e2e] Protocols breaking the end-to-end argument In-Reply-To: <4AE35B6E.1080801@bennett.com> References: <20091024180015.91FF16BE55B@mercury.lcs.mit.edu> <4AE35B6E.1080801@bennett.com> Message-ID: <4AE38383.2030603@reed.com> I can't resist commenting on this: On 10/24/2009 03:54 PM, Richard Bennett wrote: > Like it or not, Noel, there was a lot of friction between the Network > Working Group and BBN over the control BBN had over the ARPANET > protocols inside the IMP. The interesting problems of the day in > protocol design were all behind the curtain to the people who used the > ARPANET, and that's frustrating to engineers. Nobody disagrees that > ARPANET was a huge first step in packet switching; but by 1981, people > were well into the second step, and the closed implementation of the > lower three layers was a problem. This is both irrelevant, and bizarre. Again, Bennett focuses on imputed motivations to impugn people's professional actions. There was no friction that mattered - protocols were not designed to carry out "anger". Since Bennett was not there, I can only assume he is talking to some very angry people who were there. In any case, lecturing Noel Chiappa, who has more experience with the Internet and networking by far seems to be an odd thing to try to do. I'd suggest people look at Bennett's resume at http://www.bennett.com/resume.pdf. You might find his claims that he was responsible for some of the most important IEEE protocols a bit interesting. I take no position on the claims. From richard at bennett.com Sat Oct 24 16:46:42 2009 From: richard at bennett.com (Richard Bennett) Date: Sat, 24 Oct 2009 16:46:42 -0700 Subject: [e2e] Protocols breaking the end-to-end argument In-Reply-To: <4AE38383.2030603@reed.com> References: <20091024180015.91FF16BE55B@mercury.lcs.mit.edu> <4AE35B6E.1080801@bennett.com> <4AE38383.2030603@reed.com> Message-ID: <4AE391E2.80503@bennett.com> As usual, an attempt to discuss ideas in a forum inhabited by David Reed quickly becomes an exercise in scurrilous personal attack; my role in shaping IEEE 802 standards from 1984 to the present is a matter of historical record than be discovered by any conscientious person in a matter of minutes. On the subject of BBN's standing in the early Internet community, I'll simply note that the term "Big Bad Neighbor" was a common usage that I did not coin myself, and Steve Crocker's comments in RFC 1 had a well-understood subtext. RB David P. Reed wrote: > I can't resist commenting on this: > > On 10/24/2009 03:54 PM, Richard Bennett wrote: >> Like it or not, Noel, there was a lot of friction between the Network >> Working Group and BBN over the control BBN had over the ARPANET >> protocols inside the IMP. The interesting problems of the day in >> protocol design were all behind the curtain to the people who used >> the ARPANET, and that's frustrating to engineers. Nobody disagrees >> that ARPANET was a huge first step in packet switching; but by 1981, >> people were well into the second step, and the closed implementation >> of the lower three layers was a problem. > > This is both irrelevant, and bizarre. Again, Bennett focuses on > imputed motivations to impugn people's professional actions. There > was no friction that mattered - protocols were not designed to carry > out "anger". Since Bennett was not there, I can only assume he is > talking to some very angry people who were there. > > In any case, lecturing Noel Chiappa, who has more experience with the > Internet and networking by far seems to be an odd thing to try to do. > I'd suggest people look at Bennett's resume at > http://www.bennett.com/resume.pdf. You might find his claims that he > was responsible for some of the most important IEEE protocols a bit > interesting. I take no position on the claims. -- Richard Bennett Research Fellow Information Technology and Innovation Foundation Washington, DC From richard at bennett.com Sat Oct 24 16:50:50 2009 From: richard at bennett.com (Richard Bennett) Date: Sat, 24 Oct 2009 16:50:50 -0700 Subject: [e2e] Protocols breaking the end-to-end argument In-Reply-To: <4AE38220.7010202@reed.com> References: <20091024180015.91FF16BE55B@mercury.lcs.mit.edu> <4AE35B6E.1080801@bennett.com> <4AE38220.7010202@reed.com> Message-ID: <4AE392DA.2090203@bennett.com> An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20091024/150d45ee/attachment-0001.html From dga+ at cs.cmu.edu Sat Oct 24 18:56:13 2009 From: dga+ at cs.cmu.edu (David Andersen) Date: Sat, 24 Oct 2009 21:56:13 -0400 Subject: [e2e] Protocols breaking the end-to-end argument In-Reply-To: <4AE392DA.2090203@bennett.com> References: <20091024180015.91FF16BE55B@mercury.lcs.mit.edu> <4AE35B6E.1080801@bennett.com> <4AE38220.7010202@reed.com> <4AE392DA.2090203@bennett.com> Message-ID: <4F8DBE3C-E5D5-41D8-9C75-832EFB778A12@cs.cmu.edu> Hi, Richard, and everyone - Having read the e2e argument paper a number of times (I, like half the networking faculty I know, use it as a discussion point in my graduate networks and distributed systems courses), I think it's worth taking a step back from this debate a bit, which has clearly extended beyond the realm of the purely technical. (The preceding paragraph may be taken, correctly, as a doubtless unsuccessful plea to abandon the ad hominem attacks on all sides of this argument in favor of what is, actually, a fun discussion.) In particular, I believe that your argument is taking a (perhaps deliberately) overly strong interpretation of what was actually written in the e2e paper, which makes a somewhat subtle argument that is devoid of absolute black and white insistence about the placement of functionality. This seems like a very common misinterpretation -- it even shows up in the subject of this thread: "breaking" the end-to- end argument, as if it was a law writ in stone by the hand of the Internet Gods. DPR's representation of the e2e argument in this discussion is entirely in keeping with the text of the paper, which included no mention of TCP providing reliability. In fact, it's become increasingly clear over time that a careful file transfer system -- or a careful storage system -- probably has to implement exactly the type of strong error checking alluded to in the e2e paper. See, for instance, a lot of recent work on long-term digital data preservation, or, more commercially, the content-hash based storage systems now provided by major vendors such as EMC. TCP offload does not particularly seem to disagree with the point of the e2e argument, as it was stated. "It would be too simplistic to conclude that the lower levels should play no part in obtaining reliability." and the argument in the paper makes it very clear that there are legitimate performance reasons for performing functions -- even duplicating them -- at lower levels; one should simply make such optimizations with full awareness of the consequences. Offload is a great example: It's a very useful performance enhancement with today's 10GE networks, and it may cause you some difficulties if you want to take advantage of later enhancements to TCP. It's an engineering tradeoff, pure and simple, which is all the "argument" is about. So are 802.11 retransmissions, with which you're undoubtedly familiar. Great, needed performance optimization -- they're an excellent illustration of the "when you _should_ use the middle" aspect of the paper. -Dave Andersen On Oct 24, 2009, at 7:50 PM, Richard Bennett wrote: > There's no doubt about the fact that Saltzer was and still is > regarded as one of the brightest lights in the system architecture > firmament, and that in particular his seminal paper on naming and > addressing was one of the most cogent pieces of its kind ever > written. It's unfortunate that the structure of Saltzer's thinking > isn't reflected in the organization of Internet protocols, naming, > and addressing and that he wasn't able to pass his brilliance along > to all of his students. > > RB > > David P. Reed wrote: >> I don't know why I waste my time explaining to Richard Bennett what >> he misreads, but here goes: >> >> On 10/24/2009 03:54 PM, Richard Bennett wrote: >>> >>> >>> Noel Chiappa wrote: >>>> > From: Richard Bennett >>>> >>>> > Moors shows that the Saltzer, Reed, and Clark argument for >>>> end-to-end >>>> > placement is both circular and inconsistent with the FTP >>>> example that >>>> > is supposed to demonstrate it. >>>> >>>> I didn't see that at all. >>>> >>> Moors points out that TCP error detection and recovery is an end- >>> system function, but not really an endpoint function in the file >>> transfer example. The file transfer *application* is the endpoint, >>> so placing the error detection and recovery function in TCP is >>> actually putting it in an intermediate system level. This becomes >>> clear when we recognize that TCP is often implemented in hardware >>> or in firmware running on a CPU that lives on an interface card. >>> The paper goes to great lengths to show that host-based TCP is >>> immune to problem induced at MIT by a bad 1822 interface card, but >>> it was very common engineering practice in the mid-80s to >>> implement TCP on an interface card that had the same vulnerability >>> as the 1822 card. Excelan and Ungermann-Bass built these systems >>> and they were very popular. They designed in a competent level of >>> data integrity at the bus interface, so it wasn't necessary to >>> rely on software to detect bus problems. So it's at least ironic >>> that the end-to-end argument on the data integrity basis was >>> mooted by practice by the time the 1984 version of the paper was >>> published. >>> >>> Because the file transfer program doesn't do its own data >>> integrity checking but relies on TCP to do it, it's not really an >>> example of endpoint placement at all; in fact, it's a "partial >>> implementation". >>> >> OK. This is incredibly simple to understand. In the end-to-end >> argument paper, we describe a program called "careful file >> transfer", whose goal is to ensure that the file received is a >> proper copy of the source. We use this "careful file transfer" >> example as a pedagogical device. >> >> The paper carefully does not claim that TCP or FTP over TCP satisfy >> the end-to-end argument required for the function "careful file >> transfer". There was a reason: FTP/TCP does not do so. >> >> Now, RB claims that Moors's paper somehow says the argument is >> inconsistent with the FTP example. Well, no. It is consistent >> with the actual example we use, which is not FTP/TCP. >> >> Bennett may have joined late this particular discussion. If so, he >> missed my earlier posting that said that the end-to-end argument >> did not say "TCP is best". It was not a defense of TCP at all >> (unless you accept his mind-reading of the authors' intent to >> somehow write the paper to be part of some fight that Bennett >> imagines was going on). >> >> The end-to-end argument paper was not a paper about TCP or IP or >> any particular implementation of any protocol, except insofar as it >> was inspired by architectural discussions in the design, and was >> cited quite frequently by IETF architects later as they considered >> designs happening afterwards. It was about a way to think about >> architectural questions - one that was used frequently and heavily >> in the original TCP and IP design process, and as noted in the >> paper, in a number of other processes we were aware of and had been >> involved in. >> >> > > -- > Richard Bennett > Research Fellow > Information Technology and Innovation Foundation > Washington, DC > From day at std.com Sat Oct 24 19:16:35 2009 From: day at std.com (John Day) Date: Sat, 24 Oct 2009 22:16:35 -0400 Subject: [e2e] Protocols breaking the end-to-end argument In-Reply-To: <20091024180015.91FF16BE55B@mercury.lcs.mit.edu> References: <20091024180015.91FF16BE55B@mercury.lcs.mit.edu> Message-ID: > > >The reference to the "ISO protocol wars" is completely mystifying, as the >architecture of the ISO stack (at least, the CLNP/TP4 flavour, which was the >subset which gave TCP/IP the best 'run for their money') is basically >identical to that of TCP/IP (modulo disagreements on certain arcane points, >such as exactly what kind of abstract entities the names at the various levels >refer to - a subject wholly unrelated to the end-end debate). Cmon Noel, you know better than that. That was never what the protocol wars were about. It was not a war between CLNP/TP4 and TCP/IP, but a war between (CLNP/TP4; TCP/IP) and X.25. The argument at the time by the PTTs was that a Transport Protocol was unnecessary. Our argument, of course, was that it was absolutely necessary. This was the big argument from about 1976 to 1985. This is primarily what the end-to-end paper discusses and tries to create a "higher moral ground" by creating a more general (and hence more fundamental) principle to base the debate on. It was only later that the unwashed in the IETF turned it into a CLNP vs IP war. Take care, John From jnc at mercury.lcs.mit.edu Sat Oct 24 20:20:10 2009 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sat, 24 Oct 2009 23:20:10 -0400 (EDT) Subject: [e2e] Protocols breaking the end-to-end argument Message-ID: <20091025032010.3B6B56BE5DD@mercury.lcs.mit.edu> Wow, you all have been busy. I'll have to get to some tomorrow, but this one for now... > From: John Day >> The reference to the "ISO protocol wars" is completely mystifying, as >> the architecture of the ISO stack (at least, the CLNP/TP4 flavour, >> which was the subset which gave TCP/IP the best 'run for their money') >> is basically dentical to that of TCP/IP > Cmon Noel, you know better than that. That was never what the protocol > wars were about. >From where you were sitting, perhaps. My view was from a somewhat different locations... :-) Seriously, though, the only protocol war I saw involving ISO was the TCP/IP <-> ISO one - which is covered at some length in Abbabte's excellent book, IIRC. > It was not a war between CLNP/TP4 and TCP/IP, but a war between > (CLNP/TP4; TCP/IP) and X.25. Yes, but even at the time, to some of us that one had all the suspense of the First Zulu War - gee, which is better, spears or repeating rifles? Doesn't take a surfeit of brain cells to call that one.. > The argument at the time by the PTTs was that a Transport Protocol was > unnecessary. Our argument, of course, was that it was absolutely > necessary. This was the big argument from about 1976 to 1985. This is > primarily what the end-to-end paper discusses Yeah, but the reason TCP/IP clobbered X.25 had not much, I feel pretty sure, to do with the inherent fundamentals of virtual circuits versus datagrams. To me, the whole X.25 world was badly crippled by the whole X.75 (I think it was X.75 - you can correct me if I've mis-remembered) mess that you had to use if you wanted to set up a VC that spanned a number of providers. TCP/IP and CLNP/TP4 (hereinafter, 'The Datagrams') never had to deal with that - in large part because they were designed from the get-go to span multiple providers as easily as they spanned a single one. My perception is that X.75 happened, in large part, because it was an add-on to a legacy, X.25, which was designed for single-provider networks. Of course, one could say that that was inherent, because 'of course' to span multiple provider networks you'd have to a mechanism to connect VC's together, but I'm not so sure; it should have been possible to have a single unified VC 'network' that spanned multiple providers - but of course the internal protocols (for acknowledgement, etc) would have had to have been standardized, so they could operate on an inter-provider basis. But to me even that wasn't even the biggest handicap for X.25. The Datagrams were set up pretty much from the get-go to work across a range of technologies, including local area networks - and I claim it was the Datagrams' friendliness to LANs which was the real 'killer app' in the X.25 <-> Datagram war. Of course, one could say that again, this was 'inherent' in the architectures - but again, I'm not so sure; had a VC protocol been designed _from the start_ to work well across a variety of media, including LANs, it would probably have been considerably more LAN-friendly. It was the 'boat anchor' of the pre-LAN design of X.25, which the PTTs/etc couldn't or wouldn't discard (because of installed base, existing software, and brain, code, etc), that was the real killer of the X.25 dinosaurs in a world of LAN mammals. So I don't think X.25 vs The Datagrams was really a 'fair' test of the fundamental pros and cons of VCs and datagrams: X.25 versus The Datagrams was more like a rusty, bent, dull assegai versus the latest AR-15 - hardly a fair test of the fundamentals. > tries to create a "higher moral ground" by creating a more general > (and hence more fundamental) principle to base the debate on. Maybe my brain is fading, but my memory is that the trio were more interested in a design philosophy framework for designing protocols in a basically datagram environment; bringing more firepower to the VC/datagram debate was not at all of much interest. Again, to us, at the time, VC's had all the interest of rotationally optimizing assemblers - clearly a technology which the march of improvement had overtaken. > It was only later that the unwashed in the IETF turned it into a CLNP > vs IP war. Read Abbate; TCP/IP versus CLNP/TP4 was a real set-to. As a TCP/IP backer, I was far more worried about CLNP/TP4 than I ever was about X.25, which was clearly a rusty assegai in a world of repeating rifles. Unwashedly yours, :-) Noel From day at std.com Sat Oct 24 20:31:12 2009 From: day at std.com (John Day) Date: Sat, 24 Oct 2009 23:31:12 -0400 Subject: [e2e] Protocols breaking the end-to-end argument In-Reply-To: <20091024180015.91FF16BE55B@mercury.lcs.mit.edu> References: <20091024180015.91FF16BE55B@mercury.lcs.mit.edu> Message-ID: > > >The reference to the "ISO protocol wars" is completely mystifying, as the >architecture of the ISO stack (at least, the CLNP/TP4 flavour, which was the >subset which gave TCP/IP the best 'run for their money') is basically >identical to that of TCP/IP (modulo disagreements on certain arcane points, >such as exactly what kind of abstract entities the names at the various levels >refer to - a subject wholly unrelated to the end-end debate). And to add to my previous note, CLNP didn't even exist when the e2e paer was written. From day at std.com Sat Oct 24 20:48:00 2009 From: day at std.com (John Day) Date: Sat, 24 Oct 2009 23:48:00 -0400 Subject: [e2e] Protocols breaking the end-to-end argument In-Reply-To: <20091025032010.3B6B56BE5DD@mercury.lcs.mit.edu> References: <20091025032010.3B6B56BE5DD@mercury.lcs.mit.edu> Message-ID: > > >Read Abbate; TCP/IP versus CLNP/TP4 was a real set-to. As a TCP/IP backer, I >was far more worried about CLNP/TP4 than I ever was about X.25, which was >clearly a rusty assegai in a world of repeating rifles. Read Abbate? You must be kidding. Why would I use 3rd hand sources? You seem to forget, I was there. Starting with getting datagrams in the first X.25 Recommendations (1976) thru the fight to get connectionless into OSI. The debates around the IONL, getting CLNP done, ensuring that it named the node so it would be a true Internet protocol rather than a subnet protocol masquerading as an Internet protocol. As I said before, in 1982 there was no CLNP. In fact, TP4 didn't exist either accept as a revised draft of INWG 96/ CYCLADES TS. The connectionless addendum to ISO Reference Model wouldn't even be approved as a draft for another year. It seems that you and Abbate have been looking in the wrong end of the telescope. It would be a little hard for the e2e paper in 1982 to be about the CLNP/TP4 vs TCP/IP debate if half the debate didn't exist. > Unwashedly yours, :-) > > Noel From jnc at mercury.lcs.mit.edu Sat Oct 24 20:59:04 2009 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sat, 24 Oct 2009 23:59:04 -0400 (EDT) Subject: [e2e] Protocols breaking the end-to-end argument Message-ID: <20091025035904.356D26BE5DF@mercury.lcs.mit.edu> > From: John Day > It would be a little hard for the e2e paper in 1982 to be about the > CLNP/TP4 vs TCP/IP debate if half the debate didn't exist. Umm, I didn't say that the E2E paper was about the CLNP/TP4 vs TCP/IP 'debate' (competition would be more accurate, I think). You seem to be conflating my comments on two entirely separate points. One was that for _some_ of us, the only 'ISO protocol war' we saw was the CLNP/TP4 vs TCP/IP competition. The other was that the E2E paper was not principally intended as firepower in the TCP/IP vs X.25 debate, but rather was more intended to be exactly what the passage of time has shown it to be - a contemplation of the underlying fundamentals of functionality placement, one which would be of lasting value. Noel From william.allen.simpson at gmail.com Sun Oct 25 01:29:30 2009 From: william.allen.simpson at gmail.com (William Allen Simpson) Date: Sun, 25 Oct 2009 04:29:30 -0400 Subject: [e2e] Protocols breaking the end-to-end argument In-Reply-To: <20091025035904.356D26BE5DF@mercury.lcs.mit.edu> References: <20091025035904.356D26BE5DF@mercury.lcs.mit.edu> Message-ID: <4AE40C6A.4060608@gmail.com> Noel Chiappa wrote: > One was that for _some_ of us, the only 'ISO protocol war' we saw was the > CLNP/TP4 vs TCP/IP competition. > As an implementor during that period, I have to agree with Noel. Back in the late '70s, we used X.25 for transmission because that's the only thing that AT&T (via Telenet, with an 'e') would sell us. For satellite data to move from field stations, as a practical matter we were constrained by availability. Just as weather data only came in 5-bit baudot coding. I programmed a dedicated Alpha Micro (in reality, a minicomputer) to translate to 7-bit ASCII. Then, to move it from the Alpha Micro to the Perkin-Elmer Interdata 7/16, I used IBM bisync. Before I'd ever heard of TCP/IP, I simply rolled my own "higher level" packet format, to have a commonality over both X.25 and bisync. But it was clear that had to have its own checksum. Folks seem to forget that I-O buses were very unreliable. Corrupted data and dropped interrupts were common. An independent transmission layer was crucial. As I've mentioned recently, it wasn't until later that Merit decided to implement TCP/IP. Remember, Merit had its own protocol stack as far back as the '60s. ARPA was a relative late-comer around here.... It wasn't until CLNP that I ever perceived a 'war' (or competition). To me, it was always apparent that the war wasn't with the protocols per se, but rather the corporate entities that wanted to control pricing. When I worked on Michigan's NSFnet bid, we took the money from state budget line items that were using ISO protocols. To the politicians, the potential savings over dedicated telco lines were a big plus. We were still in the aftermath of the Reagan Recession. And that was another element that is often overlooked. I know this is less relevant outside the US, but the ISO corporate proponents were primarily Republicans. The NSFnet proponents were primarily Democrats, who were very interested in competition, cost savings, and leveling the playing field. > The other was that the E2E paper was not principally intended as firepower in > the TCP/IP vs X.25 debate, but rather was more intended to be exactly what > the passage of time has shown it to be - a contemplation of the underlying > fundamentals of functionality placement, one which would be of lasting value. > Admittedly, I didn't read the paper until much later, so it had little influence on my thinking. I vaguely remember a "well, duh" reaction, as surely every implementor in the field already knew from experience. But it has continued as an enduring touchstone to help explain these fundamentals to successive generations. From Jon.Crowcroft at cl.cam.ac.uk Sun Oct 25 02:40:00 2009 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Sun, 25 Oct 2009 09:40:00 +0000 Subject: [e2e] Protocols breaking the end-to-end argument In-Reply-To: References: <20091024180015.91FF16BE55B@mercury.lcs.mit.edu> Message-ID: This is exactly right - UCL were very much at the "centre" of this at the turning point (turning of NCP and on TCP/IP) and relaying from the new internet world to/from the X.25 (and other) worlds - The CLNP/TP4 paer of the ISO thing came to a small degree from the DEC (whose ideas show up again later in TCP congestion control and later still in ECN) which was a computer science approach to networking, not telco at all. The "war" was between telco (connection oriented, reliable, ordered) and computer science (connectionless, best effort) on the one hand 1. Sheer complicatedness of X.25 (both on paper and in reality) made it hard to get right, and the lack of losses on newer links (LANs) + X.25 interpretations and implmentations' failure to mask dynamic routing from transport, and therefore from applications, meant it was no longer justifiable to build such complicated networks which were also getting cheaper, albeit slowly. on the other 2. Increase in end system capability (e.g. mini computers like PDPs and LSIs, and shortly after that, workstations) meant, contrariwise, the end system effort in TCP was justifiable. likewise 3. A little too late, some smart switch people build x.25 systems that did VC on the edge, but datagrams within and went fast, but missed the curve (e.g. netcom switches). Some of those people showed up again doing ATM (e.g. ipsilon), understanding a VC service, but internal dynamics with pnni etc might work - again a little too late (and cell switching didn't have the switch speed up/cost reduction they needed to beat routers) TP4 (which my colleagues did experiments with) was a neat piece of design, but has nothing much to do with any of the main protocol wars ... The other war story people might be getting confused by when mentioning CLNP is the IPng NSAP/CLNP fiasco... again not part of the e2e arguments part of ISO v. DARPA but its own later skirmish between newer players. To be strictly fair then, while the bogey man in many a tee-shirt slogan was ISO, it was the ITU (or CCITT as was) and the telco mind set that was connection oriented networking (with reliable link and network service) specifically that was the focus of that "war" or as I prefer to see it, a debate that played out in markets and in operations - Everyone has their own particular turning point tale I'm sure, but when we built the "shoestring" IP service for UK academics, this was a clear point for me that we were able to make the particular end2end choice visible Around that time too, various governments turned off their default GOSIP (government OSI procurement) policies... Much has flowed over many bridges since then:-) A sad recent error has been EU statements that everyone doing next gen internet research should be trying to converge on IPv6, but that's a whole other rant... cheers j. In missive , John Day typed: >>It was not a war between CLNP/TP4 and TCP/IP, but a war between >>(CLNP/TP4; TCP/IP) and X.25. The argument at the time by the PTTs >>was that a Transport Protocol was unnecessary. Our argument, of >>course, was that it was absolutely necessary. This was the big >>argument from about 1976 to 1985. This is primarily what the >>end-to-end paper discusses and tries to create a "higher moral >>ground" by creating a more general (and hence more fundamental) >>principle to base the debate on. >> >>It was only later that the unwashed in the IETF turned it into a CLNP >>vs IP war. >> >>Take care, >>John cheers jon From day at std.com Sun Oct 25 04:55:57 2009 From: day at std.com (John Day) Date: Sun, 25 Oct 2009 07:55:57 -0400 Subject: [e2e] Protocols breaking the end-to-end argument In-Reply-To: <20091025035904.356D26BE5DF@mercury.lcs.mit.edu> References: <20091025035904.356D26BE5DF@mercury.lcs.mit.edu> Message-ID: At 23:59 -0400 2009/10/24, Noel Chiappa wrote: > > From: John Day > > > It would be a little hard for the e2e paper in 1982 to be about the > > CLNP/TP4 vs TCP/IP debate if half the debate didn't exist. > >Umm, I didn't say that the E2E paper was about the CLNP/TP4 vs TCP/IP 'debate' >(competition would be more accurate, I think). You seem to be conflating my >comments on two entirely separate points. No, you are the one who is conflating. The original point that I made was about the context in which the e2e paper was written.What was happening leading up to it. > >One was that for _some_ of us, the only 'ISO protocol war' we saw was the >CLNP/TP4 vs TCP/IP competition. This may be how it appeared in your corner of the world and when you appeared in the discussion. By the time you got to MIT, this had been going on for some time. The protocol wars began in 1975 (or thereabouts) when we learned that CCITT was developing X.25 and we tried to get datagrams put it into it. In fact, the TCP vs "TP4", i.e. CYCLADES TS, debate had been over for 4 years at that point. THAT debate had been carried out between 1974 and late 1977 in IFIP WG6.1 (INWG) where several Transport protocols (not just those two) were discussed and analyzed. WG6.1 was managing at least a couple of meetings a year at that time. There were many participants from the US (APRANet/Internet) and Europe. The result was INWG96 published at Danthine's conference in early 1978. As far as we were concerned that ended the transport protocol discussion. (Note that INWG 96 was authored by people from all sides of the discussion: Cerf (Internet), MacKenzie (Internet), Scantlebury (NPL), and Zimmermann (INRIA). As far as we were concerned there never was a TCP/TP4 war, that issue was resolved before the standards battles started in earnest. Of course, now we know that neither was the best choice and that delta-t was far superior to both. As far as the "IP" discussion, we were pretty happy with that. The only things we knew we needed to do for a world wide protocol was a bigger address field and fix the problem that had arisen in 1972 with Tinker AFB. We needed to name the node rather than the interface. No one saw this as a big deal. XNS, CYCLADES, DECNet, EUNet had all done that. (I always contend that the ARPANET didn't so much get it wrong as we had a lot of other things to worry about and it was first.) This is why I was so shocked when the IETF refused to name the node in 1992. We had known about the issue for 20 years. Everyone else had by then fixed it. That was when it became clear that the IETF had become more a craft guild than an engineering group and relied more stock in tradition. Actually, it had begun before that but as they say the third time is the charm. But again here we were still to attached to the beads-on-a-string model that we thought we had refuted. There was a further simplification that we couldn't see at that point. > >The other was that the E2E paper was not principally intended as firepower in >the TCP/IP vs X.25 debate, but rather was more intended to be exactly what >the passage of time has shown it to be - a contemplation of the underlying >fundamentals of functionality placement, one which would be of lasting value. It certainly spends a lot of space arguing that point. In fact, in the period leading up to its publication what other issue of what to put in the network vs the hosts was being debated? As I said, I have always seen the e2e paper as an attempt to create a more general principle to refute that hop-by-hop error control could supplant e2e error control. And by having a more general principle that when other things were proposed for "in the network" there would be something we could point to. I am afraid that your (and Abbate's) perspective on what game was afoot was very narrow and taken out of context with the war as a whole. From dpreed at reed.com Sun Oct 25 05:16:03 2009 From: dpreed at reed.com (David P. Reed) Date: Sun, 25 Oct 2009 08:16:03 -0400 Subject: [e2e] Protocols breaking the end-to-end argument In-Reply-To: <20091025035904.356D26BE5DF@mercury.lcs.mit.edu> References: <20091025035904.356D26BE5DF@mercury.lcs.mit.edu> Message-ID: <4AE44183.80908@reed.com> On 10/24/2009 11:59 PM, Noel Chiappa wrote: > > From: John Day > > > It would be a little hard for the e2e paper in 1982 to be about the > > CLNP/TP4 vs TCP/IP debate if half the debate didn't exist. > > Umm, I didn't say that the E2E paper was about the CLNP/TP4 vs TCP/IP 'debate' > The end-to-end paper was not written to be a part of any war whatsoever. I say that with knowledge of all of the 3 co-authors' intents and motivations. I *now* am beginning to understand what mentality seems to be behind Bennett's informants' views of history. It's an oddly American cultural thing to identify evolutionary and economic competitions as "wars". We have the "war on drugs", for example. Somehow the "wars" become ends in themselves: winnning vs. losing. But studying the competitions rarely provides insight into real issues. Did the Battle of Gettysburg really tell us anything about either the causes: an economy based on human slavery and "free market" ideals (the American plantation south) vs. an economy based on industrialization, internal market growth, and protectionist/imperialist approaches (the American northeast)? (who won that battle didn't even stop the argument...) Did the Battle of Gettysburg predict the creation of "Jim Crow laws"? Did it prevent them? I do remember a wide variety of battles about elements of networking, including implementations of architectures. I briefly was involved in the "token ring" vs. "bus" argument about physical infrastructure for LANs - not as an advocate of either side - and I found it completely bizarre. The idea on the "token ring" side was that somehow its puissant "quality of service" would make the end-to-end communications work, while the "unreliable" CSMA/CD would never be "carrier grade". Bushwah - and I gently pointed that out in my portion of the original paper I wrote about LANs with Clark and Pogran for IEEE Proceedings: LANs would be parts of internets, and the QoS properties of a single LAN would not transcend that LAN's scope. That argument was an implied end-to-end argument: if you want to get a specific service quality goal satisfied, putting the implementation of that function in (every part of every one of the) subnetworks is not a good design. However, one can imagine achieving it that way. The resulting architecture would be very inflexible, and costly to all of those who *don't* need that particular extreme service quality goal. It would, for example, make it hard to migrate the path of any communication while it is happening. In any case, the rather silly battle over CSMA/CD vs. token-controlled access was pretty meaningless in the context of any kind of internetworking: PUP or TCP or even the Cyclades thing. But the "QoS" logic of that day pervades the debate even now. It's so easy for those who don't build networks to wave their hands and say that (for example) Verizon can provide QoS on the Internet, when what is meant is that Verizon provides some latency control on *it's small segment of the path* to all interesting endpoints. This is a rhetorical device called synecdoche - in which the attributes of a part are assumed to carry through to the whole. The idea that Verizon can create QoS for the Internet by creating QoS for its part is a logical fallacy. But it is one that humans continue to fall prey to. So to summarize this longer diversion: the war between token ring and bus-Ethernet teaches us little, and subsequent success of Ethernet as a term teaches us very little about architecture: in fact, by shrinking the collision domain to a hub, and then later replacing it with a switch in the core, the Ethernet has moved towards the deterministic arbitrated structure of the token ring, along with the manageability of the "star-shaped" ring concept that Saltzer promoted as the topology. So let's not study wars and battles. Let's study architectural principles and their application. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20091025/63404022/attachment.html From dpreed at reed.com Sun Oct 25 05:43:24 2009 From: dpreed at reed.com (David P. Reed) Date: Sun, 25 Oct 2009 08:43:24 -0400 Subject: [e2e] Protocols breaking the end-to-end argument In-Reply-To: References: <20091025035904.356D26BE5DF@mercury.lcs.mit.edu> Message-ID: <4AE447EC.7010301@reed.com> On 10/25/2009 07:55 AM, John Day wrote: >> The other was that the E2E paper was not principally intended as >> firepower in >> the TCP/IP vs X.25 debate, but rather was more intended to be exactly >> what >> the passage of time has shown it to be - a contemplation of the >> underlying >> fundamentals of functionality placement, one which would be of >> lasting value. > > It certainly spends a lot of space arguing that point. In fact, in > the period leading up to its publication what other issue of what to > put in the network vs the hosts was being debated? I always find the logic of this sort amazing: in my rhetoric class it was called "post hoc, ergo propter hoc" argumentation. That is: because X happened and it appeared to support Y, then Y was the reason X happened. ("this was the result, therefore this was the reason") John Day asks the question "what other issue" to replace actual exploration. Since there have been numerous times in the past when he could have just asked Jerry, Dave, or me, yet he persists in his belief, perhaps he has some reason to imply that we would not tell him why we wrote the paper. In fact, we have made a variety of statements as to why we wrote it, in informal but public places. Yet he holds onto a belief. Now in some circles the desire to hold onto a belief about others' actions and motivations despite overwhelming evidence to the contrary is understood to come close to that of conspiracy theorists. I don't understand Day's obsession with this point. Since it has infected Richard Bennett's writings, and is being repeated to the FCC in policy debates supported by his "think tank" employer, it probably should be recognized for what it is: a false belief. > As I said, I have always seen the e2e paper as an attempt to create a > more general principle to refute that hop-by-hop error control could > supplant e2e error control. And by having a more general principle > that when other things were proposed for "in the network" there would > be something we could point to. > > I am afraid that your (and Abbate's) perspective on what game was > afoot was very narrow and taken out of context with the war as a whole. > From mateosj at tcd.ie Sun Oct 25 06:00:12 2009 From: mateosj at tcd.ie (Jaime Mateos) Date: Sun, 25 Oct 2009 13:00:12 +0000 Subject: [e2e] Protocols breaking the end-to-end argument In-Reply-To: References: <20091024180015.91FF16BE55B@mercury.lcs.mit.edu> Message-ID: <4AE44BDC.2050704@tcd.ie> Jon Crowcroft wrote: > A sad recent error has been > EU statements that everyone doing > next gen internet research should be > trying to converge on IPv6, but > that's a whole other rant... > > > That's a rant I'm interested about. Where in your opinion does IPv6, specially features such as flow label support, fit in the end to end argument? From Jon.Crowcroft at cl.cam.ac.uk Sun Oct 25 06:25:38 2009 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Sun, 25 Oct 2009 13:25:38 +0000 Subject: [e2e] Protocols breaking the end-to-end argument In-Reply-To: <4AE44BDC.2050704@tcd.ie> References: <20091024180015.91FF16BE55B@mercury.lcs.mit.edu> <4AE44BDC.2050704@tcd.ie> Message-ID: ok, as you asked. but this is euro-centric so others on the list might not want to read on... the next gen research programmes should be about ideas that will postdate the internet - IPv6 is, errm, around ~15 year old idea - A few things came along in the last 15, 10, 5 years that are already stressing out the basics - of the entire type of networking that the subject line discussion is about... Lots of people can make their lists, but in no particular order, my problem with the entire approach to nets predicated on packets and links and nodes comes out of the pressure from 1. trying to do multihop, multiantennae radios 2. dealing with net coding 3. dealing with a future pretty soon now where there are 10 billion mobile devices and because of critical infrastructure, we want to be organisationally (and not just topo/geo) multihomed, and multipath (for resiliance of access and flow resilience) 4. Coping with sub-lambda multiplexing on 100Gbps optical paths... is another strange vector (I suppose gMPLS afficionados believe they have this one under control, but I don't) This had already start to creep in with the internet of things, (sorry, I know thats just buzzword) social nets, and content centric networking... But new paradigms for traffic patterns loosely starting with content based networking, now with very large scale rendezvous of user contributed media and user interest... The tension between authentic source identification, (and sink), provenance of content, and the requirements for privacy, also puts a lot of pressure on the net and application architecture particularly when the matchmaking indixes for this stuff have to be rebuilt faster and faster (see what fb, imdb, amazon, etc etc) have to do every night:) (so they can get their targetted advertisement revenue that lets us all use this stuff so cheap) So where is the action? That would be telling:-) Flow labs and end-to-end arguments? well, I guess what I am trying to say above is that we are rapdily seeing the sublimation of the entire naive idea of an "end point" in network, transport and application terms so I can't answer your specific query... cheers In missive <4AE44BDC.2050704 at tcd.ie>, Jaime Mateos typed: >>Jon Crowcroft wrote: >>> A sad recent error has been >>> EU statements that everyone doing >>> next gen internet research should be >>> trying to converge on IPv6, but >>> that's a whole other rant... >>> >>> >>> >> >>That's a rant I'm interested about. Where in your opinion does IPv6, >>specially features such as flow label support, fit in the end to end >>argument? cheers jon From mateosj at tcd.ie Sun Oct 25 07:15:54 2009 From: mateosj at tcd.ie (Jaime Mateos) Date: Sun, 25 Oct 2009 14:15:54 +0000 Subject: [e2e] Protocols breaking the end-to-end argument In-Reply-To: References: <20091024180015.91FF16BE55B@mercury.lcs.mit.edu> <4AE44BDC.2050704@tcd.ie> Message-ID: <4AE45D9A.7030808@tcd.ie> Jon Crowcroft wrote: > Flow labs and end-to-end arguments? > well, I guess what I am trying to say above > is that we are rapdily seeing the sublimation > of the entire naive idea of an "end point" > in network, transport and application terms > so I can't answer your specific query... > > Do you mean we need to redefine the "end points" beyond the conventional meaning of hosts, but keep applying the end to end argument with its bias towards simpler, more flexible networks; or that we should do away with end to end, and recognize that the new demands/pressures you list above can only be met with network based protocols? Cheers, Jaime From jnc at mercury.lcs.mit.edu Sun Oct 25 08:03:03 2009 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sun, 25 Oct 2009 11:03:03 -0400 (EDT) Subject: [e2e] Protocols breaking the end-to-end argument Message-ID: <20091025150303.B2AB16BE563@mercury.lcs.mit.edu> [Apologies to all for dipping backwards a ways into the stream, but this message contained what I felt was an important point to take on, and I didn't have time/energy to do so last night.] > From: Richard Bennett >>> Moors shows that the Saltzer, Reed, and Clark argument for end-to-end >>> placement is both circular and inconsistent with the FTP example that >>> is supposed to demonstrate it. >> I didn't see that at all. > Moors points out that TCP error detection and recovery is an end-system > function, but not really an endpoint function in the file transfer > example. This is all true, but I still don't see (for reasons such as that the real-world FTP isn't the 'reliable FTP' the paper talks about) that it amounts to "[the] argument for end-to-end placement is both circular and inconsistent with the .. example that is supposed to demonstrate it", which is what I disagreed with. But this is not important, I would prefer to move on to a more important point. >>> One of the more interesting unresolved questions about "End-to-End >>> Args" is why it was written in the first place. Some people see it as >>> a salvo in the ISO protocol wars, others as an attack in BBN's >>> ARPANET, some as an attempt to criss the divide between engineering >>> and policy >> I don't know whether to be amused or outraged by this nonsense. > I don't know why this question should get anybody upset, it's just a > question about the context and motivation of the paper in the first > place. The problem is that it's like asking why Einstein wrote his thermionic emissions paper. Even in a purely 'history of science' way, this question is orders of magnitude less important than the question of the correctness of the technical content itself. And hoping that knowing exactly (even if one could know such a thing) _why_ it was written will tell you _anything_ about how correct it is, in and of itself, is utterly misguided. Down that path lies "Transgressing the Boundaries: Toward a Transformative Hermeneutics of Quantum Gravity". To even bring the question of 'why was it written' up in a discussion about the correctness of the technical content is, in a sense, to attack the very ideals of technical debate, which is _supposed_ to focus on the technical content, and leave all else (including people, and motivations), out of it. > None of the authors was part of the inner circle of the Internet > protocol design at the time the paper was written, although Clark was > either the Chief Architect of the Internet or on his way to becoming > same. Say what? Reed was still deeply involved in Internet work at that point (he'd been one of the people making the case to split TCP up into IP and TCP), as was Clark (who was writing prototype TCP code, and papers based on the lessons he learned doing so). And the two of them were extremely close professional colleagues of Saltzer, with offices basically next door to each other on the 5th floor. And although Jerry didn't go to meetings or write code, as a key member of that research group, he was definitely thinking about the things the rest were working on - as can be seen by his other papers from that time period. > I would have expected Cerf and Kahn to write something explaining the > architectural decisions they made in adapting the framework to their > system I don't know Vint well enough to say with any confidence, but to hazard a guess, but that kind of deep design philosophy thing just doesn't seem like the kind of thing he'd go for - I think his focus was at a different level. > Why these three people and why this particular time? Why them? Because they were very close professional colleagues who habitually thought at that level (i.e. design philosophy). Why then? Because at that point they'd been thinking about networking for a while, and had gotten to the point where they could usefully apply the kind of systems architecture analysis that group was known for. > It's never been explained. The fact that you could even bother to ask that question, or think that the answer is of any interest other than in a 'history of science' way, is very illuminating. > there was a lot of friction between the Network Working Group and BBN > over the control BBN had over the ARPANET protocols inside the IMP. Sure, but that was long before the period when 'End-End Arguments' was being turned out. > The interesting problems of the day in protocol design were all behind > the curtain to the people who used the ARPANET, and that's frustrating > to engineers. ... by 1981, people were well into the second step, and > the closed implementation of the lower three layers was a problem. Huh? Even by 1978 the people active in the Internet project treated the ARPANet as a black box which we didn't really have much interest in, and didn't really concern ourselves with it. Frankly, for most of us, we were up to our asses in alligators getting all these various new technologies (LANs, etc) up and running, and didn't have a lot of time to worry about anything else anyway. What little time we did have for deep thinking went to things like how to better organize OS software to deal with networking, etc, etc. Noel From jnc at mercury.lcs.mit.edu Sun Oct 25 08:24:34 2009 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sun, 25 Oct 2009 11:24:34 -0400 (EDT) Subject: [e2e] Protocols breaking the end-to-end argument Message-ID: <20091025152434.F2C916BE565@mercury.lcs.mit.edu> > From: John Day > This is why I was so shocked when the IETF refused to name the node in > 1992. ... That was when it became clear that the IETF had become more a > craft guild than an engineering group and relied more stock in > tradition. Some of us still have the scars on our foreheads from that one... :-) > There was a further simplification that we couldn't see at that point. To get back to actual technical content, that would be...? (I'm sure it's obvious, but it's not coming up for me...) Noel From jnc at mercury.lcs.mit.edu Sun Oct 25 08:44:14 2009 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sun, 25 Oct 2009 11:44:14 -0400 (EDT) Subject: [e2e] Protocols breaking the end-to-end argument Message-ID: <20091025154414.D29126BE56B@mercury.lcs.mit.edu> > From: Richard Bennett > On the subject of BBN's standing in the early Internet community, I'll > simply note that the term "Big Bad Neighbor" was a common usage that I > did not coin myself, and Steve Crocker's comments in RFC 1 had a > well-understood subtext. I think you're confusing the "early Internet community" with the 'early ARPANet community'. The view of the various divisions at BBN (since at one point the Internet work was being done in a different division of BBN from that responsible for the ARPANet) by other workers in the early Internet community was a complex, and hence lengthy, one - and also off-scope for this list (may I suggest the 'Internet-history' list if you really want to explore the topic). It seems to me that the 'end-end design ideas' have gotten mixed up in what is, at the bottom, a fight over how to divide up the economic pie of communication networks. This is not an unknown occurrence - scientific work on things like the size of the Artic ice-sheet, and discovery of new fossil species, has equally become wound up in disputes which are far larger. I don't have any pithy response to that, and any longer comment would also be off-topic, so I will simply make the observation and leave it there. Noel From dpsmiles at gmail.com Sun Oct 25 09:02:28 2009 From: dpsmiles at gmail.com (Durga Prasad Pandey) Date: Sun, 25 Oct 2009 09:02:28 -0700 Subject: [e2e] Protocols breaking the end-to-end argument In-Reply-To: <4AE35B6E.1080801@bennett.com> References: <20091024180015.91FF16BE55B@mercury.lcs.mit.edu> <4AE35B6E.1080801@bennett.com> Message-ID: <928807280910250902s473e3e4bq95b7a8895471a615@mail.gmail.com> On Sat, Oct 24, 2009 at 12:54 PM, Richard Bennett wrote: > I don't know why this question should get anybody upset, it's just a > question about the context and motivation of the paper in the first place. > None of the authors was part of the inner circle of the Internet protocol > design at the time the paper was written, although Clark was either the > Chief Architect of the Internet or on his way to becoming same. I would have > expected Cerf and Kahn to write something explaining the architectural > decisions they made in adapting the ?framework to their system, but their > failure to do so meant someone else had to do it. Why these three people and > why this particular time? It's never been explained. RB, Is your next email going to be about(humor me..) how a secret underground cult (now called NASA) funded a young clerk called Einstein to produce theories of relativity so they could "stage" the spage age and eventually perform a cultish ritual on the moon? (Actually I could have sold this storyline to Dan Brown for gazillions of dollars.) You quite obviously love conspiracy theories + juicy gossip and were probably looking for some in your first email on this thread. Now you are going to ridiculous lengths to explain yourself. :) > Why these three people and why this particular time? It's never been explained. This is a flagship question of conspiracy theorists. You ask: >>One of the more interesting unresolved questions about "End-to-End Args" is why it was written in the first place. Some people see it as a salvo in the ISO protocol wars, others as an attack in BBN's >>ARPANET, some as an attempt to criss the divide between engineering and policy, and there are probably other theories as well. Conspiracy theories you mean? One could ask these questions of almost any paper ever published. The subtle thing they do is gently cast aspersions on the authors' motivations. That's not a good thing to be trying to do. The one good thing that your questions did is provoke detailed responses from different people, some of which were very informative to me(having been conceived well after TCP/IP, I do not have the unique historical experience a lot of people on this list do). I liked Dave Anderson's summary of the e2e paper too. Durga From L.Wood at surrey.ac.uk Sun Oct 25 09:10:11 2009 From: L.Wood at surrey.ac.uk (L.Wood@surrey.ac.uk) Date: Sun, 25 Oct 2009 16:10:11 -0000 Subject: [e2e] Protocols breaking the end-to-end argument References: <20091025035904.356D26BE5DF@mercury.lcs.mit.edu> <4AE44183.80908@reed.com> Message-ID: <4835AFD53A246A40A3B8DA85D658C4BE01368B23@EVS-EC1-NODE4.surrey.ac.uk> > So let's not study wars and battles. Let's study architectural > principles and their application. So it is a principle after all, then? (It strikes me that if one is aspiring to be Darwin one shouldn't also have to be Dawkins.) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20091025/01a7f636/attachment.html From dpsmiles at gmail.com Sun Oct 25 09:18:25 2009 From: dpsmiles at gmail.com (Durga Prasad Pandey) Date: Sun, 25 Oct 2009 09:18:25 -0700 Subject: [e2e] Protocols breaking the end-to-end argument In-Reply-To: <928807280910250902s473e3e4bq95b7a8895471a615@mail.gmail.com> References: <20091024180015.91FF16BE55B@mercury.lcs.mit.edu> <4AE35B6E.1080801@bennett.com> <928807280910250902s473e3e4bq95b7a8895471a615@mail.gmail.com> Message-ID: <928807280910250918p1eaeafffx9dad624f6186efde@mail.gmail.com> Actually, after having read Noel's latest email, I realize my email was redundant(he articulated all I meant to say, and more, much more, umm, articulately..). Though I love the coincidence in reference to Einstein. (btw, coincidences are fertile grounds for conspiracy theories!). On Sun, Oct 25, 2009 at 9:02 AM, Durga Prasad Pandey wrote: > On Sat, Oct 24, 2009 at 12:54 PM, Richard Bennett wrote: > >> I don't know why this question should get anybody upset, it's just a >> question about the context and motivation of the paper in the first place. >> None of the authors was part of the inner circle of the Internet protocol >> design at the time the paper was written, although Clark was either the >> Chief Architect of the Internet or on his way to becoming same. I would have >> expected Cerf and Kahn to write something explaining the architectural >> decisions they made in adapting the ?framework to their system, but their >> failure to do so meant someone else had to do it. Why these three people and >> why this particular time? It's never been explained. > > RB, > > Is your next email going to be about(humor me..) how a secret > underground cult (now called NASA) funded a young clerk called > Einstein to produce theories of relativity so they could "stage" the > spage age and eventually perform a cultish ritual on the moon? > (Actually I could have sold this storyline to Dan Brown for gazillions > of dollars.) > > You quite obviously love conspiracy theories + juicy gossip and were > probably looking for some in your first email on this thread. Now you > are going to ridiculous lengths to explain yourself. ?:) > >> Why these three people and why this particular time? It's never been explained. > > This is a flagship question of conspiracy theorists. > > You ask: > >>>One of the more interesting unresolved questions about "End-to-End Args" is why it was written in the first place. Some people see it as a salvo in the ISO protocol wars, others as an attack in BBN's >>ARPANET, some as an attempt to criss the divide between engineering and policy, and there are probably other theories as well. > > Conspiracy theories you mean? > > One could ask these questions of almost any paper ever published. The > subtle thing they do is gently cast aspersions on the authors' > motivations. That's not a good thing to be trying to do. > > The one good thing that your questions did is provoke detailed > responses from different people, some of which were very informative > to me(having been conceived well after TCP/IP, I do not have the > unique historical experience a lot of people on this list do). I liked > Dave Anderson's summary of the e2e paper too. > > Durga > -- ?Never doubt that a small group of thoughtful, committed citizens can change the world. Indeed, it's the only thing that ever has.? -- Margaret Mead From Jon.Crowcroft at cl.cam.ac.uk Sun Oct 25 09:39:34 2009 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Sun, 25 Oct 2009 16:39:34 +0000 Subject: [e2e] Protocols breaking the end-to-end argument In-Reply-To: <4AE45D9A.7030808@tcd.ie> References: <20091024180015.91FF16BE55B@mercury.lcs.mit.edu> <4AE44BDC.2050704@tcd.ie> <4AE45D9A.7030808@tcd.ie> Message-ID: Jaime, maybe - i'm too staid and stuck in my ways to come up with new stuff, but it worries me i) that we use simple graphs and labeling to describe things (wireless) that isnt ii) there are ways to do content centric networking (couple of papers comin up in CoNeXT this year in Rome) mapped into ipv6 which only slightly fly in the face of the ipv6 address structuring conventiosn (there are always ways to hash object id's into a bit number space) but that doesn't address some of the things one might do with time shifting iii) I'm aware that there are people workin on "fuzzy end points" - perhaps this is just the mist around the edge of clouds... iv) i'm not sure people take on board what new technology like multicore do to your OS/protocol stack or like Terminator does to your code safety/security enough... and lots more stuff In missive <4AE45D9A.7030808 at tcd.ie>, Jaime Mateos typed: >>Jon Crowcroft wrote: >>> Flow labs and end-to-end arguments? >>> well, I guess what I am trying to say above >>> is that we are rapdily seeing the sublimation >>> of the entire naive idea of an "end point" >>> in network, transport and application terms >>> so I can't answer your specific query... >>Do you mean we need to redefine the "end points" beyond the conventional >>meaning of hosts, but keep applying the end to end argument with its >>bias towards simpler, more flexible networks; or that we should do away >>with end to end, and recognize that the new demands/pressures you list >>above can only be met with network based protocols? cheers jon From dpreed at reed.com Sun Oct 25 10:13:48 2009 From: dpreed at reed.com (David P. Reed) Date: Sun, 25 Oct 2009 13:13:48 -0400 Subject: [e2e] Protocols breaking the end-to-end argument In-Reply-To: <4835AFD53A246A40A3B8DA85D658C4BE01368B23@EVS-EC1-NODE4.surrey.ac.uk> References: <20091025035904.356D26BE5DF@mercury.lcs.mit.edu> <4AE44183.80908@reed.com> <4835AFD53A246A40A3B8DA85D658C4BE01368B23@EVS-EC1-NODE4.surrey.ac.uk> Message-ID: <4AE4874C.9000202@reed.com> On 10/25/2009 12:10 PM, L.Wood at surrey.ac.uk wrote: > > > So let's not study wars and battles. Let's study architectural > > principles and their application. > > So it is a principle after all, then? > > (It strikes me that if one is aspiring to be Darwin one shouldn't > also have to be Dawkins.) > To be precise, the end-to-end argument refers to a class of arguments, with a few free variables. Jerry and I (and perhaps Dave) have long been students of a thing called "rhetoric". In classical rhetoric (a la Aristotle), one discusses what kinds of arguments are valid. Logic is a part of rhetoric, but rhetoric as a whole includes many other aspects of argumentation. Linking rhetoric to formal logic, the end-to-end argument would be one of a set of "rules of inference" - acceptable combinators that take other factors into account and provide new valid statements. Substituting for the free variables in the end-to-end argument provides a large set of implied valid statements. Now rhetoric includes the mechanisms for argumentation where there is not one "truth". In fact, in general, rhetoric handles cases where one line of argumentation supports a particular decision, and another line supports a different decision. Therefore, rhetoric has been part of the general set of tools that lawyers use for argumentation - there is no guarantee that all laws are consistent, nor are their set of valid arguments complete in the sense of deciding every case. Architecture is like that: it is why good systems architects need to understand rhetoric in all of its glory. Examples of rhetoric: The much misunderstood "ad hominem argument" - which is an argument that makes claims based on who is making a particular claim. The term has been redefined in popular culture to mean "insult", but in fact it was never that. The argument "post hoc ergo propter hoc". That is the idea that "correlation equals causation" - John Day's argument that because of the date of publication, Jerry Dave and I must have invented the argument as part of some contemporaneous battle about network adoption. etc. I commend study of rhetoric to all. It helps decode the rather strange logics that pervade discourse today. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20091025/a77f1aec/attachment.html From perfgeek at mac.com Sun Oct 25 11:31:07 2009 From: perfgeek at mac.com (rick jones) Date: Sun, 25 Oct 2009 11:31:07 -0700 Subject: [e2e] TCP offload (was part of Protocols breaking the end-to-end argument) In-Reply-To: <4AE31066.8010109@reed.com> References: <4AE184EE.5040800@tcd.ie> <4AE1A414.4090302@gmail.com> <4AE1CDE1.5070205@reed.com> <070399CF-B67C-41E0-95A3-A528A931A1E6@mac.com> <4AE2EDB0.3010406@gmail.com> <4AE31066.8010109@reed.com> Message-ID: <1D769A86-46B5-49C6-9E64-915F892200C8@mac.com> On Oct 24, 2009, at 7:34 AM, David P. Reed wrote: > Because I sense this thread might be interesting, and should be > separated from the trolling going on in the original thread, I > changed the title. > > TCP offload is interesting. We actually addressed this kind of > thing is the "Active Networks" vs. end-to-end paper. Function > placement at the architectural level actually can be discussed with > regard to "design time" and "implementation time" versions of the > arguments. For example, if I am an "end host" but I do some of my > functions on "attached support processors" (excuse the "I" as > metaphor for the main OS and CPU), that may be quite clean > architecturally - IF the communication between me and the attached > support processor is one that makes it act as part of "me". So one > could consider it part of the "end", even if it is in a middlebox: > the distinction is that it is under my sole control (so it acts as a > fully controlled module). > > The end-to-end argument in the paper says that such acceleration can > be in the network, if indeed it merely accelerates a function that > is in all endpoints. However, the argument asks that we consider > whether the improvement overall is really worth it. > > I leave it to the community of architects (not the chip designers, > who have a bias to believe that every "feature" is a differentiating > advantage) to decide whether the benefit of this particular thing is > really worth the potential inflexibility it creates - in particular > the risk that the chip will do the wrong thing on the forwarding > path, and the risk that the TCP spec will change in a way that makes > the chip's popularity a barrier to innovation. > > It sounds as if there is a chance that, due to how one of the TOS > chips works, the portion of TCP that it implements is not strictly > an "agent" of the host TCP stack running on the host processor, but > instead based on "pattern recognition" that cannot be turned off. > (I haven't read the spec, so maybe it is more subtle than that). I don't interact much with "big TOE" functionality (full stateful protocol offload - TCP Offload Engine) but the "little toe" stateless stuff - ChecKsum Offload (CKO), TSO, LRO. I have yet to encounter a card/chip/NIC where those little toes cannot be cut-off (to spite what I'm not sure :) LRO (distict from GRO perhaps) may be one where it is either on or off. CKO and TSO are ones where they can be on, off, or on and ignored by the stack. rick jones Wisdom teeth are impacted, people are affected by the effects of events From craig at aland.bbn.com Sun Oct 25 12:51:17 2009 From: craig at aland.bbn.com (Craig Partridge) Date: Sun, 25 Oct 2009 15:51:17 -0400 Subject: [e2e] Protocols breaking the end-to-end argument Message-ID: <20091025195117.B871528E137@aland.bbn.com> > It wasn't until CLNP that I ever perceived a 'war' (or competition). To > me, it was always apparent that the war wasn't with the protocols per > se, but rather the corporate entities that wanted to control pricing. I find this historical discussion interesting because it suggests some very different vantage points. My vantage point was close to John Day's. I was at BBN (arrived in 1983) and there were internal debates of TCP/IP vs. TP0/X.25 with the additional twist that folks like John and Ross Callon were working to develop TP4/CLNP to compete with TP0/X.25. We had cheerful debates over CLNP vs. IP. (I read a draft or two of the CLNP specs for Ross -- which led to an odd statement later during the protocol wars where I was asked if I'd read the CLNP spec and the answer, honestly, was "no" -- I'd read the earlier drafts... and I got pilloried for commenting on CLNP without reading it that bit of stupidity on my part). But the big fight was TCP/IP vs. TP0/X.25 (or, more truthfully, my recollection was the fight was TCP vs. X.25 -- where to put the smarts...) Thanks! Craig From richard at bennett.com Sun Oct 25 19:04:49 2009 From: richard at bennett.com (Richard Bennett) Date: Sun, 25 Oct 2009 19:04:49 -0700 Subject: [e2e] Protocols breaking the end-to-end argument In-Reply-To: <20091025154414.D29126BE56B@mercury.lcs.mit.edu> References: <20091025154414.D29126BE56B@mercury.lcs.mit.edu> Message-ID: <4AE503C1.8040903@bennett.com> Noel Chiappa wrote: > It seems to me that the 'end-end design ideas' have gotten mixed up in what > is, at the bottom, a fight over how to divide up the economic pie of > communication networks. You mean the end-to-end design ideas have gotten mixed up in a fight over not changing how the economic pie is currently divided. 37 years of networking history boils down to this: 1. Pouzin designs CYCLADES as a layered system of protocols in order to experiment with some interesting ideas about reliability, performance, and routing; it's all based on datagrams. 2. Pouzin and Kahn share some ideas and Internet ends up following the same design as CYCLADES, modulo addressing. DECNet, XNS, and TP4/CLNP follow. 3. End-to-End Args proposes applying the notion of smart, reliable endpoints communicating over unreliable comms system to all sorts of other things as a rhetorical trick. 4. Internet eventually becomes an open (public) system. 5. RFC 1958 says "let's not descend into dogma." 6. Clark and Blumenthal's Brave New World says "end to end still has value." 7. Lessig reads Brave New World as saying "capitalism is corrupting the Internet; Save End-to-End!" 8. Moors points out that E2E Args never did describe the Internet. 9. AT&T admits to being a capitalist entity. 10. Google's MCI vets worry that telcos will put them out of business like they did MCI unless end-to-end is law. 11. Public interest groups push for end-to-end law. 12. FCC asks: "What's wrong with descending into dogma? That's what we do." 13. Angry old hippies go "Right on, FCC, your daddy's Internet is good enough for you!" And that's where we are today. RB From L.Wood at surrey.ac.uk Sun Oct 25 23:19:29 2009 From: L.Wood at surrey.ac.uk (L.Wood@surrey.ac.uk) Date: Mon, 26 Oct 2009 06:19:29 -0000 Subject: [e2e] Protocols breaking the end-to-end argument References: <20091025154414.D29126BE56B@mercury.lcs.mit.edu> <4AE503C1.8040903@bennett.com> Message-ID: <4835AFD53A246A40A3B8DA85D658C4BE01368B24@EVS-EC1-NODE4.surrey.ac.uk> > 3. End-to-End Args proposes applying the notion of smart, reliable > endpoints communicating over unreliable comms system to all sorts of > other things as a rhetorical trick. Reed's comment on rhetoric bringing structure to logical argument has nothing to do with a paper doing engineering analysis and drawing insights from commonalities. (I would submit that to fully understand its arguments and internalize its concepts, an engineering mindset is required.) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20091026/e9c54fc2/attachment.html From richard at bennett.com Mon Oct 26 02:07:20 2009 From: richard at bennett.com (Richard Bennett) Date: Mon, 26 Oct 2009 02:07:20 -0700 Subject: [e2e] Protocols breaking the end-to-end argument In-Reply-To: <4835AFD53A246A40A3B8DA85D658C4BE01368B24@EVS-EC1-NODE4.surrey.ac.uk> References: <20091025154414.D29126BE56B@mercury.lcs.mit.edu> <4AE503C1.8040903@bennett.com> <4835AFD53A246A40A3B8DA85D658C4BE01368B24@EVS-EC1-NODE4.surrey.ac.uk> Message-ID: <4AE566C8.7070203@bennett.com> An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20091026/e7f98ec6/attachment.html From william.allen.simpson at gmail.com Mon Oct 26 05:53:18 2009 From: william.allen.simpson at gmail.com (William Allen Simpson) Date: Mon, 26 Oct 2009 08:53:18 -0400 Subject: [e2e] TCP offload (was part of Protocols breaking the end-to-end argument) In-Reply-To: <1D769A86-46B5-49C6-9E64-915F892200C8@mac.com> References: <4AE184EE.5040800@tcd.ie> <4AE1A414.4090302@gmail.com> <4AE1CDE1.5070205@reed.com> <070399CF-B67C-41E0-95A3-A528A931A1E6@mac.com> <4AE2EDB0.3010406@gmail.com> <4AE31066.8010109@reed.com> <1D769A86-46B5-49C6-9E64-915F892200C8@mac.com> Message-ID: <4AE59BBE.8070000@gmail.com> rick jones wrote: > > On Oct 24, 2009, at 7:34 AM, David P. Reed wrote: > >> I leave it to the community of architects (not the chip designers, who >> have a bias to believe that every "feature" is a differentiating >> advantage) to decide whether the benefit of this particular thing is >> really worth the potential inflexibility it creates - in particular >> the risk that the chip will do the wrong thing on the forwarding path, >> and the risk that the TCP spec will change in a way that makes the >> chip's popularity a barrier to innovation. >> > I don't interact much with "big TOE" functionality (full stateful > protocol offload - TCP Offload Engine) but the "little toe" stateless > stuff - ChecKsum Offload (CKO), TSO, LRO. I have yet to encounter a > card/chip/NIC where those little toes cannot be cut-off (to spite what > I'm not sure :) LRO (distict from GRO perhaps) may be one where it is > either on or off. CKO and TSO are ones where they can be on, off, or on > and ignored by the stack. > TCP Checksum Offload (shouldn't that be TCO or CSO?) has been done for years. I've always been a bit leery of it, as my many experiences with bus problems indicates that the checksum should be calculated as close to the CPU as possible.... TCP Segment Offload (TSO) -- large TCP segments are broken into smaller ones -- wouldn't be a problem where the stack always feeds the chip properly-sized PMTU segments. For routing a LAN jumbogram into a WAN, that's broken! The drivers had better be smart enough to honor "Don't Fragment" (DF), even though that technically only applies to IP. Best to turn it off for all routed packets. Does your implementation? TCP Large Receive Offload (LRO) -- small TCP segments are combined into larger ones -- is an unmitigated disaster. The sender has no ability to turn it off, and no idea that it's happening. Assuming it leaves SYN-bearing segments untouched, I'd still think that breaks almost every existing Ack-bearing TCP option. In either of the latter cases, I don't see how PAWS Timestamps or the MD5 Authentication Option would ever work. From william.allen.simpson at gmail.com Mon Oct 26 06:54:09 2009 From: william.allen.simpson at gmail.com (William Allen Simpson) Date: Mon, 26 Oct 2009 09:54:09 -0400 Subject: [e2e] Protocols breaking the end-to-end argument In-Reply-To: <20091025195117.B871528E137@aland.bbn.com> References: <20091025195117.B871528E137@aland.bbn.com> Message-ID: <4AE5AA01.6070800@gmail.com> Craig Partridge wrote: >> It wasn't until CLNP that I ever perceived a 'war' (or competition). To >> me, it was always apparent that the war wasn't with the protocols per >> se, but rather the corporate entities that wanted to control pricing. > > I find this historical discussion interesting because it suggests some > very different vantage points. > Yes. Mine was much closer to the view of Noel Chiappa, where he says: # Frankly, for most of us, we were up to our asses in alligators getting all # these various new technologies (LANs, etc) up and running, and didn't have a # lot of time to worry about anything else anyway. What little time we did have # for deep thinking went to things like how to better organize OS software to # deal with networking, etc, etc. # But I'd also the experience of actually trying to order links. It was quite difficult. Then, AT&T required putting these little gray boxes on every data line, and charging double (or more) the usual voice rate. We took the box apart, and discovered that we could build the same thing for less than 35 cents retail, but they were charging hundreds of dollars per year (forever). So, for me, the Green decision couldn't have come soon enough. And we did everything under the sun to avoid AT&T links. Maybe that's the underlying reason that X.25 wasn't a competitor, as we were using it as little as possible. > My vantage point was close to John Day's. I was at BBN (arrived in 1983) > and there were internal debates of TCP/IP vs. TP0/X.25 with the additional > twist that folks like John and Ross Callon were working to develop TP4/CLNP > to compete with TP0/X.25. > By 1981, I'd left the University for a small startup that did front-end data concentrators (using the HP 21MX with nicely re-programmable microcode for handling data). Over a couple of years, we did a couple of dozen protocols, none of which were X.25. By 1983, I'd become a full-time consultant. Auto companies and suppliers, political campaigns -- none of them ever expressed any interest in X.25. Lots of serial multi-point cabling connected to front-ends talking to back-ends over various proprietary data channels or (thick) ethernet in electronically noisy, chaotic environments. > But the big fight was TCP/IP vs. TP0/X.25 (or, more truthfully, my recollection > was the fight was TCP vs. X.25 -- where to put the smarts...) > Believe me, there is nothing that can better reinforce the absolute necessity for end-to-end transmission control than heterogeneous networking on a factory floor over multiple hops, or with a satellite link in the middle. Nothing else actually works! More important, nothing else is testable by a factory electrician or (usually mechanical) engineer that has to debug and fix the link. The smarts has to be located in the CPE. If folks at BBN were still talking about X.25, they were way behind the curve, or were badly infected with severe standard-committee-itis. From craig at aland.bbn.com Mon Oct 26 07:10:33 2009 From: craig at aland.bbn.com (Craig Partridge) Date: Mon, 26 Oct 2009 10:10:33 -0400 Subject: [e2e] Protocols breaking the end-to-end argument Message-ID: <20091026141033.2C07D28E137@aland.bbn.com> > If folks at BBN were still talking about X.25, they were way behind the > curve, or were badly infected with severe standard-committee-itis. The latter. Recall that part of BBN's networking team was paid by NIST to represent the US at ISO/CCITT meetings. So BBN was simultaneously pushing ahead on TCP/IP work AND working with ISO/CCITT on ISO standards. Add to this that it was official US policy at the time that they'd transition from TCP/IP to the OSI standards, and so there was much effort inside BBN to try to get the OSI standards to a good enough state to be transitioned to, and there was pushback from other countries represented at ISO, and you have the internal debates. Thanks! Craig From dpreed at reed.com Mon Oct 26 07:23:35 2009 From: dpreed at reed.com (David P. Reed) Date: Mon, 26 Oct 2009 10:23:35 -0400 Subject: [e2e] Protocols breaking the end-to-end argument In-Reply-To: <4AE503C1.8040903@bennett.com> References: <20091025154414.D29126BE56B@mercury.lcs.mit.edu> <4AE503C1.8040903@bennett.com> Message-ID: <4AE5B0E7.8090107@reed.com> On 10/25/2009 10:04 PM, Richard Bennett wrote: > 37 years of networking history boils down to this: ... > 13. Angry old hippies go "Right on, FCC, your daddy's Internet is good > enough for you!" > What a warped interpretation of history... it discredits itself, in my opinion only, of course. If this were a forum for discussing policy matters, I'd engage in debunking it. It is not such a forum, however. This is a research forum, loosely associated with the IRTF, and Bennett's comments (true or not) have not contributed to this forum. With regard to historical analysis, Bennett (and his informants) are welcome to write an article for ACMs Annals in the History of Computing, where actual historians apply peer review to such claims and submissions. The use of the phrase "rhetorical trick" is offensive to me personally. Bennett persists in this claim, and John Day surprisingly (to me) joins him in this warped idea that our paper was written as a move in a battle (war) that some would claim was relevant to today. That it offends me personally doesn't matter that much in the scheme of things - certainly Bennett's strange historical analysis of "causation" wouldn't stand a test against facts. However, it is clear we must take Bennett seriously: Jon Peha (FCC Chief Technologist), Robert Pepper (former FCC senior exec and Cisco senior exec), Rob Atkinson (progressive political activist and friend of Blair Levin), and several Congress members (including Darryl Issa) support the organization that employs Bennett as a Senior Fellow where he makes this set of claims (ITIF) *as part of his job*. That organization claims to be a "non-partisan think tank" devoted to research and analysis. So I'd suggest that this analysis be subjected to rigorous review - but NOT on an IRTF list. Perhaps Bennett's claim (made in his online resume) that he was "responsible" for major networking standards, "including ... WiFi and UWB" will also be reviewed rigorously, again, not on this list, but elsewhere, perhaps by the FCC. Many people on this list know some of the people who are given credit for 802.11 in the community -- you're welcome to ask them about Bennett. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20091026/fc7f7cf2/attachment-0001.html From dhc2 at dcrocker.net Mon Oct 26 07:52:33 2009 From: dhc2 at dcrocker.net (Dave CROCKER) Date: Mon, 26 Oct 2009 07:52:33 -0700 Subject: [e2e] Tussle-points In-Reply-To: <20091024180015.91FF16BE55B@mercury.lcs.mit.edu> References: <20091024180015.91FF16BE55B@mercury.lcs.mit.edu> Message-ID: <4AE5B7B1.4050905@dcrocker.net> Noel Chiappa wrote: > For one, NATs became widespread mostly a result of flaws in the original > engineering (too small an address space) and architecture (too few namespaces, > leading to difficulty in supporting things like provider independence). NATs > are not inherently desirable, and would not, I think, have > evolved/proliferated had TCP/IP avoided those (in hindsight, now obvious) > mistakes. The name "NAT" certainly justifies the claim that they were created to resolve an issue with addressing. And given what they do to an address, they certainly affect end-to-end behaviors. But there is pretty strong indication that something like them would have been needed anyhow. For example... Back when CIDR was being deployed -- and repeated in the Tussles in Cyberspace paper -- it was observed that the way addresses are structured locks a user into their provider. NATs fix that (if you don't have any publicly-visible servers inside your net.) In other words, NATs have important administrative benefits that need to be acknowledged. The interface between an organization and the outside world needs a potentially sophisticated boundary device, no matter how wonderful the Net's addressing scheme. Whether the legitimate services of such a boundary device impinges on E2E principles is a worthy discussion, but we ought to be careful not to dismiss the topic with the usual, quick wave of the E2E flag over the limited and rotten corpse of the address-translation-is-bad assertion. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From perfgeek at mac.com Mon Oct 26 08:12:58 2009 From: perfgeek at mac.com (rick jones) Date: Mon, 26 Oct 2009 08:12:58 -0700 Subject: [e2e] TCP offload (was part of Protocols breaking the end-to-end argument) In-Reply-To: <4AE59BBE.8070000@gmail.com> References: <4AE184EE.5040800@tcd.ie> <4AE1A414.4090302@gmail.com> <4AE1CDE1.5070205@reed.com> <070399CF-B67C-41E0-95A3-A528A931A1E6@mac.com> <4AE2EDB0.3010406@gmail.com> <4AE31066.8010109@reed.com> <1D769A86-46B5-49C6-9E64-915F892200C8@mac.com> <4AE59BBE.8070000@gmail.com> Message-ID: On Oct 26, 2009, at 5:53 AM, William Allen Simpson wrote: > TCP Checksum Offload (shouldn't that be TCO or CSO?) It wouldn't be the former for it is used for UDP as well. As for CSO vs CKO, a (stinking?) rose by any other name I suppose. The feature got named CKO, I'm content to leave it as such. > TCP Segment Offload (TSO) -- large TCP segments are broken into > smaller > ones -- wouldn't be a problem where the stack always feeds the chip > properly-sized PMTU segments. I may have misunderstood your wording, but if TCP has already segmented, there wouldn't be much if any offloading. The stack hands the chip everything it needs to know to make properly-sized segments on each large send. (IIRC Solaris experimented with Multi Data Transmit (MDT - a joy of a search term...) where they did have TCP do all the segmentation and all it did was pass a list of multiple segments in one go (not unlike packet trains in say HP-UX 8.07 IP fragmentation and elsestacks I suspect) but that "poor man's TSO" I don't think went very far even though it could give a little boost over a non-TSO-capable NIC. "All" the NICs can do TSO now. (TSO itself is sometimes referred to as "poor man's Jumbo Frames" and we would circle-back to a de jure MTU that has remained unchanged for decades....) > For routing a LAN jumbogram into a WAN, > that's broken! The drivers had better be smart enough to honor "Don't > Fragment" (DF), even though that technically only applies to IP. > Best to > turn it off for all routed packets. Does your implementation? I do not have my own TCP/IP stack :) I interact to varying degrees with the stacks of others. Based on that experience, the decision to do TSO is on a send by send basis. TCP sets-up the send to be either TSO or non-TSO, the driver does the appropriate thing to the packet descriptor(s) to inform the NIC. While I cannot say that I've gone looking for the code in Linux and elsewhere, unless IP tries to set it up on a routed datagram, and I do not believe it does, TSO will not be applied as the datagram leaves via the egress interface. > TCP Large Receive Offload (LRO) -- small TCP segments are combined > into > larger ones -- is an unmitigated disaster. The sender has no > ability to > turn it off, and no idea that it's happening. Assuming it leaves > SYN-bearing segments untouched, I'd still think that breaks almost > every > existing Ack-bearing TCP option. You must really like the HP-UX and Solaris (and any other Mentat- derived stack's) ACK avoidance heuristics :) Another example of customer LAN/MAN needs/desires coming-up against what is felt to be necessary for the big-I Internet. IIRC the Solaris stack does attempt to make a distinction between local and remote when deciding to (not) apply the ACK avoidance heuristic. Both have mechanisms to evolve up to their levels of avoidance and devolve back to the chapter-and-verse ack-every-other behaviour suggested by the RFCs in the presence of anomalies. Both can be controlled completely (on, off, degree) by the system administrator. > In either of the latter cases, I don't see how PAWS Timestamps or > the MD5 > Authentication Option would ever work. PAWS Timestamps need-not (should not?) be unique from segment to segment, only from window to window or transmission to retransmission yes? So, on the sending side, since the host TCP is very much in control, if a sequence of N segments would have a PAWS increment in the middle, TCP can split the large send into two at that point. I do not know if GRO (or the card-based LRO) does the opposite on the way in, but I could easily see (and not actually) them checking and asking "is this timestamp the same as the previous" when making coalescing decisions. rick jones Wisdom teeth are impacted, people are affected by the effects of events From richard at bennett.com Mon Oct 26 10:20:13 2009 From: richard at bennett.com (Richard Bennett) Date: Mon, 26 Oct 2009 10:20:13 -0700 Subject: [e2e] Protocols breaking the end-to-end argument In-Reply-To: <4AE5B0E7.8090107@reed.com> References: <20091025154414.D29126BE56B@mercury.lcs.mit.edu> <4AE503C1.8040903@bennett.com> <4AE5B0E7.8090107@reed.com> Message-ID: <4AE5DA4D.1040806@bennett.com> An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20091026/424938fc/attachment.html From dpreed at reed.com Mon Oct 26 10:44:43 2009 From: dpreed at reed.com (David P. Reed) Date: Mon, 26 Oct 2009 13:44:43 -0400 Subject: [e2e] Protocols breaking the end-to-end argument In-Reply-To: <4AE5DA4D.1040806@bennett.com> References: <20091025154414.D29126BE56B@mercury.lcs.mit.edu> <4AE503C1.8040903@bennett.com> <4AE5B0E7.8090107@reed.com> <4AE5DA4D.1040806@bennett.com> Message-ID: <4AE5E00B.2090909@reed.com> Note: I did not and have never tried to get Bennett fired. I will say that it is my opinion (openly held) that ITIF gains little from employing him as a spokesperson, and that Bennett has several times expressed the idea that my employment at MIT is somehow not to his liking. On 10/26/2009 01:20 PM, Richard Bennett wrote: > Excellent response, David Reed. Don't forget that the FCC's Notice of > Proposed Rulemaking on Internet regulation quotes me re: the fact that > Pouzin invented the framework that we find in the Internet protocols > and four other systems of that era. > > BTW, I'm not participating on this e-mail list as part of my job, but > I'm sure David Reed will go ahead and try to get me fired again for > having the nerve to question his reasoning; it's been about a week > since he did that, so it's probably time again. > > Meanwhile, I'm revising my "Designed for Change" paper for > publication. The discussion about rhetoric and all has been very > illuminating regarding the motivation for the paper what has been > claimed to fuel the debate on Internet regulation, but to me the paper > seems to be a more a creature of some of the fashions of its age (RISC > and all that sort of thing.) Some applications have worked out well, > others not; do we know why? > > RB > > David P. Reed wrote: >> On 10/25/2009 10:04 PM, Richard Bennett wrote: >>> 37 years of networking history boils down to this: >> ... >>> 13. Angry old hippies go "Right on, FCC, your daddy's Internet is >>> good enough for you!" >>> >> >> >> What a warped interpretation of history... it discredits itself, in >> my opinion only, of course. If this were a forum for discussing >> policy matters, I'd engage in debunking it. It is not such a forum, >> however. This is a research forum, loosely associated with the IRTF, >> and Bennett's comments (true or not) have not contributed to this forum. >> >> With regard to historical analysis, Bennett (and his informants) are >> welcome to write an article for ACMs Annals in the History of >> Computing, where actual historians apply peer review to such claims >> and submissions. >> >> The use of the phrase "rhetorical trick" is offensive to me >> personally. Bennett persists in this claim, and John Day >> surprisingly (to me) joins him in this warped idea that our paper was >> written as a move in a battle (war) that some would claim was >> relevant to today. That it offends me personally doesn't matter that >> much in the scheme of things - certainly Bennett's strange historical >> analysis of "causation" wouldn't stand a test against facts. >> >> However, it is clear we must take Bennett seriously: Jon Peha (FCC >> Chief Technologist), Robert Pepper (former FCC senior exec and Cisco >> senior exec), Rob Atkinson (progressive political activist and friend >> of Blair Levin), and several Congress members (including Darryl Issa) >> support the organization that employs Bennett as a Senior Fellow >> where he makes this set of claims (ITIF) *as part of his job*. That >> organization claims to be a "non-partisan think tank" devoted to >> research and analysis. So I'd suggest that this analysis be >> subjected to rigorous review - but NOT on an IRTF list. Perhaps >> Bennett's claim (made in his online resume) that he was "responsible" >> for major networking standards, "including ... WiFi and UWB" will >> also be reviewed rigorously, again, not on this list, but elsewhere, >> perhaps by the FCC. Many people on this list know some of the people >> who are given credit for 802.11 in the community -- you're welcome to >> ask them about Bennett. >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20091026/107e3a4b/attachment.html From jnc at mercury.lcs.mit.edu Mon Oct 26 18:13:10 2009 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 26 Oct 2009 21:13:10 -0400 (EDT) Subject: [e2e] Protocols breaking the end-to-end argument Message-ID: <20091027011310.C49266BE612@mercury.lcs.mit.edu> > From: Richard Bennett >> It seems to me that the 'end-end design ideas' have gotten mixed up in >> what is, at the bottom, a fight over how to divide up the economic pie >> of communication networks. > You mean the end-to-end design ideas have gotten mixed up in a fight > over not changing how the economic pie is currently divided. Err, 'the current division pattern' is one of the possible answers to the question 'how should the economic pie of communication networks be divided up', I would have thought. But this is not important, let me move on... > End-to-End Args proposes applying the notion of smart, reliable > endpoints communicating over unreliable comms system to all sorts of > other things as a rhetorical trick. 'Distributed systems' is a long-standing area of interest in computing 'science' (but that's a different rathole), and it covers a far larger field than simply communication networks (which is the subject area in which the end-end analysis originated). The design philosophy framework discussed in "End-to-End Arguments", while originating in an analysis of communication networks, can viably be applied to a wide variety of distributed systems (say, for instance, a distributed file system which uses replication for robustness and performance). Calling the application to such a system, in the larger problem domain, "a rhetorical trick" seems considerably 'over the top' to me. Moreover, your phraseology above ("End-to-End Args proposes applying the notion ... to all sorts of other things as a rhetorical trick") seems to imply that a principal feature of the paper are attempts to apply the end-to-end argument to places outside the computerized information systems domain. In fact, there is only paragraph, in the section entitled "History, and application to other system areas" which deals with such examples. That hardly qualifies as what your wording implies - which is that such expansionary applications are a major thrust of the paper. You're also incorrect to characterize even that paragraph as "applying the notion of smart, reliable endpoints communicating over unreliable comms system". The banking example certainly doesn't fit that rubric. It would be more apt to describe the examples in that paragraph as examples of "functions placed at low levels of a system [which] may be redundant or of little value when compared with the cost of providing them at that low level" - that phrase, of course, being from the paper's own abstract. > Moors points out that E2E Args never did describe the Internet. I think this is again a misreprentation of what the Moors paper says - but we've been down that rabbit hole before. > 10. Google's MCI vets worry that telcos will put them out of business > like they did MCI unless end-to-end is law. > 11. Public interest groups push for end-to-end law. > 12. FCC asks: "What's wrong with descending into dogma? That's what we do." Policy and engineering are two very different problem domains, and the former is free to ignore the latter, if other external (i.e. non-engineering) factors make that the preferable choice. (Within limits, of course; I treat that point last.) Just because an engineering discipline says 'X is the way to go', that doesn't mean policy has to follow. As a made-up example, country Y might decide that for non-engineering reasons, they prefer to ban gas turbines as aircraft engines, in favour of piston engines (perhaps because they don't like the high-pitched whine of turbines, say). However, clearly, if country Y communally makes the decision to ban gas turbines, that's their call - even at the same time that it remains a non-optimal decision from an _engineering_ perspective. The interesting question, of course, is whether it's good public policy to make policy choices that are a non-optimal decision from an engineering perspective. Clearly in cases where that is done there will be a price to pay (e.g. in the example above, slower planes, and higher fuel consumption), but only the community in question can decide if those costs are worth the benefits (e.g. getting rid of turbine whine). There is no general principle one can apply in such cases, to decide whether or not to follow the optimal engineering path; each will have to be decided on the overall merits. So if some factions are calling for an 'end-to-end law' (whatever that might be - my opinion would be that that is a poor name, although I can see where it came from), that's a legitimate policy position, on a legitimate policy decision. Engineering can only provide data to that debate, as to whether it's the most efficient choice, or not - as in the gas turbine example. The one place policy _cannot_ go is to _ignore hard constraints_. As Feynman so elegantly put it (in his appendix to the 'Challenger' crash report'): "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." > 13. Angry old hippies go "Right on, FCC, your daddy's Internet is good > enough for you!" The implication here seems to be that people who advocate a certain position on how to divide up the network pie are also associated with a certain place on the political spectrum - at least, in terms of their views on economics? (Those who know me will no doubt be as amused as I am by the seeming supposition that I might fall into this imaginary category - but I digress.) I haven't actually stated here anything about my views on how to divide up the network money pie. Actually, I don't really care about that issue: although I do have views on what kind of service model the network should offer, they are driven by other factors, such as engineering. All of which should serve to make several points that everyone should retain - that discussing whether or not the End-to-End princple is a good/valid engineering point is separate from the question of what service model the network should offer to its customers - and that people can have positions on that latter question which are utterly not a result of their views (if any) on the issue of how to divide up the network pie. Some consequences in the latter will obviously be a _result_ of their position on the service model, of course, but it should be noted that the effects on the pie division are a _result_ of their position on the service model issue, not the _cause_ of the latter - seemingly unlike that for some other people. Noel From richard at bennett.com Mon Oct 26 20:33:51 2009 From: richard at bennett.com (Richard Bennett) Date: Mon, 26 Oct 2009 23:33:51 -0400 Subject: [e2e] Protocols breaking the end-to-end argument In-Reply-To: <20091027011310.C49266BE612@mercury.lcs.mit.edu> References: <20091027011310.C49266BE612@mercury.lcs.mit.edu> Message-ID: <4AE66A1F.9000305@bennett.com> I agree with about all of this, and would simply note that I don't know most of the people on this list well enough to say who's an angry old hippie and who isn't, not that it matters. An awful lot of the net neut issue is rehashing grievances against the defunct monopoly phone companies, which is all fine if one is into that sort of thing, just not quite relevant to the world we live in today. Noel Chiappa wrote: > > From: Richard Bennett > > >> It seems to me that the 'end-end design ideas' have gotten mixed up in > >> what is, at the bottom, a fight over how to divide up the economic pie > >> of communication networks. > > > You mean the end-to-end design ideas have gotten mixed up in a fight > > over not changing how the economic pie is currently divided. > > Err, 'the current division pattern' is one of the possible answers to the > question 'how should the economic pie of communication networks be divided > up', I would have thought. But this is not important, let me move on... > > > > End-to-End Args proposes applying the notion of smart, reliable > > endpoints communicating over unreliable comms system to all sorts of > > other things as a rhetorical trick. > > 'Distributed systems' is a long-standing area of interest in computing > 'science' (but that's a different rathole), and it covers a far larger field > than simply communication networks (which is the subject area in which the > end-end analysis originated). > > The design philosophy framework discussed in "End-to-End Arguments", while > originating in an analysis of communication networks, can viably be applied > to a wide variety of distributed systems (say, for instance, a distributed > file system which uses replication for robustness and performance). Calling > the application to such a system, in the larger problem domain, "a rhetorical > trick" seems considerably 'over the top' to me. > > Moreover, your phraseology above ("End-to-End Args proposes applying the > notion ... to all sorts of other things as a rhetorical trick") seems to > imply that a principal feature of the paper are attempts to apply the > end-to-end argument to places outside the computerized information systems > domain. In fact, there is only paragraph, in the section entitled "History, > and application to other system areas" which deals with such examples. That > hardly qualifies as what your wording implies - which is that such > expansionary applications are a major thrust of the paper. > > You're also incorrect to characterize even that paragraph as "applying the > notion of smart, reliable endpoints communicating over unreliable comms > system". The banking example certainly doesn't fit that rubric. It would be > more apt to describe the examples in that paragraph as examples of "functions > placed at low levels of a system [which] may be redundant or of little value > when compared with the cost of providing them at that low level" - that > phrase, of course, being from the paper's own abstract. > > > > Moors points out that E2E Args never did describe the Internet. > > I think this is again a misreprentation of what the Moors paper says - but > we've been down that rabbit hole before. > > > > 10. Google's MCI vets worry that telcos will put them out of business > > like they did MCI unless end-to-end is law. > > 11. Public interest groups push for end-to-end law. > > 12. FCC asks: "What's wrong with descending into dogma? That's what we do." > > Policy and engineering are two very different problem domains, and the former > is free to ignore the latter, if other external (i.e. non-engineering) factors > make that the preferable choice. (Within limits, of course; I treat that point > last.) > > Just because an engineering discipline says 'X is the way to go', that > doesn't mean policy has to follow. As a made-up example, country Y might > decide that for non-engineering reasons, they prefer to ban gas turbines as > aircraft engines, in favour of piston engines (perhaps because they don't > like the high-pitched whine of turbines, say). However, clearly, if country Y > communally makes the decision to ban gas turbines, that's their call - even > at the same time that it remains a non-optimal decision from an _engineering_ > perspective. > > The interesting question, of course, is whether it's good public policy to > make policy choices that are a non-optimal decision from an engineering > perspective. Clearly in cases where that is done there will be a price to pay > (e.g. in the example above, slower planes, and higher fuel consumption), but > only the community in question can decide if those costs are worth the > benefits (e.g. getting rid of turbine whine). There is no general principle > one can apply in such cases, to decide whether or not to follow the optimal > engineering path; each will have to be decided on the overall merits. > > So if some factions are calling for an 'end-to-end law' (whatever that might > be - my opinion would be that that is a poor name, although I can see where > it came from), that's a legitimate policy position, on a legitimate policy > decision. Engineering can only provide data to that debate, as to whether > it's the most efficient choice, or not - as in the gas turbine example. > > The one place policy _cannot_ go is to _ignore hard constraints_. As Feynman > so elegantly put it (in his appendix to the 'Challenger' crash report'): > > "For a successful technology, reality must take precedence over public > relations, for nature cannot be fooled." > > > > 13. Angry old hippies go "Right on, FCC, your daddy's Internet is good > > enough for you!" > > The implication here seems to be that people who advocate a certain position > on how to divide up the network pie are also associated with a certain place > on the political spectrum - at least, in terms of their views on economics? > > (Those who know me will no doubt be as amused as I am by the seeming > supposition that I might fall into this imaginary category - but I digress.) > > I haven't actually stated here anything about my views on how to divide up the > network money pie. Actually, I don't really care about that issue: although I > do have views on what kind of service model the network should offer, they are > driven by other factors, such as engineering. > > > All of which should serve to make several points that everyone should retain - > that discussing whether or not the End-to-End princple is a good/valid > engineering point is separate from the question of what service model the > network should offer to its customers - and that people can have positions on > that latter question which are utterly not a result of their views (if any) on > the issue of how to divide up the network pie. > > Some consequences in the latter will obviously be a _result_ of their position > on the service model, of course, but it should be noted that the effects on > the pie division are a _result_ of their position on the service model issue, > not the _cause_ of the latter - seemingly unlike that for some other people. > > Noel > -- Richard Bennett Research Fellow Information Technology and Innovation Foundation Washington, DC From Jon.Crowcroft at cl.cam.ac.uk Tue Oct 27 00:35:36 2009 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Tue, 27 Oct 2009 07:35:36 +0000 Subject: [e2e] Protocols breaking the end-to-end argument In-Reply-To: <4AE66A1F.9000305@bennett.com> References: <20091027011310.C49266BE612@mercury.lcs.mit.edu> <4AE66A1F.9000305@bennett.com> Message-ID: In missive <4AE66A1F.9000305 at bennett.com>, Richard Bennett typed: >>hippie and who isn't, not that it matters. An awful lot of the net neut >>issue is rehashing grievances against the defunct monopoly phone >>companies, which is all fine if one is into that sort of thing, just not >>quite relevant to the world we live in today. yes but... it was relevant _again_ for a while because of cellular phone companies reluctance to do anything interesting in the internet-stylee, but after the iPhone did an end-run on them, and android and half-dozen other smart phone systems moved to an end-system app market independent of provider, that problem went away... for a while, i thought that ISPs might be evolving into telcos too (its part of the territory)- but this recent nanog talk encouraged me: http://www.nanog.org/meetings/nanog47/presentations/Monday/Labovitz_Ob serveReport_N47_Mon.pdf btw, the "old hippie" tag is a bit off in terms of age and location for some of us....for example, I'm a card carrying london ex punk:) (read "memoirs of a geezer" by jah wobble, and you'll see that we are closer in ethos to yippees, seein as we don't subscribe to liberalism) j. From dpreed at reed.com Tue Oct 27 06:32:35 2009 From: dpreed at reed.com (David P. Reed) Date: Tue, 27 Oct 2009 09:32:35 -0400 Subject: [e2e] Protocols breaking the end-to-end argument In-Reply-To: References: <20091027011310.C49266BE612@mercury.lcs.mit.edu> <4AE66A1F.9000305@bennett.com> Message-ID: <4AE6F673.8080807@reed.com> Is it the "aging" part or the "hippie" part that makes a person suspect? I could give you a list of labels that have been applied to me, in discussions of network technology, to conjure with as you like: corporate-type, libertarian, communist, hippie, net-nutter, past-it, ivory-tower, propellerhead, mere engineer, non-economist, naive, fuzzy-minded, ... I personally don't think such labels make a whit of difference. In fact, I am a member of AAAS, AARP, ACLU, ACM, and that's only the first four A's on the list of memberships. Does that make a difference? It turns out that one of my ancestors (John Reed) arrived in Rhode Island in 1615, and another came to the US on Ellis Island. One of my ancestors was at the battle of Lexington and Concord, and another was a Gibson Girl on 42nd street, having immigrated into the country. My father can be seen in documentary footage shot on the USS Missouri during the Korean Conflict, and was in charge of designing many of the modern US Navy ships now in service. Do those things make a difference? I guess the fellow who is responsible for WiFi and UWB knows how to judge ideas by the person's lifestyle. And by the way, I'm neither aging (I'm 57, and can beat most people in arm-wrestling, if nothing else), nor a classic "hippie" (my views in those days tended toward a very different direction - a mixture of systems design, AI, and math, mixed with stopping the Vietnam War and creating a free market of ideas). But so what if I were? From Jon.Crowcroft at cl.cam.ac.uk Tue Oct 27 07:43:15 2009 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Tue, 27 Oct 2009 14:43:15 +0000 Subject: [e2e] Protocols breaking the end-to-end argument In-Reply-To: <4AE6F673.8080807@reed.com> References: <20091027011310.C49266BE612@mercury.lcs.mit.edu> <4AE66A1F.9000305@bennett.com> <4AE6F673.8080807@reed.com> Message-ID: I may fall down on relevance (c.f. Deirdre Wilson & Dan Sperberr Relevance Theory, 1985) but I think I am going to have to refer you to youtube: http://www.youtube.com/watch?v=2SNHtKfDxlg but anyhow, I suspect I am just as suspect as you for what its worth... this has to be set against the rabid free market libertarianism fairly common in Internet Research circles from 1992 until the present day, which is also extremely unrepresentative of the world... In missive <4AE6F673.8080807 at reed.com>, "David P. Reed" typed: >>Is it the "aging" part or the "hippie" part that makes a person suspect? >>I could give you a list of labels that have been applied to me, in >>discussions of network technology, to conjure with as you like: >> >>corporate-type, libertarian, communist, hippie, net-nutter, past-it, >>ivory-tower, propellerhead, mere engineer, non-economist, naive, >>fuzzy-minded, ... >> >>I personally don't think such labels make a whit of difference. >> >>In fact, I am a member of AAAS, AARP, ACLU, ACM, and that's only the >>first four A's on the list of memberships. Does that make a difference? >> >>It turns out that one of my ancestors (John Reed) arrived in Rhode >>Island in 1615, and another came to the US on Ellis Island. One of my >>ancestors was at the battle of Lexington and Concord, and another was a >>Gibson Girl on 42nd street, having immigrated into the country. My >>father can be seen in documentary footage shot on the USS Missouri >>during the Korean Conflict, and was in charge of designing many of the >>modern US Navy ships now in service. >> >>Do those things make a difference? >> >>I guess the fellow who is responsible for WiFi and UWB knows how to >>judge ideas by the person's lifestyle. >> >>And by the way, I'm neither aging (I'm 57, and can beat most people in >>arm-wrestling, if nothing else), nor a classic "hippie" (my views in >>those days tended toward a very different direction - a mixture of >>systems design, AI, and math, mixed with stopping the Vietnam War and >>creating a free market of ideas). >> >>But so what if I were? cheers jon From richard at bennett.com Tue Oct 27 14:27:31 2009 From: richard at bennett.com (Richard Bennett) Date: Tue, 27 Oct 2009 14:27:31 -0700 Subject: [e2e] Protocols breaking the end-to-end argument In-Reply-To: References: <20091027011310.C49266BE612@mercury.lcs.mit.edu> <4AE66A1F.9000305@bennett.com> <4AE6F673.8080807@reed.com> Message-ID: <4AE765C3.1090303@bennett.com> Seems to me that the real hippies were pretty much libertarians who didn't trust The Man's Government any more than The Man's Corporations. Internet Research circles are interesting, in that they consist of people taking money from The Man's War Machine to spread peace, love, and understanding, which may be the best form of national defense anyhow. And in plain engineering circles, there seems to be a divide between libertarians who don't trust authority period and socialists who view society as a machine to be optimized and markets as too messy an inefficient for the purpose. Of course, socialism is inconsistent with net neutrality in principle, but nobody really understands that. In the course of reading the 1984 version of E2E Args, I was struck by the mention of RISC. It's interesting because back in the 1970s and 80s, there was this general train of thought about building reliable, high quality systems on cheap and plentiful unreliable parts. It was interesting because it seemed to resolve the "good, fast, cheap: pick any two" dilemma that I used to see above programmers' desks from about 1980 on. RAID, RISC, datagrams, old-fashioned CSMA/CD Ethernet, and massively parallel microprocessor-based supercomputers were all explorations of that idea, which worked out well in some contexts and less well in others. RISC was a bust, for example, and while datagrams are good for content-oriented network applications, they're obviously less good for real-time network apps, and Ethernet only became dominant when we dumped CSMA/CD for the collision-free, flow controlled, full duplex switches that we use today. So why is it that you can build a nice system using crappy parts in some cases and not in others? Perhaps the constraint is time, and these systems didn't get all three of "good, fast, cheap" but only good and cheap. If that's the case, it places a boundary on how far you can go with an E2E model in large-scale networks. People want to use the Internet as more than a content network these days, because interpersonal communication is the real killer app for networking, and that takes QoS, and you can't do QoS E2E. Public policy needs to be constrained by engineering, as Noel said, but the engineering needs to be good, not ideological. RB Jon Crowcroft wrote: > I may fall down on relevance > (c.f. Deirdre Wilson & Dan Sperberr Relevance Theory, 1985) > but I think I am going to have to refer you to youtube: > > http://www.youtube.com/watch?v=2SNHtKfDxlg > > but anyhow, I suspect I am just as suspect as you > for what its worth... > > this has to be set against the rabid free market libertarianism > fairly common in Internet Research circles from 1992 until the present > day, which is also extremely unrepresentative of the world... > > In missive <4AE6F673.8080807 at reed.com>, "David P. Reed" typed: > > >>Is it the "aging" part or the "hippie" part that makes a person suspect? > > >>I could give you a list of labels that have been applied to me, in > >>discussions of network technology, to conjure with as you like: > >> > >>corporate-type, libertarian, communist, hippie, net-nutter, past-it, > >>ivory-tower, propellerhead, mere engineer, non-economist, naive, > >>fuzzy-minded, ... > >> > >>I personally don't think such labels make a whit of difference. > >> > >>In fact, I am a member of AAAS, AARP, ACLU, ACM, and that's only the > >>first four A's on the list of memberships. Does that make a difference? > >> > >>It turns out that one of my ancestors (John Reed) arrived in Rhode > >>Island in 1615, and another came to the US on Ellis Island. One of my > >>ancestors was at the battle of Lexington and Concord, and another was a > >>Gibson Girl on 42nd street, having immigrated into the country. My > >>father can be seen in documentary footage shot on the USS Missouri > >>during the Korean Conflict, and was in charge of designing many of the > >>modern US Navy ships now in service. > >> > >>Do those things make a difference? > >> > >>I guess the fellow who is responsible for WiFi and UWB knows how to > >>judge ideas by the person's lifestyle. > >> > >>And by the way, I'm neither aging (I'm 57, and can beat most people in > >>arm-wrestling, if nothing else), nor a classic "hippie" (my views in > >>those days tended toward a very different direction - a mixture of > >>systems design, AI, and math, mixed with stopping the Vietnam War and > >>creating a free market of ideas). > >> > >>But so what if I were? > > cheers > > jon > > -- Richard Bennett Research Fellow Information Technology and Innovation Foundation Washington, DC From davide+e2e at cs.cmu.edu Tue Oct 27 19:57:38 2009 From: davide+e2e at cs.cmu.edu (Dave Eckhardt) Date: Tue, 27 Oct 2009 22:57:38 -0400 Subject: [e2e] Protocols breaking the end-to-end argument In-Reply-To: <4AE765C3.1090303@bennett.com> Message-ID: <18710.1256698658@lunacy.ugrad.cs.cmu.edu> > [...] Ethernet only became dominant when we dumped CSMA/CD for > the collision-free, flow controlled, full duplex switches that > we use today. In the two environments I'm familiar with, Ethernet had firmly crowded out everything else (and there were other things: IBM Token Ring, Corvus OmniNet, AppleTalk over PhoneNet, LattisNet, etc.) when it was still half-duplex thin-net, which was replaced by 10-megabit twisted-pair into hubs, *then* 100-megabit twisted-pair into switches. I think there were a lot of places where Ethernet was dominant before switches... though maybe we're using different definitions of "dominant"? I think I mean something like "more than 90% of desktops". Dave Eckhardt From richard at bennett.com Tue Oct 27 23:34:45 2009 From: richard at bennett.com (Richard Bennett) Date: Wed, 28 Oct 2009 02:34:45 -0400 Subject: [e2e] Protocols breaking the end-to-end argument In-Reply-To: <18710.1256698658@lunacy.ugrad.cs.cmu.edu> References: <18710.1256698658@lunacy.ugrad.cs.cmu.edu> Message-ID: <4AE7E605.7010600@bennett.com> An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20091028/89cc429f/attachment.html From dhc2 at dcrocker.net Wed Oct 28 03:44:23 2009 From: dhc2 at dcrocker.net (Dave CROCKER) Date: Wed, 28 Oct 2009 06:44:23 -0400 Subject: [e2e] Protocols breaking the end-to-end argument In-Reply-To: <18710.1256698658@lunacy.ugrad.cs.cmu.edu> References: <18710.1256698658@lunacy.ugrad.cs.cmu.edu> Message-ID: <4AE82087.4040202@dcrocker.net> Dave Eckhardt wrote: >> [...] Ethernet only became dominant when we dumped CSMA/CD for >> the collision-free, flow controlled, full duplex switches that >> we use today. > > In the two environments I'm familiar with, Ethernet had firmly > crowded out everything else (and there were other things: IBM > Token Ring, Corvus OmniNet, AppleTalk over PhoneNet, LattisNet, > etc.) when it was still half-duplex thin-net, which was replaced > by 10-megabit twisted-pair into hubs, *then* 100-megabit > twisted-pair into switches. Yup. "Ethernet" collision-free switches came quite a bit after real ethernet dominated LANs. (The quotations are because the former presents an Ethernet interface but not Ethernet over the wire. Thicknet, thin-net, and I believe the original versions of twisted-pair, all used had the shared-access, collision-capable ethernet over the wire.) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dpreed at reed.com Wed Oct 28 05:13:40 2009 From: dpreed at reed.com (David P. Reed) Date: Wed, 28 Oct 2009 08:13:40 -0400 Subject: [e2e] Protocols breaking the end-to-end argument In-Reply-To: <4AE7E605.7010600@bennett.com> References: <18710.1256698658@lunacy.ugrad.cs.cmu.edu> <4AE7E605.7010600@bennett.com> Message-ID: <4AE83574.2050801@reed.com> On 10/28/2009 02:34 AM, Richard Bennett wrote: > CSMA/CD Ethernet was simply a best-efforts LAN, but switched Ethernet > is a QoS-capable WAN and facilities fabric as well; ever seen an > Internet Exchange Point? Big fat Ethernet switches sit at the heart > of them, passing multiple packets at a time in parallel. It's a whole > different concept of networking than the fat dumb pipe. > If I had seen an Internet Exchange point, what would looking at racks, cables, power supplies, etc. tell me exactly? And since the word "dumb pipe" is a construct largely used by operators who use it to describe a "business model", and to explain the Internet to Ted Stevens as a "series of tubes" but "not a dump-truck," what contribution to Internet architecture is being made by this idiotic thread now that Bennett has hooked people into his trolling rig? "whole different kind of networking" is a really useful description - it's up there with "carrier-grade" as a marketing concept that has no content. Bennett is *paid* by ITIF to throw out these kinds of statements, calculated to get someone to extend a conversational diversion. He is not contributing technically on this list which is about technology and architectural *research*. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20091028/29ebfeae/attachment.html From jtk at depaul.edu Wed Oct 28 05:21:20 2009 From: jtk at depaul.edu (John Kristoff) Date: Wed, 28 Oct 2009 07:21:20 -0500 Subject: [e2e] Protocols breaking the end-to-end argument In-Reply-To: <4AE82087.4040202@dcrocker.net> References: <18710.1256698658@lunacy.ugrad.cs.cmu.edu> <4AE82087.4040202@dcrocker.net> Message-ID: <20091028122120.GA27331@condor.depaul.edu> On Wed, Oct 28, 2009 at 06:44:23AM -0400, Dave CROCKER wrote: > >etc.) when it was still half-duplex thin-net, which was replaced > >by 10-megabit twisted-pair into hubs, *then* 100-megabit > >twisted-pair into switches. > > Yup. "Ethernet" collision-free switches came quite a bit after real > ethernet dominated LANs. 10 Mb/s Etherhet LAN switches arrived even before 100 Mb/s Ethernet was available, largely thanks to Kalpana (eventually bought by Cisco). In addition to hubs and other reasons, switches really helped answer criticisms of competing technologies such as Token Ring, eventually leading to Ethernet becoming the RS-232 of LAN technology. John From jnc at mercury.lcs.mit.edu Wed Oct 28 07:44:34 2009 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Wed, 28 Oct 2009 10:44:34 -0400 (EDT) Subject: [e2e] Protocols breaking the end-to-end argument Message-ID: <20091028144434.8BE676BE583@mercury.lcs.mit.edu> > From: Dave CROCKER > The quotations are because the former presents an Ethernet interface > but not Ethernet over the wire. Thereby becoming a perfect illustration of the systems architecture truism that _interfaces_ between subsystems are far more persistent (lifetime-wise) than the internals of the subsystem. Other examples of this phenomenon include the RJ-11 phone jack (both physically and electrically), the standard screw-in light bulb socket (now hosting those fluorescent spiral tube bulbs), etc, etc. Noel From davide+e2e at cs.cmu.edu Wed Oct 28 08:09:05 2009 From: davide+e2e at cs.cmu.edu (Dave Eckhardt) Date: Wed, 28 Oct 2009 11:09:05 -0400 Subject: [e2e] Protocols breaking the end-to-end argument In-Reply-To: <20091028122120.GA27331@condor.depaul.edu> Message-ID: <21118.1256742545@lunacy.ugrad.cs.cmu.edu> > 10 Mb/s Etherhet LAN switches arrived even before 100 Mb/s > Ethernet was available, largely thanks to Kalpana (eventually > bought by Cisco). The original claim used (without definition) the word "dominant". I proposed (without objection so far) the definition "90% of desktops". My counter-claim is that Ethernet was dominant (90% of desktops) without the arrival of switches having been the cause. The existence of a small number of 10-megabit switches doesn't force acceptance of one causal claim over the other. So how about this update: "Ethernet was serving 90% of desktops before 50% of those desktops were talking to switches"? Dave Eckhardt From davide+e2e at cs.cmu.edu Wed Oct 28 08:12:35 2009 From: davide+e2e at cs.cmu.edu (Dave Eckhardt) Date: Wed, 28 Oct 2009 11:12:35 -0400 Subject: [e2e] Protocols breaking the end-to-end argument In-Reply-To: <4AE7E605.7010600@bennett.com> Message-ID: <21130.1256742755@lunacy.ugrad.cs.cmu.edu> >> I think there were a lot of places where Ethernet was dominant >> before switches... though maybe we're using different definitions >> of "dominant"? I think I mean something like "more than 90% of >> desktops". > CSMA/CD Ethernet was simply a best-efforts LAN, but switched > Ethernet is a QoS-capable WAN and facilities fabric as well; > ever seen an Internet Exchange Point? Big fat Ethernet switches > sit at the heart of them, passing multiple packets at a time > in parallel. It's a whole different concept of networking than > the fat dumb pipe. I don't understand how your comment is a response to the testable claim I made in response to your incompletely specified claim. Dave Eckhardt From Maha.Abdallah at lip6.fr Tue Oct 27 06:14:39 2009 From: Maha.Abdallah at lip6.fr (Maha Abdallah) Date: Tue, 27 Oct 2009 14:14:39 +0100 Subject: [e2e] NetGames 2009 - Call for Participation (Nov. 23-24 - Paris, France) Message-ID: <47983aa62688c1c5861bf42c6177ff0e.squirrel@mailtwo.lip6.fr> CALL FOR PARTICIPATION ************************************************************************** * NetGames 2009 * * The 8th Annual Workshop on Network and Systems Support for Games * * November 23-24, 2009 * * Paris , France * * * * In co-operation with ACM SIGCOMM and ACM SIGMM * * Technically sponsored by IEEE Communications Society * * * * Early registration deadline: Nov 8, 2009 * * http://netgames2009.lip6.fr/ * ************************************************************************** We would like to cordially invite you to attend the 8th Annual Workshop on Network and Systems Support for Games (NetGames 2009), which will be held on November 23-24, 2009 in Paris, France. KEYNOTE SPEAKERS ================ Two exciting keynote talks will be given by distinguished speakers with tremendous experience in networked games and virtual environments: 1. Dr. Michael Macedonia (Vice President and General Manager, Forterra Federal Systems) Title: Next Generation Virtual Worlds 2. Dr. R?mi Arnaud (Chief Software Architect, Screampoint International) Title: Trends in 3D technologies and the impact on networked games OVERVIEW ======== The NetGames workshop is a major annual international workshop that brings together researchers and visionaries from academia, research labs, and industry to present new research in understanding networked games of today and in enabling the next generation of them. NetGames has become a recognized venue for Promoting exciting discussions among its participants in all areas related to online games and Virtual environments. Two keynotes addresses, and a total of 18 research papers, posters and demos spanning various topics related to networked games will be presented and discussed. We cordially invite you to attend the workshop and share with us your feedback, thoughts, and experience. Further details can be found at: http://netgames2009.lip6.fr/ ACCEPTED PAPERS =============== A. Full papers: ------------ Measurement and Analysis of World of Warcraft in Mobile WiMAX Networks Xiaofei Wang (Seoul national university, KR) Hyun-chul Kim (Seoul National University, KR) Taekyoung Kwon (Seoul National University, KR) Yanghee Choi (Seoul National University, KR) Sunghyun Choi (Seoul National University, KR) Jang Hanyoung (XRONet Corporation, KR) 802.11 Wireless LAN Multiplayer Game Capacity and Optimization Hanghang Qi (Hamilton Institute, NUIM, IE) David Malone (NUI Maynooth, IE) Dimitri D Botvich (Waterford Institute of Technology, IE) Hack, Slash, and Chat: A study of players? behavior and communication in MMORPGs Mirko Su?njevic (University of Zagreb, HR) Ognjen Dobrijevic (University of Zagreb, HR) Maja Matijasevic (University of Zagreb, HR) Peer NAT Proxies for Peer-to-Peer Applications Daryl Seah (National University of Singapore, SG) Wai Kay Leong (National University of Singapore, SG) Qingwei Yang (National University of Singapore, SG) Ben Leong (National University of Singapore, SG) Razeen Ali (National University of Singapore, SG) Distributed Avatar Management for Second Life Matteo Varvello (Eurecom - Thomson, FR) Stefano Ferrari (Politecnico di torino, IT) Ernst W Biersack (EURECOM, FR) Christophe Diot (Thomson, FR) PlayerRating: A Reputation System for Multiplayer Online Games Ed Kaiser (Portland State University, US) Wu-chang Feng (Portland State University, US) Avatar movement in World of Warcraft Battlegrounds John L. Miller (Microsoft Research, Cambridge, UK) Jon Crowcroft (University of Cambridge, UK) The Impact of Virtualization on the Performance of Massively Multiplayer Online Games Vlad Nae (University of Innsbruck, AT) Alexandru Iosup (Delft University of Technology, NL) Radu Prodan (University of Innsbruck, AT) Thomas Fahringer (University of Innsbruck, AT) Evaluating Ginnungagap: a middleware for migration of partial game-state utilizing core-selection for latency reduction Paul B Beskow (Simula Research Laboratory, NO) Geir Erikstad (Simula Research Laboratory/University of Oslo, NO) P?l Halvorsen (Simula Research Laboratory, NO) Carsten Griwodz (Simula Research Laboratory, NO) Bandwidth-Aware Peer-to-Peer 3D Streaming Chien-Hao Chien (National Central University, TW) Shun-Yun Hu (National Central University, TW) Jehn-Ruey Jiang (National Central University, TW) B. Posters & Demos: ---------------- FizzX: Multiplayer Time Manipulation in Networked Games Colin Towle (University of Ottawa, CA) Pascal Proulx (University of Ottawa, CA) Saurabh Ratti (University of Ottawa, CA) Shervin Shirmohammadi (University of Ottawa, CA) Transparency Analysis and Haptic Synchronization for Transparency of Force-reflecting Teleoperation Seokhee Lee (Gwangju Institute of Science and Technology, KR) Yutaka Ishibashi (Nagoya Institute of Technology, JP) JongWon Kim (GIST (Gwangju Institute of Science & Technology), KR) AOI cast by Tolerance Based Compass Routing in Distributed Virtual Environments Michele Albano (University of Pisa, IT) Luca Genovali (IMT, IT) Antonio Quartulli (University of Trento, IT) Laura Ricci (University of Pisa, IT) Peer-to-Peer Support for Low-Latency Massively Multiplayer Online Games in the Cloud Richard S?selbeck (University of Mannheim, DE) Gregor A Schiele (University of Mannheim, DE) Christian Becker (Universit?t Mannheim, DE) Player-Customized Puzzle Instance Generation for Massively Multiplayer Online Games Alexandru Iosup (Delft University of Technology, NL) On Prophesying Online Gamer Departure Pin-Yun Tarng (National Taiwan University, TW) Kuan-Ta Chen (Academia Sinica, TW) Polly Huang (National Taiwan University, TW) Capturing and Storing Profile Information for Gamers Playing Multiplayer Online Games Tomas Hildebrandt (TU Darmstadt, DE) Sonja Bergstr??er (Technical University of Darmstadt, DE) Christoph Rensing (Technical University of Darmstadt, DE) Ralf Steinmetz (Technische Universitaet Darmstadt, DE) Interconnection of Game Worlds and Physical Environments in Educational Settings Raphael Zender (University of Rostock, DE) Ulrike Lucke (University of Rostock, DE) Dennis Maciuszek (University of Rostock, DE) Alke Martens (University of Rostock, DE) From dhc2 at dcrocker.net Wed Oct 28 09:23:47 2009 From: dhc2 at dcrocker.net (Dave CROCKER) Date: Wed, 28 Oct 2009 12:23:47 -0400 Subject: [e2e] Protocols breaking the end-to-end argument In-Reply-To: <20091028144434.8BE676BE583@mercury.lcs.mit.edu> References: <20091028144434.8BE676BE583@mercury.lcs.mit.edu> Message-ID: <4AE87013.8080201@dcrocker.net> Noel Chiappa wrote: > Thereby becoming a perfect illustration of the systems architecture truism > that _interfaces_ between subsystems are far more persistent (lifetime-wise) > than the internals of the subsystem. > > Other examples of this phenomenon include the RJ-11 phone jack (both > physically and electrically), the standard screw-in light bulb socket (now > hosting those fluorescent spiral tube bulbs), etc, etc. A particularly fun example of this is RFC 1001/1002, which re-implemented NetBIOS. Preserve the IBM API, but use TCP protocols. (There had been a couple of proprietary non-IBM TCP versions earlier; this created a standard.) Had IBM published the underlying protocols, the TCP version would no doubt have been quite different. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From richard at bennett.com Wed Oct 28 20:09:11 2009 From: richard at bennett.com (Richard Bennett) Date: Wed, 28 Oct 2009 23:09:11 -0400 Subject: [e2e] Protocols breaking the end-to-end argument In-Reply-To: <21118.1256742545@lunacy.ugrad.cs.cmu.edu> References: <21118.1256742545@lunacy.ugrad.cs.cmu.edu> Message-ID: <4AE90757.2090405@bennett.com> An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20091028/63a2fa10/attachment.html From richard at bennett.com Wed Oct 28 20:15:48 2009 From: richard at bennett.com (Richard Bennett) Date: Wed, 28 Oct 2009 23:15:48 -0400 Subject: [e2e] Protocols breaking the end-to-end argument In-Reply-To: <4AE87013.8080201@dcrocker.net> References: <20091028144434.8BE676BE583@mercury.lcs.mit.edu> <4AE87013.8080201@dcrocker.net> Message-ID: <4AE908E4.6020208@bennett.com> I had personally seen the source code to the IBM/Sytek protocols, under NDA, for NETBIOS/SMB before RFC 1001/2 were written, which is one reason I could only be a cheerleader for 1001/2. At Tandem we implemented an SMB server under the T16's Guardian OS. SMB wasn't too hard to reverse engineer, as the SAMBA guys found out; the IBM PC Network was harder, so we used a PC with both PC Network and Ethernet cards as a bridge. Dave CROCKER wrote: > > > Noel Chiappa wrote: >> Thereby becoming a perfect illustration of the systems architecture >> truism >> that _interfaces_ between subsystems are far more persistent >> (lifetime-wise) >> than the internals of the subsystem. >> >> Other examples of this phenomenon include the RJ-11 phone jack (both >> physically and electrically), the standard screw-in light bulb socket >> (now >> hosting those fluorescent spiral tube bulbs), etc, etc. > > > A particularly fun example of this is RFC 1001/1002, which > re-implemented NetBIOS. Preserve the IBM API, but use TCP protocols. > (There had been a couple of proprietary non-IBM TCP versions earlier; > this created a standard.) > > Had IBM published the underlying protocols, the TCP version would no > doubt have been quite different. > > d/ > -- Richard Bennett Research Fellow Information Technology and Innovation Foundation Washington, DC From william.allen.simpson at gmail.com Thu Oct 29 01:29:31 2009 From: william.allen.simpson at gmail.com (William Allen Simpson) Date: Thu, 29 Oct 2009 04:29:31 -0400 Subject: [e2e] Protocols breaking the end-to-end argument In-Reply-To: <4AE82087.4040202@dcrocker.net> References: <18710.1256698658@lunacy.ugrad.cs.cmu.edu> <4AE82087.4040202@dcrocker.net> Message-ID: <4AE9526B.7050306@gmail.com> Dave CROCKER wrote: > Dave Eckhardt wrote: >> Richard Bennett wrote: >>> [...] Ethernet only became dominant when we dumped CSMA/CD for >>> the collision-free, flow controlled, full duplex switches that >>> we use today. >> >> In the two environments I'm familiar with, Ethernet had firmly >> crowded out everything else (and there were other things: IBM >> Token Ring, Corvus OmniNet, AppleTalk over PhoneNet, LattisNet, >> etc.) when it was still half-duplex thin-net, which was replaced >> by 10-megabit twisted-pair into hubs, *then* 100-megabit >> twisted-pair into switches. > > Yup. "Ethernet" collision-free switches came quite a bit after real > ethernet dominated LANs. > Agreed, as to multi-point LAN technology, but only after circa 1990. One of the environments that I wrestled with during the '80s was considered the largest thicknet installation in the world. But even then, terminals, computers, and entire facilities were primarily connected with one or more variants of a poll-select protocol over RS-232. There were usually two serial connectors on every machine (with no ethernet at all). Even today, there are *far* more point-to-point WAN links than ethernet. I have the advantage of working on far more than 2 facilities. Token ring and related were never more than fragile and overpriced disasters. The market spoke, even when big industry was trying to force them down our throats. The pedant that interrupted this thread appears to be fairly clueless about real deployment. And his economic analysis is ... ill-informed. Perhaps that's a reason that IEEE 802 development in general was so conservative and poorly done. From davide+e2e at cs.cmu.edu Thu Oct 29 11:05:58 2009 From: davide+e2e at cs.cmu.edu (Dave Eckhardt) Date: Thu, 29 Oct 2009 14:05:58 -0400 Subject: [e2e] Protocols breaking the end-to-end argument In-Reply-To: <4AE90757.2090405@bennett.com> Message-ID: <30424.1256839558@lunacy.ugrad.cs.cmu.edu> > It strikes me that your 90% claim is a bit of an exaggeration, > and more importantly that it misses the point. Actually, I was trying to get you to define what you meant by "Ethernet became dominant" by proposing a definition, since you hadn't. > Define "the market" as all the places where switched Ethernet > is used today, crank in some realistic shares, and tell me > what you get; by guess is that coax Ethernet was deployed in > around 10-20% of the places where twisted pair and optical > Ethernet LANs, MANs, and WANs are used today Now I get it: when you wrote "Ethernet only became dominant when we dumped CSMA/CD for the collision-free, flow controlled, full duplex switches that we use today" you meant something like "Switches were a necessary addition to Ethernet before it could grow from a single-building LAN to a campus-spanning technology". I buy that, because treating an entire campus or medium-sized company as one collision domain wouldn't have worked out very well. On the other hand... > ARCNet was very big in desktop connections, as far as that > goes, especially in IBM shops because it used the 3270 PHY. I don't think any of Ethernet's competitors would have scaled very well either--ARCNet had single-byte node addresses; Token Ring would have been painful if you had to share a transmit token with thousands of other machines; etc. So it's unclear that CSMA/CD was a structural limit of Ethernet--the reality is probably more like "It doesn't matter much how you contend among a few hosts, but you can't build large networks unless you limit contention domains to less than the size of the large network", which is almost a tautology. Dave Eckhardt From L.Wood at surrey.ac.uk Thu Oct 29 12:43:17 2009 From: L.Wood at surrey.ac.uk (Lloyd Wood) Date: Thu, 29 Oct 2009 19:43:17 +0000 Subject: [e2e] Protocols breaking the end-to-end argument In-Reply-To: <30424.1256839558@lunacy.ugrad.cs.cmu.edu> References: <30424.1256839558@lunacy.ugrad.cs.cmu.edu> Message-ID: On 29 Oct 2009, at 18:05, Dave Eckhardt wrote: > > Define "the market" as all the places where switched Ethernet >> is used today, crank in some realistic shares, and tell me >> what you get; by guess is that coax Ethernet was deployed in >> around 10-20% of the places where twisted pair and optical >> Ethernet LANs, MANs, and WANs are used today > > Now I get it: when you wrote "Ethernet only became dominant > when we dumped CSMA/CD for the collision-free, flow controlled, > full duplex switches that we use today" you meant something > like "Switches were a necessary addition to Ethernet before > it could grow from a single-building LAN to a campus-spanning > technology". I buy that, because treating an entire campus > or medium-sized company as one collision domain wouldn't have > worked out very well. Never mind that. Two anecdotes from the early days of my comparatively late PhD studies (1996 or so): 1. The networks lab was next to the artificial intelligence lab. The AI students were cooler than we were; they dressed better, had more funding, and had laptop computers. But, in connecting the laptops to the Ethernet LAN, they didn't care how a big shared Ethernet coax LAN worked. They'd just hook up connections any old how, T off more coax, disconnect when they were done... and often they'd bring the network down, usually just before they locked up and took their laptops home for the day. Never mind collisions. Ethernet switches were necessary just to protect against and isolate the users. 2. Everyone in networks was working on ATM, and talking about the Next Big Thing: 25Mbps ATM to the desktop. I kept looking at the 10Mbps Ethernet we were already using all the time every day along with the TCP/IP stack to do daily work on and send emails about ATM, thinking "Something is wrong with this picture." L. DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/ From touch at ISI.EDU Fri Oct 30 15:45:25 2009 From: touch at ISI.EDU (Joe Touch) Date: Fri, 30 Oct 2009 15:45:25 -0700 Subject: [e2e] a note about some ad hominem attacks Message-ID: <4AEB6C85.3050007@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, all, I sent out a few notes off-list direct to those whose posts included what could be considered ad hominem attacks. As a reminder, such behavior on this list is a quick ticket to having your posts held for administrative review - which means (at best) once daily, with a 24-hour lag. To be safe, please avoid any claims or judgments about individuals. Joe (as list admin) PS - Anyone who feels personally slighted can send me a note off-list, and I'll evaluate the post and send them a warning if deemed appropriate and not already sent. PPS - If you've received more than one of these notes (as I'm catching up), consider yourself on *very* thin ice. PPPS - If you didn't yet receive a note, don't assume you haven't exhibited poor behavior. - -- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkrrbIUACgkQE5f5cImnZrsmxQCguxudtyfyqNeoth+byFuoZ4an AXAAnixJ+OnsiZ1LFmRdb9gvrrKCmlYV =Ob11 -----END PGP SIGNATURE----- From richard at bennett.com Sat Oct 31 14:46:55 2009 From: richard at bennett.com (Richard Bennett) Date: Sat, 31 Oct 2009 17:46:55 -0400 Subject: [e2e] Switched Ethernet is Not an End-to-End System; was Protocols breaking the end-to-end argument In-Reply-To: <30424.1256839558@lunacy.ugrad.cs.cmu.edu> References: <30424.1256839558@lunacy.ugrad.cs.cmu.edu> Message-ID: <4AECB04F.8020802@bennett.com> Dave Eckhardt wrote: > So it's unclear > that CSMA/CD was a structural limit of Ethernet--the reality > is probably more like "It doesn't matter much how you contend > among a few hosts, but you can't build large networks unless > you limit contention domains to less than the size of the > large network", which is almost a tautology. > That's part of the story, but the implications of the switched Ethernet killing off CSMA/CD Ethernet are much larger, and relate the end-to-end arguments principle. CSMA/CD Ethernet was an end-point managed system sharing a dump pipe, while switched Ethernet is a system that deploys intelligence - switching, flow control, buffering, QoS discrimination, VLANs - inside the network at multiple points. Switched Ethernet is scalable, manageable, diagnosable, and future-proof, while CSMA/CD Ethernet is none of these things. So the competition of CSMA/CD and Active Switching for markets demonstrates something about which approach to the design of layer 2 networks is superior. Now the question that this historical fact raises for me is whether we can draw any implications from the well-settled outcome of the layer 2 tussle for layer 3 and 4 protocols, given the fact that IP is a very thin abstraction of the Ethernet layer 2 and that TCP is a vehicle for resolving problems that are typical of the CSMA/CD Ethernet environment; I offer that as a realistic assessment of the design choices, realizing that the official story differs from the reality. In other words: does the success of Switched Ethernet suggest that it's better to think of network protocols as units of recursion than as collections of statically-placed functions that operate once and only once in the lifetime of a packet? RB -- Richard Bennett Research Fellow Information Technology and Innovation Foundation Washington, DC From dpreed at reed.com Sat Oct 31 20:04:22 2009 From: dpreed at reed.com (David P. Reed) Date: Sat, 31 Oct 2009 23:04:22 -0400 Subject: [e2e] Switched Ethernet is Not an End-to-End System; was Protocols breaking the end-to-end argument In-Reply-To: <4AECB04F.8020802@bennett.com> References: <30424.1256839558@lunacy.ugrad.cs.cmu.edu> <4AECB04F.8020802@bennett.com> Message-ID: <4AECFAB6.8030705@reed.com> On 10/31/2009 05:46 PM, Richard Bennett wrote: > the fact that IP is a very thin abstraction of the Ethernet layer 2 > and that TCP is a vehicle for resolving problems that are typical of > the CSMA/CD Ethernet environment This statement is nonsense. IP is not a very thin abstraction of Ethernet layer 2. IP is carried over many protocols other than the Ethernet. TCP is an end-to-end protocol for in-order virtual circuit data delivery, designed to work over IP, and to handle problems that have nothing to do with CSMA/CD. > In other words: does the success of Switched Ethernet suggest that > it's better to think of network protocols as units of recursion than > as collections of statically-placed functions that operate once and > only once in the lifetime of a packet? No. This is also nonsense, and begs the question. Network protocols have never been described as not "collections of statically-placed functions that operate once and only once in the lifetime of a packet". Nor does the "success" of anything in the marketplace suggest how to think.