From detlef.bosau at web.de Mon Apr 1 03:56:10 2013 From: detlef.bosau at web.de (Detlef Bosau) Date: Mon, 01 Apr 2013 12:56:10 +0200 Subject: [e2e] How many TCP flows fit in the Internet? In-Reply-To: <8C48B86A895913448548E6D15DA7553B7ECC8D@xmb-rcd-x09.cisco.com> References: <5156F6BB.8050901@web.de> <8C48B86A895913448548E6D15DA7553B7ECC8D@xmb-rcd-x09.cisco.com> Message-ID: <515967CA.4050303@web.de> Am 01.04.2013 02:24, schrieb Fred Baker (fred): > On Mar 30, 2013, at 7:29 AM, Detlef Bosau wrote: > >> Actually, the Internet has limited, if huge, capacity and the issue is to share this in a reasonable manner. > Numbers in the integer space may be very large, but are generally finite. That's a breaking mathematical insight :-) > Yes, one can have only so many simultaneously-active active TCP sessions on any given link that actually accomplish something. > > The next question is how to figure out what "so many" means. This is a complementary view to the discussion between Matt and me. Either we allow for an unbounded number of simultaneous flows, than we cannot tolerate an, if implicit, "minimal throughput" or "minimal rate" for the flow. Or, which I think is the easier and actually more reasonable way, we well accept a minimal rate MSS/RTT, then we cannot accept an unbounded number of flows. The latter may lead into a discussion about a means of admission control. I'm curious, which alternative causes the larger protest in the community ;-) However both are trivial consequences from TANSTAAFL. > I suspect that the most useful number is related somehow to a measure of bandwidth. How do we measure bandwidth? I well know several approaches, packet pair, packet train, packet whatever, packet brigade, national guard of packetiers, no one is really convincing, however all of these mix up physical throughput ("bandwidth") and the share of throughput available for a flow. A possible way would be some kind of explicit scheduling of flows on routers or switches, however this beyond the scope of what is actually being done in the Internet. I'm still to read Keshav's thesis, however I think we have two extreme positions: No central regulation, best effort and the "packet switching community", central regulation, QoS and the "circuit switching community". For quite some time now, I'm curious whether there is some "third way" in between. > If we assume that a mouse might move one MSS each way, or an elephant will want to move one MSS per RTT for several RTTs, the question is the duration of an MSS on the wire and the duration of a typical RTT; you're probably not going to have more active sessions simultaneously than some small multiple of the ratio of RTT to MSS. Up to know, I was fine :-) I'm totally with you and when I consider a "third way", the mouse/elephant issue you refer to directly turns into a scalability issue. This is not a trivial one. > > That question, of course, has similarities to the question of how many angels can dance on the head of a pin. Although in the real world you would rather encounter TCP flows than angels ;-) (From an operational point of view, network operators often would prefer it the other way round ;-)) > That will perhaps have as a limiting function the ratio of the surface area of a head of a pin to the sole of an angel's foot. But when dancing, don't angels sometimes have their feet in the air? TCP will have the same problem. At least extremely similar. However, we meet another sacred cow here. One of the most sacred cows in the elephantastic Internet community is to ignore the mere existence of mice ;-) (Without kidding: For decades, the loudest unspoken assumption in our papers are "sources are greedy" and "there are only long term flows".) -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From william.allen.simpson at gmail.com Tue Apr 2 00:34:58 2013 From: william.allen.simpson at gmail.com (William Allen Simpson) Date: Tue, 02 Apr 2013 03:34:58 -0400 Subject: [e2e] How many TCP flows fit in the Internet? In-Reply-To: References: <5156F6BB.8050901@web.de> <515819A0.7070405@web.de> Message-ID: <515A8A22.6010705@gmail.com> On 3/31/13 2:08 PM, Matt Mathis wrote: > You may have overlooked one additional important detail: > > Linux TCP ignores the requirement in RFC 2018 that the SACK scoreboard > be cleared on a timeout. [...] > There is an errata against 2018, with the relevant details. RFC content and the relevant protocol details aren't changed by "errata". We generally only pay attention to what's actually specified by the RFC, not what some Linux implementer decided might be better. > Thanks, > --MM-- > The best way to predict the future is to create it. - Alan Kay > > Privacy matters! We know from recent events that people are using our > services to speak in defiance of unjust governments. We treat > privacy and security as matters of life and death, because for some > users, they are. > Excellent! From detlef.bosau at web.de Tue Apr 2 02:53:53 2013 From: detlef.bosau at web.de (Detlef Bosau) Date: Tue, 02 Apr 2013 11:53:53 +0200 Subject: [e2e] How many TCP flows fit in the Internet? In-Reply-To: <515A8A22.6010705@gmail.com> References: <5156F6BB.8050901@web.de> <515819A0.7070405@web.de> <515A8A22.6010705@gmail.com> Message-ID: <515AAAB1.9010705@web.de> Am 02.04.2013 09:34, schrieb William Allen Simpson: > On 3/31/13 2:08 PM, Matt Mathis wrote: >> You may have overlooked one additional important detail: >> >> Linux TCP ignores the requirement in RFC 2018 that the SACK scoreboard >> be cleared on a timeout. [...] >> There is an errata against 2018, with the relevant details. > > RFC content and the relevant protocol details aren't changed by > "errata". We generally only pay attention to what's actually > specified by the RFC, not what some Linux implementer decided > might be better. > In this particular case, however, the Linux implementation does make more sense then what's written in RFC 2018. Wouldn't it be helpful then to update this RFC by a new one? -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From detlef.bosau at web.de Tue Apr 2 03:07:33 2013 From: detlef.bosau at web.de (Detlef Bosau) Date: Tue, 02 Apr 2013 12:07:33 +0200 Subject: [e2e] How many TCP flows fit in the Internet? In-Reply-To: <5158B741.1030206@web.de> References: <5156F6BB.8050901@web.de> <515819A0.7070405@web.de> <5158B741.1030206@web.de> Message-ID: <515AADE5.4090702@web.de> I would like refer to mobile networks in this discussion. Particularly in mobile networks it may be the case that the throughput on the air interface drops below 1 MSS/RTT, whatever the meaning of "RTT" would mean here. However, when we encounter a throughput of, say, 300 bit/s this would certainly be a "low throughtput" in this sense. When we have a constant, stationary throughput of 300 bit/s then the timer back off would be sufficient: Perhaps, it takes some time outs to sufficiently increase RTO and afterwards, a stationary RTT (say 1 second) and variance (say 0.5 seconds) can well be treated. Unfortunately, a mobile network's throughput is hardly constant or stationary. This may have several reasons, we recently talked about GPRS and I was pointed to implementation deficiencies there - however, a user wouldn't be more comfortable with a huge RTT if he knew, that this is due to the implementation ;-) However, from recent discussions I think we can identify at least three reasons for huge RTT: 1. Low throughput on a link, e.g. a mobile link with noise on its air interface, 2. Network overload 3. Buffer bloat. Would you agree here? I'm curious whether these three cases could, or should, be treated using the same mechanism. Detlef -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From vitacaishun at gmail.com Tue Apr 2 04:20:47 2013 From: vitacaishun at gmail.com (shun cai) Date: Tue, 2 Apr 2013 19:20:47 +0800 Subject: [e2e] Why do we need congestion control? In-Reply-To: <0037066628D6FC449C61186553CAE11D032D43A83ED9@njfpsrvexg2.research.att.com> References: <0037066628D6FC449C61186553CAE11D032D43A83ED9@njfpsrvexg2.research.att.com> Message-ID: Hi£¬ I found two papers which state that with ideal fountain code,there is generally no congestion collapse.Efficiency remains higher than 90% for most network topologiesas long as maximum source rates are less than link capacity by one or two orders of magnitude. Moreover, a simple fair drop policy enforcing fair sharing at flow level is sufficient to guarantee 100% efficiency in all cases. I refer to several papers on the congestion problem when fountain code is used. [1] [2] [1] Bonald, T., M. Feuillet, et al. (2009). *Is the''Law of the Jungle''Sustainable for the Internet?* INFOCOM 2009, IEEE [2] B. Raghavan and A. Snoeren. Decongestion control. In HOTNETS-V, 2006. 2013/3/7 RAMAKRISHNAN, KADANGODE (K. K.) > I want to second what Jon and Keshav say with regard to the assistance > provided by coding, but the limitations that arise in an environment > without effective congestion control. > > We'd explored the benefit of coding (admittedly simple R-S codes) at the > end-end transport layer to complement TCP, so as to help sustain losses on > wireless links, in our work on LT-TCP. > We did see the benefit of coding, to extend the dynamic range of transport > protocols to tolerate higher loss rates, but only up to a point. Beyond > that, you see the same results as you would see in an uncontrolled > environment where losses (and the resulting wasted work) begin to dominate > the utilization of the resources in the network. That is without paying > attention to the delays that result from excessive losses that cause the > receiver to wait to reconstruct a block. There is still the need for > reasonable congestion control mechanisms to keep from causing excessive > losses. And Keshav's point of the unfairness across flows in the short term > and the eventual result of everyone losing out is certainly important to > keep in mind. > > Finally, I heartily agree with Jon's last point regarding ECN... > > -- > K. K. Ramakrishnan Email: kkrama at research.att.com > AT&T Labs-Research, Rm. A161 Tel: (973)360-8764 > 180 Park Ave, Florham Park, NJ 07932 Fax: (973) 360-8871 > URL: > http://www.research.att.com/people/Ramakrishnan_Kadangode_K/index.html > > > -----Original Message----- > From: end2end-interest-bounces at postel.org [mailto: > end2end-interest-bounces at postel.org] On Behalf Of Jon Crowcroft > Sent: Wednesday, March 06, 2013 10:03 AM > To: shun cai > Cc: Jon.Crowcroft at cl.cam.ac.uk; end2end-interest at postel.org > Subject: Re: [e2e] Why do we need congestion control? > > ok - i see your point - this is true if your sources have a peak rate they > can send at > > this could be the line rate of their uplink - > that would be embarrasingly bad > (see keshav's followup on escalating costs of coding) > or the rate they can get data off disk (which could be as bad, but might > be lower) > or an application specific rate (e.g. streamed video) for which you're > suggestion is > quite reasonable.... > > but for data sources which are greedy > (TCP with arbitrarily large files) > you need a way to tell sources a non wasteful way of sending - > > and what is more > there isn't just one set of sources in one location > and a set of sinks in one other location > so the system of senders sending at > unconstrainted rates on a finite speed net with high speed edges, > would create multiple bottlenecks, > which would exponentiate the problem > > coding isn't magic - its info theory - if you lose info > you must add redundency - coding does it pre-emptively > rather than post-hoc the way ARQ/Retransmit does, > which saves you time, but in the end, can't defer the inevitable > > if you look at digital fountin systems for video > they pick a likely loss rate, pick a tolerable picture degradation rate > and use those to derive/choose a code > > the assumption is that the losses are capped because most other systems > are backing off just like TCP - if you break that assumption, > you'll break the coding parameter choice > > anyhow, roll out ECN - much betterer technology:) > congestion avoidance without keeping queues filled everywhere... > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20130402/db0853d2/attachment.html From detlef.bosau at web.de Tue Apr 2 05:53:49 2013 From: detlef.bosau at web.de (Detlef Bosau) Date: Tue, 02 Apr 2013 14:53:49 +0200 Subject: [e2e] Why do we need congestion control? In-Reply-To: References: <0037066628D6FC449C61186553CAE11D032D43A83ED9@njfpsrvexg2.research.att.com> Message-ID: <515AD4DD.4030809@web.de> Am 02.04.2013 13:20, schrieb shun cai: > Hi£¬ > > I found two papers which state that with ideal fountain code,there is > generally no congestion collapse.Efficiency remains higher than 90% > for most network topologiesas long as maximum source rates are less > than link capacity by one or two orders of magnitude. Moreover, a > simple fair drop policy enforcing fair sharing at flow level is > sufficient to guarantee 100% efficiency in all cases. I refer to > several papers on the congestion problem when fountain code is used. > [1] [2] > Don't we compare peaches and oranges here? When we talk about TCP, we talk about a reliable protocol. Are digital fountain codes reliable?? -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20130402/228caffe/attachment.html From oliver at net.t-labs.tu-berlin.de Tue Apr 2 05:58:17 2013 From: oliver at net.t-labs.tu-berlin.de (Oliver Hohlfeld) Date: Tue, 2 Apr 2013 14:58:17 +0200 Subject: [e2e] Do we have buffer bloat on edge routers or on core routers? In-Reply-To: <8C48B86A895913448548E6D15DA7553B7EBBB3@xmb-rcd-x09.cisco.com> References: <51547467.20607@web.de> <8C48B86A895913448548E6D15DA7553B7EBBB3@xmb-rcd-x09.cisco.com> Message-ID: <20130402125816.GA14420@net.t-labs.tu-berlin.de> On Sat, Mar 30, 2013 at 10:11:34PM +0000, Fred Baker (fred) wrote: > Mark Allman recently published a paper, in which he says that his massively over-provisioned FIOS network doesn't seem to have this problem, so he doesn't think it's a real problem. That's a commonly discussed misunderstanding of Marks paper (see related discussions in the bloat and tsvwg mailing list, e.g., posts by Mark Allman). His paper is /not/ about measuring buffer bloat in an FTTH network. While his /vantage point/ is indeed located in the FTTH network, the paper actually measures buffer bloat in various remote networks. Also Marks paper is not the only study suggesting the extend of the problem to be modest. The presented results are in line with recent findings by Chirichella and Rossi [1]. Based on unpublished work, I can confirm the low magnitude of the problem. I analyzed passive measurements of residential users traffic from multiple continents (~60 million IPs originating from 50\% of all ASes) and rarely find excessive RTTs that, among other problems, can indicate the presence of buffer bloat. One reason for the outcome of these studies is that users often do not sustainably utilize their uplink capacity and fill-up their potentially large queues. > The primary way that network designers can reduce buffer bloat is > over-provisioning. This assumes that buffer bloat mainly occurs in the core. However, the current evidence suggest it to be a problem in the edge: oversized buffers in hosts, 3G, cable / DSL modems or home routers have been shown to be often oversized and thus have the potential to inject large queueing delays when filled. To me, buffer bloat is more of a configuration problem than a fundamental network problem. The first step in resolving buffer bloat should therefore be fixing the misconfigurations by deploying reasonable sized buffers in edge equipment. This is an initiative that is currently taken in DOCSIS standards to give cable operators the chance to tune the buffer size in the deployed edge devices. Once buffers are reasonably sized, the effect on end-user experience might not be that large as suggested by this work: BufferBloat: How Relevant? A QoE Perspective on Buffer Sizing. Oliver Hohlfeld, Enric Pujol, Florin Ciucu, Anja Feldmann, Paul Barford http://downloads.ohohlfeld.com/paper/bufferbloat-qoe-tr.pdf We found network workload / congestion, rather than buffer size, to be the primary determinant of end-user experience. In this way, I agree with you that any means to reduce congestion, e.g., by over-provisioning links, will improve user experience. However, this is very specific to the core and I haven't seen much evidence of buffer bloat in the core. To me, over-provisioning doesn't apply much to residential access lines. Other means to improve are QoS / service differentiation, or queue management. Oliver From detlef.bosau at web.de Tue Apr 2 07:36:24 2013 From: detlef.bosau at web.de (Detlef Bosau) Date: Tue, 02 Apr 2013 16:36:24 +0200 Subject: [e2e] Do we have buffer bloat on edge routers or on core routers? In-Reply-To: <20130402125816.GA14420@net.t-labs.tu-berlin.de> References: <51547467.20607@web.de> <8C48B86A895913448548E6D15DA7553B7EBBB3@xmb-rcd-x09.cisco.com> <20130402125816.GA14420@net.t-labs.tu-berlin.de> Message-ID: <515AECE8.8060908@web.de> Am 02.04.2013 14:58, schrieb Oliver Hohlfeld: > > One reason for the outcome of these studies is that users often do not > sustainably utilize their uplink capacity and fill-up their potentially > large queues. As a quite general remark let me say, that it is not a user's job to utilize his uplink capacity. (O.k., some German tabloids and some Internet discussions do not so indicate, however, in general it is the network's job to serve the user - and never the other way round.) I've seen quite some papers who stated the contrary and wrote sophisticated algorithms to utilize a potential uplink capacity, in my opinion this is a completely wrong understanding of computer networking. >> The primary way that network designers can reduce buffer bloat is >> over-provisioning. > This assumes that buffer bloat mainly occurs in the core. > However, the current evidence suggest it to be a problem > in the edge: oversized buffers in hosts, 3G, cable / DSL modems > or home routers have been shown to be often oversized and > thus have the potential to inject large queueing delays > when filled. Perhaps we do not always realize the reason for buffering. In some cases we want to harmonize arrival patterns and service patterns, in other cases (3G and the like) the purpose of buffering is work conservation. Both are valid reasons. The question is whether one and the same buffer can successfully and, most of all, in an acceptable manner, serve both purposes. > > To me, buffer bloat is more of a configuration problem than > a fundamental network problem. The first step in resolving > buffer bloat should therefore be fixing the misconfigurations > by deploying reasonable sized buffers in edge equipment. What is "reasonably sized"? It is particularly this "one size fits all" attitude which I think is highly questionable. Buffers may serve different purposes and so we should allow for different requirements and sizes. > This is an initiative that is currently taken in DOCSIS > standards to give cable operators the chance to tune the > buffer size in the deployed edge devices. OMG ;-) Oliver, admittedly the world has no problems. So, we Germans create one: We detect that after the unification we forgot to provide eastern Germany with appropriate Internet supply and now we revive commercial approaches from the 80s and early 90s.-- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From Emmanuel.LOCHIN at isae.fr Tue Apr 2 09:15:55 2013 From: Emmanuel.LOCHIN at isae.fr (LOCHIN Emmanuel) Date: Tue, 02 Apr 2013 18:15:55 +0200 Subject: [e2e] =?utf-8?q?Why_do_we_need_congestion_control=3F?= In-Reply-To: <515AD4DD.4030809@web.de> References: <0037066628D6FC449C61186553CAE11D032D43A83ED9@njfpsrvexg2.research.att.com> <515AD4DD.4030809@web.de> Message-ID: Le 02.04.2013 14:53, Detlef Bosau a ?crit?: > Am 02.04.2013 13:20, schrieb shun cai: > >> Hi? >> >> I found two papers which state that with ideal fountain code,there >> is generally no congestion collapse.Efficiency remains higher than >> 90% for most network topologiesas long as maximum source rates are >> less than link capacity by one or two orders of magnitude. Moreover, >> a simple fair drop policy enforcing fair sharing at flow level is >> sufficient to guarantee 100% efficiency in all cases. I refer to >> several papers on the congestion problem when fountain code is used. >> [1] [2] > Don't we compare peaches and oranges here? > > When we talk about TCP, we talk about a reliable protocol. Are > digital fountain codes reliable?? Hi Detlef In these papers the authors consider "perfect code", meaning that all the redundancy is useful. Look at our implementation of Decongestion Control Protocol : http://www.lochin.net/tetrysjungle.pdf where full reliability is achieved without retransmission. Manu From detlef.bosau at web.de Tue Apr 2 14:20:19 2013 From: detlef.bosau at web.de (Detlef Bosau) Date: Tue, 02 Apr 2013 23:20:19 +0200 Subject: [e2e] Why do we need congestion control? In-Reply-To: References: <0037066628D6FC449C61186553CAE11D032D43A83ED9@njfpsrvexg2.research.att.com> <515AD4DD.4030809@web.de> Message-ID: <515B4B93.5060702@web.de> Am 02.04.2013 18:15, schrieb LOCHIN Emmanuel: > > Hi Detlef > > In these papers the authors consider "perfect code", meaning that all > the redundancy is useful. > Look at our implementation of Decongestion Control Protocol : > http://www.lochin.net/tetrysjungle.pdf > where full reliability is achieved without retransmission. > > Manu > I only qoute one sentence: > the recovery delay is > independent of the RTT Hm. I think, we exchanged some pm on this issue, however: either I don't understand this sentence or I don't believe it. Perhaps, I misunderstand ist completely. However, your paper and others insinuate that with erasure codes a recovery the time for a packet transfer is somehow statistically bounded. Where is the fault in my way of thinking? -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20130402/59d7f812/attachment.html From detlef.bosau at web.de Tue Apr 2 16:11:52 2013 From: detlef.bosau at web.de (Detlef Bosau) Date: Wed, 03 Apr 2013 01:11:52 +0200 Subject: [e2e] Fwd: Re: Why do we need congestion control? In-Reply-To: <1364943586.34266656@apps.rackspace.com> References: <1364943586.34266656@apps.rackspace.com> Message-ID: <515B65B8.4000907@web.de> Dave Reed sent me the following comments via PM, I think it may be helpful for the discussion, particularly his remark on the asymptotic behaviour, so I forward this to the list (with explicit permission of DPR). -------- Original-Nachricht -------- Betreff: Re: [e2e] Why do we need congestion control? Datum: Tue, 2 Apr 2013 18:59:46 -0400 (EDT) Von: dpreed at reed.com An: Detlef Bosau Kopie (CC): end2end-interest at postel.org "Erasure codes" is not a proper term for this. Which creates lots of confusion on the list, and that will get worse. Erasure codes correct erasures, but that is not the key attribute of fountain codes. You need "ratelessness". The correct technical term is "rateless erasure codes". That is, codes that correct erasures but are not dependent on a particular "error rate". A "rateless erasure code" has the property that the goodput over the long term on *any* erasure channel is asymptotically equal to the total number of symbols actually delivered (or symbols sent minus symbols erased). An erasure channel is an information theoretic "channel" where the loss process causes erasure of zero or more symbols in the stream, but all symbols actually delivered to the destination are correct. Fountain codes are one example of a rateless erasure code. If you look up "rateless erasure code" on Google, you can learn all about them. Feel free to forward this clarification to e2e, since I cannot post there. PS: rateless erasure codes do not obviate the need for congestion signalling within a network. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20130403/59504e8b/attachment.html From lachlan.andrew at gmail.com Tue Apr 2 16:18:36 2013 From: lachlan.andrew at gmail.com (Lachlan Andrew) Date: Wed, 3 Apr 2013 10:18:36 +1100 Subject: [e2e] Why do we need congestion control? In-Reply-To: <515B4B93.5060702@web.de> References: <0037066628D6FC449C61186553CAE11D032D43A83ED9@njfpsrvexg2.research.att.com> <515AD4DD.4030809@web.de> <515B4B93.5060702@web.de> Message-ID: On 3 April 2013 08:20, Detlef Bosau wrote: > I only qoute one sentence: > > the recovery delay is > independent of the RTT > > Hm. I think, we exchanged some pm on this issue, however: either I don't > understand this sentence or I don't believe it. > > Perhaps, I misunderstand ist completely. However, your paper and others > insinuate that with erasure codes a recovery the time for a packet transfer > is somehow statistically bounded. Where is the fault in my way of thinking? Greetings Detlef, That statement is true. The "recovery" isn't triggered by the loss, and so there is no need for a RTT feedback delay to ask for retransmission. An ideal erasure code works by sending many "views" or "hashes" of a file (rather than each packet corresponding to a small piece of the file). The sender sends continuously until the receiver has received enough views to be able to reconstruct the file. There is no feedback from the receiver during this time, and so no RTT delay. Of course, there is a one-way delay before the first packet is received. Once the receiver has decoded the file, it sends a single ACK to tell the sender to stop. (That "single ACK" could be a stream of packets, if the chance of losing an ACK packet is high.) That ACK takes another one-way delay to get to the sender, but that doesn't slow down the "recover" of the data. We can't avoid the need for the total transfer to take at least one RTT, but that doesn't have to be incurred for every packet recovery. Cheers, Lachlan -- Lachlan Andrew Centre for Advanced Internet Architectures (CAIA) Swinburne University of Technology, Melbourne, Australia Ph +61 3 9214 4837 From detlef.bosau at web.de Wed Apr 3 02:01:16 2013 From: detlef.bosau at web.de (Detlef Bosau) Date: Wed, 03 Apr 2013 11:01:16 +0200 Subject: [e2e] Why do we need congestion control? In-Reply-To: References: <0037066628D6FC449C61186553CAE11D032D43A83ED9@njfpsrvexg2.research.att.com> <515AD4DD.4030809@web.de> <515B4B93.5060702@web.de> Message-ID: <515BEFDC.8040105@web.de> Let me frame the problem in a different way, then I think it becomes obvious where we talk at cross purposes. Let me assume a greedy, infinite data stream. Let me call the original data stream "information bytes" and the encoded stream "code bytes" (as in usual channel coding). Now the problem is that we want to /reliably/ convey data from a sender to a receiver. How long does it take to convey 1000 bytes without errors? O.k., this may be independent from the RTT - however, how is the RTT defined? When the channel is error free, it may perhaps (due to overhead) suffice to send 1500 bytes - and the receiver can correctly the first 1000 bytes. When there is little noise, we may perhaps need 10.000 bytes. Perhaps, we have some channel outages during the transfer and need 200.000 bytes. I don't know. Different from traditional TCP, the receiver issues ACKs in certain intervals - independent from what he actually has successfully received, correct? So I see that this RTT is in fact independent from the time it takes to successfully convey a certain amount of data - to the price that this time is hardly known. As a general remark I recall the well known fact: TANSTAAFL. Whenever a certain sophisticated technology insinuates the existence of some perpetual motion machine, we should stop our thoughts immediately and look for the error. The error may be not obvious. But it exists. Without any reasonable doubt. When a long formal deduction leads to result which is known to be wrong, there must be a flaw in the deduction. In this case the flaw may be (and this is quite often met) some, if very slight and subtle, confusion of terms. Am 03.04.2013 01:18, schrieb Lachlan Andrew: > On 3 April 2013 08:20, Detlef Bosau wrote: >> I only qoute one sentence: >> >> the recovery delay is >> independent of the RTT >> >> Hm. I think, we exchanged some pm on this issue, however: either I don't >> understand this sentence or I don't believe it. >> >> Perhaps, I misunderstand ist completely. However, your paper and others >> insinuate that with erasure codes a recovery the time for a packet transfer >> is somehow statistically bounded. Where is the fault in my way of thinking? > Greetings Detlef, > > That statement is true. The "recovery" isn't triggered by the loss, > and so there is no need for a RTT feedback delay to ask for > retransmission. An ideal erasure code works by sending many "views" > or "hashes" of a file (rather than each packet corresponding to a > small piece of the file). The sender sends continuously until the > receiver has received enough views to be able to reconstruct the file. > There is no feedback from the receiver during this time, and so no > RTT delay. Of course, there is a one-way delay before the first > packet is received. > > Once the receiver has decoded the file, it sends a single ACK to tell > the sender to stop. (That "single ACK" could be a stream of packets, > if the chance of losing an ACK packet is high.) That ACK takes > another one-way delay to get to the sender, but that doesn't slow down > the "recover" of the data. We can't avoid the need for the total > transfer to take at least one RTT, but that doesn't have to be > incurred for every packet recovery. > > Cheers, > Lachlan > > -- > Lachlan Andrew Centre for Advanced Internet Architectures (CAIA) > Swinburne University of Technology, Melbourne, Australia > > Ph +61 3 9214 4837 -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20130403/88c47f47/attachment.html From Jon.Crowcroft at cl.cam.ac.uk Wed Apr 3 02:41:40 2013 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Wed, 03 Apr 2013 10:41:40 +0100 Subject: [e2e] Why do we need congestion control? In-Reply-To: <515BEFDC.8040105@web.de> References: <0037066628D6FC449C61186553CAE11D032D43A83ED9@njfpsrvexg2.research.att.com> <515AD4DD.4030809@web.de> <515B4B93.5060702@web.de> <515BEFDC.8040105@web.de> Message-ID: lets do a simple thought experiment lets say you have two users sharing at least one router's output port/link as part of their path, and both users are greedy lets say you have a choice in each user whether to use either 1) feedback based rate adjustment (don't care if its VJCC cwnd or TFRC based) or 2) a rateless erasure code you could have both users' flows use 1 or both 2 or a mix, i.e. 3 cases 1+1, 2+2 or 1+2 now, how do you choose the code to get max goodput for the 3 cases... >> >>Let me frame the problem in a different way, then I think it becomes >>obvious where we talk at cross purposes. >>Let me assume a greedy, infinite data stream. >>Let me call the original data stream "information bytes" and the encoded >>stream "code bytes" (as in usual channel coding). >> >>Now the problem is that we want to /reliably/ convey data from a sender >>to a receiver. >> >>How long does it take to convey 1000 bytes without errors? O.k., this >>may be independent from the RTT - however, how is the RTT defined? >> >>When the channel is error free, it may perhaps (due to overhead) suffice >>to send 1500 bytes - and the receiver can correctly the first 1000 bytes. >>When there is little noise, we may perhaps need 10.000 bytes. >> >>Perhaps, we have some channel outages during the transfer and need >>200.000 bytes. >> >>I don't know. >> >>Different from traditional TCP, the receiver issues ACKs in certain >>intervals - independent from what he actually has successfully received, >>correct? >> >>So I see that this RTT is in fact independent from the time it takes to >>successfully convey a certain amount of data - to the price that this >>time is hardly known. >> >>As a general remark I recall the well known fact: TANSTAAFL. >> >>Whenever a certain sophisticated technology insinuates the existence of >>some perpetual motion machine, we should stop our thoughts immediately >>and look for the error. The error may be not obvious. But it exists. >>Without any reasonable doubt. When a long formal deduction leads to >>result which is known to be wrong, there must be a flaw in the deduction. >> >>In this case the flaw may be (and this is quite often met) some, if very >>slight and subtle, confusion of terms. >> >> >>Am 03.04.2013 01:18, schrieb Lachlan Andrew: >>> On 3 April 2013 08:20, Detlef Bosau wrote: >>>> I only qoute one sentence: >>>> >>>> the recovery delay is >>>> independent of the RTT >>>> >>>> Hm. I think, we exchanged some pm on this issue, however: either I don't >>>> understand this sentence or I don't believe it. >>>> >>>> Perhaps, I misunderstand ist completely. However, your paper and others >>>> insinuate that with erasure codes a recovery the time for a packet transfer >>>> is somehow statistically bounded. Where is the fault in my way of thinking? >>> Greetings Detlef, >>> >>> That statement is true. The "recovery" isn't triggered by the loss, >>> and so there is no need for a RTT feedback delay to ask for >>> retransmission. An ideal erasure code works by sending many "views" >>> or "hashes" of a file (rather than each packet corresponding to a >>> small piece of the file). The sender sends continuously until the >>> receiver has received enough views to be able to reconstruct the file. >>> There is no feedback from the receiver during this time, and so no >>> RTT delay. Of course, there is a one-way delay before the first >>> packet is received. >>> >>> Once the receiver has decoded the file, it sends a single ACK to tell >>> the sender to stop. (That "single ACK" could be a stream of packets, >>> if the chance of losing an ACK packet is high.) That ACK takes >>> another one-way delay to get to the sender, but that doesn't slow down >>> the "recover" of the data. We can't avoid the need for the total >>> transfer to take at least one RTT, but that doesn't have to be >>> incurred for every packet recovery. >>> >>> Cheers, >>> Lachlan >>> >>> -- >>> Lachlan Andrew Centre for Advanced Internet Architectures (CAIA) >>> Swinburne University of Technology, Melbourne, Australia >>> >>> Ph +61 3 9214 4837 >> >> >>-- >>------------------------------------------------------------------ >>Detlef Bosau >>Galileistra?e 30 >>70565 Stuttgart Tel.: +49 711 5208031 >> mobile: +49 172 6819937 >> skype: detlef.bosau >> ICQ: 566129673 >>detlef.bosau at web.de http://www.detlef-bosau.de >> >> >>--------------030907090300010502060106 >>Content-Type: text/html; charset=ISO-8859-1 >>Content-Transfer-Encoding: 7bit >> >> >> >> > http-equiv="Content-Type"> >> >> >>
Let me frame the problem in a different >> way, then  I think it becomes obvious where we talk at cross >> purposes.
>> Let me assume a greedy, infinite data stream.
>> Let me call the original data stream "information bytes" and the >> encoded stream "code bytes" (as in usual channel coding).
>>
>> Now the problem is that we want to reliably convey data >> from a sender to a receiver.
>>
>> How long does it take to convey 1000 bytes without errors? O.k., >> this may be independent from the RTT - however, how is the RTT >> defined?
>>
>> When the channel is error free, it may perhaps (due to overhead) >> suffice to send 1500 bytes - and the receiver can correctly the >> first 1000 bytes.
>> When there is little noise, we may perhaps need 10.000 bytes.
>>
>> Perhaps, we have some channel outages during the transfer and need >> 200.000 bytes.
>>
>> I don't know.
>>
>> Different from traditional TCP, the receiver issues ACKs in >> certain intervals - independent from what he actually has >> successfully received, correct?
>>
>> So I see that this RTT is in fact independent from the time it >> takes to successfully convey a certain amount of data - to the >> price that this time is hardly known.
>>
>> As a general remark I recall the well known fact: TANSTAAFL.
>>
>> Whenever a certain sophisticated technology insinuates the >> existence of some perpetual motion machine, we should stop our >> thoughts immediately and look for the error. The error may be not >> obvious. But it exists. Without any reasonable doubt. When a long >> formal deduction leads to result which is known to be wrong, there >> must be a flaw in the deduction.
>>
>> In this case the flaw may be (and this is quite often met) some, >> if very slight and subtle, confusion of terms.
>>
>>
>> Am 03.04.2013 01:18, schrieb Lachlan Andrew:
>>
>>
>cite="mid:CAPpWWaKMn6MzUj461UuXjvLx9gQnu4n=DhFZreOnEPQMsgOLKg at mail.gmail.com" >> type="cite"> >> 
On 3 April 2013 08:20, Detlef Bosau <detlef.bosau at web.de> wrote:
 >>
>>
>> 
I only qoute one sentence:
 >>
 >>the recovery delay is
 >>independent of the RTT
 >>
 >>Hm. I think, we exchanged some pm on this issue, however: either I don't
 >>understand this sentence or I don't believe it.
 >>
 >>Perhaps, I misunderstand ist completely. However, your paper and others
 >>insinuate that with erasure codes a recovery the time for a packet transfer
 >>is somehow statistically bounded. Where is the fault in my way of thinking?
 >>
>>
>> 
 >>Greetings Detlef,
 >>
 >>That statement is true.  The "recovery" isn't triggered by the loss,
 >>and so there is no need for a RTT feedback delay to ask for
 >>retransmission.  An ideal erasure code works by sending many "views"
 >>or "hashes" of a file (rather than each packet corresponding to a
 >>small piece of the file).  The sender sends continuously until the
 >>receiver has received enough views to be able to reconstruct the file.
 >> There is no feedback from the receiver during this time, and so no
 >>RTT delay.  Of course, there is a one-way delay before the first
 >>packet is received.
 >>
 >>Once the receiver has decoded the file, it sends a single ACK to tell
 >>the sender to stop.  (That "single ACK" could be a stream of packets,
 >>if the chance of losing an ACK packet is high.)  That ACK takes
 >>another one-way delay to get to the sender, but that doesn't slow down
 >>the "recover" of the data.  We can't avoid the need for the total
 >>transfer to take at least one RTT, but that doesn't have to be
 >>incurred for every packet recovery.
 >>
 >>Cheers,
 >>Lachlan
 >>
 >>--
 >>Lachlan Andrew  Centre for Advanced Internet Architectures (CAIA)
 >>Swinburne University of Technology, Melbourne, Australia
 >><http://caia.swin.edu.au/cv/landrew>
 >>Ph +61 3 9214 4837
 >>
>>
>>
>>
>> 
-- 
 >>------------------------------------------------------------------
 >>Detlef Bosau
 >>Galileistraße 30   
 >>70565 Stuttgart                            Tel.:   +49 711 5208031
 >>                                           mobile: +49 172 6819937
 >>                                           skype:     detlef.bosau
 >>                                           ICQ:          566129673
 >>detlef.bosau at web.de                     http://www.detlef-bosau.de
 >>
 >>
>> >> >> >>--------------030907090300010502060106-- cheers jon From detlef.bosau at web.de Wed Apr 3 03:38:55 2013 From: detlef.bosau at web.de (Detlef Bosau) Date: Wed, 03 Apr 2013 12:38:55 +0200 Subject: [e2e] Why do we need congestion control? In-Reply-To: References: <0037066628D6FC449C61186553CAE11D032D43A83ED9@njfpsrvexg2.research.att.com> <515AD4DD.4030809@web.de> <515B4B93.5060702@web.de> <515BEFDC.8040105@web.de> Message-ID: <515C06BF.1020608@web.de> Am 03.04.2013 11:41, schrieb Jon Crowcroft: > lets do a simple thought experiment lets say you have two users > sharing at least one router's output port/link as part of their path, > and both users are greedy lets say you have a choice in each user > whether to use either 1) feedback based rate adjustment (don't care if > its VJCC cwnd or TFRC based) or 2) a rateless erasure code you could > have both users' flows use 1 or both 2 or a mix, i.e. 3 cases 1+1, 2+2 > or 1+2 now, how do you choose the code to get max goodput for the 3 > cases... Hm. Maybe I miss something essential. However, I don't know whether there is "that only" and "simple" answer to this question. As Joe wrote some days ago, in networks with huge (R)TT, FEC dominated approaches would often be prefarable, so perhaps 2+2. In networks with small (R)TT, ARQ based approaches would be preferable, so perhaps 1+1. However: What about two flows which only share a part of their paths, so one flow has a huge RTT, the other a small one? And one point is missing: In case 2+2, we have to distribute the path's capacity. "Somehow". In case 1+1, it is VJCC which distributes available resources among the flows. How is this achieved in 2+2? From Jon.Crowcroft at cl.cam.ac.uk Wed Apr 3 03:58:52 2013 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Wed, 03 Apr 2013 11:58:52 +0100 Subject: [e2e] Why do we need congestion control? In-Reply-To: <515C06BF.1020608@web.de> References: <0037066628D6FC449C61186553CAE11D032D43A83ED9@njfpsrvexg2.research.att.com> <515AD4DD.4030809@web.de> <515B4B93.5060702@web.de> <515BEFDC.8040105@web.de> <515C06BF.1020608@web.de> Message-ID: assume your goals are a. efficiency b. fairness where to meet a, you must not waste capacity on the links up to the bottleneck (for type 1 flow, this means not too much packet loss) and to meet b, you can use the Jain fairness equation. now assume flows of type 2 can start and stop at some point. what level of FEC do you use when there is 0, 1, or 2 flows of type 2? now have a mix of flows of type 1 & 2 what level of FEC do you use when there is 0, 1 or 2 flows of type 1 andor type 2? repeat for 1million flows. In missive <515C06BF.1020608 at web.de>, Detlef Bosau typed: >>Am 03.04.2013 11:41, schrieb Jon Crowcroft: >>> lets do a simple thought experiment lets say you have two users >>> sharing at least one router's output port/link as part of their path, >>> and both users are greedy lets say you have a choice in each user >>> whether to use either 1) feedback based rate adjustment (don't care if >>> its VJCC cwnd or TFRC based) or 2) a rateless erasure code you could >>> have both users' flows use 1 or both 2 or a mix, i.e. 3 cases 1+1, 2+2 >>> or 1+2 now, how do you choose the code to get max goodput for the 3 >>> cases... >> >> >>Hm. Maybe I miss something essential. However, I don't know whether >>there is "that only" and "simple" answer to this question. As Joe wrote >>some days ago, in networks with huge (R)TT, FEC dominated approaches >>would often be prefarable, so perhaps 2+2. In networks with small (R)TT, >>ARQ based approaches would be preferable, so perhaps 1+1. >> >>However: What about two flows which only share a part of their paths, so >>one flow has a huge RTT, the other a small one? >> >>And one point is missing: In case 2+2, we have to distribute the path's >>capacity. "Somehow". In case 1+1, it is VJCC which distributes available >>resources among the flows. How is this achieved in 2+2? >> >> cheers jon From emmanuel.lochin at isae.fr Wed Apr 3 04:47:05 2013 From: emmanuel.lochin at isae.fr (Emmanuel Lochin) Date: Wed, 03 Apr 2013 13:47:05 +0200 Subject: [e2e] Why do we need congestion control? In-Reply-To: References: <0037066628D6FC449C61186553CAE11D032D43A83ED9@njfpsrvexg2.research.att.com> <515AD4DD.4030809@web.de> <515B4B93.5060702@web.de> <515BEFDC.8040105@web.de> Message-ID: <515C16B9.3070007@isae.fr> On 03/04/2013 11:41, Jon Crowcroft wrote: > lets do a simple thought experiment > > lets say you have two users sharing at least one router's output port/link > as part of their path, and both users are greedy > > lets say you have a choice in each user whether to use either > 1) feedback based rate adjustment (don't care if its VJCC cwnd or TFRC based) > or > 2) a rateless erasure code > > you could have both users' flows use 1 or both 2 or a mix, i.e. 3 cases > 1+1, 2+2 or 1+2 > > now, how do you choose the code to get max goodput for the 3 cases... Hi Detlef, You might have missed the last curves in my PDF. However, I think you should have look to these recent work: M. Kim, M. Medard, J. Barros "Modeling network coded TCP throughput: a simple model and its validation" Valuetools 2011 : http://www.mit.edu/~medard/papers2011/Modeling%20Network%20Coded%20TCP.pdf and our work here : Tournoux, Pierre-Ugo and Lochin, Emmanuel and Lacan, J?r?me and Bouabdallah, Amine and Roca, Vincent /On-the-fly erasure coding for real-time video applications./ (2011) IEEE Transactions on Multimedia : http://oatao.univ-toulouse.fr/4867/ to have an idea of the coding scheme used. Also, there are proposal that enable adaptive FEC (or adpative on-the-fly coding in my case) to adapt the coding scheme use. EL > > >> > >>Let me frame the problem in a different way, then I think it becomes > >>obvious where we talk at cross purposes. > >>Let me assume a greedy, infinite data stream. > >>Let me call the original data stream "information bytes" and the encoded > >>stream "code bytes" (as in usual channel coding). > >> > >>Now the problem is that we want to /reliably/ convey data from a sender > >>to a receiver. > >> > >>How long does it take to convey 1000 bytes without errors? O.k., this > >>may be independent from the RTT - however, how is the RTT defined? > >> > >>When the channel is error free, it may perhaps (due to overhead) suffice > >>to send 1500 bytes - and the receiver can correctly the first 1000 bytes. > >>When there is little noise, we may perhaps need 10.000 bytes. > >> > >>Perhaps, we have some channel outages during the transfer and need > >>200.000 bytes. > >> > >>I don't know. > >> > >>Different from traditional TCP, the receiver issues ACKs in certain > >>intervals - independent from what he actually has successfully received, > >>correct? > >> > >>So I see that this RTT is in fact independent from the time it takes to > >>successfully convey a certain amount of data - to the price that this > >>time is hardly known. > >> > >>As a general remark I recall the well known fact: TANSTAAFL. > >> > >>Whenever a certain sophisticated technology insinuates the existence of > >>some perpetual motion machine, we should stop our thoughts immediately > >>and look for the error. The error may be not obvious. But it exists. > >>Without any reasonable doubt. When a long formal deduction leads to > >>result which is known to be wrong, there must be a flaw in the deduction. > >> > >>In this case the flaw may be (and this is quite often met) some, if very > >>slight and subtle, confusion of terms. > >> > >> > >>Am 03.04.2013 01:18, schrieb Lachlan Andrew: > >>> On 3 April 2013 08:20, Detlef Bosau wrote: > >>>> I only qoute one sentence: > >>>> > >>>> the recovery delay is > >>>> independent of the RTT > >>>> > >>>> Hm. I think, we exchanged some pm on this issue, however: either I don't > >>>> understand this sentence or I don't believe it. > >>>> > >>>> Perhaps, I misunderstand ist completely. However, your paper and others > >>>> insinuate that with erasure codes a recovery the time for a packet transfer > >>>> is somehow statistically bounded. Where is the fault in my way of thinking? > >>> Greetings Detlef, > >>> > >>> That statement is true. The "recovery" isn't triggered by the loss, > >>> and so there is no need for a RTT feedback delay to ask for > >>> retransmission. An ideal erasure code works by sending many "views" > >>> or "hashes" of a file (rather than each packet corresponding to a > >>> small piece of the file). The sender sends continuously until the > >>> receiver has received enough views to be able to reconstruct the file. > >>> There is no feedback from the receiver during this time, and so no > >>> RTT delay. Of course, there is a one-way delay before the first > >>> packet is received. > >>> > >>> Once the receiver has decoded the file, it sends a single ACK to tell > >>> the sender to stop. (That "single ACK" could be a stream of packets, > >>> if the chance of losing an ACK packet is high.) That ACK takes > >>> another one-way delay to get to the sender, but that doesn't slow down > >>> the "recover" of the data. We can't avoid the need for the total > >>> transfer to take at least one RTT, but that doesn't have to be > >>> incurred for every packet recovery. > >>> > >>> Cheers, > >>> Lachlan > >>> > >>> -- > >>> Lachlan Andrew Centre for Advanced Internet Architectures (CAIA) > >>> Swinburne University of Technology, Melbourne, Australia > >>> > >>> Ph +61 3 9214 4837 > >> > >> > >>-- > >>------------------------------------------------------------------ > >>Detlef Bosau > >>Galileistra?e 30 > >>70565 Stuttgart Tel.: +49 711 5208031 > >> mobile: +49 172 6819937 > >> skype: detlef.bosau > >> ICQ: 566129673 > >>detlef.bosau at web.de http://www.detlef-bosau.de > >> > >> > >>--------------030907090300010502060106 > >>Content-Type: text/html; charset=ISO-8859-1 > >>Content-Transfer-Encoding: 7bit > >> > >> > >> > >> >> http-equiv="Content-Type"> > >> > >> > >>
Let me frame the problem in a different > >> way, then  I think it becomes obvious where we talk at cross > >> purposes.
> >> Let me assume a greedy, infinite data stream.
> >> Let me call the original data stream "information bytes" and the > >> encoded stream "code bytes" (as in usual channel coding).
> >>
> >> Now the problem is that we want to reliably convey data > >> from a sender to a receiver.
> >>
> >> How long does it take to convey 1000 bytes without errors? O.k., > >> this may be independent from the RTT - however, how is the RTT > >> defined?
> >>
> >> When the channel is error free, it may perhaps (due to overhead) > >> suffice to send 1500 bytes - and the receiver can correctly the > >> first 1000 bytes.
> >> When there is little noise, we may perhaps need 10.000 bytes.
> >>
> >> Perhaps, we have some channel outages during the transfer and need > >> 200.000 bytes.
> >>
> >> I don't know.
> >>
> >> Different from traditional TCP, the receiver issues ACKs in > >> certain intervals - independent from what he actually has > >> successfully received, correct?
> >>
> >> So I see that this RTT is in fact independent from the time it > >> takes to successfully convey a certain amount of data - to the > >> price that this time is hardly known.
> >>
> >> As a general remark I recall the well known fact: TANSTAAFL.
> >>
> >> Whenever a certain sophisticated technology insinuates the > >> existence of some perpetual motion machine, we should stop our > >> thoughts immediately and look for the error. The error may be not > >> obvious. But it exists. Without any reasonable doubt. When a long > >> formal deduction leads to result which is known to be wrong, there > >> must be a flaw in the deduction.
> >>
> >> In this case the flaw may be (and this is quite often met) some, > >> if very slight and subtle, confusion of terms.
> >>
> >>
> >> Am 03.04.2013 01:18, schrieb Lachlan Andrew:
> >>
> >>
>>cite="mid:CAPpWWaKMn6MzUj461UuXjvLx9gQnu4n=DhFZreOnEPQMsgOLKg at mail.gmail.com" > >> type="cite"> > >> 
On 3 April 2013 08:20, Detlef Bosau <detlef.bosau at web.de> wrote:
>   >>
> >>
> >> 
I only qoute one sentence:
>   >>
>   >>the recovery delay is
>   >>independent of the RTT
>   >>
>   >>Hm. I think, we exchanged some pm on this issue, however: either I don't
>   >>understand this sentence or I don't believe it.
>   >>
>   >>Perhaps, I misunderstand ist completely. However, your paper and others
>   >>insinuate that with erasure codes a recovery the time for a packet transfer
>   >>is somehow statistically bounded. Where is the fault in my way of thinking?
>   >>
> >>
> >> 
>   >>Greetings Detlef,
>   >>
>   >>That statement is true.  The "recovery" isn't triggered by the loss,
>   >>and so there is no need for a RTT feedback delay to ask for
>   >>retransmission.  An ideal erasure code works by sending many "views"
>   >>or "hashes" of a file (rather than each packet corresponding to a
>   >>small piece of the file).  The sender sends continuously until the
>   >>receiver has received enough views to be able to reconstruct the file.
>   >> There is no feedback from the receiver during this time, and so no
>   >>RTT delay.  Of course, there is a one-way delay before the first
>   >>packet is received.
>   >>
>   >>Once the receiver has decoded the file, it sends a single ACK to tell
>   >>the sender to stop.  (That "single ACK" could be a stream of packets,
>   >>if the chance of losing an ACK packet is high.)  That ACK takes
>   >>another one-way delay to get to the sender, but that doesn't slow down
>   >>the "recover" of the data.  We can't avoid the need for the total
>   >>transfer to take at least one RTT, but that doesn't have to be
>   >>incurred for every packet recovery.
>   >>
>   >>Cheers,
>   >>Lachlan
>   >>
>   >>--
>   >>Lachlan Andrew  Centre for Advanced Internet Architectures (CAIA)
>   >>Swinburne University of Technology, Melbourne, Australia
>   >><http://caia.swin.edu.au/cv/landrew>
>   >>Ph +61 3 9214 4837
>   >>
> >>
> >>
> >>
> >> 
--
>   >>------------------------------------------------------------------
>   >>Detlef Bosau
>   >>Galileistraße 30
>   >>70565 Stuttgart                            Tel.:   +49 711 5208031
>   >>                                           mobile: +49 172 6819937
>   >>                                           skype:     detlef.bosau
>   >>                                           ICQ:          566129673
>   >>detlef.bosau at web.de                     http://www.detlef-bosau.de
>   >>
>   >>
> >> > >> > >> > >>--------------030907090300010502060106-- > > cheers > > jon > > -- Emmanuel Lochin Professeur ISAE - OSSI Institut Sup?rieur de l'A?ronautique et de l'Espace (ISAE) Issu du rapprochement SUPAERO et ENSICA 10 avenue Edouard Belin - BP 54032 - 31055 Toulouse cedex 4 Tel : 05 61 33 91 85 - Fax : 05 61 33 91 88 Web : http://personnel.isae.fr/emmanuel-lochin/ --- "This email and any attachments are confidential. They may contain legally privileged information or copyright material. You should not read, copy, use or disclose them without authorisation. If you are not an intended recipient, please contact us at once by return email and then delete both messages. We do not accept liability in connection with computer virus, data corruption, delay, interruption, unauthorised access or unauthorised amendment. This notice should not be removed" -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20130403/f9d3685f/attachment-0001.html From detlef.bosau at web.de Wed Apr 3 06:40:14 2013 From: detlef.bosau at web.de (Detlef Bosau) Date: Wed, 03 Apr 2013 15:40:14 +0200 Subject: [e2e] Why do we need congestion control? In-Reply-To: <515C16B9.3070007@isae.fr> References: <0037066628D6FC449C61186553CAE11D032D43A83ED9@njfpsrvexg2.research.att.com> <515AD4DD.4030809@web.de> <515B4B93.5060702@web.de> <515BEFDC.8040105@web.de> <515C16B9.3070007@isae.fr> Message-ID: <515C313E.6090205@web.de> Just some few remarks. DTCP assumes fair AQM. How is this achieved? Particularly: Fair queueing is criticized for being to expensive. Isn't "fair AQM" similarly expensive? Second question: Jon and you refer to Jain's fairness index. Fine. From a bird's perspective, we can assess the JFI for a given network. However: How is good fairness then achieved by the protocol? (I just got the Snoeren-Paper, this will be enlightening here :-)) As a last remark: You always assume greedy flows here. When I claimed our problem would be that we neglect the existence of mice, I received a PM, I certainly would be kidding. Now, we all are one whole day older ;-) And we go on to neglect the existence of mice! Only as some few remarks. DB BTW: It would be interesting to discuss code strength here which certainly depend on the (corruption caused) loss rate and the (congestion caused) drop rate here and which directly affect a flow's goodput. Even more, and that's a quite basic criticism: You once more solve all congestion problems purely end to end. Actually, that's one of the major flaws in congestion control at all. When I correctly understand the principles of Jerry Salzer's paper, it would be nice to solve problems at their origin. Or at least there, where they can be solved effectively. So, when resource distribution is being done best at routers, it should be done at routers. And not at the end points. And when the adaptation of an FEC scheme to an actual link noise situation is being done best at the radio interface, where the noise situation is immediately known e.g. by observation and assessment of a pilot signal, adaptation should be done there and not at the end points "200 ms later". Particularly, it does not make sense to bother the whole network with the overhead of some extremely strong FEC scheme because there is one flow which has to pass a noisy air interface. And we place the error protection / recovery on the end nodes while this fits into some e2e-religion. According to Joe's remark some days ago, it would make much more sense to locally retransmit a faulty block now and then locally than to let the whole world suffer from unnecessary overhead. However, the only correct answer which scheme is eventually to be chosen is "it depends..." and than we have to carefully discuss the necessary trade offs. Am 03.04.2013 13:47, schrieb Emmanuel Lochin: > On 03/04/2013 11:41, Jon Crowcroft wrote: >> lets do a simple thought experiment >> >> lets say you have two users sharing at least one router's output port/link >> as part of their path, and both users are greedy >> >> lets say you have a choice in each user whether to use either >> 1) feedback based rate adjustment (don't care if its VJCC cwnd or TFRC based) >> or >> 2) a rateless erasure code >> >> you could have both users' flows use 1 or both 2 or a mix, i.e. 3 cases >> 1+1, 2+2 or 1+2 >> >> now, how do you choose the code to get max goodput for the 3 cases... > > Hi Detlef, > > You might have missed the last curves in my PDF. However, I think you > should have look to these recent work: > > M. Kim, M. Medard, J. Barros "Modeling network coded TCP throughput: a > simple model and its validation" Valuetools 2011 : > http://www.mit.edu/~medard/papers2011/Modeling%20Network%20Coded%20TCP.pdf > > and our work here : > > Tournoux, Pierre-Ugo and Lochin, Emmanuel and Lacan, J?r?me and > Bouabdallah, Amine and Roca, Vincent /On-the-fly erasure coding for > real-time video applications./ > (2011) IEEE Transactions on Multimedia : > http://oatao.univ-toulouse.fr/4867/ > > to have an idea of the coding scheme used. > > Also, there are proposal that enable adaptive FEC (or adpative > on-the-fly coding in my case) to adapt the coding scheme use. > > EL > -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20130403/bf9cd33d/attachment.html From detlef.bosau at web.de Wed Apr 3 08:43:37 2013 From: detlef.bosau at web.de (Detlef Bosau) Date: Wed, 03 Apr 2013 17:43:37 +0200 Subject: [e2e] Why do we need congestion control? In-Reply-To: <515C313E.6090205@web.de> References: <0037066628D6FC449C61186553CAE11D032D43A83ED9@njfpsrvexg2.research.att.com> <515AD4DD.4030809@web.de> <515B4B93.5060702@web.de> <515BEFDC.8040105@web.de> <515C16B9.3070007@isae.fr> <515C313E.6090205@web.de> Message-ID: <515C4E29.8090205@web.de> I've just had a first look at the Snoeren paper. OMG. Remembers me of typical parliament debates. Let the people babble as much as they can - afterwards make a "fair bullshit removal" (so, no party is advantaged while others are disadvantaged) and the rest is the reasonable content of the debate. Perhaps, my knowledge is a bit outdated here, but I well remember times where people had to pay for network resources. The idea is interesting anyway, however we should carefully discuss who eventually does the clean up work and which are the consequences of congestion. I agree with Dave, that erasure codes do not obviate the need for congestion control. Actually, at the moment we shift around the responsibilities, what does not necessarily clarify the situation. The idea of the paper is appealing: When we have 10 flows, let each flow send as fast as he can - the network imposes fair drop on each flow and hence the experienced goodput is a consequence of the drop rate. A single flow may experience no drop and hence yields high good put, if the network is fully overcrowded, each flow experiences high packet drop and the goodput is hence low. The first immediate objection is the same as with VJCC: How is fairness defined and what is the common resource for two flows? Particularly, we meet the same difficulty here as I have seen it in some papers by Frank Kelly: Implicitly, the common resource is always sending time. What about wireless networks? Where the shared resource is not always time but power? And when I may elaborate on this one: In UMTS like networks, the approach would only lead to maximum interference in a cell - which most likely simply would render the cell unusable. -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From Emmanuel.LOCHIN at isae.fr Wed Apr 3 08:49:53 2013 From: Emmanuel.LOCHIN at isae.fr (LOCHIN Emmanuel) Date: Wed, 03 Apr 2013 17:49:53 +0200 Subject: [e2e] =?utf-8?q?Why_do_we_need_congestion_control=3F?= In-Reply-To: <515C313E.6090205@web.de> References: <0037066628D6FC449C61186553CAE11D032D43A83ED9@njfpsrvexg2.research.att.com> <515AD4DD.4030809@web.de> <515B4B93.5060702@web.de> <515BEFDC.8040105@web.de> <515C16B9.3070007@isae.fr> <515C313E.6090205@web.de> Message-ID: <461062fad137c560a27a3d54e577e377@merisier.isae.fr> Le 03.04.2013 15:40, Detlef Bosau a ?crit?: > And when the adaptation of an FEC scheme to an > actual link noise situation is being done best at the radio > interface, > where the noise situation is immediately known e.g. by observation > and > assessment of a pilot signal, adaptation should be done there and not > at the end points "200 ms later". Particularly, it does not make > sense > to bother the whole network with the overhead of some extremely > strong > FEC scheme because there is one flow which has to pass a noisy air > interface. Detlef, you now talk about link-layer FEC while at the beginning of this thread and following the subject, we talk about congestion control (i.e. at transport layer). The erasure codes presented are based at the transport or application layers, for instance, to prevent retransmission due to big delay or to attempt to implement anarchical network proposals. Emmanuel From detlef.bosau at web.de Wed Apr 3 10:41:29 2013 From: detlef.bosau at web.de (Detlef Bosau) Date: Wed, 03 Apr 2013 19:41:29 +0200 Subject: [e2e] Why do we need congestion control? In-Reply-To: <461062fad137c560a27a3d54e577e377@merisier.isae.fr> References: <0037066628D6FC449C61186553CAE11D032D43A83ED9@njfpsrvexg2.research.att.com> <515AD4DD.4030809@web.de> <515B4B93.5060702@web.de> <515BEFDC.8040105@web.de> <515C16B9.3070007@isae.fr> <515C313E.6090205@web.de> <461062fad137c560a27a3d54e577e377@merisier.isae.fr> Message-ID: <515C69C9.1080600@web.de> Am 03.04.2013 17:49, schrieb LOCHIN Emmanuel: > Le 03.04.2013 15:40, Detlef Bosau a ?crit : >> And when the adaptation of an FEC scheme to an >> actual link noise situation is being done best at the radio interface, >> where the noise situation is immediately known e.g. by observation and >> assessment of a pilot signal, adaptation should be done there and not >> at the end points "200 ms later". Particularly, it does not make sense >> to bother the whole network with the overhead of some extremely strong >> FEC scheme because there is one flow which has to pass a noisy air >> interface. > > Detlef, you now talk about link-layer FEC while at the beginning of > this thread and following the subject, we talk about congestion > control (i.e. at transport layer). Yes. And that's part of the problem. We mix up different tasks here. Actually, we cannot split these tasks as clearly as we want to. > The erasure codes presented are based at the transport or application > layers, for instance, to prevent retransmission due to big delay or to > attempt to implement anarchical network proposals. Even for application layers we have to keep costs in mind. -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From snoeren at cs.ucsd.edu Wed Apr 3 11:40:24 2013 From: snoeren at cs.ucsd.edu (Alex C. Snoeren) Date: Wed, 3 Apr 2013 11:40:24 -0700 Subject: [e2e] Why do we need congestion control? In-Reply-To: <515C4E29.8090205@web.de> References: <0037066628D6FC449C61186553CAE11D032D43A83ED9@njfpsrvexg2.research.att.com> <515AD4DD.4030809@web.de> <515B4B93.5060702@web.de> <515BEFDC.8040105@web.de> <515C16B9.3070007@isae.fr> <515C313E.6090205@web.de> <515C4E29.8090205@web.de> Message-ID: <60CC5ED9-45A2-465F-A6F6-15C580226D65@cs.ucsd.edu> I've remained deliberately quiet here, but will point out that the mere fact that one has to pay for a service does not mean there is actually a marginal cost. Take, for example, 10G Ethernet---it is constantly sending bits to keep the link locked. Only some of those bits are currently used to send actual packets, however. - Alex On Apr 3, 2013, at 8:43 AM, Detlef Bosau wrote: > I've just had a first look at the Snoeren paper. > > OMG. > > Remembers me of typical parliament debates. > > Let the people babble as much as they can - afterwards make a "fair bullshit removal" (so, no party is advantaged while others are disadvantaged) and the rest is the reasonable content of the debate. > > Perhaps, my knowledge is a bit outdated here, but I well remember times where people had to pay for network resources. > > The idea is interesting anyway, however we should carefully discuss who eventually does the clean up work and which are the consequences of congestion. > I agree with Dave, that erasure codes do not obviate the need for congestion control. Actually, at the moment we shift around the responsibilities, what does not necessarily clarify the situation. > > The idea of the paper is appealing: When we have 10 flows, let each flow send as fast as he can - the network imposes fair drop on each flow and hence the experienced goodput is a consequence of the drop rate. A single flow may experience no drop and hence yields high good put, if the network is fully overcrowded, each flow experiences high packet drop and the goodput is hence low. > > The first immediate objection is the same as with VJCC: How is fairness defined and what is the common resource for two flows? Particularly, we meet the same difficulty here as I have seen it in some papers by Frank Kelly: Implicitly, the common resource is always sending time. > What about wireless networks? Where the shared resource is not always time but power? And when I may elaborate on this one: In UMTS like networks, the approach would only lead to maximum interference in a cell - which most likely simply would render the cell unusable. > > > > > -- > ------------------------------------------------------------------ > Detlef Bosau > Galileistra?e 30 > 70565 Stuttgart Tel.: +49 711 5208031 > mobile: +49 172 6819937 > skype: detlef.bosau > ICQ: 566129673 > detlef.bosau at web.de http://www.detlef-bosau.de > From vinayakh at gmail.com Wed Apr 3 18:48:50 2013 From: vinayakh at gmail.com (Vinayak Hegde) Date: Thu, 4 Apr 2013 07:18:50 +0530 Subject: [e2e] Why do we need congestion control? In-Reply-To: <515BEFDC.8040105@web.de> References: <0037066628D6FC449C61186553CAE11D032D43A83ED9@njfpsrvexg2.research.att.com> <515AD4DD.4030809@web.de> <515B4B93.5060702@web.de> <515BEFDC.8040105@web.de> Message-ID: And a bit more work work so d wrote I have read each war were in each week of this message e rather Read On Apr 3, 2013 3:40 AM, "Detlef Bosau" wrote: > Let me frame the problem in a different way, then I think it becomes > obvious where we talk at cross purposes. > Let me assume a greedy, infinite data stream. > Let me call the original data stream "information bytes" and the encoded > stream "code bytes" (as in usual channel coding). > > Now the problem is that we want to *reliably* convey data from a sender > to a receiver. > > How long does it take to convey 1000 bytes without errors? O.k., this may > be independent from the RTT - however, how is the RTT defined? > > When the channel is error free, it may perhaps (due to overhead) suffice > to send 1500 bytes - and the receiver can correctly the first 1000 bytes. > When there is little noise, we may perhaps need 10.000 bytes. > > Perhaps, we have some channel outages during the transfer and need 200.000 > bytes. > > I don't know. > > Different from traditional TCP, the receiver issues ACKs in certain > intervals - independent from what he actually has successfully received, > correct? > > So I see that this RTT is in fact independent from the time it takes to > successfully convey a certain amount of data - to the price that this time > is hardly known. > > As a general remark I recall the well known fact: TANSTAAFL. > > Whenever a certain sophisticated technology insinuates the existence of > some perpetual motion machine, we should stop our thoughts immediately and > look for the error. The error may be not obvious. But it exists. Without > any reasonable doubt. When a long formal deduction leads to result which is > known to be wrong, there must be a flaw in the deduction. > > In this case the flaw may be (and this is quite often met) some, if very > slight and subtle, confusion of terms. > > > Am 03.04.2013 01:18, schrieb Lachlan Andrew: > > On 3 April 2013 08:20, Detlef Bosau wrote: > > I only qoute one sentence: > > the recovery delay is > independent of the RTT > > Hm. I think, we exchanged some pm on this issue, however: either I don't > understand this sentence or I don't believe it. > > Perhaps, I misunderstand ist completely. However, your paper and others > insinuate that with erasure codes a recovery the time for a packet transfer > is somehow statistically bounded. Where is the fault in my way of thinking? > > > Greetings Detlef, > > That statement is true. The "recovery" isn't triggered by the loss, > and so there is no need for a RTT feedback delay to ask for > retransmission. An ideal erasure code works by sending many "views" > or "hashes" of a file (rather than each packet corresponding to a > small piece of the file). The sender sends continuously until the > receiver has received enough views to be able to reconstruct the file. > There is no feedback from the receiver during this time, and so no > RTT delay. Of course, there is a one-way delay before the first > packet is received. > > Once the receiver has decoded the file, it sends a single ACK to tell > the sender to stop. (That "single ACK" could be a stream of packets, > if the chance of losing an ACK packet is high.) That ACK takes > another one-way delay to get to the sender, but that doesn't slow down > the "recover" of the data. We can't avoid the need for the total > transfer to take at least one RTT, but that doesn't have to be > incurred for every packet recovery. > > Cheers, > Lachlan > > -- > Lachlan Andrew Centre for Advanced Internet Architectures (CAIA) > Swinburne University of Technology, Melbourne, Australia > Ph +61 3 9214 4837 > > > > -- > ------------------------------------------------------------------ > Detlef Bosau > Galileistra?e 30 > 70565 Stuttgart Tel.: +49 711 5208031 > mobile: +49 172 6819937 > skype: detlef.bosau > ICQ: 566129673detlef.bosau at web.de http://www.detlef-bosau.de > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20130404/e5c6e515/attachment.html From detlef.bosau at web.de Thu Apr 4 04:31:00 2013 From: detlef.bosau at web.de (Detlef Bosau) Date: Thu, 04 Apr 2013 13:31:00 +0200 Subject: [e2e] Why do we need congestion control? In-Reply-To: <60CC5ED9-45A2-465F-A6F6-15C580226D65@cs.ucsd.edu> References: <0037066628D6FC449C61186553CAE11D032D43A83ED9@njfpsrvexg2.research.att.com> <515AD4DD.4030809@web.de> <515B4B93.5060702@web.de> <515BEFDC.8040105@web.de> <515C16B9.3070007@isae.fr> <515C313E.6090205@web.de> <515C4E29.8090205@web.de> <60CC5ED9-45A2-465F-A6F6-15C580226D65@cs.ucsd.edu> Message-ID: <515D6474.909@web.de> Simple question. Where is "fair dropping" that different from "fair queueing"? I'm with you that we try to obviate the need of some reasonable resource management in the Internet. However: When you require some "fair dropping" mechanism, you could simply use the same implementation and instead of scheduling n flows in a round robin manner like this: "Each turn, one flow is served and n-1 packets are dropped" frame as "Each turn, one flow is served and the other n-1 flows wait." And then you have the fair queueing approach which already well exists. And which you reject because it would be too expensive. -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From emmanuel.lochin at isae.fr Thu Apr 4 05:22:27 2013 From: emmanuel.lochin at isae.fr (Emmanuel Lochin) Date: Thu, 04 Apr 2013 14:22:27 +0200 Subject: [e2e] Why do we need congestion control? In-Reply-To: <515D6474.909@web.de> References: <0037066628D6FC449C61186553CAE11D032D43A83ED9@njfpsrvexg2.research.att.com> <515AD4DD.4030809@web.de> <515B4B93.5060702@web.de> <515BEFDC.8040105@web.de> <515C16B9.3070007@isae.fr> <515C313E.6090205@web.de> <515C4E29.8090205@web.de> <60CC5ED9-45A2-465F-A6F6-15C580226D65@cs.ucsd.edu> <515D6474.909@web.de> Message-ID: <515D7083.4030307@isae.fr> On 04/04/2013 13:31, Detlef Bosau wrote: > Simple question. Where is "fair dropping" that different from "fair > queueing"? The FairDrop queue we have implemented to drive our tests with DCTP simply drops packet of the most opportunistic flows in the queue. Meaning that if you have 3 flows and a full queue of 30 packets, you should have 10 packets of each flow enqueued. E. > > I'm with you that we try to obviate the need of some reasonable > resource management in the Internet. However: When you require some > "fair dropping" mechanism, you could simply use the same > implementation and instead of scheduling n flows in a round robin > manner like this: "Each turn, one flow is served and n-1 packets are > dropped" frame as "Each turn, one flow is served and the other n-1 > flows wait." And then you have the fair queueing approach which > already well exists. And which you reject because it would be too > expensive. > -- Emmanuel Lochin Professeur ISAE - OSSI Institut Sup?rieur de l'A?ronautique et de l'Espace (ISAE) Issu du rapprochement SUPAERO et ENSICA 10 avenue Edouard Belin - BP 54032 - 31055 Toulouse cedex 4 Tel : 05 61 33 91 85 - Fax : 05 61 33 91 88 Web : http://personnel.isae.fr/emmanuel-lochin/ --- "This email and any attachments are confidential. They may contain legally privileged information or copyright material. You should not read, copy, use or disclose them without authorisation. If you are not an intended recipient, please contact us at once by return email and then delete both messages. We do not accept liability in connection with computer virus, data corruption, delay, interruption, unauthorised access or unauthorised amendment. This notice should not be removed" From rs at netapp.com Thu Apr 4 07:44:38 2013 From: rs at netapp.com (Scheffenegger, Richard) Date: Thu, 4 Apr 2013 14:44:38 +0000 Subject: [e2e] How many TCP flows fit in the Internet? In-Reply-To: <515A8A22.6010705@gmail.com> References: <5156F6BB.8050901@web.de> <515819A0.7070405@web.de> <515A8A22.6010705@gmail.com> Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F24AE4ECD@SACEXCMBX02-PRD.hq.netapp.com> Hi, > RFC content and the relevant protocol details aren't changed by "errata". > We generally only pay attention to what's actually specified by the RFC, > not what some Linux implementer decided might be better. Actually, they are. http://www.rfc-editor.org/errata_search.php?rfc=0793 http://www.rfc-editor.org/errata_search.php?rfc=2018 Also, when one of the lead authors of an RFC publicly (and multiple times) admits that there is a technical issue with an RFC (and not some random implementer), there is probably some meat to it :) While most errata are editorial or nits, there are a number of technical errata against a number of core tcp RFCs, that an implementer better follows unless he wants to chase bugs in the mechanisms that have been found and fixed a couple of times over (e.g. RFC0793) And yes, I would also like to see updated RFCs (and the buggy ones obsoleted) when technical errata in the mechanisms are found. However, there is often only limited energy to pursue such an effort (generating a new RFC), and often a filed errata is seen as sufficient. Best regards, Richard Scheffenegger > -----Original Message----- > From: end2end-interest-bounces at postel.org [mailto:end2end-interest- > bounces at postel.org] On Behalf Of William Allen Simpson > Sent: Dienstag, 02. April 2013 09:35 > To: end2end-interest at postel.org > Subject: Re: [e2e] How many TCP flows fit in the Internet? > > On 3/31/13 2:08 PM, Matt Mathis wrote: > > You may have overlooked one additional important detail: > > > > Linux TCP ignores the requirement in RFC 2018 that the SACK scoreboard > > be cleared on a timeout. [...] There is an errata against 2018, with > > the relevant details. > > RFC content and the relevant protocol details aren't changed by "errata". > We generally only pay attention to what's actually specified by the RFC, > not what some Linux implementer decided might be better. > > > > Thanks, > > --MM-- > > The best way to predict the future is to create it. - Alan Kay > > > > Privacy matters! We know from recent events that people are using our > > services to speak in defiance of unjust governments. We treat > > privacy and security as matters of life and death, because for some > > users, they are. > > > Excellent! > From detlef.bosau at web.de Thu Apr 4 08:19:35 2013 From: detlef.bosau at web.de (Detlef Bosau) Date: Thu, 04 Apr 2013 17:19:35 +0200 Subject: [e2e] How many TCP flows fit in the Internet? In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F24AE4ECD@SACEXCMBX02-PRD.hq.netapp.com> References: <5156F6BB.8050901@web.de> <515819A0.7070405@web.de> <515A8A22.6010705@gmail.com> <012C3117EDDB3C4781FD802A8C27DD4F24AE4ECD@SACEXCMBX02-PRD.hq.netapp.com> Message-ID: <515D9A07.8080104@web.de> Am 04.04.2013 16:44, schrieb Scheffenegger, Richard: > And yes, I would also like to see updated RFCs (and the buggy ones > obsoleted) when technical errata in the mechanisms are found. However, > there is often only limited energy to pursue such an effort > (generating a new RFC), and often a filed errata is seen as > sufficient. Best regards, Richard Scheffenegger Feel free to write / propose one. -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From detlef.bosau at web.de Thu Apr 4 08:23:09 2013 From: detlef.bosau at web.de (Detlef Bosau) Date: Thu, 04 Apr 2013 17:23:09 +0200 Subject: [e2e] Why do we need congestion control? In-Reply-To: <515D6474.909@web.de> References: <0037066628D6FC449C61186553CAE11D032D43A83ED9@njfpsrvexg2.research.att.com> <515AD4DD.4030809@web.de> <515B4B93.5060702@web.de> <515BEFDC.8040105@web.de> <515C16B9.3070007@isae.fr> <515C313E.6090205@web.de> <515C4E29.8090205@web.de> <60CC5ED9-45A2-465F-A6F6-15C580226D65@cs.ucsd.edu> <515D6474.909@web.de> Message-ID: <515D9ADD.8080400@web.de> After some additional thinking: "Fair dropping" is exactly what we attempt to do in the moment. However, VJCC and flavours affect the /throughput///while the decongestion work affekts the /goodput/. So both solutions will encounter the same difficulties, however one of them is cheaper. O.k., workshop paper, that's fine. That's the purpose of workshops: Gather ideas, present them, assess them. DB Am 04.04.2013 13:31, schrieb Detlef Bosau: > Simple question. Where is "fair dropping" that different from "fair > queueing"? > > I'm with you that we try to obviate the need of some reasonable > resource management in the Internet. However: When you require some > "fair dropping" mechanism, you could simply use the same > implementation and instead of scheduling n flows in a round robin > manner like this: "Each turn, one flow is served and n-1 packets are > dropped" frame as "Each turn, one flow is served and the other n-1 > flows wait." And then you have the fair queueing approach which > already well exists. And which you reject because it would be too > expensive. > -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20130404/2854efdb/attachment-0001.html From jwbensley at gmail.com Fri Apr 5 05:41:33 2013 From: jwbensley at gmail.com (James Bensley) Date: Fri, 5 Apr 2013 13:41:33 +0100 Subject: [e2e] Research On Protocols In-Reply-To: <5137A603.8070403@cs.uni-goettingen.de> References: <5137A603.8070403@cs.uni-goettingen.de> Message-ID: Hi All, Thanks for your responses both on and off list. I will look into everyone's recommendations. Also, sorry for the delay in my reply, I have been unwell of late. Kind regards, James. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20130405/0f87c8a6/attachment.html From detlef.bosau at web.de Fri Apr 5 14:29:34 2013 From: detlef.bosau at web.de (Detlef Bosau) Date: Fri, 05 Apr 2013 23:29:34 +0200 Subject: [e2e] Why do we need congestion control? In-Reply-To: <515D7083.4030307@isae.fr> References: <0037066628D6FC449C61186553CAE11D032D43A83ED9@njfpsrvexg2.research.att.com> <515AD4DD.4030809@web.de> <515B4B93.5060702@web.de> <515BEFDC.8040105@web.de> <515C16B9.3070007@isae.fr> <515C313E.6090205@web.de> <515C4E29.8090205@web.de> <60CC5ED9-45A2-465F-A6F6-15C580226D65@cs.ucsd.edu> <515D6474.909@web.de> <515D7083.4030307@isae.fr> Message-ID: <515F423E.2080703@web.de> Am 04.04.2013 14:22, schrieb Emmanuel Lochin: > On 04/04/2013 13:31, Detlef Bosau wrote: >> Simple question. Where is "fair dropping" that different from "fair >> queueing"? > > The FairDrop queue we have implemented to drive our tests with DCTP > simply drops packet of the most opportunistic flows in the queue. > Meaning that if you have 3 flows and a full queue of 30 packets, you > should have 10 packets of each flow enqueued. > Three flows. Manu, how do you want to implement fair queueing on a backbone router with actually 200.000 flows? 150.000 of them being "mice"? At least this question should be discussed for both kind of approaches, VJCC and DTCP. So to my understanding, neither VJCC nor DTCP separates the problem of resource allocation from the problem of congestion control, nor do they eventually /solve/ the problem of (fair) resource allocation. To my understanding, many of us recognize the problem of a missing (convincing) resource allocation scheme here and replacing VJCC by a scheme which runs into the same difficulties as VJCC is a bit beating about the bush. -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20130405/f68f8f4e/attachment.html From Emmanuel.LOCHIN at isae.fr Fri Apr 5 23:56:06 2013 From: Emmanuel.LOCHIN at isae.fr (LOCHIN Emmanuel) Date: Sat, 06 Apr 2013 08:56:06 +0200 Subject: [e2e] =?utf-8?q?Why_do_we_need_congestion_control=3F?= In-Reply-To: <515F423E.2080703@web.de> References: <0037066628D6FC449C61186553CAE11D032D43A83ED9@njfpsrvexg2.research.att.com> <515AD4DD.4030809@web.de> <515B4B93.5060702@web.de> <515BEFDC.8040105@web.de> <515C16B9.3070007@isae.fr> <515C313E.6090205@web.de> <515C4E29.8090205@web.de> <60CC5ED9-45A2-465F-A6F6-15C580226D65@cs.ucsd.edu> <515D6474.909@web.de> <515D7083.4030307@isae.fr> <515F423E.2080703@web.de> Message-ID: Le 05.04.2013 23:29, Detlef Bosau a ?crit?: > Am 04.04.2013 14:22, schrieb Emmanuel Lochin: > >> On 04/04/2013 13:31, Detlef Bosau wrote: >> >>> Simple question. Where is "fair dropping" that different from >>> "fair queueing"? >> >> The FairDrop queue we have implemented to drive our tests with DCTP >> simply drops packet of the most opportunistic flows in the queue. >> Meaning that if you have 3 flows and a full queue of 30 packets, you >> should have 10 packets of each flow enqueued. > > Three flows. > > Manu, how do you want to implement fair queueing on a backbone > router First, I've never claimed that I wanted to implement such mechanism inside the core router. > with actually 200.000 flows? 150.000 of them being "mice"? You talk on average not instantaneously. You only maintain a state for flows currently enqueued. It means that if you have a queue size of 30 packets, you can't have more than 30 states in your table. > At least this question should be discussed for both kind of > approaches, VJCC and DTCP. It has been already discussed for TCP, just google FairDrop and TCP. > So to my understanding, neither VJCC nor DTCP separates the problem > of resource allocation from the problem of congestion control, nor do > they eventually _solve_ the problem of (fair) resource allocation. Anyway, my ISP with CAC or DiffServ does? > To my understanding, many of us recognize the problem of a missing > (convincing) resource allocation scheme here and replacing VJCC by a > scheme which runs into the same difficulties as VJCC is a bit beating > about the bush. From detlef.bosau at web.de Sat Apr 6 03:35:02 2013 From: detlef.bosau at web.de (Detlef Bosau) Date: Sat, 06 Apr 2013 12:35:02 +0200 Subject: [e2e] Why do we need congestion control? In-Reply-To: References: <0037066628D6FC449C61186553CAE11D032D43A83ED9@njfpsrvexg2.research.att.com> <515AD4DD.4030809@web.de> <515B4B93.5060702@web.de> <515BEFDC.8040105@web.de> <515C16B9.3070007@isae.fr> <515C313E.6090205@web.de> <515C4E29.8090205@web.de> <60CC5ED9-45A2-465F-A6F6-15C580226D65@cs.ucsd.edu> <515D6474.909@web.de> <515D7083.4030307@isae.fr> <515F423E.2080703@web.de> Message-ID: <515FFA56.7060200@web.de> Am 06.04.2013 08:56, schrieb LOCHIN Emmanuel: > Le 05.04.2013 23:29, Detlef Bosau a ?crit : >> Am 04.04.2013 14:22, schrieb Emmanuel Lochin: >> >>> On 04/04/2013 13:31, Detlef Bosau wrote: >>> >>>> Simple question. Where is "fair dropping" that different from >>>> "fair queueing"? >>> >>> The FairDrop queue we have implemented to drive our tests with DCTP >>> simply drops packet of the most opportunistic flows in the queue. >>> Meaning that if you have 3 flows and a full queue of 30 packets, you >>> should have 10 packets of each flow enqueued. >> >> Three flows. >> >> Manu, how do you want to implement fair queueing on a backbone router > > First, I've never claimed that I wanted to implement such mechanism > inside the core router. I see. Howver: To my understanding, fair queueing must be available on any router in this approach? > >> with actually 200.000 flows? 150.000 of them being "mice"? > > You talk on average not instantaneously. You only maintain a state for > flows currently enqueued. > It means that if you have a queue size of 30 packets, you can't have > more than 30 states in your table. > >> At least this question should be discussed for both kind of >> approaches, VJCC and DTCP. > > It has been already discussed for TCP, just google FairDrop and TCP. > >> So to my understanding, neither VJCC nor DTCP separates the problem >> of resource allocation from the problem of congestion control, nor do >> they eventually _solve_ the problem of (fair) resource allocation. > > Anyway, my ISP with CAC or DiffServ does? Do we talk about fair queueing in the sense of best effort? The problem to find the right trade off between a more or less uncontrolled system and a QoS system here. CAC and DiffServ are clearly on the QoS side. -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From Jon.Crowcroft at cl.cam.ac.uk Sat Apr 6 03:56:03 2013 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Sat, 06 Apr 2013 11:56:03 +0100 Subject: [e2e] Why do we need congestion control? In-Reply-To: <515FFA56.7060200@web.de> References: <0037066628D6FC449C61186553CAE11D032D43A83ED9@njfpsrvexg2.research.att.com> <515AD4DD.4030809@web.de> <515B4B93.5060702@web.de> <515BEFDC.8040105@web.de> <515C16B9.3070007@isae.fr> <515C313E.6090205@web.de> <515C4E29.8090205@web.de> <60CC5ED9-45A2-465F-A6F6-15C580226D65@cs.ucsd.edu> <515D6474.909@web.de> <515D7083.4030307@isae.fr> <515F423E.2080703@web.de> <515FFA56.7060200@web.de> Message-ID: In missive <515FFA56.7060200 at web.de>, Detlef Bosau typed: >>>> Manu, how do you want to implement fair queueing on a backbone router >>> First, I've never claimed that I wanted to implement such mechanism=20 >>> inside the core router. >>I see. Howver: To my understanding, fair queueing must be available on=20 >>any router in this approach? not necessarily - see Core Stateless Fair Queueing http://www.cs.cmu.edu/~istoica/csfq/ >>>> with actually 200.000 flows? 150.000 of them being "mice"? >>> >>> You talk on average not instantaneously. You only maintain a state for=20 >>> flows currently enqueued. >>> It means that if you have a queue size of 30 packets, you can't have=20 >>> more than 30 states in your table. >> >> >>> >>>> At least this question should be discussed for both kind of >>>> approaches, VJCC and DTCP. >>> >>> It has been already discussed for TCP, just google FairDrop and TCP. >>> >>>> So to my understanding, neither VJCC nor DTCP separates the problem >>>> of resource allocation from the problem of congestion control, nor do >>>> they eventually _solve_ the problem of (fair) resource allocation. >>> >>> Anyway, my ISP with CAC or DiffServ does? >> >>Do we talk about fair queueing in the sense of best effort? The problem=20 >>to find the right trade off between a more or less uncontrolled system=20 >>and a QoS system here. CAC and DiffServ are clearly on the QoS side. >> >> >> >> >>--=20 >>------------------------------------------------------------------ >>Detlef Bosau >>Galileistra=C3=9Fe 30 >>70565 Stuttgart Tel.: +49 711 5208031 >> mobile: +49 172 6819937 >> skype: detlef.bosau >> ICQ: 566129673 >>detlef.bosau at web.de http://www.detlef-bosau.de >> cheers jon From detlef.bosau at web.de Mon Apr 8 03:25:10 2013 From: detlef.bosau at web.de (Detlef Bosau) Date: Mon, 08 Apr 2013 12:25:10 +0200 Subject: [e2e] Why do we need congestion control? In-Reply-To: References: <0037066628D6FC449C61186553CAE11D032D43A83ED9@njfpsrvexg2.research.att.com> <515AD4DD.4030809@web.de> <515B4B93.5060702@web.de> <515BEFDC.8040105@web.de> <515C16B9.3070007@isae.fr> <515C313E.6090205@web.de> <515C4E29.8090205@web.de> <60CC5ED9-45A2-465F-A6F6-15C580226D65@cs.ucsd.edu> <515D6474.909@web.de> <515D7083.4030307@isae.fr> <515F423E.2080703@web.de> <515FFA56.7060200@web.de> Message-ID: <51629B06.1050707@web.de> Am 06.04.2013 12:56, schrieb Jon Crowcroft: > In missive <515FFA56.7060200 at web.de>, Detlef Bosau typed: > > >>>> Manu, how do you want to implement fair queueing on a backbone router > > >>> First, I've never claimed that I wanted to implement such mechanism=20 > >>> inside the core router. > > >>I see. Howver: To my understanding, fair queueing must be available on=20 > >>any router in this approach? > > > not necessarily - see Core Stateless Fair Queueing > http://www.cs.cmu.edu/~istoica/csfq/ > What is particularly appealing here is the fact that there is no necessity to handle each TCP flow individually, the "flows" themselves are already aggregates. And the "fair dropping" happens within the flows, hence assumed TCP flows are "somewhat homogeneously mixed within a flow", the random drop within a flow may fairly affect all TCP flows along this aggregate flow. It is, however, still a "fair drop approach" which makes flows match their fair share of bandwidth by dropping packets. So, I expect at least the "mice elephant problem" is not eventually solved here? -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From detlef.bosau at web.de Wed Apr 10 06:14:15 2013 From: detlef.bosau at web.de (Detlef Bosau) Date: Wed, 10 Apr 2013 15:14:15 +0200 Subject: [e2e] Why do we need congestion control? In-Reply-To: <513788A3.6030005@richardclegg.org> References: <513788A3.6030005@richardclegg.org> Message-ID: <516565A7.6040200@web.de> Am 06.03.2013 19:19, schrieb Richard G. Clegg: > On 06/03/13 15:02, Jon Crowcroft wrote: >> ok - i see your point - this is true if your sources have a peak rate >> they can send at >> >> this could be the line rate of their uplink - >> that would be embarrasingly bad >> (see keshav's followup on escalating costs of coding) >> or the rate they can get data off disk (which could be as bad, but >> might be lower) >> or an application specific rate (e.g. streamed video) for which >> you're suggestion is >> quite reasonable... > Apologies if this has been mentioned already -- the "blast it out at > full whack and code against loss" strategy is explored in > Is the ''Law of the Jungle'' Sustainable for the Internet? from > Infocom 2009. > > Nice maths in that paper actually -- I was lucky enough to see them > present it. The conclusions are interesting. > > http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=5061903 > > I'm generally reluctant to "nice maths" in this discussion - quite a lot of the "mathwork" is an impressive envelope with hardly a letter inside. I think we should reconsider our goals here in order not to give another confirmation to the well known quote: "Having lost sight of our goals, we endoubled our efforts". In a PM, Matt Mathis mentioned that we should be particularly careful to use maths from "statistics" and "stochastics" - when actually there is hardly any stochastic behaviour is present. Matt pointed out that in many TCP scenarios, the behaviour of the net is mainly deterministic - and hence some of our statistical apparatus simply does not apply here, e.g. Little's Law. And I fear, the same holds true for erasure codes and statistic rationales for "fair goodput reduction". Let me sketch a very simple scenario here. Think of four nodes, e.g. PC, attached to a simple coax Ethernet. PC 1 PC 2 PC 3 PC 4 | | | | ----------------------------------------------------------------------- Think of two bidirectional TCP flows here. One betwenn PC 1 and PC 3, the other between PC 2 and PC 4. And now allow me to ask some questions. Q1: What do we want to achieve at all in this scenario? With particular respect to the categories - goodput - throughput - congestion avoidance - fairness? Q2: Do we need VJCC in this scenario? Q3: Which of the goals stated in response to Q 1 are achieved? Q4: If goals are achieved, refer to Q3, what is the particular contribution of VJCC here? This scenario is quite easy - and when I answered this questions for myself, it became clear that I simply asked the wrong question when I asked how many flows would fit into the Internet. To some degree, VJCC is a stroke of genius - while being a kludge at the same time. So, I would like to ask: What are our goals? What do we achieve? Did we achieve our goals? And is that what we achieve identical to our intentions in the first? -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From fred at cisco.com Wed Apr 10 07:48:28 2013 From: fred at cisco.com (Fred Baker (fred)) Date: Wed, 10 Apr 2013 14:48:28 +0000 Subject: [e2e] Why do we need congestion control? In-Reply-To: <516565A7.6040200@web.de> References: <513788A3.6030005@richardclegg.org> <516565A7.6040200@web.de> Message-ID: <8C48B86A895913448548E6D15DA7553B8081EE@xmb-rcd-x09.cisco.com> I find this whole discussion a little amazing. Let me step aside from math and esoteric arguments. Let me attach a simple test scenario, one that any of us could do at any time. I happen to be in a hotel; it's the Fairmont San Jose in San Jose California, but I don't know that the name of the hotel matters. I am located a few miles from Cisco's main campus, and am connected over a combination of the hotel wireless and one of the local internet providers to that campus using a VPN. I ran a ping (on Linux, it's "ping -s") from my hotel room to a computer "at the plant" for 12 hours overnight. I ran that through a simple script that summarizes, per minute, the minimum, maximum, median, arithmetic mean, and standard deviation of the samples in the minute, as well as the loss rate. The ping stands in for any packet; if the ping would see a given RTT at a given time, any packet exchange would see that RTT AFAIK. The data is dumped into a CSV file, which I can pull into my favorite spreadsheet application. You can look at a pdf of the median and minimum values overnight at ftp://ftpeng.cisco.com/fred/e2e/Fairmont-2013-04-09-median+minimum.pdf The other files are in the same directory including the raw ping output. One sample is at best anecdotal evidence, and I present it as nothing stronger. However, at the point where the median RTT in a given minute is on the order of seconds, and this is not an isolated event but happens from time to time throughout the test period, something's not right. Note that this is in a network *with* what we call congestion control and competing primarily with TCP sessions that use congestion control. Samples like this one, which are trivial to obtain, are the reason for congestion control in TCP and for AQM in the network. What I think folks are generally looking for is good throughput (if I want to move something from here to there, move it as fast as the available connectivity will permit), reasonable competition (if one neighbor is playing with bitorrent and another is watching a movie on his IP TV, I'd like to be able to do the same and have a satisfactory experience), and reasonable responsiveness (my median RTT should approximate my minimum RTT to a given site within some tolerance). BTW, statements such as RFC 6057 would suggest that service providers have pretty similar goals - they want their help-line phones to not ring and want their customers to recommend their services to other potential customers, and will take whatever steps they deem necessary to make that be true. That doesn't call for TDM purity, and it doesn't call for discussions of angels and heads of pins. It does call for reasonable behavior both by the ISP and by the end user equipment attached to it. On Apr 10, 2013, at 6:14 AM, Detlef Bosau wrote: > Am 06.03.2013 19:19, schrieb Richard G. Clegg: >> On 06/03/13 15:02, Jon Crowcroft wrote: >>> ok - i see your point - this is true if your sources have a peak rate they can send at >>> >>> this could be the line rate of their uplink - >>> that would be embarrasingly bad >>> (see keshav's followup on escalating costs of coding) >>> or the rate they can get data off disk (which could be as bad, but might be lower) >>> or an application specific rate (e.g. streamed video) for which you're suggestion is >>> quite reasonable... >> Apologies if this has been mentioned already -- the "blast it out at full whack and code against loss" strategy is explored in >> Is the ''Law of the Jungle'' Sustainable for the Internet? from Infocom 2009. >> >> Nice maths in that paper actually -- I was lucky enough to see them present it. The conclusions are interesting. >> >> http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=5061903 >> >> > > I'm generally reluctant to "nice maths" in this discussion - quite a lot of the "mathwork" is an impressive envelope with hardly a letter inside. > > I think we should reconsider our goals here in order not to give another confirmation to the well known quote: "Having lost sight of our goals, we endoubled our efforts". > > In a PM, Matt Mathis mentioned that we should be particularly careful to use maths from "statistics" and "stochastics" - when actually there is hardly any stochastic behaviour is present. Matt pointed out that in many TCP scenarios, the behaviour of the net is mainly deterministic - and hence some of our statistical apparatus simply does not apply here, e.g. Little's Law. And I fear, the same holds true for erasure codes and statistic rationales for "fair goodput reduction". > > > Let me sketch a very simple scenario here. > > Think of four nodes, e.g. PC, attached to a simple coax Ethernet. > > PC 1 PC 2 PC 3 PC 4 > | | | | > > ----------------------------------------------------------------------- > > Think of two bidirectional TCP flows here. > > One betwenn PC 1 and PC 3, the other between PC 2 and PC 4. > > > And now allow me to ask some questions. > > Q1: What do we want to achieve at all in this scenario? With particular respect to the categories > - goodput > - throughput > - congestion avoidance > - fairness? > > Q2: Do we need VJCC in this scenario? > > Q3: Which of the goals stated in response to Q 1 are achieved? > > Q4: If goals are achieved, refer to Q3, what is the particular contribution of VJCC here? > > This scenario is quite easy - and when I answered this questions for myself, it became clear that I simply asked the wrong question when I asked how many flows would fit into the Internet. > > To some degree, VJCC is a stroke of genius - while being a kludge at the same time. > > So, I would like to ask: What are our goals? What do we achieve? Did we achieve our goals? And is that what we achieve identical to our intentions in the first? > > > > > > -- > ------------------------------------------------------------------ > Detlef Bosau > Galileistra?e 30 > 70565 Stuttgart Tel.: +49 711 5208031 > mobile: +49 172 6819937 > skype: detlef.bosau > ICQ: 566129673 > detlef.bosau at web.de http://www.detlef-bosau.de > From detlef.bosau at web.de Wed Apr 10 08:21:58 2013 From: detlef.bosau at web.de (Detlef Bosau) Date: Wed, 10 Apr 2013 17:21:58 +0200 Subject: [e2e] Why do we need congestion control? In-Reply-To: <8C48B86A895913448548E6D15DA7553B8081EE@xmb-rcd-x09.cisco.com> References: <513788A3.6030005@richardclegg.org> <516565A7.6040200@web.de> <8C48B86A895913448548E6D15DA7553B8081EE@xmb-rcd-x09.cisco.com> Message-ID: <51658396.3070301@web.de> Am 10.04.2013 16:48, schrieb Fred Baker (fred): > I find this whole discussion a little amazing. > > Let me step aside from math and esoteric arguments. Let me attach a simple test scenario, one that any of us could do at any time. Like my little scenario :-) (O.k., perhaps you have no coax Ethernet handy, it's a bit outdated ;-)) > I happen to be in a hotel; it's the Fairmont San Jose in San Jose California, but I don't know that the name of the hotel matters. I am located a few miles from Cisco's main campus, and am connected over a combination of the hotel wireless and one of the local internet providers to that campus using a VPN. > > I ran a ping (on Linux, it's "ping -s") from my hotel room to a computer "at the plant" for 12 hours overnight. I ran that through a simple script that summarizes, per minute, the minimum, maximum, median, arithmetic mean, and standard deviation of the samples in the minute, as well as the loss rate. The ping stands in for any packet; if the ping would see a given RTT at a given time, any packet exchange would see that RTT AFAIK. The data is dumped into a CSV file, which I can pull into my favorite spreadsheet application. Hm. My scenario is a bit easier ;-) > You can look at a pdf of the median and minimum values overnight at > ftp://ftpeng.cisco.com/fred/e2e/Fairmont-2013-04-09-median+minimum.pdf > The other files are in the same directory including the raw ping output. Wonderful. And most of all: So easy to understand :-) > > One sample is at best anecdotal evidence, and I present it as nothing stronger. However, at the point where the median RTT in a given minute is on the order of seconds, and this is not an isolated event but happens from time to time throughout the test period, something's not right. Note that this is in a network *with* what we call congestion control and competing primarily with TCP sessions that use congestion control. Samples like this one, which are trivial to obtain, are the reason for congestion control in TCP and for AQM in the network. First of all, they are an observation. And first of all, they show that quite some statistics which we frequently assume to be constant or stationary are neither constant nor stationary. > > What I think folks are generally looking for is good throughput This is a valid attitude. However, I well know at least one person who is generally looking for a small RTT :-) Both is valid - the problem is however: Both attitudes are not necessarily compatible. > (if I want to move something from here to there, move it as fast as the available connectivity will permit), reasonable competition (if one neighbor is playing with bitorrent and another is watching a movie on his IP TV, I'd like to be able to do the same and have a satisfactory experience), and reasonable responsiveness (my median RTT should approximate my minimum RTT to a given site within some tolerance). BTW, statements such as RFC 6057 would suggest that service providers have pretty similar goals - they want their help-line phones to not ring and want their customers to recommend their services to other potential customers, and will take whatever steps they deem necessary to make that be true. > > That doesn't call for TDM purity, and it doesn't call for discussions of angels and heads of pins. It does call for reasonable behavior both by the ISP and by the end user equipment attached to it. Absolutely. And I refer to a talk by Matt Mathis, I read yesterday: Perhpas, there is not "the one and only" reasonable behaviour for each and everybody. When I wrote my post, I've chosen a scenario where VJCC, while not doing really harm, makes absolutely no contribution, neither to congestion control nor to fairness and scheduling. However, it is not harmful. But it doesn't make sense as well. It may not be the mainstream view, however I would like to identify a bit more precisely which problems we would like to solve. Of course, in my 4 node scenario, there is a common ressource: The Ethernet. And it is limited: To one packet being actually in transit. So, perhaps we have a congestion issue here: We must not have more packets in transit than one. And we have a scheduling issue here, although for this scenario we would rather call it "media access". And rates in this scenario are not "dominated" by CWND - but by the MAC latency. (BTW: Doesn't the congavoid paper makes a difference between "bandwidth dominated scenarios" and "latency dominated scenarios"? This is similar to that discussion.) None of these problems is addressed by VJCC here - so, the problems are existent - and being solved - however not by VJCC and VJCC is a really fine solution, hover in the aforementioned scenario, it is yet to find a problem. This is not to criticize VJCC. Hower, I sometimes have the expression that we derived huge mathematical models for VJCC and from VJCC - and that we sometimes mix up these sophisticated models with reality. Perhaps, this is only a personal matter of mine, and I'm the only person who tends to make this mistake. However, if there are others out there, we could talk about it and found a self help group ;-) > > On Apr 10, 2013, at 6:14 AM, Detlef Bosau > wrote: > >> Am 06.03.2013 19:19, schrieb Richard G. Clegg: >>> On 06/03/13 15:02, Jon Crowcroft wrote: >>>> ok - i see your point - this is true if your sources have a peak rate they can send at >>>> >>>> this could be the line rate of their uplink - >>>> that would be embarrasingly bad >>>> (see keshav's followup on escalating costs of coding) >>>> or the rate they can get data off disk (which could be as bad, but might be lower) >>>> or an application specific rate (e.g. streamed video) for which you're suggestion is >>>> quite reasonable... >>> Apologies if this has been mentioned already -- the "blast it out at full whack and code against loss" strategy is explored in >>> Is the ''Law of the Jungle'' Sustainable for the Internet? from Infocom 2009. >>> >>> Nice maths in that paper actually -- I was lucky enough to see them present it. The conclusions are interesting. >>> >>> http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=5061903 >>> >>> >> I'm generally reluctant to "nice maths" in this discussion - quite a lot of the "mathwork" is an impressive envelope with hardly a letter inside. >> >> I think we should reconsider our goals here in order not to give another confirmation to the well known quote: "Having lost sight of our goals, we endoubled our efforts". >> >> In a PM, Matt Mathis mentioned that we should be particularly careful to use maths from "statistics" and "stochastics" - when actually there is hardly any stochastic behaviour is present. Matt pointed out that in many TCP scenarios, the behaviour of the net is mainly deterministic - and hence some of our statistical apparatus simply does not apply here, e.g. Little's Law. And I fear, the same holds true for erasure codes and statistic rationales for "fair goodput reduction". >> >> >> Let me sketch a very simple scenario here. >> >> Think of four nodes, e.g. PC, attached to a simple coax Ethernet. >> >> PC 1 PC 2 PC 3 PC 4 >> | | | | >> >> ----------------------------------------------------------------------- >> >> Think of two bidirectional TCP flows here. >> >> One betwenn PC 1 and PC 3, the other between PC 2 and PC 4. >> >> >> And now allow me to ask some questions. >> >> Q1: What do we want to achieve at all in this scenario? With particular respect to the categories >> - goodput >> - throughput >> - congestion avoidance >> - fairness? >> >> Q2: Do we need VJCC in this scenario? >> >> Q3: Which of the goals stated in response to Q 1 are achieved? >> >> Q4: If goals are achieved, refer to Q3, what is the particular contribution of VJCC here? >> >> This scenario is quite easy - and when I answered this questions for myself, it became clear that I simply asked the wrong question when I asked how many flows would fit into the Internet. >> >> To some degree, VJCC is a stroke of genius - while being a kludge at the same time. >> >> So, I would like to ask: What are our goals? What do we achieve? Did we achieve our goals? And is that what we achieve identical to our intentions in the first? >> >> >> >> >> >> -- >> ------------------------------------------------------------------ >> Detlef Bosau >> Galileistra?e 30 >> 70565 Stuttgart Tel.: +49 711 5208031 >> mobile: +49 172 6819937 >> skype: detlef.bosau >> ICQ: 566129673 >> detlef.bosau at web.de http://www.detlef-bosau.de >> -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From dhc2 at dcrocker.net Wed Apr 10 11:02:01 2013 From: dhc2 at dcrocker.net (Dave Crocker) Date: Wed, 10 Apr 2013 11:02:01 -0700 Subject: [e2e] Why do we need congestion control? In-Reply-To: <8C48B86A895913448548E6D15DA7553B8081EE@xmb-rcd-x09.cisco.com> References: <513788A3.6030005@richardclegg.org> <516565A7.6040200@web.de> <8C48B86A895913448548E6D15DA7553B8081EE@xmb-rcd-x09.cisco.com> Message-ID: <5165A919.5040309@dcrocker.net> On 4/10/2013 7:48 AM, Fred Baker (fred) wrote: > I find this whole discussion a little amazing. +1 >Samples like this one, which are trivial to obtain, are the > reason for congestion control in TCP and for AQM in the network. +1 Your note nicely and simply points out pragmatics that persist in the modern Internet. None of what you've written is new or unusual (and no, you didn't pretend otherwise.) In the face of this, what I don't understand is why this thread has gone on for so long. Surely it should be allowed to die, given that the core -- possibly reasonable -- concern was long-ago answered. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From detlef.bosau at web.de Wed Apr 10 11:26:38 2013 From: detlef.bosau at web.de (Detlef Bosau) Date: Wed, 10 Apr 2013 20:26:38 +0200 Subject: [e2e] Why do we need congestion control? In-Reply-To: <51658396.3070301@web.de> References: <513788A3.6030005@richardclegg.org> <516565A7.6040200@web.de> <8C48B86A895913448548E6D15DA7553B8081EE@xmb-rcd-x09.cisco.com> <51658396.3070301@web.de> Message-ID: <5165AEDE.2040109@web.de> I could even extend my scenario with, say, PC 5 to PC 20 and TCP flows (bidirectional) from PC 5 to PC 7 etc. up to PC 18 to PC 20. In other words: I can increase the load. Hence, an individual flow's throughput / goodput will be decreased. Perhaps, this should be commonplaces here. However, I hardly find this in many papers or even less in simulations. (E.g. I never really understood/believed the Ethernet-simulation in the NS2.....) Am 10.04.2013 17:21, schrieb Detlef Bosau: > >>> Let me sketch a very simple scenario here. >>> >>> Think of four nodes, e.g. PC, attached to a simple coax Ethernet. >>> >>> PC 1 PC 2 PC >>> 3 PC 4 >>> | | | | >>> >>> ----------------------------------------------------------------------- >>> >>> Think of two bidirectional TCP flows here. >>> >>> One betwenn PC 1 and PC 3, the other between PC 2 and PC 4. >>> >>> >>> And now allow me to ask some questions. >>> >>> Q1: What do we want to achieve at all in this scenario? With >>> particular respect to the categories >>> - goodput >>> - throughput >>> - congestion avoidance >>> - fairness? >>> >>> Q2: Do we need VJCC in this scenario? >>> >>> Q3: Which of the goals stated in response to Q 1 are achieved? >>> >>> Q4: If goals are achieved, refer to Q3, what is the particular >>> contribution of VJCC here? >>> >>> This scenario is quite easy - and when I answered this questions for >>> myself, it became clear that I simply asked the wrong question when >>> I asked how many flows would fit into the Internet. >>> >>> To some degree, VJCC is a stroke of genius - while being a kludge at >>> the same time. >>> >>> So, I would like to ask: What are our goals? What do we achieve? Did >>> we achieve our goals? And is that what we achieve identical to our >>> intentions in the first? >>> >>> >>> >>> >>> >>> -- >>> ------------------------------------------------------------------ >>> Detlef Bosau >>> Galileistra?e 30 >>> 70565 Stuttgart Tel.: +49 711 5208031 >>> mobile: +49 172 6819937 >>> Ich sehe nur den Klappentext zu Hetze-Rita: >>> >>> skype: detlef.bosau >>> ICQ: 566129673 >>> detlef.bosau at web.de http://www.detlef-bosau.de >>> > > -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From mellia at tlc.polito.it Wed Apr 10 12:30:31 2013 From: mellia at tlc.polito.it (Marco Mellia) Date: Wed, 10 Apr 2013 21:30:31 +0200 Subject: [e2e] Why do we need congestion control? In-Reply-To: <5165A919.5040309@dcrocker.net> References: <513788A3.6030005@richardclegg.org> <516565A7.6040200@web.de> <8C48B86A895913448548E6D15DA7553B8081EE@xmb-rcd-x09.cisco.com> <5165A919.5040309@dcrocker.net> Message-ID: > > In the face of this, what I don't understand is why this thread has gone on for so long. Surely it should be allowed to die, given +1 > that the core -- possibly reasonable -- concern was long-ago answered. my 2c M From dhavey at yahoo.com Wed Apr 10 13:06:30 2013 From: dhavey at yahoo.com (Daniel Havey) Date: Wed, 10 Apr 2013 13:06:30 -0700 (PDT) Subject: [e2e] Why do we need congestion control? In-Reply-To: <5165A919.5040309@dcrocker.net> Message-ID: <1365624390.55729.YahooMailClassic@web163004.mail.bf1.yahoo.com> --- On Wed, 4/10/13, Dave Crocker wrote: > From: Dave Crocker > Subject: Re: [e2e] Why do we need congestion control? > To: "Fred Baker (fred)" > Cc: "" > Date: Wednesday, April 10, 2013, 11:02 AM > > > On 4/10/2013 7:48 AM, Fred Baker (fred) wrote: > > I find this whole discussion a little amazing. > > +1 > > > Samples like this one, which are trivial to obtain, are > the > > reason for congestion control in TCP and for AQM in the > network. > > +1 These are the best kind of samples. If they are trivial then it will be easier to obtain many of them for statistical significance. > > Your note nicely and simply points out pragmatics that > persist in the modern Internet.? None of what you've > written is new or unusual (and no, you didn't pretend > otherwise.) Pragmatics? To the exclusion of intellectual or artistic matters...Hmmm, probably not gonna get my PhD that way. Yeah, we will probably ignore the artistic stuff... > > In the face of this, what I don't understand is why this > thread has gone on for so long.? Surely it should be > allowed to die, given that the core -- possibly reasonable > -- concern was long-ago answered. So I don't understand this. The so called "bufferbloat" problem is solved in the core? But pragmatically speaking it still exists? This wont get me a PhD, but, one has to ask, why? Does the core drop segments? Or does it buffer them? > d/ > --? Dave Crocker > Brandenburg InternetWorking > bbiw.net > From sanjay at ecn.purdue.edu Sun Apr 7 17:00:29 2013 From: sanjay at ecn.purdue.edu (Sanjay G Rao) Date: Sun, 7 Apr 2013 20:00:29 -0400 (EDT) Subject: [e2e] Call for Papers: ACM CoNext 2013 Message-ID: Call For Papers *************** ACM CoNext 2013, Dec 9th to 12th, Santa Barbara, CA, USA ********************************************************* The 9th International Conference on emerging Networking EXperiments and Technologies (CoNEXT) will be held from December 9th to 12th in Santa Barbara, CA. CoNEXT 2013 will be a major forum for presentations and discussions of novel networking technologies that will shape the future of Internetworking. The conference is single track and features a high-quality technical program with significant opportunities for individual and small-group technical and social interactions among a diverse set of participants. This year the conference will feature two separate calls for papers. The first one will be targeted to mature, technical work, that has been the focus of the conference throughout the past 8 years (12 pages, 10 pt, 2 column). The second will be an explicit call for short papers (6 pages, 10pt, 2 column). With that call we would like to make CoNEXT a vehicle for the dissemination of new ideas, that may not have reached the level of maturity of full papers. Both types of papers will be reviewed by the same Technical Program Committee, but with separate processes. Relevant topics for the conference include, but are not limited to: ******************************************************************* Internet measurement and modeling Wireless networks Mobile and cellular networks Mesh, ad hoc and sensor networks Economic aspects of the Internet Network security Datacenter networks Peer-to-peer, overlay and content distribution networks Online social networks Routing and traffic engineering Network management, including energy issues Interface between networking, communications and information theory New networking protocols and architectures Applications of network science in communication networks Important Dates: **************** CoNEXT'13: Abstract submission June 8, 2013 CoNEXT'13: Full paper submission June 14, 2013 (hard deadline) CoNEXT'13: Short paper submission July 12, 2013 (hard deadline) CoNEXT'13: Acceptance notification September 23, 2013 CoNEXT'13: Camera ready November 1, 2013 CoNEXT'13: Conference December 9-12, 2013 General Chairs: **************** Kevin Almeroth, UC Santa Barbara, USA and Laurent Mathy, Université de Liège, Belgium Technical Program Chairs: ************************ Dina Papagiannaki,Telefonica Research, spain and Vishal Misra, Columbia University, USA For More Details: ***************** Please see http://conferences.sigcomm.org/co-next/2013/ From fred at cisco.com Wed Apr 10 13:44:26 2013 From: fred at cisco.com (Fred Baker (fred)) Date: Wed, 10 Apr 2013 20:44:26 +0000 Subject: [e2e] Why do we need congestion control? In-Reply-To: <1365624390.55729.YahooMailClassic@web163004.mail.bf1.yahoo.com> References: <1365624390.55729.YahooMailClassic@web163004.mail.bf1.yahoo.com> Message-ID: <8C48B86A895913448548E6D15DA7553B808A36@xmb-rcd-x09.cisco.com> On Apr 10, 2013, at 1:06 PM, Daniel Havey wrote: >> In the face of this, what I don't understand is why this >> thread has gone on for so long. Surely it should be >> allowed to die, given that the core -- possibly reasonable >> -- concern was long-ago answered. > So I don't understand this. The so called "bufferbloat" problem is solved in the core? But pragmatically speaking it still exists? This wont get me a PhD, but, one has to ask, why? Does the core drop segments? Or does it buffer them? It does. Not often, but it does when it needs to. http://www.ieee-infocom.org/2004/papers/37_4.pdf Most buffer bloat behavior is at the edge - WiFi, Mobile telephone, broadband. There are other cases. But think about dumbbell networks - two fast networks connected by something slower. That's where you'll find it. From detlef.bosau at web.de Thu Apr 11 04:19:05 2013 From: detlef.bosau at web.de (Detlef Bosau) Date: Thu, 11 Apr 2013 13:19:05 +0200 Subject: [e2e] Why do we need congestion control? In-Reply-To: <1365624390.55729.YahooMailClassic@web163004.mail.bf1.yahoo.com> References: <1365624390.55729.YahooMailClassic@web163004.mail.bf1.yahoo.com> Message-ID: <51669C29.9050900@web.de> Am 10.04.2013 22:06, schrieb Daniel Havey: > These are the best kind of samples. If they are trivial then it will be easier to obtain many of them for statistical significance. For significance of what? Do you gather deterministic examples for statistical significance? Or trivial examples which shall be significant for complex problems? The most prominent problem in VJCC is that it intertwines scheduling and congestion control. And while there are well scenarios where this works, there are well scenarios where VJCC neither provides appropriate scheduling nor fixes a congestion problem. > In the face of this, what I don't understand is why this > thread has gone on for so long. Surely it should be > allowed to die, given that the core -- possibly reasonable > -- concern was long-ago answered. I think, some reasonable concerns are NOT well answered. > So I don't understand this. The so called "bufferbloat" problem is solved in the core? But pragmatically speaking it still exists? This wont get me a PhD, but, one has to ask, why? Does the core drop segments? Or does it buffer them? > May I speak frankly? Although VJCC is a wonderful thesis generator, the "buffer bloat problem" seems to be more a mixture of wrong configuration than a structural problem, a solution of which would justify a PhD. -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From detlef.bosau at web.de Thu Apr 11 07:14:21 2013 From: detlef.bosau at web.de (Detlef Bosau) Date: Thu, 11 Apr 2013 16:14:21 +0200 Subject: [e2e] Why do we need congestion control? In-Reply-To: <8C48B86A895913448548E6D15DA7553B808A36@xmb-rcd-x09.cisco.com> References: <1365624390.55729.YahooMailClassic@web163004.mail.bf1.yahoo.com> <8C48B86A895913448548E6D15DA7553B808A36@xmb-rcd-x09.cisco.com> Message-ID: <5166C53D.3090304@web.de> Am 10.04.2013 22:44, schrieb Fred Baker (fred): > On Apr 10, 2013, at 1:06 PM, Daniel Havey > wrote: > >>> In the face of this, what I don't understand is why this >>> thread has gone on for so long. Surely it should be >>> allowed to die, given that the core -- possibly reasonable >>> -- concern was long-ago answered. >> So I don't understand this. The so called "bufferbloat" problem is solved in the core? But pragmatically speaking it still exists? This wont get me a PhD, but, one has to ask, why? Does the core drop segments? Or does it buffer them? > It does. Not often, but it does when it needs to. And this was, at least several times in this discussion IIRC, clearly identified as a configuration problem. At least when packets are dropped to that degree that this causes a problem like buffer bloat. To my understanding, the Internet core (Tier 1) does overprovisioning, hence drops should be extremely rare there. -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From dhavey at yahoo.com Thu Apr 11 14:16:41 2013 From: dhavey at yahoo.com (Daniel Havey) Date: Thu, 11 Apr 2013 14:16:41 -0700 (PDT) Subject: [e2e] Why do we need congestion control? In-Reply-To: <8C48B86A895913448548E6D15DA7553B808A36@xmb-rcd-x09.cisco.com> Message-ID: <1365715001.4369.YahooMailClassic@web163002.mail.bf1.yahoo.com> --- On Wed, 4/10/13, Fred Baker (fred) wrote: > From: Fred Baker (fred) > Subject: Re: [e2e] Why do we need congestion control? > To: "" > Cc: "" , "" > Date: Wednesday, April 10, 2013, 1:44 PM > > On Apr 10, 2013, at 1:06 PM, Daniel Havey > wrote: > > >> In the face of this, what I don't understand is why > this > >> thread has gone on for so long.? Surely it > should be > >> allowed to die, given that the core -- possibly > reasonable > >> -- concern was long-ago answered. > > So I don't understand this.? The so called > "bufferbloat" problem is solved in the core?? But > pragmatically speaking it still exists?? This wont get > me a PhD, but, one has to ask, why?? Does the core drop > segments?? Or does it buffer them? > > It does. Not often, but it does when it needs to. > > http://www.ieee-infocom.org/2004/papers/37_4.pdf > > Most buffer bloat behavior is at the edge - WiFi, Mobile > telephone, broadband. There are other cases. But think about > dumbbell networks - two fast networks connected by something > slower. That's where you'll find it. I agree. The segments fly through the core then probably slam into a rate limiter at the edge of the ISP. Either that, or they blow through the rate limiter and hit a slow wireless hop. From dhc2 at dcrocker.net Thu Apr 11 20:59:42 2013 From: dhc2 at dcrocker.net (Dave Crocker) Date: Thu, 11 Apr 2013 20:59:42 -0700 Subject: [e2e] Internet "architecture" Message-ID: <516786AE.5020009@dcrocker.net> This is a risky query. There have been previous threads about such things as the "start" of the Internet. Instead, I want to ask about the "architecture" of the Internet. Here's a comment that I sent earlier today, to a non-technical person who is aware of the overall Internet timeline, but I believe does not understand what is distinctive about Internet 'architecture'. I'm curious about reactions on this list, and any possible improvements -- including complete replacement -- but more importantly I'm interested in filling in the details: The original use of the term Internet was to describe a distinctive technical design for a distributed, scalable data exchange fabric. Its design characteristics differ dramatically from those of its predecessor, the Arpanet, and from other related efforts. That's what I sent. To prime the pump for the detail: By saying 'fabric' I meant to distinguish the mechanism for moving raw data from the applications that used it. What I'd class as distinctive were the TCP/IP separation, the remarkably modest functionality of IP, even to the point of moving it's control plane to the next level up with ICMP, and continuing with modest expectations the layer below (which made it possible to operate over any medium including birds.) This is usually characterized as moving robustness to the edges. Thoughts? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From Jon.Crowcroft at cl.cam.ac.uk Thu Apr 11 22:22:30 2013 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Fri, 12 Apr 2013 06:22:30 +0100 Subject: [e2e] Internet "architecture" In-Reply-To: <516786AE.5020009@dcrocker.net> References: <516786AE.5020009@dcrocker.net> Message-ID: just before the word internet was used, some people used the terms catenet (for a concatenation of networks) and gateway (for something that did protocol translation) this was around the time of the switchover from NCP to the seperation of TCP and IP - however, the clarity of the simplification you describe about the "architecture" was not, as far as I saw at the time part of the deliberate choice - it is described in dave clarks 1988 sigcomm paper, but that is nearly a decade after that time... the internet you describe is an emergent post hoc rationalisation for IP's alleged parsimony by the way, while ICMP was moved out of IP, the control plane you need to participate in the net (ARP, DHCP, NAT, OSPF, BGP, etc) is by no means simple indeed is mor LOC and bugs than any TCP... In missive <516786AE.5020009 at dcrocker.net>, Dave Crocker typed: >>This is a risky query. There have been previous threads about such >>things as the "start" of the Internet. Instead, I want to ask about the >>"architecture" of the Internet. >> >>Here's a comment that I sent earlier today, to a non-technical person >>who is aware of the overall Internet timeline, but I believe does not >>understand what is distinctive about Internet 'architecture'. I'm >>curious about reactions on this list, and any possible improvements -- >>including complete replacement -- but more importantly I'm interested in >>filling in the details: >> >> The original use of the term Internet was to describe a >>distinctive technical design for a distributed, scalable data exchange >>fabric. Its design characteristics differ dramatically from those of >>its predecessor, the Arpanet, and from other related efforts. >> >>That's what I sent. To prime the pump for the detail: >> >> By saying 'fabric' I meant to distinguish the mechanism for moving >>raw data from the applications that used it. What I'd class as >>distinctive were the TCP/IP separation, the remarkably modest >>functionality of IP, even to the point of moving it's control plane to >>the next level up with ICMP, and continuing with modest expectations the >>layer below (which made it possible to operate over any medium including >>birds.) This is usually characterized as moving robustness to the edges. >> >> >>Thoughts? >> >>d/ >> >>-- >> Dave Crocker >> Brandenburg InternetWorking >> bbiw.net cheers jon From fred at cisco.com Fri Apr 12 06:07:10 2013 From: fred at cisco.com (Fred Baker (fred)) Date: Fri, 12 Apr 2013 13:07:10 +0000 Subject: [e2e] Internet "architecture" In-Reply-To: <516786AE.5020009@dcrocker.net> References: <516786AE.5020009@dcrocker.net> Message-ID: <8C48B86A895913448548E6D15DA7553B80B149@xmb-rcd-x09.cisco.com> I'd suggest running the assertion by Vint. I made a similar assertion in a document not too long ago, which I ran by him for comment, and he told me I was flatly wrong. Yes, the circuit switch folks were using the term "catenet" to refer to networks that interoperated through translation, such as frame relay/ATM interoperation, he asserted, but at least some (he?) was using the term "Internet" as early as the mid 1970's. On Apr 11, 2013, at 8:59 PM, Dave Crocker wrote: > This is a risky query. There have been previous threads about such things as the "start" of the Internet. Instead, I want to ask about the "architecture" of the Internet. > > Here's a comment that I sent earlier today, to a non-technical person who is aware of the overall Internet timeline, but I believe does not understand what is distinctive about Internet 'architecture'. I'm curious about reactions on this list, and any possible improvements -- including complete replacement -- but more importantly I'm interested in filling in the details: > > The original use of the term Internet was to describe a distinctive technical design for a distributed, scalable data exchange fabric. Its design characteristics differ dramatically from those of its predecessor, the Arpanet, and from other related efforts. > > That's what I sent. To prime the pump for the detail: > > By saying 'fabric' I meant to distinguish the mechanism for moving raw data from the applications that used it. What I'd class as distinctive were the TCP/IP separation, the remarkably modest functionality of IP, even to the point of moving it's control plane to the next level up with ICMP, and continuing with modest expectations the layer below (which made it possible to operate over any medium including birds.) This is usually characterized as moving robustness to the edges. > > > Thoughts? > > d/ > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net From jnc at mercury.lcs.mit.edu Fri Apr 12 07:04:23 2013 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Fri, 12 Apr 2013 10:04:23 -0400 (EDT) Subject: [e2e] Internet "architecture" Message-ID: <20130412140423.886C718C17A@mercury.lcs.mit.edu> > From: Dave Crocker > The original use of the term Internet was to describe a distinctive > technical design Err, that would be '_i_nternet'; that term came first, by quite a few years. The term '_I_nternet', introduced later, was brought in to denote specifically to the large one which has nowdays swallowed most (But not all! The term 'airgap' exists for a reason!) of them. > for a distributed, scalable data exchange fabric. I'm not sure how far I'd go with the 'scalable'. The earliest version only supported 256 networks, and it's been a constant struggle ever since to keep it growable! (Long diatribe on turns missed elided...) I think its main novelty, in terms of goals, was its ability to tie together many heterogeneous kinds of networks; it was that that led to many of its characteristic architectural aspects (e.g. moving the reliability into the hosts). > What I'd class as distinctive were the TCP/IP separation True, although i) that wasn't in the earliest versions, and I _think_ (without checking) that CYCLADES had a similar kind of thing. > the remarkably modest functionality of IP, even to the point of moving > it's control plane to the next level up with ICMP Again, I think CYCLADES had that (ditto comment about having to check). > and continuing with modest expectations the layer below (which made it > possible to operate over any medium including birds.) I think this (along with the whole 'separate _inter_network header which stays the same as local headers come and go', with a single internet-wide naming domain which was used for the names in that header) is probably TCP/IP's big step over CYCLADES. (And I'd have to check if CYCLADES made an unreliable packet service available directly to users. If not, add that to the list.) > This is usually characterized as moving robustness to the edges. I think those two are somewhat orthogonal, actually. Yes, to get that 'run over anything' you probably do have to move the reliability to the edges, but I can imagine homogeneous networks which also moved reliability to the edges. Noel From jon.crowcroft at cl.cam.ac.uk Fri Apr 12 07:23:23 2013 From: jon.crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Fri, 12 Apr 2013 16:23:23 +0200 Subject: [e2e] Internet "architecture" In-Reply-To: <8C48B86A895913448548E6D15DA7553B80B149@xmb-rcd-x09.cisco.com> References: <516786AE.5020009@dcrocker.net> <8C48B86A895913448548E6D15DA7553B80B149@xmb-rcd-x09.cisco.com> Message-ID: the folks who called it catenet included bob braden who was working at UCL when i was there - of course, we were concatenating networks that ran other protocols (Cambridge Ring, X.25 (transport layer relays) and so on...so perhaps I'm conflating two things - the interconnection of multiple disprate protocol systems, and the IP interconenction of multiple IP networks with disparete layer 2 and below.... it is the case (as some other folks privately pointed out to me) that IENs (including IEN 1 written at UCL) are Internet Experiment Notes, and go back to mid 1970s, so i'm wrong to say "internet" however, my point about parsimony is really over compressed - IP trades off simplicity in the data plane, for complexity in the control plane - its not a pure trade off (it can be seen partly as a win-win, as signaling protocols for VC networks can be nearly as complex (or in X.25 and B-ISDN's Q.2931's cases, more complex) as routing protocols....nevertheless, getting routing right and all associated components is seriously non-trivial - other systems (the aforesaid cambridge ring protocol stack) represent a different trade off that is also quite elegant. the post-hoc rationalisation phrase is way too glib....certainly not intended to be rude to people that created this cool stuff we all use - in fact i was conflating three things 1. a bunch of work fairly recently on optimal protocols and narrow waist of the hour glass... 2. the ordering of constrints on the design of the internet protocols (as per dave clarks 88 paper) and 3. the apparent simplicity of IP - my missing point was that the complexity pops out somewhere, and that place is in the control plane....as we've since disovered... of course, there were people that ran dynamic distributed routing for VC networks (X.25 for example - we had switches in the JANET network that did this) so they were even more complex in both data and control plane (what with crankback etc etc:) so yes, a bit glib really...sorry normal service will be resumed as soon as I get my IPTV QoS back :) j. On Fri, Apr 12, 2013 at 3:07 PM, Fred Baker (fred) wrote: > I'd suggest running the assertion by Vint. I made a similar assertion in a > document not too long ago, which I ran by him for comment, and he told me I > was flatly wrong. Yes, the circuit switch folks were using the term > "catenet" to refer to networks that interoperated through translation, such > as frame relay/ATM interoperation, he asserted, but at least some (he?) was > using the term "Internet" as early as the mid 1970's. > > On Apr 11, 2013, at 8:59 PM, Dave Crocker wrote: > > > This is a risky query. There have been previous threads about such > things as the "start" of the Internet. Instead, I want to ask about the > "architecture" of the Internet. > > > > Here's a comment that I sent earlier today, to a non-technical person > who is aware of the overall Internet timeline, but I believe does not > understand what is distinctive about Internet 'architecture'. I'm curious > about reactions on this list, and any possible improvements -- including > complete replacement -- but more importantly I'm interested in filling in > the details: > > > > The original use of the term Internet was to describe a distinctive > technical design for a distributed, scalable data exchange fabric. Its > design characteristics differ dramatically from those of its predecessor, > the Arpanet, and from other related efforts. > > > > That's what I sent. To prime the pump for the detail: > > > > By saying 'fabric' I meant to distinguish the mechanism for moving > raw data from the applications that used it. What I'd class as distinctive > were the TCP/IP separation, the remarkably modest functionality of IP, even > to the point of moving it's control plane to the next level up with ICMP, > and continuing with modest expectations the layer below (which made it > possible to operate over any medium including birds.) This is usually > characterized as moving robustness to the edges. > > > > > > Thoughts? > > > > d/ > > > > -- > > Dave Crocker > > Brandenburg InternetWorking > > bbiw.net > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20130412/6c2a19ad/attachment-0001.html From touch at isi.edu Fri Apr 12 07:41:19 2013 From: touch at isi.edu (Joe Touch) Date: Fri, 12 Apr 2013 07:41:19 -0700 Subject: [e2e] Internet "architecture" In-Reply-To: <20130412140423.886C718C17A@mercury.lcs.mit.edu> References: <20130412140423.886C718C17A@mercury.lcs.mit.edu> Message-ID: <51681D0F.900@isi.edu> Hi, all, FYI, postel.org also hosts an Internet History email list. You might find more interested parties for this discussion there (though the topic is welcome here). (I know some parties in this discussion already knew that, but wanted to remind any others on this list) Joe (as list admin) On 4/12/2013 7:04 AM, Noel Chiappa wrote: > > From: Dave Crocker > > > The original use of the term Internet was to describe a distinctive > > technical design > > Err, that would be '_i_nternet'; that term came first, by quite a few years. > The term '_I_nternet', introduced later, was brought in to denote specifically > to the large one which has nowdays swallowed most (But not all! The term > 'airgap' exists for a reason!) of them. > > > > for a distributed, scalable data exchange fabric. > > I'm not sure how far I'd go with the 'scalable'. The earliest version only > supported 256 networks, and it's been a constant struggle ever since to keep > it growable! (Long diatribe on turns missed elided...) > > I think its main novelty, in terms of goals, was its ability to tie together > many heterogeneous kinds of networks; it was that that led to many of its > characteristic architectural aspects (e.g. moving the reliability into the > hosts). > > > What I'd class as distinctive were the TCP/IP separation > > True, although i) that wasn't in the earliest versions, and I _think_ (without > checking) that CYCLADES had a similar kind of thing. > > > the remarkably modest functionality of IP, even to the point of moving > > it's control plane to the next level up with ICMP > > Again, I think CYCLADES had that (ditto comment about having to check). > > > and continuing with modest expectations the layer below (which made it > > possible to operate over any medium including birds.) > > I think this (along with the whole 'separate _inter_network header which stays > the same as local headers come and go', with a single internet-wide naming > domain which was used for the names in that header) is probably TCP/IP's big > step over CYCLADES. (And I'd have to check if CYCLADES made an unreliable > packet service available directly to users. If not, add that to the list.) > > > This is usually characterized as moving robustness to the edges. > > I think those two are somewhat orthogonal, actually. Yes, to get that 'run > over anything' you probably do have to move the reliability to the edges, but > I can imagine homogeneous networks which also moved reliability to the edges. > > Noel > From dhc2 at dcrocker.net Fri Apr 12 09:35:26 2013 From: dhc2 at dcrocker.net (Dave Crocker) Date: Fri, 12 Apr 2013 09:35:26 -0700 Subject: [e2e] Internet "architecture" In-Reply-To: <20130412140423.886C718C17A@mercury.lcs.mit.edu> References: <20130412140423.886C718C17A@mercury.lcs.mit.edu> Message-ID: <516837CE.4050905@dcrocker.net> On 4/12/2013 7:04 AM, Noel Chiappa wrote: >> From: Dave Crocker > >> The original use of the term Internet was to describe a distinctive >> technical design > > Err, that would be '_i_nternet'; that term came first, by quite a > few years. For this exercise, that kind of esoterica is far, far out of scope. Really. I'm trying to discern core technical issues about the integrated design. In an informed, deep discussion among experts the capitalization of the 'i' makes a large difference; but it doesn't matter for the coarse-grained exercise of this query. > I'm not sure how far I'd go with the 'scalable'. The earliest > version only supported 256 networks, and it's been a constant > struggle ever since to keep The difference between initial proposals vs. eventual deployment are extremely important when discussing an evolutionary process, collaborative style and the like. But those weren't my question. When deployed, IP had 32 bits, 4 times its as many as NCP. (One might enjoy the consistency of having done that again, when moving to IPv6...) As for the fact that 32 bits has limits, no kidding. But to say that something that had continuous operation over the course of 25+ years, in going from a very small research network into a global service with billions of user does not represent scalability. Sorry, but that sounds like a mathematician and not an engineer... (hmmm. was that insulting?) > I think its main novelty, in terms of goals, was its ability to tie > together many heterogeneous kinds of networks; Right. Embracing modest goals can produce remarkable flexibility. >> What I'd class as distinctive were the TCP/IP separation > > True, although i) that wasn't in the earliest versions, and I > _think_ (without checking) that CYCLADES had a similar kind of > thing. > >> the remarkably modest functionality of IP, even to the point of >> moving it's control plane to the next level up with ICMP > > Again, I think CYCLADES had that (ditto comment about having to > check). > >> and continuing with modest expectations the layer below (which >> made it possible to operate over any medium including birds.) and... On 4/12/2013 7:51 AM, dpreed at reed.com wrote: > There is a vast literature in the late 1960's and early 1970's of > ideas that were brought into the Internet fold - ideas about LANs, > catenets, "resource sharing", atomicity, error recovery, control > systems, ... and the current Internet design brought almost all of > those together, by the simple virtue of bringing together a wide > collection of folks. Some, many or maybe all of the 'component' ideas within the Internet architecture had been demonstrated elsewhere. Documenting these details is a useful exercise. But it's quite distinct from documenting the distinctive synthesize of components into a specific networking design. The choices made in synthesizing an integrated design represent a separate skill from the design of the component technologies. Look at how many system designs get the balance of functionality, usability and complexity wrong. To repeat: I think it an entirely worthy exercise to be clear about the invention of components, but my question is about the integrated system that I meant, by asking after the /architecture/ of the Internet's data exchange fabric. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From jnc at mercury.lcs.mit.edu Fri Apr 12 10:55:23 2013 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Fri, 12 Apr 2013 13:55:23 -0400 (EDT) Subject: [e2e] Internet "architecture" Message-ID: <20130412175523.242DD18C135@mercury.lcs.mit.edu> > From: Dave Crocker > When deployed, IP had 32 bits, 4 times its as many as NCP. As an aside (to correct the record lest someone read it later and take it as accurate), err, no. That would have been 'short headers', deprecated ca. 1975. 'Long headers' had 8 bits of host, and 12 of IMP (20 bits). (There was also an 8-bit 'Network' field, but it was unused.) > my question is about the integrated system that I meant, by asking > after the /architecture/ of the Internet's data exchange fabric. Well, now I'm completely lost; I thought that's what we were talking about, in discussing how it introduced a single namespace to cover the entire collection of networks (namespaces are key to architecture, no?), an unchanging header across all of them, etc. So now I have no idea what it is you want. Noel From detlef.bosau at web.de Fri Apr 12 11:44:56 2013 From: detlef.bosau at web.de (Detlef Bosau) Date: Fri, 12 Apr 2013 20:44:56 +0200 Subject: [e2e] Internet "architecture" In-Reply-To: References: <516786AE.5020009@dcrocker.net> Message-ID: <51685628.1000300@web.de> Am 12.04.2013 07:22, schrieb Jon Crowcroft: > just before the word internet was used, some people used the terms > catenet (for a concatenation of networks) > and > gateway (for something that did protocol translation) > > this was around the time of the switchover from NCP to the seperation of > TCP and IP - however, the clarity of the simplification you describe > about the "architecture" was not, as far as I saw at the time > part of the deliberate choice - it is described in dave clarks 1988 sigcomm paper, but that is nearly a > decade after that time... > Some months ago, I had a look at the original catenet paper by Vint Cerf and compared it to RFC 791. To my understanding, the catenet model makes stronger assumptions to the network segments. In particular, to my understanding in catenet, there was a flow control mechanism, while RFC 791 states that there is no mechanism for flow control. When I rethink the discussion about congestion control during the recent past, I today considered, whether it could make sense to allow for a flow control mechanism along L 2 again. That's a risky thought, but I dare think it ;-) -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From Jon.Crowcroft at cl.cam.ac.uk Sat Apr 13 04:29:09 2013 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Sat, 13 Apr 2013 12:29:09 +0100 Subject: [e2e] Internet "architecture" In-Reply-To: References: <516786AE.5020009@dcrocker.net> <8C48B86A895913448548E6D15DA7553B80B149@xmb-rcd-x09.cisco.com> Message-ID: so the dogma here was that the business of manageing the net was just another distributed system (see the Cambridge Distributed System) wherre name services, router services, security services were implemented in exactly the same way as any other distributred system (file systems, transaction services, distributed computation tools)... but the control plane model of the net arrived in internet-land some time back - for example simon crosby took ideas (this was around the time when everyone was trying to do IP over ATM, which morphed into mpls) from "switchlet" territory with remote computation as controlplanestechnology...other people, e.g. ipsilon, also took the seperation of concerns that are forwarding packets as fast as you can, from working out where they should and shouldn't go and put them on different boxes, originally to be coordinated via the Generic Switch Management Protocol later re-discoverd as Software Definted Networkign and Openflow... plus ca change... In missive , John Day typed: >>The whole distinction of data plane and control plane arises with >>ISDN. It is a CCITT concept and was never used to describe anything >>Internet related, either in the US or Europe. Such distinctions only >>make sense in the beads-on-a-string models of the ITU. Routing, >>ICMP, DHCP, etc. type functions were characterized as layer >>management, which can exist to greater or lesser degree in all layers >>and must be within the layer owing to the different scopes of the >>layers. >> >>Take care, >>John Day >> >>> >>>the post-hoc rationalisation phrase is way too glib....certainly not >>>intended to be rude to people that created this cool stuff we all >>>use - in fact i was conflating three things >>> >>>1. a bunch of work fairly recently on optimal protocols and narrow >>>waist of the hour glass... >>>2. the ordering of constrints on the design of the internet >>>protocols (as per dave clarks 88 paper) >>>and >>>3. the apparent simplicity of IP - my missing point was that the >>>complexity pops out somewhere, and that place is in the control >>>plane....as we've since disovered... >>> >>>of course, there were people that ran dynamic distributed routing >>>for VC networks (X.25 for example - we had switches in the JANET >>>network that did this) so they were even more complex in both data >>>and control plane (what with crankback etc etc:) >>> >>>so yes, a bit glib really...sorry >>> >>>normal service will be resumed as soon as I get my IPTV QoS back :) >>> >>>j. >>> >>> >>>On Fri, Apr 12, 2013 at 3:07 PM, Fred Baker (fred) >>><fred at cisco.com> wrote: >>> >>>I'd suggest running the assertion by Vint. I made a similar >>>assertion in a document not too long ago, which I ran by him for >>>comment, and he told me I was flatly wrong. Yes, the circuit switch >>>folks were using the term "catenet" to refer to networks that >>>interoperated through translation, such as frame relay/ATM >>>interoperation, he asserted, but at least some (he?) was using the >>>term "Internet" as early as the mid 1970's. >>> >>> >>>On Apr 11, 2013, at 8:59 PM, Dave Crocker >>><dhc2 at dcrocker.net> wrote: >>> >>>> This is a risky query. There have been previous threads about >>>>such things as the "start" of the Internet. Instead, I want to ask >>>>about the "architecture" of the Internet. >>>> >>>> Here's a comment that I sent earlier today, to a non-technical >>>>person who is aware of the overall Internet timeline, but I believe >>>>does not understand what is distinctive about Internet >>>>'architecture'. I'm curious about reactions on this list, and any >>>>possible improvements -- including complete replacement -- but more >>>>importantly I'm interested in filling in the details: >>> > >>>> The original use of the term Internet was to describe a >>>>distinctive technical design for a distributed, scalable data >>>>exchange fabric. Its design characteristics differ dramatically >>>>from those of its predecessor, the Arpanet, and from other related >>>>efforts. >>>> >>>> That's what I sent. To prime the pump for the detail: >>>> >>>> By saying 'fabric' I meant to distinguish the mechanism for >>>>moving raw data from the applications that used it. What I'd class >>>>as distinctive were the TCP/IP separation, the remarkably modest >>>>functionality of IP, even to the point of moving it's control plane >>>>to the next level up with ICMP, and continuing with modest >>>>expectations the layer below (which made it possible to operate >>>>over any medium including birds.) This is usually characterized as >>>>moving robustness to the edges. >>>> >>>> >>>> Thoughts? >>>> >>>> d/ >>>> >>>> -- >>>> Dave Crocker >>>> Brandenburg InternetWorking >>>> bbiw.net >> >>--============_-846339397==_ma============ >>Content-Type: text/html; charset="us-ascii" >> >> >>Re: [e2e] Internet >>"architecture" >>
This is a can of worms, but. . .
>>

>>
At 4:23 PM +0200 4/12/13, Jon Crowcroft wrote:
>>
the folks who called it catenet included >>bob braden who was working at UCL when i was there - of course, we >>were concatenating networks that ran other protocols (Cambridge Ring, >>X.25 (transport layer relays) and so on...so perhaps I'm conflating >>two things - the interconnection of multiple disprate protocol >>systems, and the IP interconenction of multiple IP networks with >>disparete layer 2 and below....
>>

>>
Early on the term catenet was applied without respect to >>connection or connectionless, but only with respect to forwarding vs. >>translation (if necessary).
>>

>>

>>
it is the case (as some other folks >>privately pointed out to me) that IENs (including IEN 1 written at >>UCL) are Internet Experiment Notes, and go back to mid 1970s, so i'm >>wrong to say "internet"
>>

>>
however, my point about parsimony is >>really over compressed - IP trades off simplicity in the data plane, >>for complexity in the control plane - its not a pure trade off (it can >>be seen partly as a win-win, as signaling protocols for VC networks >>can be nearly as complex (or in X.25 and B-ISDN's Q.2931's cases, more >>complex) as routing protocols....nevertheless, getting routing right >>and all associated components is seriously non-trivial - other systems >>(the aforesaid cambridge ring protocol stack) represent a different >>trade off that is also quite elegant.
>>

>>
The whole distinction of data plane and control plane arises with >>ISDN. It is a CCITT concept and was never used to describe anything >>Internet related, either in the US or Europe. Such distinctions only >>make sense in the beads-on-a-string models of the ITU.  Routing, >>ICMP, DHCP, etc. type functions were characterized as layer >>management, which can exist to greater or lesser degree in all layers >>and must be within the layer owing to the different scopes of the >>layers.
>>

>>
Take care,
>>
John Day
>>

>>

>>
the post-hoc rationalisation phrase is >>way too glib....certainly not intended to be rude to people that >>created this cool stuff we all use - in fact i was conflating three >>things
>>

>>
1. a bunch of work fairly recently on >>optimal protocols and narrow waist of the hour glass...
>>
2. the ordering of constrints on the >>design of the internet protocols (as per dave clarks 88 >>paper)
>>
and
>>
3. the apparent simplicity of IP - my >>missing point was that the complexity pops out somewhere, and that >>place is in the control plane....as we've since >>disovered...
>>

>>
of course, there were people that ran >>dynamic distributed routing for VC networks (X.25 for example - we had >>switches in the JANET network that did this) so they were even more >>complex in both data and control plane (what with crankback etc >>etc:)
>>

>>
so yes, a bit glib >>really...sorry
>>

>>
normal service will be resumed as soon as >>I get my IPTV QoS back :)
>>

>>
j.
>>

>>
>>
>>
On Fri, Apr 12, 2013 at 3:07 PM, Fred >>Baker (fred) <fred at cisco.com> >>wrote:
>>
I'd suggest running the assertion by Vint. I made a >>similar assertion in a document not too long ago, which I ran by him >>for comment, and he told me I was flatly wrong. Yes, the circuit >>switch folks were using the term "catenet" to refer to >>networks that interoperated through translation, such as frame >>relay/ATM interoperation, he asserted, but at least some (he?) was >>using the term "Internet" as early as the mid 1970's.
>>
>>

>>On Apr 11, 2013, at 8:59 PM, Dave Crocker <>href="mailto:dhc2 at dcrocker.net">dhc2 at dcrocker.net> wrote:
>>
>>> This is a risky query.  There have been previous threads >>about such things as the "start" of the Internet. >> Instead, I want to ask about the "architecture" of the >>Internet.
>>>
>>> Here's a comment that I sent earlier today, to a non-technical >>person who is aware of the overall Internet timeline, but I believe >>does not understand what is distinctive about Internet 'architecture'. >> I'm curious about reactions on this list, and any possible >>improvements -- including complete replacement -- but more importantly >>I'm interested in filling in the details:
>>
>
>>>     The original use of the term Internet was >>to describe a distinctive technical design for a distributed, scalable >>data exchange fabric.  Its design characteristics differ >>dramatically from those of its predecessor, the Arpanet, and from >>other related efforts.
>>>
>>> That's what I sent.  To prime the pump for the detail:
>>>
>>>     By saying 'fabric' I meant to distinguish >>the mechanism for moving raw data from the applications that used it. >> What I'd class as distinctive were the TCP/IP separation, the >>remarkably modest functionality of IP, even to the point of moving >>it's control plane to the next level up with ICMP, and continuing with >>modest expectations the layer below (which made it possible to operate >>over any medium including birds.)  This is usually characterized >>as moving robustness to the edges.
>>>
>>>
>>> Thoughts?
>>>
>>> d/
>>>
>>> --
>>> Dave Crocker
>>> Brandenburg InternetWorking
>>> bbiw.net
>>
>>

>> >> >>--============_-846339397==_ma============-- cheers jon From Jon.Crowcroft at cl.cam.ac.uk Sat Apr 13 12:25:55 2013 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Sat, 13 Apr 2013 20:25:55 +0100 Subject: [e2e] Internet "architecture" In-Reply-To: References: <516786AE.5020009@dcrocker.net> <8C48B86A895913448548E6D15DA7553B80B149@xmb-rcd-x09.cisco.com> Message-ID: well i've seen scott shenker do his SDN vision talk a couple of times, and I know nick mckeown's work pretty well, and I do not think they are bell heads one point is that computer science has grown up slightly since 40+ years ago, so we are capabile of building way more flexible safe, secure and performant systems that in the past, when the design constraints on protocol stacks were set by 1960s ideas of s/w... so the stuff out of berkeley, stanford, princeton, gatech etc in this space is not constrained by the old rules it is deconstrained by new capabilities... [slightly stolen from John Doyle's cool idea of de-constraining constraints] so the realpolitik of openflow is (as it was with GSMP) to get arms length from the legacy router biz, and move the functionality somwhere where we can do disruptive innovation but that is another chapter... In missive , John Day typed: >>Jon. >> >>Yes, precisely. The first place it shows up is in ISDN, then Frame >>Relay, ATM, and MPLS. All those CCITT-like connection oriented >>solutions. And you undoubtedly are correct, it was brought into the >>Internet by the Europeans where the new model was largely ignored >>after the suppression of CYCLADES and the completion other early work >>such as the Cambridge DS. (As near as I can tell the vast majority >>of European universities never strayed too far from the traditional >>ITU model during the 70s to 90s. In fact most of the research still >>bears a strong mark of it with an Internet veneer.) >> >>Yes, it did arrive sometime back and has been a constant source of >>humor since the ATM lunacy. In fact, this is what makes it so >>wonderful that OpenFlow and SDN have embraced the ITU world view so >>completely. The Internet becomes about as anti-Internet as it can >>get. The Bell-heads have taken over. You have to admit it is pretty >>amusing. >> >>Take care, >>John >> >> >>At 12:29 PM +0100 4/13/13, Jon Crowcroft wrote: >>>so the dogma here was that the business of manageing the net was just >>>another distributed system (see the Cambridge Distributed System) >>>wherre name services, router services, security services were >>>implemented in exactly the same way as any other distributred system >>>(file systems, transaction services, distributed computation tools)... >>> >>>but the control plane model of the net arrived in internet-land some >>>time back - for example simon crosby took ideas (this was around the >>>time when everyone was trying to do IP over ATM, which morphed into >>>mpls) from "switchlet" territory with remote computation as >>>controlplanestechnology...other people, e.g. ipsilon, also took the >>>seperation of concerns that are >>>forwarding packets as fast as you can, >>>from >>>working out where they should and shouldn't go >>>and put them on different boxes, originally to be coordinated via the >>>Generic Switch Management Protocol >>>later re-discoverd as Software Definted Networkign and Openflow... >>> >>>plus ca change... >>>In missive , John Day typed: >>> >>> >>The whole distinction of data plane and control plane arises with >>> >>ISDN. It is a CCITT concept and was never used to describe anything >>> >>Internet related, either in the US or Europe. Such distinctions only >>> >>make sense in the beads-on-a-string models of the ITU. Routing, >>> >>ICMP, DHCP, etc. type functions were characterized as layer >>> >>management, which can exist to greater or lesser degree in all layers >>> >>and must be within the layer owing to the different scopes of the >>> >>layers. >>> >> >>> >>Take care, >>> >>John Day >>> >> >>> >>> >>> >>>the post-hoc rationalisation phrase is way too glib....certainly not >>> >>>intended to be rude to people that created this cool stuff we all >>> >>>use - in fact i was conflating three things >>> >>> >>> >>>1. a bunch of work fairly recently on optimal protocols and narrow >>> >>>waist of the hour glass... >>> >>>2. the ordering of constrints on the design of the internet >>> >>>protocols (as per dave clarks 88 paper) >>> >>>and >>> >>>3. the apparent simplicity of IP - my missing point was that the >>> >>>complexity pops out somewhere, and that place is in the control >>> >>>plane....as we've since disovered... >>> >>> >>> >>>of course, there were people that ran dynamic distributed routing >>> >>>for VC networks (X.25 for example - we had switches in the JANET >>> >>>network that did this) so they were even more complex in both data >>> >>>and control plane (what with crankback etc etc:) >>> >>> >>> >>>so yes, a bit glib really...sorry >>> >>> >>> >>>normal service will be resumed as soon as I get my IPTV QoS back :) >>> >>> >>> >>>j. >>> >>> >>> >>> >>> >>>On Fri, Apr 12, 2013 at 3:07 PM, Fred Baker (fred) >>> >>><fred at cisco.com> wrote: >>> >>> >>> >>>I'd suggest running the assertion by Vint. I made a similar >>> >>>assertion in a document not too long ago, which I ran by him for >>> >>>comment, and he told me I was flatly wrong. Yes, the circuit switch >>> >>>folks were using the term "catenet" to refer to networks that >>> >>>interoperated through translation, such as frame relay/ATM >>> >>>interoperation, he asserted, but at least some (he?) was using the >>> >>>term "Internet" as early as the mid 1970's. >>> >>> >>> >>> >>> >>>On Apr 11, 2013, at 8:59 PM, Dave Crocker >>> >>><dhc2 at dcrocker.net> wrote: >>> >>> >>> >>>> This is a risky query. There have been previous threads about >>> >>>>such things as the "start" of the Internet. Instead, I want to ask >>> >>>>about the "architecture" of the Internet. >>> >>>> >>> >>>> Here's a comment that I sent earlier today, to a non-technical >>> >>>>person who is aware of the overall Internet timeline, but I believe >>> >>>>does not understand what is distinctive about Internet >>> >>>>'architecture'. I'm curious about reactions on this list, and any >>> >>>>possible improvements -- including complete replacement -- but more >>> >>>>importantly I'm interested in filling in the details: >>> >>> > >>> >>>> The original use of the term Internet was to describe a >>> >>>>distinctive technical design for a distributed, scalable data >>> >>>>exchange fabric. Its design characteristics differ dramatically >>> >>>>from those of its predecessor, the Arpanet, and from other related >>> >>>>efforts. >>> >>>> >>> >>>> That's what I sent. To prime the pump for the detail: >>> >>>> >>> >>>> By saying 'fabric' I meant to distinguish the mechanism for >>> >>>>moving raw data from the applications that used it. What I'd class >>> >>>>as distinctive were the TCP/IP separation, the remarkably modest >>> >>>>functionality of IP, even to the point of moving it's control plane >>> >>>>to the next level up with ICMP, and continuing with modest >>> >>>>expectations the layer below (which made it possible to operate >>> >>>>over any medium including birds.) This is usually characterized as >>> >>>>moving robustness to the edges. >>> >>>> >>> >>>> >>> >>>> Thoughts? >>> >>>> >>> >>>> d/ >>> >>>> >>> >>>> -- >>> >>>> Dave Crocker >>> >>>> Brandenburg InternetWorking >>> >>>> bbiw.net >>> >> >>> >>--============_-846339397==_ma============ >>> >>Content-Type: text/html; charset="us-ascii" >>> >> >>> >> >>> >>Re: [e2e] Internet >>> >>"architecture" >>> >>
This is a can of worms, but. . .
>>> >>

>>> >>
At 4:23 PM +0200 4/12/13, Jon Crowcroft wrote:
>>> >>
the folks who called it catenet included >>> >>bob braden who was working at UCL when i was there - of course, we >>> >>were concatenating networks that ran other protocols (Cambridge Ring, >>> >>X.25 (transport layer relays) and so on...so perhaps I'm conflating >>> >>two things - the interconnection of multiple disprate protocol >>> >>systems, and the IP interconenction of multiple IP networks with >>> >>disparete layer 2 and below....
>>> >>

>>> >>
Early on the term catenet was applied without respect to >>> >>connection or connectionless, but only with respect to forwarding vs. >>> >>translation (if necessary).
>>> >>

>>> >>

>>> >>
it is the case (as some other folks >>> >>privately pointed out to me) that IENs (including IEN 1 written at >>> >>UCL) are Internet Experiment Notes, and go back to mid 1970s, so i'm >>> >>wrong to say "internet"
>>> >>

>>> >>
however, my point about parsimony is >>> >>really over compressed - IP trades off simplicity in the data plane, >>> >>for complexity in the control plane - its not a pure trade off (it can >>> >>be seen partly as a win-win, as signaling protocols for VC networks >>> >>can be nearly as complex (or in X.25 and B-ISDN's Q.2931's cases, more >>> >>complex) as routing protocols....nevertheless, getting routing right >>> >>and all associated components is seriously non-trivial - other systems >>> >>(the aforesaid cambridge ring protocol stack) represent a different >>> >>trade off that is also quite elegant.
>>> >>

>>> >>
The whole distinction of data plane and control plane arises with >>> >>ISDN. It is a CCITT concept and was never used to describe anything >>> >>Internet related, either in the US or Europe. Such distinctions only >>> >>make sense in the beads-on-a-string models of the ITU.  Routing, >>> >>ICMP, DHCP, etc. type functions were characterized as layer >>> >>management, which can exist to greater or lesser degree in all layers >>> >>and must be within the layer owing to the different scopes of the >>> >>layers.
>>> >>

>>> >>
Take care,
>>> >>
John Day
>>> >>

>>> >>

>>> >>
the post-hoc rationalisation phrase is >>> >>way too glib....certainly not intended to be rude to people that >>> >>created this cool stuff we all use - in fact i was conflating three >>> >>things
>>> >>

>>> >>
1. a bunch of work fairly recently on >>> >>optimal protocols and narrow waist of the hour glass...
>>> >>
2. the ordering of constrints on the >>> >>design of the internet protocols (as per dave clarks 88 >>> >>paper)
>>> >>
and
>>> >>
3. the apparent simplicity of IP - my >>> >>missing point was that the complexity pops out somewhere, and that >>> >>place is in the control plane....as we've since >>> >>disovered...
>>> >>

>>> >>
of course, there were people that ran >>> >>dynamic distributed routing for VC networks (X.25 for example - we had >>> >>switches in the JANET network that did this) so they were even more >>> >>complex in both data and control plane (what with crankback etc >>> >>etc:)
>>> >>

>>> >>
so yes, a bit glib >>> >>really...sorry
>>> >>

>>> >>
normal service will be resumed as soon as >>> >>I get my IPTV QoS back :)
>>> >>

>>> >>
j.
>>> >>

>>> >>
>>> >>
>>> >>
On Fri, Apr 12, 2013 at 3:07 PM, Fred >>> >>Baker (fred) <fred at cisco.com> >>> >>wrote:
>>> >>
I'd suggest running the assertion by Vint. I made a >>> >>similar assertion in a document not too long ago, which I ran by him >>> >>for comment, and he told me I was flatly wrong. Yes, the circuit >>> >>switch folks were using the term "catenet" to refer to >>> >>networks that interoperated through translation, such as frame >>> >>relay/ATM interoperation, he asserted, but at least some (he?) was >>> >>using the term "Internet" as early as the mid 1970's.
>>> >>
>>> >>

>>> >>On Apr 11, 2013, at 8:59 PM, Dave Crocker <>> >>href="mailto:dhc2 at dcrocker.net">dhc2 at dcrocker.net> wrote:
>>> >>
>>> >>> This is a risky query.  There have been previous threads >>> >>about such things as the "start" of the Internet. >>> >> Instead, I want to ask about the "architecture" of the >>> >>Internet.
>>> >>>
>>> >>> Here's a comment that I sent earlier today, to a non-technical >>> >>person who is aware of the overall Internet timeline, but I believe >>> >>does not understand what is distinctive about Internet 'architecture'. >>> >> I'm curious about reactions on this list, and any possible >>> >>improvements -- including complete replacement -- but more importantly >>> >>I'm interested in filling in the details:
>>> >>
>
>>> >>>     The original use of the term Internet was >>> >>to describe a distinctive technical design for a distributed, scalable >>> >>data exchange fabric.  Its design characteristics differ >>> >>dramatically from those of its predecessor, the Arpanet, and from >>> >>other related efforts.
>>> >>>
>>> >>> That's what I sent.  To prime the pump for the detail:
>>> >>>
>>> >>>     By saying 'fabric' I meant to distinguish >>> >>the mechanism for moving raw data from the applications that used it. >>> >> What I'd class as distinctive were the TCP/IP separation, the >>> >>remarkably modest functionality of IP, even to the point of moving >>> >>it's control plane to the next level up with ICMP, and continuing with >>> >>modest expectations the layer below (which made it possible to operate >>> >>over any medium including birds.)  This is usually characterized >>> >>as moving robustness to the edges.
>>> >>>
>>> >>>
>>> >>> Thoughts?
>>> >>>
>>> >>> d/
>>> >>>
>>> >>> --
>>> >>> Dave Crocker
>>> >>> Brandenburg InternetWorking
>>> >>> bbiw.net
>>> >>
>>> >>

>>> >> >>> >> >>> >>--============_-846339397==_ma============-- >>> >>> cheers >>> >>> jon >> cheers jon From dhc2 at dcrocker.net Sat Apr 13 14:04:46 2013 From: dhc2 at dcrocker.net (Dave Crocker) Date: Sat, 13 Apr 2013 14:04:46 -0700 Subject: [e2e] Internet "architecture" In-Reply-To: References: <516786AE.5020009@dcrocker.net> <8C48B86A895913448548E6D15DA7553B80B149@xmb-rcd-x09.cisco.com> Message-ID: <5169C86E.7050208@dcrocker.net> On 4/13/2013 12:25 PM, Jon Crowcroft wrote: > one point is that computer science has grown up slightly since 40+ > years ago, so we are capabile of building way more flexible safe, > secure and performant systems that in the past, Hmmm... Are we? Safe and secure? I mean, I know we /think/ we are, and that we have lots of ways to defend the view that we are, but I'm not sure I know what constitutes an actual existence proof of it, that operates in scale... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From jon.crowcroft at cl.cam.ac.uk Sun Apr 14 03:04:48 2013 From: jon.crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Sun, 14 Apr 2013 11:04:48 +0100 Subject: [e2e] Internet "architecture" In-Reply-To: References: <516786AE.5020009@dcrocker.net> <8C48B86A895913448548E6D15DA7553B80B149@xmb-rcd-x09.cisco.com> Message-ID: I think you can look at it a different way - SDN lets you move even more smarts out of the network into end systems - as far as we implement it, that looks even less like the ITU than the current ancient-route-computation/firewall/middlebox ridden IPv4 ossification of today so i can see that you could cast SDN in the Wicked Witch of the ITU role, but equally, I think of it as not being in Kansas anymore.... cheers jon On Sat, Apr 13, 2013 at 10:39 PM, John Day wrote: > Yea, I have seen their stuff too, pretty amusing. about as disruptive as a > speed bump. ;-) > > Actually you have it backwards, we *are* using the reactionary designs of > 40 years ago and that is what is holding things back, rather than the > forward looking designs that were being pursued. > > Those weren't the answer, but it was on the way to the answer, that is > clear now and they would have found it if they had been able to keep going. > > Things become much simpler once you are out of the ITU model that SDN and > Open Flow are locked into. > > Have fun, > John > > > > At 8:25 PM +0100 4/13/13, Jon Crowcroft wrote: > >> well i've seen scott shenker do his SDN vision talk a couple of times, >> and I know nick mckeown's work pretty well, and I do not think they >> are bell heads >> >> one point is that computer science has grown up slightly since 40+ >> years ago, so we are capabile of building way more flexible safe, >> secure and performant systems that in the past, when the design >> constraints on protocol stacks were set by 1960s ideas of s/w... >> >> so the stuff out of berkeley, stanford, princeton, gatech etc >> in this space is not constrained by the old rules >> >> it is deconstrained by new capabilities... >> >> [slightly stolen from John Doyle's cool idea of de-constraining >> constraints] >> >> >> so the realpolitik of openflow is (as it was with GSMP) to get arms >> length from the legacy router biz, and move the functionality somwhere >> where we can do disruptive innovation >> >> but that is another chapter... >> >> In missive , John Day typed: >> >> >>Jon. >> >> >> >>Yes, precisely. The first place it shows up is in ISDN, then Frame >> >>Relay, ATM, and MPLS. All those CCITT-like connection oriented >> >>solutions. And you undoubtedly are correct, it was brought into the >> >>Internet by the Europeans where the new model was largely ignored >> >>after the suppression of CYCLADES and the completion other early work >> >>such as the Cambridge DS. (As near as I can tell the vast majority >> >>of European universities never strayed too far from the traditional >> >>ITU model during the 70s to 90s. In fact most of the research still >> >>bears a strong mark of it with an Internet veneer.) >> >> >> >>Yes, it did arrive sometime back and has been a constant source of >> >>humor since the ATM lunacy. In fact, this is what makes it so >> >>wonderful that OpenFlow and SDN have embraced the ITU world view so >> >>completely. The Internet becomes about as anti-Internet as it can >> >>get. The Bell-heads have taken over. You have to admit it is pretty >> >>amusing. >> >> >> >>Take care, >> >>John >> >> >> >> >> >>At 12:29 PM +0100 4/13/13, Jon Crowcroft wrote: >> >>>so the dogma here was that the business of manageing the net was just >> >>>another distributed system (see the Cambridge Distributed System) >> >>>wherre name services, router services, security services were >> >>>implemented in exactly the same way as any other distributred system >> >>>(file systems, transaction services, distributed computation tools)... >> >>> >> >>>but the control plane model of the net arrived in internet-land some >> >>>time back - for example simon crosby took ideas (this was around the >> >>>time when everyone was trying to do IP over ATM, which morphed into >> >>>mpls) from "switchlet" territory with remote computation as >> >>>controlplanestechnology...**other people, e.g. ipsilon, also took the >> >>>seperation of concerns that are >> >>>forwarding packets as fast as you can, >> >>>from >> >>>working out where they should and shouldn't go >> >>>and put them on different boxes, originally to be coordinated via the >> >>>Generic Switch Management Protocol >> >>>later re-discoverd as Software Definted Networkign and Openflow... >> >>> >> >>>plus ca change... >> >>>In missive , John Day typed: >> >>> >> >>> >>The whole distinction of data plane and control plane arises with >> >>> >>ISDN. It is a CCITT concept and was never used to describe >> anything >> >>> >>Internet related, either in the US or Europe. Such distinctions >> only >> >>> >>make sense in the beads-on-a-string models of the ITU. Routing, >> >>> >>ICMP, DHCP, etc. type functions were characterized as layer >> >>> >>management, which can exist to greater or lesser degree in all >> layers >> >>> >>and must be within the layer owing to the different scopes of the >> >>> >>layers. >> >>> >> >> >>> >>Take care, >> >>> >>John Day >> >>> >> >> >>> >>> >> >>> >>>the post-hoc rationalisation phrase is way too glib....certainly >> not >> >>> >>>intended to be rude to people that created this cool stuff we all >> >>> >>>use - in fact i was conflating three things >> >>> >>> >> >>> >>>1. a bunch of work fairly recently on optimal protocols and >> narrow >> >>> >>>waist of the hour glass... >> >>> >>>2. the ordering of constrints on the design of the internet >> >>> >>>protocols (as per dave clarks 88 paper) >> >>> >>>and >> >>> >>>3. the apparent simplicity of IP - my missing point was that the >> >>> >>>complexity pops out somewhere, and that place is in the control >> >>> >>>plane....as we've since disovered... >> >>> >>> >> >>> >>>of course, there were people that ran dynamic distributed routing >> >>> >>>for VC networks (X.25 for example - we had switches in the JANET >> >>> >>>network that did this) so they were even more complex in both >> data >> >>> >>>and control plane (what with crankback etc etc:) >> >>> >>> >> >>> >>>so yes, a bit glib really...sorry >> >>> >>> >> >>> >>>normal service will be resumed as soon as I get my IPTV QoS back >> :) >> >>> >>> >> >>> >>>j. >> >>> >>> >> >>> >>> >> >>> >>>On Fri, Apr 12, 2013 at 3:07 PM, Fred Baker (fred) >> >>> >>><fre**d at cisco.com > >> wrote: >> >>> >>> >> >>> >>>I'd suggest running the assertion by Vint. I made a similar >> >>> >>>assertion in a document not too long ago, which I ran by him for >> >>> >>>comment, and he told me I was flatly wrong. Yes, the circuit >> switch >> >>> >>>folks were using the term "catenet" to refer to networks that >> >>> >>>interoperated through translation, such as frame relay/ATM >> >>> >>>interoperation, he asserted, but at least some (he?) was using >> the >> >>> >>>term "Internet" as early as the mid 1970's. >> >>> >>> >> >>> >>> >> >>> >>>On Apr 11, 2013, at 8:59 PM, Dave Crocker >> >>> >>><**dhc2 at dcrocker.net> >> wrote: >> >>> >>> >> >>> >>>> This is a risky query. There have been previous threads about >> >>> >>>>such things as the "start" of the Internet. Instead, I want to >> ask >> >>> >>>>about the "architecture" of the Internet. >> >>> >>>> >> >>> >>>> Here's a comment that I sent earlier today, to a non-technical >> >>> >>>>person who is aware of the overall Internet timeline, but I >> believe >> >>> >>>>does not understand what is distinctive about Internet >> >>> >>>>'architecture'. I'm curious about reactions on this list, and >> any >> >>> >>>>possible improvements -- including complete replacement -- but >> more >> >>> >>>>importantly I'm interested in filling in the details: >> >>> >>> > >> >>> >>>> The original use of the term Internet was to describe a >> >>> >>>>distinctive technical design for a distributed, scalable data >> >>> >>>>exchange fabric. Its design characteristics differ dramatically >> >>> >>>>from those of its predecessor, the Arpanet, and from other >> related >> >>> >>>>efforts. >> >>> >>>> >> >>> >>>> That's what I sent. To prime the pump for the detail: >> >>> >>>> >> >>> >>>> By saying 'fabric' I meant to distinguish the mechanism >> for >> >>> >>>>moving raw data from the applications that used it. What I'd >> class >> >>> >>>>as distinctive were the TCP/IP separation, the remarkably modest >> >>> >>>>functionality of IP, even to the point of moving it's control >> plane >> >>> >>>>to the next level up with ICMP, and continuing with modest >> >>> >>>>expectations the layer below (which made it possible to operate >> >>> >>>>over any medium including birds.) This is usually >> characterized as >> >>> >>>>moving robustness to the edges. >> >>> >>>> >> >>> >>>> >> >>> >>>> Thoughts? >> >>> >>>> >> >>> >>>> d/ >> >>> >>>> >> >>> >>>> -- >> >>> >>>> Dave Crocker >> >>> >>>> Brandenburg InternetWorking >> >>> >>>> bbiw.net >> >>> >> >> >>> >>--============_-846339397==_**ma============ >> >>> >>Content-Type: text/html; charset="us-ascii" >> >>> >> >> >>> >> >> >>> >>Re: [e2e] Internet >> >>> >>"architecture"</**title></head><body> >> >>> >><div>This is a can of worms, but. . .</div> >> >>> >><div><br></div> >> >>> >><div>At 4:23 PM +0200 4/12/13, Jon Crowcroft wrote:</div> >> >>> >><blockquote type="cite" cite>the folks who called it catenet >> included >> >>> >>bob braden who was working at UCL when i was there - of course, we >> >>> >>were concatenating networks that ran other protocols (Cambridge >> Ring, >> >>> >>X.25 (transport layer relays) and so on...so perhaps I'm >> conflating >> >>> >>two things - the interconnection of multiple disprate protocol >> >>> >>systems, and the IP interconenction of multiple IP networks with >> >>> >>disparete layer 2 and below....</blockquote> >> >>> >><div><br></div> >> >>> >><div>Early on the term catenet was applied without respect to >> >>> >>connection or connectionless, but only with respect to forwarding >> vs. >> >>> >>translation (if necessary).</div> >> >>> >><div><br></div> >> >>> >><blockquote type="cite" cite><br></blockquote> >> >>> >><blockquote type="cite" cite>it is the case (as some other folks >> >>> >>privately pointed out to me) that IENs (including IEN 1 written at >> >>> >>UCL) are Internet Experiment Notes, and go back to mid 1970s, so >> i'm >> >>> >>wrong to say "internet"</**blockquote> >> >>> >><blockquote type="cite" cite><br></blockquote> >> >>> >><blockquote type="cite" cite>however, my point about parsimony is >> >>> >>really over compressed - IP trades off simplicity in the data >> plane, >> >>> >>for complexity in the control plane - its not a pure trade off >> (it can >> >>> >>be seen partly as a win-win, as signaling protocols for VC >> networks >> >>> >>can be nearly as complex (or in X.25 and B-ISDN's Q.2931's cases, >> more >> >>> >>complex) as routing protocols....nevertheless, getting routing >> right >> >>> >>and all associated components is seriously non-trivial - other >> systems >> >>> >>(the aforesaid cambridge ring protocol stack) represent a >> different >> >>> >>trade off that is also quite elegant.</blockquote> >> >>> >><div><br></div> >> >>> >><div>The whole distinction of data plane and control plane arises >> with >> >>> >>ISDN. It is a CCITT concept and was never used to describe >> anything >> >>> >>Internet related, either in the US or Europe. Such distinctions >> only >> >>> >>make sense in the beads-on-a-string models of the ITU.  >> Routing, >> >>> >>ICMP, DHCP, etc. type functions were characterized as layer >> >>> >>management, which can exist to greater or lesser degree in all >> layers >> >>> >>and must be within the layer owing to the different scopes of the >> >>> >>layers.</div> >> >>> >><div><br></div> >> >>> >><div>Take care,</div> >> >>> >><div>John Day</div> >> >>> >><div><br></div> >> >>> >><blockquote type="cite" cite><br></blockquote> >> >>> >><blockquote type="cite" cite>the post-hoc rationalisation phrase >> is >> >>> >>way too glib....certainly not intended to be rude to people that >> >>> >>created this cool stuff we all use - in fact i was conflating >> three >> >>> >>things</blockquote> >> >>> >><blockquote type="cite" cite><br></blockquote> >> >>> >><blockquote type="cite" cite>1. a bunch of work fairly recently on >> >>> >>optimal protocols and narrow waist of the hour >> glass...</blockquote> >> >>> >><blockquote type="cite" cite>2. the ordering of constrints on the >> >>> >>design of the internet protocols (as per dave clarks 88 >> >>> >>paper)</blockquote> >> >>> >><blockquote type="cite" cite>and</blockquote> >> >>> >><blockquote type="cite" cite>3. the apparent simplicity of IP - my >> >>> >>missing point was that the complexity pops out somewhere, and that >> >>> >>place is in the control plane....as we've since >> >>> >>disovered...</blockquote> >> >>> >><blockquote type="cite" cite><br></blockquote> >> >>> >><blockquote type="cite" cite>of course, there were people that ran >> >>> >>dynamic distributed routing for VC networks (X.25 for example - >> we had >> >>> >>switches in the JANET network that did this) so they were even >> more >> >>> >>complex in both data and control plane (what with crankback etc >> >>> >>etc:)</blockquote> >> >>> >><blockquote type="cite" cite><br></blockquote> >> >>> >><blockquote type="cite" cite>so yes, a bit glib >> >>> >>really...sorry</blockquote> >> >>> >><blockquote type="cite" cite><br></blockquote> >> >>> >><blockquote type="cite" cite>normal service will be resumed as >> soon as >> >>> >>I get my IPTV QoS back :)</blockquote> >> >>> >><blockquote type="cite" cite><br></blockquote> >> >>> >><blockquote type="cite" cite>j.</blockquote> >> >>> >><blockquote type="cite" cite><br> >> >>> >><br> >> >>> >></blockquote> >> >>> >><blockquote type="cite" cite>On Fri, Apr 12, 2013 at 3:07 PM, Fred >> >>> >>Baker (fred) <<a href="mailto:fred at cisco.com">f**red at cisco.com<fred at cisco.com> >> </a>> >> >>> >>wrote:<br> >> >>> >><blockquote>I'd suggest running the assertion by Vint. I made a >> >>> >>similar assertion in a document not too long ago, which I ran by >> him >> >>> >>for comment, and he told me I was flatly wrong. Yes, the circuit >> >>> >>switch folks were using the term "catenet" to refer to >> >>> >>networks that interoperated through translation, such as frame >> >>> >>relay/ATM interoperation, he asserted, but at least some (he?) was >> >>> >>using the term "Internet" as early as the mid >> 1970's.<br> >> >>> >></blockquote> >> >>> >><blockquote><br> >> >>> >>On Apr 11, 2013, at 8:59 PM, Dave Crocker <<a >> >>> >>href="mailto:dhc2 at dcrocker.**net <dhc2 at dcrocker.net>"> >> dhc2 at dcrocker.net</a>> wrote:<br> >> >>> >><br> >> >>> >>> This is a risky query.  There have been previous threads >> >>> >>about such things as the "start" of the Internet. >> >>> >> Instead, I want to ask about the "architecture" >> of the >> >>> >>Internet.<br> >> >>> >>><br> >> >>> >>> Here's a comment that I sent earlier today, to a >> non-technical >> >>> >>person who is aware of the overall Internet timeline, but I >> believe >> >>> >>does not understand what is distinctive about Internet >> 'architecture'. >> >>> >> I'm curious about reactions on this list, and any possible >> >>> >>improvements -- including complete replacement -- but more >> importantly >> >>> >>I'm interested in filling in the details:</blockquote> >> >>> >><blockquote>><br> >> >>> >>>     The original use of the term >> Internet was >> >>> >>to describe a distinctive technical design for a distributed, >> scalable >> >>> >>data exchange fabric.  Its design characteristics differ >> >>> >>dramatically from those of its predecessor, the Arpanet, and from >> >>> >>other related efforts.<br> >> >>> >>><br> >> >>> >>> That's what I sent.  To prime the pump for the >> detail:<br> >> >>> >>><br> >> >>> >>>     By saying 'fabric' I meant to >> distinguish >> >>> >>the mechanism for moving raw data from the applications that used >> it. >> >>> >> What I'd class as distinctive were the TCP/IP separation, >> the >> >>> >>remarkably modest functionality of IP, even to the point of moving >> >>> >>it's control plane to the next level up with ICMP, and continuing >> with >> >>> >>modest expectations the layer below (which made it possible to >> operate >> >>> >>over any medium including birds.)  This is usually >> characterized >> >>> >>as moving robustness to the edges.<br> >> >>> >>><br> >> >>> >>><br> >> >>> >>> Thoughts?<br> >> >>> >>><br> >> >>> >>> d/<br> >> >>> >>><br> >> >>> >>> --<br> >> >>> >>> Dave Crocker<br> >> >>> >>> Brandenburg InternetWorking<br> >> >>> >>> <a href="http://bbiw.net">bbiw.**net <http://bbiw.net> >> </a></blockquote> >> >>> >></blockquote> >> >>> >><div><br></div> >> >>> >></body> >> >>> >></html> >> >>> >>--============_-846339397==_**ma============-- >> >>> >> >>> cheers >> >>> >> >>> jon >> >> >> >> cheers >> >> jon >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20130414/4e4fee20/attachment-0001.html From jon.crowcroft at cl.cam.ac.uk Sun Apr 14 09:51:28 2013 From: jon.crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Sun, 14 Apr 2013 17:51:28 +0100 Subject: [e2e] Internet "architecture" In-Reply-To: <1365957620.324222272@apps.rackspace.com> References: <516786AE.5020009@dcrocker.net> <8C48B86A895913448548E6D15DA7553B80B149@xmb-rcd-x09.cisco.com> <CAEeTejJ347cmQ_q2MavczKFnfNVnExOJpHrVnAnNFe8fwG48RQ@mail.gmail.com> <a062408a1cd8ddf0a5bcd@10.0.1.3> <E1UQyds-0003y4-Oy@mta1.cl.cam.ac.uk> <a062408c2cd8f33d66244@10.0.1.3> <E1UR65D-0004ZU-Vr@mta0.cl.cam.ac.uk> <a062408c9cd8f7e25c93f@10.0.1.3> <CAEeTejL2EMMEi9e6d6UE-5y_dvWkKbJ1tPKTSg+uX4vVM-+2+w@mail.gmail.com> <1365957620.324222272@apps.rackspace.com> Message-ID: <CAEeTej+SfBpG9cEfVciVXAVozZxUH+Bu=4Fwzf_nFQ-Qcm_euw@mail.gmail.com> I'm not claiming CS can architect things better - I am claiming that people architecting things today should assimilatethe idea that we have differt CS tools at our disposal - this is quite a different.claim architecure remains as hard as ever, and as rare in any discipline (except maybe norman foster's :-) I totally agree that things could go either way - SDN (like active nets before it) could go horribly horribly wrong.... on the other hand, i suppose, it would then not get adopted much... On Sun, Apr 14, 2013 at 5:40 PM, <dpreed at reed.com> wrote: > Jon - I strongly disagree with your views that SDN *will* solve the > problem of simplifying network architecture and that computer scientists > today are capable of architecting systems much better than those 40 years > ago. I don't have a problem with SDN technology per se, but it changes very > little in regard to most aspects of quality network design and architecture. > > [usual disclaimer about my posts being blocked to the full e2e list, but I > invited to the conversation some people who might agree or disagree, > because I think it's an interesting question] > > > > As someone who has worked on SDN (with McKeown's own code, at HP Labs), I > think it can go either way - > > > > 1) do a better job of moving flexibility and function to the edges, or > > 2) create a vast nightmarish terrain of virtual middleboxes that do > unpredictable and random things to traffic packets. > > > > Having seen what the deployers of middleboxes get wrong, I'm not sure that > a virtualization platform for middleboxes will do to reduce the problems. > It's a sociopolitical problem, not a technical one. > > > > Inside a company, where the fabric is completely owned and operated by a > unified IT dept. (there is much evidence that IT dept's in large companies > are hardly unified, though), SDN's can be extremely helpful - precisely > because the network is virtualized by SDN. You can roll out changes in a > coordinated fashion, orchestrate resilience in the face of faults and > signficant load changes, etc. All that is quite doable, even while > preserving the essential separation between transport and heterogeneous > infrastructure. That separation is quite important to the long-term nature > of the systems that use any network. > > > > However, the mess that is evolving in IPv4 comes from poorly thought out > regulations (wiretapping and "firewall" mechanisms that try to operate at a > level where there is no end-point semantics, for example) and a struggle to > create business "control points" that can be monopolized. > > > > Merely emulating that mess (perfectly feasible with SDN) creates the > opportunity to ramify the process of chaotic evolution of the network. > > > > As far as your view that modern computer science and computer scientists > can now do what we couldn't do 40 years ago, I'm extraordinarily skeptical. > Modern computer scientists (the people) are much less capable of clean > architectural thinking on the average, and being faced with problems with a > vast increase in interactions among uncontrollable factors. > > > > This is why I continue to complain about network pedagogy that starts with > the idea that networks somehow live in a world of stationary random > processes that are all Gaussian, and that there is a "central limit > theorem" that therefore makes aggregation reduce complexity. I've even > heard someone say that there may be a little bit of "fractal" structure, > but that it is "drowned out" by Gaussian stationary traffic. Anyone who > understood the actual math would be appalled, but computer scientists > *pretend* to be mathematicians for the most part, applying cookbook > formulas and "gut instincts" that they got by solving simple textbook > exercises and watching lectures without questioning assumptions, and never > challenging their professors. > > > > 40 years ago, there was not so much teachiing of "things that we know that > 'taint so" as the phrase goes. So in that sense, today's computer > scientists have a herd instinct that never questions anything, and worse, > feels completely empowered to disregard those who don't agree with the > consensus, no matter how well they put the alternative forth. > > > > How else did we end up in a place where nearly every access network has > key links where "bufferbloat" can allow a single person to run an > application that builds up a blockage in either the downlink or the uplink, > creating latencies of 1-4 seconds when the nominal latency is on the order > of < 10 msec and the cross-country latency including all hops is around 30 > msec? Was this "expertise by computer scientists"? Hardly. It was vastly > ramified result of ignorance, not expertise. > > > > And worse, NO ONE in the community bothers to actually measure the real > Internet in any detail. That would make their publications in academic > journals be suspect, and eliminate the cozy world of conferences that seem > to be more like a mutual admiration society among an isolated elite. > > > > So I'm skeptical that there is this wonderful world of computer scientists > that have mastered anything. > > > > Some people in the community are pretty damn smart. Too few. Most are > mis-employed. > > > > So, in the case of SDN, I'm pretty sure that the mess will continue to get > worse due precisely to the ease with which SDN enables the blind deployment > of bad ideas, and does not enhance the ability to detect the effects of bad > ideas, measure their problems, and chuck the bad ideas. > > > > SDN becomes an accelerator of a network Gresham's Law, if that is the way > things go. > > > > Nonetheless, SDN is a really helpful concept, put in its place - > virtualization can be enormously helpful when it creates a simple > abstraction without "cross-layer optimization". > > > > And don't get me started on the academic fascination in computer science > with how "great" cross-layer optimizations are. Next we'll have thousands > of papers talking about the wonders of kludges and crocks in network > designs. > > > > > > On Sunday, April 14, 2013 6:04am, "Jon Crowcroft" < > jon.crowcroft at cl.cam.ac.uk> said: > > I think you can look at it a different way - SDN lets you move even more > smarts out of the network into end systems - as far as we implement it, > that looks even less like the ITU than the current > ancient-route-computation/firewall/middlebox ridden IPv4 ossification of > today > so i can see that you could cast SDN in the Wicked Witch of the ITU role, > but equally, I think of it as not being in Kansas anymore.... > cheers > jon > > > On Sat, Apr 13, 2013 at 10:39 PM, John Day <jeanjour at comcast.net> wrote: > >> Yea, I have seen their stuff too, pretty amusing. about as disruptive as >> a speed bump. ;-) >> >> Actually you have it backwards, we *are* using the reactionary designs of >> 40 years ago and that is what is holding things back, rather than the >> forward looking designs that were being pursued. >> >> Those weren't the answer, but it was on the way to the answer, that is >> clear now and they would have found it if they had been able to keep going. >> >> Things become much simpler once you are out of the ITU model that SDN and >> Open Flow are locked into. >> >> Have fun, >> John >> >> >> >> At 8:25 PM +0100 4/13/13, Jon Crowcroft wrote: >> >>> well i've seen scott shenker do his SDN vision talk a couple of times, >>> and I know nick mckeown's work pretty well, and I do not think they >>> are bell heads >>> >>> one point is that computer science has grown up slightly since 40+ >>> years ago, so we are capabile of building way more flexible safe, >>> secure and performant systems that in the past, when the design >>> constraints on protocol stacks were set by 1960s ideas of s/w... >>> >>> so the stuff out of berkeley, stanford, princeton, gatech etc >>> in this space is not constrained by the old rules >>> >>> it is deconstrained by new capabilities... >>> >>> [slightly stolen from John Doyle's cool idea of de-constraining >>> constraints] >>> >>> >>> so the realpolitik of openflow is (as it was with GSMP) to get arms >>> length from the legacy router biz, and move the functionality somwhere >>> where we can do disruptive innovation >>> >>> but that is another chapter... >>> >>> In missive <a062408c2cd8f33d66244@[10.0. 1.3]>, John Day typed: >>> >>> >>> >>Jon. >>> >> >>> >>Yes, precisely. The first place it shows up is in ISDN, then Frame >>> >>Relay, ATM, and MPLS. All those CCITT-like connection oriented >>> >>solutions. And you undoubtedly are correct, it was brought into the >>> >>Internet by the Europeans where the new model was largely ignored >>> >>after the suppression of CYCLADES and the completion other early work >>> >>such as the Cambridge DS. (As near as I can tell the vast majority >>> >>of European universities never strayed too far from the traditional >>> >>ITU model during the 70s to 90s. In fact most of the research still >>> >>bears a strong mark of it with an Internet veneer.) >>> >> >>> >>Yes, it did arrive sometime back and has been a constant source of >>> >>humor since the ATM lunacy. In fact, this is what makes it so >>> >>wonderful that OpenFlow and SDN have embraced the ITU world view so >>> >>completely. The Internet becomes about as anti-Internet as it can >>> >>get. The Bell-heads have taken over. You have to admit it is pretty >>> >>amusing. >>> >> >>> >>Take care, >>> >>John >>> >> >>> >> >>> >>At 12:29 PM +0100 4/13/13, Jon Crowcroft wrote: >>> >>>so the dogma here was that the business of manageing the net was just >>> >>>another distributed system (see the Cambridge Distributed System) >>> >>>wherre name services, router services, security services were >>> >>>implemented in exactly the same way as any other distributred system >>> >>>(file systems, transaction services, distributed computation tools)... >>> >>> >>> >>>but the control plane model of the net arrived in internet-land some >>> >>>time back - for example simon crosby took ideas (this was around the >>> >>>time when everyone was trying to do IP over ATM, which morphed into >>> >>>mpls) from "switchlet" territory with remote computation as >>> >>>controlplanestechnology... other people, e.g. ipsilon, also took the >>> >>> >>>seperation of concerns that are >>> >>>forwarding packets as fast as you can, >>> >>>from >>> >>>working out where they should and shouldn't go >>> >>>and put them on different boxes, originally to be coordinated via the >>> >>>Generic Switch Management Protocol >>> >>>later re-discoverd as Software Definted Networkign and Openflow... >>> >>> >>> >>>plus ca change... >>> >>>In missive <a062408a1cd8ddf0a5bcd@[10.0. 1.3]>, John Day typed: >>> >>> >>> >>> >>> >>The whole distinction of data plane and control plane arises with >>> >>> >>ISDN. It is a CCITT concept and was never used to describe >>> anything >>> >>> >>Internet related, either in the US or Europe. Such distinctions >>> only >>> >>> >>make sense in the beads-on-a-string models of the ITU. Routing, >>> >>> >>ICMP, DHCP, etc. type functions were characterized as layer >>> >>> >>management, which can exist to greater or lesser degree in all >>> layers >>> >>> >>and must be within the layer owing to the different scopes of the >>> >>> >>layers. >>> >>> >> >>> >>> >>Take care, >>> >>> >>John Day >>> >>> >> >>> >>> >>> >>> >>> >>>the post-hoc rationalisation phrase is way too glib....certainly >>> not >>> >>> >>>intended to be rude to people that created this cool stuff we all >>> >>> >>>use - in fact i was conflating three things >>> >>> >>> >>> >>> >>>1. a bunch of work fairly recently on optimal protocols and >>> narrow >>> >>> >>>waist of the hour glass... >>> >>> >>>2. the ordering of constrints on the design of the internet >>> >>> >>>protocols (as per dave clarks 88 paper) >>> >>> >>>and >>> >>> >>>3. the apparent simplicity of IP - my missing point was that the >>> >>> >>>complexity pops out somewhere, and that place is in the control >>> >>> >>>plane....as we've since disovered... >>> >>> >>> >>> >>> >>>of course, there were people that ran dynamic distributed routing >>> >>> >>>for VC networks (X.25 for example - we had switches in the JANET >>> >>> >>>network that did this) so they were even more complex in both >>> data >>> >>> >>>and control plane (what with crankback etc etc:) >>> >>> >>> >>> >>> >>>so yes, a bit glib really...sorry >>> >>> >>> >>> >>> >>>normal service will be resumed as soon as I get my IPTV QoS back >>> :) >>> >>> >>> >>> >>> >>>j. >>> >>> >>> >>> >>> >>> >>> >>> >>>On Fri, Apr 12, 2013 at 3:07 PM, Fred Baker (fred) >>> >>> >>><<mailto:fred at cisco.com>fre d at cisco.com <fred at cisco.com>> wrote: >>> >>> >>> >>> >>> >>>I'd suggest running the assertion by Vint. I made a similar >>> >>> >>>assertion in a document not too long ago, which I ran by him for >>> >>> >>>comment, and he told me I was flatly wrong. Yes, the circuit >>> switch >>> >>> >>>folks were using the term "catenet" to refer to networks that >>> >>> >>>interoperated through translation, such as frame relay/ATM >>> >>> >>>interoperation, he asserted, but at least some (he?) was using >>> the >>> >>> >>>term "Internet" as early as the mid 1970's. >>> >>> >>> >>> >>> >>> >>> >>> >>>On Apr 11, 2013, at 8:59 PM, Dave Crocker >>> >>> >>><<mailto:dhc2 at dcrocker.net>dhc2 at dcrocker.net> wrote: >>> >>> >>> >>> >>> >>>> This is a risky query. There have been previous threads about >>> >>> >>>>such things as the "start" of the Internet. Instead, I want to >>> ask >>> >>> >>>>about the "architecture" of the Internet. >>> >>> >>>> >>> >>> >>>> Here's a comment that I sent earlier today, to a non-technical >>> >>> >>>>person who is aware of the overall Internet timeline, but I >>> believe >>> >>> >>>>does not understand what is distinctive about Internet >>> >>> >>>>'architecture'. I'm curious about reactions on this list, and >>> any >>> >>> >>>>possible improvements -- including complete replacement -- but >>> more >>> >>> >>>>importantly I'm interested in filling in the details: >>> >>> >>> > >>> >>> >>>> The original use of the term Internet was to describe a >>> >>> >>>>distinctive technical design for a distributed, scalable data >>> >>> >>>>exchange fabric. Its design characteristics differ dramatically >>> >>> >>>>from those of its predecessor, the Arpanet, and from other >>> related >>> >>> >>>>efforts. >>> >>> >>>> >>> >>> >>>> That's what I sent. To prime the pump for the detail: >>> >>> >>>> >>> >>> >>>> By saying 'fabric' I meant to distinguish the mechanism >>> for >>> >>> >>>>moving raw data from the applications that used it. What I'd >>> class >>> >>> >>>>as distinctive were the TCP/IP separation, the remarkably modest >>> >>> >>>>functionality of IP, even to the point of moving it's control >>> plane >>> >>> >>>>to the next level up with ICMP, and continuing with modest >>> >>> >>>>expectations the layer below (which made it possible to operate >>> >>> >>>>over any medium including birds.) This is usually >>> characterized as >>> >>> >>>>moving robustness to the edges. >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> Thoughts? >>> >>> >>>> >>> >>> >>>> d/ >>> >>> >>>> >>> >>> >>>> -- >>> >>> >>>> Dave Crocker >>> >>> >>>> Brandenburg InternetWorking >>> >>> >>>> <http://bbiw.net>bbiw.net >>> >>> >> >>> >>> >>--============_-846339397==_ma============ >>> >>> >>Content-Type: text/html; charset="us-ascii" >>> >>> >> >>> >>> >><!doctype html public "-//W3C//DTD W3 HTML//EN"> >>> >>> >><html><head><style type="text/css"><!-- >>> >>> >>blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 } >>> >>> >> --></style><title>Re: [e2e] Internet >>> >>> >>"architecture" >>> >>> >>
This is a can of worms, but. . .
>>> >>> >>

>>> >>> >>
At 4:23 PM +0200 4/12/13, Jon Crowcroft wrote:
>>> >>> >>
the folks who called it catenet >>> included >>> >>> >>bob braden who was working at UCL when i was there - of course, we >>> >>> >>were concatenating networks that ran other protocols (Cambridge >>> Ring, >>> >>> >>X.25 (transport layer relays) and so on...so perhaps I'm >>> conflating >>> >>> >>two things - the interconnection of multiple disprate protocol >>> >>> >>systems, and the IP interconenction of multiple IP networks with >>> >>> >>disparete layer 2 and below....
>>> >>> >>

>>> >>> >>
Early on the term catenet was applied without respect to >>> >>> >>connection or connectionless, but only with respect to forwarding >>> vs. >>> >>> >>translation (if necessary).
>>> >>> >>

>>> >>> >>

>>> >>> >>
it is the case (as some other folks >>> >>> >>privately pointed out to me) that IENs (including IEN 1 written at >>> >>> >>UCL) are Internet Experiment Notes, and go back to mid 1970s, so >>> i'm >>> >>> >>wrong to say "internet"
>>> >>> >>

>>> >>> >>
however, my point about parsimony is >>> >>> >>really over compressed - IP trades off simplicity in the data >>> plane, >>> >>> >>for complexity in the control plane - its not a pure trade off >>> (it can >>> >>> >>be seen partly as a win-win, as signaling protocols for VC >>> networks >>> >>> >>can be nearly as complex (or in X.25 and B-ISDN's Q.2931's cases, >>> more >>> >>> >>complex) as routing protocols....nevertheless, getting routing >>> right >>> >>> >>and all associated components is seriously non-trivial - other >>> systems >>> >>> >>(the aforesaid cambridge ring protocol stack) represent a >>> different >>> >>> >>trade off that is also quite elegant.
>>> >>> >>

>>> >>> >>
The whole distinction of data plane and control plane arises >>> with >>> >>> >>ISDN. It is a CCITT concept and was never used to describe >>> anything >>> >>> >>Internet related, either in the US or Europe. Such distinctions >>> only >>> >>> >>make sense in the beads-on-a-string models of the ITU.  >>> Routing, >>> >>> >>ICMP, DHCP, etc. type functions were characterized as layer >>> >>> >>management, which can exist to greater or lesser degree in all >>> layers >>> >>> >>and must be within the layer owing to the different scopes of the >>> >>> >>layers.
>>> >>> >>

>>> >>> >>
Take care,
>>> >>> >>
John Day
>>> >>> >>

>>> >>> >>

>>> >>> >>
the post-hoc rationalisation phrase >>> is >>> >>> >>way too glib....certainly not intended to be rude to people that >>> >>> >>created this cool stuff we all use - in fact i was conflating >>> three >>> >>> >>things
>>> >>> >>

>>> >>> >>
1. a bunch of work fairly recently on >>> >>> >>optimal protocols and narrow waist of the hour >>> glass...
>>> >>> >>
2. the ordering of constrints on the >>> >>> >>design of the internet protocols (as per dave clarks 88 >>> >>> >>paper)
>>> >>> >>
and
>>> >>> >>
3. the apparent simplicity of IP - my >>> >>> >>missing point was that the complexity pops out somewhere, and that >>> >>> >>place is in the control plane....as we've since >>> >>> >>disovered...
>>> >>> >>

>>> >>> >>
of course, there were people that ran >>> >>> >>dynamic distributed routing for VC networks (X.25 for example - >>> we had >>> >>> >>switches in the JANET network that did this) so they were even >>> more >>> >>> >>complex in both data and control plane (what with crankback etc >>> >>> >>etc:)
>>> >>> >>

>>> >>> >>
so yes, a bit glib >>> >>> >>really...sorry
>>> >>> >>

>>> >>> >>
normal service will be resumed as >>> soon as >>> >>> >>I get my IPTV QoS back :)
>>> >>> >>

>>> >>> >>
j.
>>> >>> >>

>>> >>> >>
>>> >>> >>
>>> >>> >>
On Fri, Apr 12, 2013 at 3:07 PM, Fred >>> >>> >>Baker (fred) <fred at cisco.com >>> > >>> >>> >>wrote:
>>> >>> >>
I'd suggest running the assertion by Vint. I made a >>> >>> >>similar assertion in a document not too long ago, which I ran by >>> him >>> >>> >>for comment, and he told me I was flatly wrong. Yes, the circuit >>> >>> >>switch folks were using the term "catenet" to refer to >>> >>> >>networks that interoperated through translation, such as frame >>> >>> >>relay/ATM interoperation, he asserted, but at least some (he?) was >>> >>> >>using the term "Internet" as early as the mid >>> 1970's.
>>> >>> >>
>>> >>> >>

>>> >>> >>On Apr 11, 2013, at 8:59 PM, Dave Crocker <>> >>> >>href="mailto:dhc2 at dcrocker.net">dhc2 at dcrocker.net> >>> wrote:
>>> >>> >>
>>> >>> >>> This is a risky query.  There have been previous threads >>> >>> >>about such things as the "start" of the Internet. >>> >>> >> Instead, I want to ask about the "architecture" >>> of the >>> >>> >>Internet.
>>> >>> >>>
>>> >>> >>> Here's a comment that I sent earlier today, to a >>> non-technical >>> >>> >>person who is aware of the overall Internet timeline, but I >>> believe >>> >>> >>does not understand what is distinctive about Internet >>> 'architecture'. >>> >>> >> I'm curious about reactions on this list, and any possible >>> >>> >>improvements -- including complete replacement -- but more >>> importantly >>> >>> >>I'm interested in filling in the details:
>>> >>> >>
>
>>> >>> >>>     The original use of the term >>> Internet was >>> >>> >>to describe a distinctive technical design for a distributed, >>> scalable >>> >>> >>data exchange fabric.  Its design characteristics differ >>> >>> >>dramatically from those of its predecessor, the Arpanet, and from >>> >>> >>other related efforts.
>>> >>> >>>
>>> >>> >>> That's what I sent.  To prime the pump for the >>> detail:
>>> >>> >>>
>>> >>> >>>     By saying 'fabric' I meant to >>> distinguish >>> >>> >>the mechanism for moving raw data from the applications that used >>> it. >>> >>> >> What I'd class as distinctive were the TCP/IP separation, >>> the >>> >>> >>remarkably modest functionality of IP, even to the point of moving >>> >>> >>it's control plane to the next level up with ICMP, and continuing >>> with >>> >>> >>modest expectations the layer below (which made it possible to >>> operate >>> >>> >>over any medium including birds.)  This is usually >>> characterized >>> >>> >>as moving robustness to the edges.
>>> >>> >>>
>>> >>> >>>
>>> >>> >>> Thoughts?
>>> >>> >>>
>>> >>> >>> d/
>>> >>> >>>
>>> >>> >>> --
>>> >>> >>> Dave Crocker
>>> >>> >>> Brandenburg InternetWorking
>>> >>> >>> bbiw.net
>>> >>> >>
>>> >>> >>

>>> >>> >> >>> >>> >> >>> >>> >>--============_-846339397==_ma============-- >>> >>> >>> >>> cheers >>> >>> >>> >>> jon >>> >> >>> >>> cheers >>> >>> jon >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20130414/9737b696/attachment-0001.html From Jon.Crowcroft at cl.cam.ac.uk Sun Apr 14 12:16:15 2013 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Sun, 14 Apr 2013 20:16:15 +0100 Subject: [e2e] Internet "architecture" In-Reply-To: References: <516786AE.5020009@dcrocker.net> <8C48B86A895913448548E6D15DA7553B80B149@xmb-rcd-x09.cisco.com> <1365957620.324222272@apps.rackspace.com> Message-ID: your work on ML and active nets is the ancestor of our work on verifiable control plane stuff, so i was referring to the broader stream of less well formulated work in this space i am disappointed at people being pessimistic about the fruits of computer science (science, not just engineering) in practice we;ve made great strides (e.g. in information flow, and symbolic execution) and people unaware of work on verfying device drivers by byron cook and others need to get up to speed a bit more ... cheers! In missive , "Jonathan M. S mith" typed: >>Jon: >> How exactly did AN go wrong? >> = >> -JMS >> >>On Apr 14, 2013, at 12:51 PM, Jon Crowcroft = >>wrote: >> >>> I'm not claiming CS can architect things better - I am claiming that = >>people architecting things today should assimilatethe idea that we have = >>differt CS tools at our disposal - this is quite a different.claim >>>=20 >>> architecure remains as hard as ever, and as rare in any discipline = >>(except maybe norman foster's :-) >>>=20 >>> I totally agree that things could go either way - SDN (like active = >>nets before it) could go horribly horribly wrong.... >>>=20 >>> on the other hand, i suppose, it would then not get adopted much... >>>=20 >>>=20 >>> On Sun, Apr 14, 2013 at 5:40 PM, wrote: >>> Jon - I strongly disagree with your views that SDN *will* solve the = >>problem of simplifying network architecture and that computer scientists = >>today are capable of architecting systems much better than those 40 = >>years ago. I don't have a problem with SDN technology per se, but it = >>changes very little in regard to most aspects of quality network design = >>and architecture. >>> [usual disclaimer about my posts being blocked to the full e2e list, = >>but I invited to the conversation some people who might agree or = >>disagree, because I think it's an interesting question] >>> =20 >>> As someone who has worked on SDN (with McKeown's own code, at HP = >>Labs), I think it can go either way - >>> =20 >>> 1) do a better job of moving flexibility and function to the edges, or >>> 2) create a vast nightmarish terrain of virtual middleboxes that do = >>unpredictable and random things to traffic packets. >>> =20 >>> Having seen what the deployers of middleboxes get wrong, I'm not sure = >>that a virtualization platform for middleboxes will do to reduce the = >>problems. It's a sociopolitical problem, not a technical one. >>> =20 >>> Inside a company, where the fabric is completely owned and operated by = >>a unified IT dept. (there is much evidence that IT dept's in large = >>companies are hardly unified, though), SDN's can be extremely helpful - = >>precisely because the network is virtualized by SDN. You can roll out = >>changes in a coordinated fashion, orchestrate resilience in the face of = >>faults and signficant load changes, etc. All that is quite doable, even = >>while preserving the essential separation between transport and = >>heterogeneous infrastructure. That separation is quite important to the = >>long-term nature of the systems that use any network. >>> =20 >>> However, the mess that is evolving in IPv4 comes from poorly thought = >>out regulations (wiretapping and "firewall" mechanisms that try to = >>operate at a level where there is no end-point semantics, for example) = >>and a struggle to create business "control points" that can be = >>monopolized. >>> =20 >>> Merely emulating that mess (perfectly feasible with SDN) creates the = >>opportunity to ramify the process of chaotic evolution of the network. >>> =20 >>> As far as your view that modern computer science and computer = >>scientists can now do what we couldn't do 40 years ago, I'm = >>extraordinarily skeptical. Modern computer scientists (the people) are = >>much less capable of clean architectural thinking on the average, and = >>being faced with problems with a vast increase in interactions among = >>uncontrollable factors. >>> =20 >>> This is why I continue to complain about network pedagogy that starts = >>with the idea that networks somehow live in a world of stationary random = >>processes that are all Gaussian, and that there is a "central limit = >>theorem" that therefore makes aggregation reduce complexity. I've even = >>heard someone say that there may be a little bit of "fractal" structure, = >>but that it is "drowned out" by Gaussian stationary traffic. Anyone who = >>understood the actual math would be appalled, but computer scientists = >>*pretend* to be mathematicians for the most part, applying cookbook = >>formulas and "gut instincts" that they got by solving simple textbook = >>exercises and watching lectures without questioning assumptions, and = >>never challenging their professors. >>> =20 >>> 40 years ago, there was not so much teachiing of "things that we know = >>that 'taint so" as the phrase goes. So in that sense, today's computer = >>scientists have a herd instinct that never questions anything, and = >>worse, feels completely empowered to disregard those who don't agree = >>with the consensus, no matter how well they put the alternative forth. >>> =20 >>> How else did we end up in a place where nearly every access network = >>has key links where "bufferbloat" can allow a single person to run an = >>application that builds up a blockage in either the downlink or the = >>uplink, creating latencies of 1-4 seconds when the nominal latency is on = >>the order of < 10 msec and the cross-country latency including all hops = >>is around 30 msec? Was this "expertise by computer scientists"? = >>Hardly. It was vastly ramified result of ignorance, not expertise. >>> =20 >>> And worse, NO ONE in the community bothers to actually measure the = >>real Internet in any detail. That would make their publications in = >>academic journals be suspect, and eliminate the cozy world of = >>conferences that seem to be more like a mutual admiration society among = >>an isolated elite. >>> =20 >>> So I'm skeptical that there is this wonderful world of computer = >>scientists that have mastered anything. >>> =20 >>> Some people in the community are pretty damn smart. Too few. Most are = >>mis-employed. >>> =20 >>> So, in the case of SDN, I'm pretty sure that the mess will continue to = >>get worse due precisely to the ease with which SDN enables the blind = >>deployment of bad ideas, and does not enhance the ability to detect the = >>effects of bad ideas, measure their problems, and chuck the bad ideas. >>> =20 >>> SDN becomes an accelerator of a network Gresham's Law, if that is the = >>way things go. >>> =20 >>> Nonetheless, SDN is a really helpful concept, put in its place - = >>virtualization can be enormously helpful when it creates a simple = >>abstraction without "cross-layer optimization". >>> =20 >>> And don't get me started on the academic fascination in computer = >>science with how "great" cross-layer optimizations are. Next we'll have = >>thousands of papers talking about the wonders of kludges and crocks in = >>network designs. >>> =20 >>>=20 >>>=20 >>> On Sunday, April 14, 2013 6:04am, "Jon Crowcroft" = >> said: >>>=20 >>> I think you can look at it a different way - SDN lets you move even = >>more smarts out of the network into end systems - as far as we implement = >>it, that looks even less like the ITU than the current = >>ancient-route-computation/firewall/middlebox ridden IPv4 ossification of = >>today >>> so i can see that you could cast SDN in the Wicked Witch of the ITU = >>role, but equally, I think of it as not being in Kansas anymore.... >>> cheers >>> jon >>>=20 >>>=20 >>> On Sat, Apr 13, 2013 at 10:39 PM, John Day = >>wrote: >>> Yea, I have seen their stuff too, pretty amusing. about as disruptive = >>as a speed bump. ;-) >>>=20 >>> Actually you have it backwards, we *are* using the reactionary designs = >>of 40 years ago and that is what is holding things back, rather than the = >>forward looking designs that were being pursued. >>>=20 >>> Those weren't the answer, but it was on the way to the answer, that is = >>clear now and they would have found it if they had been able to keep = >>going. >>>=20 >>> Things become much simpler once you are out of the ITU model that SDN = >>and Open Flow are locked into. >>>=20 >>> Have fun, >>> John >>>=20 >>>=20 >>>=20 >>> At 8:25 PM +0100 4/13/13, Jon Crowcroft wrote: >>> well i've seen scott shenker do his SDN vision talk a couple of times, >>> and I know nick mckeown's work pretty well, and I do not think they >>> are bell heads >>>=20 >>> one point is that computer science has grown up slightly since 40+ >>> years ago, so we are capabile of building way more flexible safe, >>> secure and performant systems that in the past, when the design >>> constraints on protocol stacks were set by 1960s ideas of s/w... >>>=20 >>> so the stuff out of berkeley, stanford, princeton, gatech etc >>> in this space is not constrained by the old rules >>>=20 >>> it is deconstrained by new capabilities... >>>=20 >>> [slightly stolen from John Doyle's cool idea of de-constraining >>> constraints] >>>=20 >>>=20 >>> so the realpolitik of openflow is (as it was with GSMP) to get arms >>> length from the legacy router biz, and move the functionality somwhere >>> where we can do disruptive innovation >>>=20 >>> but that is another chapter... >>>=20 >>> In missive , John Day typed: >>>=20 >>>=20 >>> >>Jon. >>> >> >>> >>Yes, precisely. The first place it shows up is in ISDN, then Frame >>> >>Relay, ATM, and MPLS. All those CCITT-like connection oriented >>> >>solutions. And you undoubtedly are correct, it was brought into the >>> >>Internet by the Europeans where the new model was largely ignored >>> >>after the suppression of CYCLADES and the completion other early = >>work >>> >>such as the Cambridge DS. (As near as I can tell the vast majority >>> >>of European universities never strayed too far from the traditional >>> >>ITU model during the 70s to 90s. In fact most of the research still >>> >>bears a strong mark of it with an Internet veneer.) >>> >> >>> >>Yes, it did arrive sometime back and has been a constant source of >>> >>humor since the ATM lunacy. In fact, this is what makes it so >>> >>wonderful that OpenFlow and SDN have embraced the ITU world view so >>> >>completely. The Internet becomes about as anti-Internet as it can >>> >>get. The Bell-heads have taken over. You have to admit it is = >>pretty >>> >>amusing. >>> >> >>> >>Take care, >>> >>John >>> >> >>> >> >>> >>At 12:29 PM +0100 4/13/13, Jon Crowcroft wrote: >>> >>>so the dogma here was that the business of manageing the net was = >>just >>> >>>another distributed system (see the Cambridge Distributed System) >>> >>>wherre name services, router services, security services were >>> >>>implemented in exactly the same way as any other distributred = >>system >>> >>>(file systems, transaction services, distributed computation = >>tools)... >>> >>> >>> >>>but the control plane model of the net arrived in internet-land = >>some >>> >>>time back - for example simon crosby took ideas (this was around = >>the >>> >>>time when everyone was trying to do IP over ATM, which morphed into >>> >>>mpls) from "switchlet" territory with remote computation as >>> >>>controlplanestechnology... other people, e.g. ipsilon, also took = >>the >>>=20 >>> >>>seperation of concerns that are >>> >>>forwarding packets as fast as you can, >>> >>>from >>> >>>working out where they should and shouldn't go >>> >>>and put them on different boxes, originally to be coordinated via = >>the >>> >>>Generic Switch Management Protocol >>> >>>later re-discoverd as Software Definted Networkign and Openflow... >>> >>> >>> >>>plus ca change... >>> >>>In missive , John Day typed: >>>=20 >>> >>> >>> >>> >>The whole distinction of data plane and control plane arises = >>with >>> >>> >>ISDN. It is a CCITT concept and was never used to describe = >>anything >>> >>> >>Internet related, either in the US or Europe. Such distinctions = >>only >>> >>> >>make sense in the beads-on-a-string models of the ITU. = >>Routing, >>> >>> >>ICMP, DHCP, etc. type functions were characterized as layer >>> >>> >>management, which can exist to greater or lesser degree in all = >>layers >>> >>> >>and must be within the layer owing to the different scopes of = >>the >>> >>> >>layers. >>> >>> >> >>> >>> >>Take care, >>> >>> >>John Day >>> >>> >> >>> >>> >>> >>> >>> >>>the post-hoc rationalisation phrase is way too = >>glib....certainly not >>> >>> >>>intended to be rude to people that created this cool stuff we = >>all >>> >>> >>>use - in fact i was conflating three things >>> >>> >>> >>> >>> >>>1. a bunch of work fairly recently on optimal protocols and = >>narrow >>> >>> >>>waist of the hour glass... >>> >>> >>>2. the ordering of constrints on the design of the internet >>> >>> >>>protocols (as per dave clarks 88 paper) >>> >>> >>>and >>> >>> >>>3. the apparent simplicity of IP - my missing point was that = >>the >>> >>> >>>complexity pops out somewhere, and that place is in the = >>control >>> >>> >>>plane....as we've since disovered... >>> >>> >>> >>> >>> >>>of course, there were people that ran dynamic distributed = >>routing >>> >>> >>>for VC networks (X.25 for example - we had switches in the = >>JANET >>> >>> >>>network that did this) so they were even more complex in both = >>data >>> >>> >>>and control plane (what with crankback etc etc:) >>> >>> >>> >>> >>> >>>so yes, a bit glib really...sorry >>> >>> >>> >>> >>> >>>normal service will be resumed as soon as I get my IPTV QoS = >>back :) >>> >>> >>> >>> >>> >>>j. >>> >>> >>> >>> >>> >>> >>> >>> >>>On Fri, Apr 12, 2013 at 3:07 PM, Fred Baker (fred) >>> >>> >>><fre d at cisco.com> wrote: >>> >>> >>> >>> >>> >>>I'd suggest running the assertion by Vint. I made a similar >>> >>> >>>assertion in a document not too long ago, which I ran by him = >>for >>> >>> >>>comment, and he told me I was flatly wrong. Yes, the circuit = >>switch >>> >>> >>>folks were using the term "catenet" to refer to networks that >>> >>> >>>interoperated through translation, such as frame relay/ATM >>> >>> >>>interoperation, he asserted, but at least some (he?) was using = >>the >>> >>> >>>term "Internet" as early as the mid 1970's. >>> >>> >>> >>> >>> >>> >>> >>> >>>On Apr 11, 2013, at 8:59 PM, Dave Crocker >>> >>> >>><dhc2 at dcrocker.net> wrote: >>> >>> >>> >>> >>> >>>> This is a risky query. There have been previous threads = >>about >>> >>> >>>>such things as the "start" of the Internet. Instead, I want = >>to ask >>> >>> >>>>about the "architecture" of the Internet. >>> >>> >>>> >>> >>> >>>> Here's a comment that I sent earlier today, to a = >>non-technical >>> >>> >>>>person who is aware of the overall Internet timeline, but I = >>believe >>> >>> >>>>does not understand what is distinctive about Internet >>> >>> >>>>'architecture'. I'm curious about reactions on this list, = >>and any >>> >>> >>>>possible improvements -- including complete replacement -- = >>but more >>> >>> >>>>importantly I'm interested in filling in the details: >>> >>> >>> > >>> >>> >>>> The original use of the term Internet was to describe a >>> >>> >>>>distinctive technical design for a distributed, scalable data >>> >>> >>>>exchange fabric. Its design characteristics differ = >>dramatically >>> >>> >>>>from those of its predecessor, the Arpanet, and from other = >>related >>> >>> >>>>efforts. >>> >>> >>>> >>> >>> >>>> That's what I sent. To prime the pump for the detail: >>> >>> >>>> >>> >>> >>>> By saying 'fabric' I meant to distinguish the mechanism = >>for >>> >>> >>>>moving raw data from the applications that used it. What I'd = >>class >>> >>> >>>>as distinctive were the TCP/IP separation, the remarkably = >>modest >>> >>> >>>>functionality of IP, even to the point of moving it's control = >>plane >>> >>> >>>>to the next level up with ICMP, and continuing with modest >>> >>> >>>>expectations the layer below (which made it possible to = >>operate >>> >>> >>>>over any medium including birds.) This is usually = >>characterized as >>> >>> >>>>moving robustness to the edges. >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> Thoughts? >>> >>> >>>> >>> >>> >>>> d/ >>> >>> >>>> >>> >>> >>>> -- >>> >>> >>>> Dave Crocker >>> >>> >>>> Brandenburg InternetWorking >>> >>> >>>> bbiw.net >>> >>> >> >>> >>> >>--=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D_-846339397=3D=3D_ma=3D=3D=3D= >>=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> >>> >>Content-Type: text/html; charset=3D"us-ascii" >>> >>> >> >>> >>> >> >>> >>> >>Re: [e2e] Internet >>> >>> >>"architecture" >>> >>> >>
This is a can of worms, but. . .
>>> >>> >>

>>> >>> >>
At 4:23 PM +0200 4/12/13, Jon Crowcroft wrote:
>>> >>> >>
the folks who called it catenet = >>included >>> >>> >>bob braden who was working at UCL when i was there - of course, = >>we >>> >>> >>were concatenating networks that ran other protocols (Cambridge = >>Ring, >>> >>> >>X.25 (transport layer relays) and so on...so perhaps I'm = >>conflating >>> >>> >>two things - the interconnection of multiple disprate protocol >>> >>> >>systems, and the IP interconenction of multiple IP networks = >>with >>> >>> >>disparete layer 2 and below....
>>> >>> >>

>>> >>> >>
Early on the term catenet was applied without respect to >>> >>> >>connection or connectionless, but only with respect to = >>forwarding vs. >>> >>> >>translation (if necessary).
>>> >>> >>

>>> >>> >>

>>> >>> >>
it is the case (as some other = >>folks >>> >>> >>privately pointed out to me) that IENs (including IEN 1 written = >>at >>> >>> >>UCL) are Internet Experiment Notes, and go back to mid 1970s, = >>so i'm >>> >>> >>wrong to say "internet"
>>> >>> >>

>>> >>> >>
however, my point about = >>parsimony is >>> >>> >>really over compressed - IP trades off simplicity in the data = >>plane, >>> >>> >>for complexity in the control plane - its not a pure trade off = >>(it can >>> >>> >>be seen partly as a win-win, as signaling protocols for VC = >>networks >>> >>> >>can be nearly as complex (or in X.25 and B-ISDN's Q.2931's = >>cases, more >>> >>> >>complex) as routing protocols....nevertheless, getting routing = >>right >>> >>> >>and all associated components is seriously non-trivial - other = >>systems >>> >>> >>(the aforesaid cambridge ring protocol stack) represent a = >>different >>> >>> >>trade off that is also quite elegant.
>>> >>> >>

>>> >>> >>
The whole distinction of data plane and control plane = >>arises with >>> >>> >>ISDN. It is a CCITT concept and was never used to describe = >>anything >>> >>> >>Internet related, either in the US or Europe. Such distinctions = >>only >>> >>> >>make sense in the beads-on-a-string models of the ITU.  = >>Routing, >>> >>> >>ICMP, DHCP, etc. type functions were characterized as layer >>> >>> >>management, which can exist to greater or lesser degree in all = >>layers >>> >>> >>and must be within the layer owing to the different scopes of = >>the >>> >>> >>layers.
>>> >>> >>

>>> >>> >>
Take care,
>>> >>> >>
John Day
>>> >>> >>

>>> >>> >>

>>> >>> >>
the post-hoc rationalisation = >>phrase is >>> >>> >>way too glib....certainly not intended to be rude to people = >>that >>> >>> >>created this cool stuff we all use - in fact i was conflating = >>three >>> >>> >>things
>>> >>> >>

>>> >>> >>
1. a bunch of work fairly = >>recently on >>> >>> >>optimal protocols and narrow waist of the hour = >>glass...
>>> >>> >>
2. the ordering of constrints on = >>the >>> >>> >>design of the internet protocols (as per dave clarks 88 >>> >>> >>paper)
>>> >>> >>
and
>>> >>> >>
3. the apparent simplicity of IP = >>- my >>> >>> >>missing point was that the complexity pops out somewhere, and = >>that >>> >>> >>place is in the control plane....as we've since >>> >>> >>disovered...
>>> >>> >>

>>> >>> >>
of course, there were people = >>that ran >>> >>> >>dynamic distributed routing for VC networks (X.25 for example - = >>we had >>> >>> >>switches in the JANET network that did this) so they were even = >>more >>> >>> >>complex in both data and control plane (what with crankback etc >>> >>> >>etc:)
>>> >>> >>

>>> >>> >>
so yes, a bit glib >>> >>> >>really...sorry
>>> >>> >>

>>> >>> >>
normal service will be resumed = >>as soon as >>> >>> >>I get my IPTV QoS back :)
>>> >>> >>

>>> >>> >>
j.
>>> >>> >>

>>> >>> >>
>>> >>> >>
>>> >>> >>
On Fri, Apr 12, 2013 at 3:07 PM, = >>Fred >>> >>> >>Baker (fred) <>href=3D"mailto:fred at cisco.com">fred at cisco.com> >>> >>> >>wrote:
>>> >>> >>
I'd suggest running the assertion by Vint. I made a >>> >>> >>similar assertion in a document not too long ago, which I ran = >>by him >>> >>> >>for comment, and he told me I was flatly wrong. Yes, the = >>circuit >>> >>> >>switch folks were using the term "catenet" to refer = >>to >>> >>> >>networks that interoperated through translation, such as frame >>> >>> >>relay/ATM interoperation, he asserted, but at least some (he?) = >>was >>> >>> >>using the term "Internet" as early as the mid = >>1970's.
>>> >>> >>
>>> >>> >>

>>> >>> >>On Apr 11, 2013, at 8:59 PM, Dave Crocker <>> >>> >>href=3D"mailto:dhc2 at dcrocker.net">dhc2 at dcrocker.net> = >>wrote:
>>> >>> >>
>>> >>> >>> This is a risky query.  There have been previous = >>threads >>> >>> >>about such things as the "start" of the Internet. >>> >>> >> Instead, I want to ask about the "architecture" = >>of the >>> >>> >>Internet.
>>> >>> >>>
>>> >>> >>> Here's a comment that I sent earlier today, to a = >>non-technical >>> >>> >>person who is aware of the overall Internet timeline, but I = >>believe >>> >>> >>does not understand what is distinctive about Internet = >>'architecture'. >>> >>> >> I'm curious about reactions on this list, and any = >>possible >>> >>> >>improvements -- including complete replacement -- but more = >>importantly >>> >>> >>I'm interested in filling in the details:
>>> >>> >>
>
>>> >>> >>>     The original use of the term = >>Internet was >>> >>> >>to describe a distinctive technical design for a distributed, = >>scalable >>> >>> >>data exchange fabric.  Its design characteristics differ >>> >>> >>dramatically from those of its predecessor, the Arpanet, and = >>from >>> >>> >>other related efforts.
>>> >>> >>>
>>> >>> >>> That's what I sent.  To prime the pump for the = >>detail:
>>> >>> >>>
>>> >>> >>>     By saying 'fabric' I meant to = >>distinguish >>> >>> >>the mechanism for moving raw data from the applications that = >>used it. >>> >>> >> What I'd class as distinctive were the TCP/IP separation, = >>the >>> >>> >>remarkably modest functionality of IP, even to the point of = >>moving >>> >>> >>it's control plane to the next level up with ICMP, and = >>continuing with >>> >>> >>modest expectations the layer below (which made it possible to = >>operate >>> >>> >>over any medium including birds.)  This is usually = >>characterized >>> >>> >>as moving robustness to the edges.
>>> >>> >>>
>>> >>> >>>
>>> >>> >>> Thoughts?
>>> >>> >>>
>>> >>> >>> d/
>>> >>> >>>
>>> >>> >>> --
>>> >>> >>> Dave Crocker
>>> >>> >>> Brandenburg InternetWorking
>>> >>> >>> bbiw.net
>>> >>> >>
>>> >>> >>

>>> >>> >> >>> >>> >> >>> >>> >>--=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D_-846339397=3D=3D_ma=3D=3D=3D= >>=3D=3D=3D=3D=3D=3D=3D=3D=3D-- >>> >>> >>> >>> cheers >>> >>> >>> >>> jon >>> >> >>>=20 >>> cheers >>>=20 >>> jon >>>=20 >> cheers jon From jnc at mercury.lcs.mit.edu Sun Apr 14 13:35:31 2013 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sun, 14 Apr 2013 16:35:31 -0400 (EDT) Subject: [e2e] Internet "architecture" Message-ID: <20130414203531.5D10818C105@mercury.lcs.mit.edu> > From: Jon Crowcroft > architecure remains as hard as ever I'm interested to know what 'architecture' means to you both; I know what _I_ mean by the term, but I'm not sure the field as a whole has a consistent, well-understood meaning, yet. Noel From jeanjour at comcast.net Sun Apr 14 15:07:07 2013 From: jeanjour at comcast.net (John Day) Date: Sun, 14 Apr 2013 18:07:07 -0400 Subject: [e2e] Internet "architecture" In-Reply-To: <20130414203531.5D10818C105@mercury.lcs.mit.edu> References: <20130414203531.5D10818C105@mercury.lcs.mit.edu> Message-ID: I basically use the dictionary definition of "a style of construction." The important distinction being between an architecture and buildings built to that architecture. (I don't remember what dictionary I found that in. It was 30 years ago.) I would say that 90% of the usage in the field refers buildings, rather than *architectures.* For example, the 7-layer OSI model is a building, not an architecture. Take care, John At 4:35 PM -0400 4/14/13, Noel Chiappa wrote: > > From: Jon Crowcroft > > > architecure remains as hard as ever > >I'm interested to know what 'architecture' means to you both; I know what >_I_ mean by the term, but I'm not sure the field as a whole has a consistent, >well-understood meaning, yet. > > Noel From jon.crowcroft at cl.cam.ac.uk Sun Apr 14 23:17:53 2013 From: jon.crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Mon, 15 Apr 2013 07:17:53 +0100 Subject: [e2e] Internet "architecture" In-Reply-To: References: <20130414203531.5D10818C105@mercury.lcs.mit.edu> Message-ID: that's pretty much how i'd use it too (having spent 30 years meeting people who design styles of construction of living spaces, but dont often actually build buildings, i'm stuck with the le courbusier, gaudi, foster, rogers, gehry meaning:) On Sun, Apr 14, 2013 at 11:07 PM, John Day wrote: > I basically use the dictionary definition of "a style of construction." > The important distinction being between an architecture and buildings > built to that architecture. (I don't remember what dictionary I found that > in. It was 30 years ago.) > > I would say that 90% of the usage in the field refers buildings, rather > than *architectures.* > > For example, the 7-layer OSI model is a building, not an architecture. > > Take care, > John > > > At 4:35 PM -0400 4/14/13, Noel Chiappa wrote: > >> > From: Jon Crowcroft >> >> > architecure remains as hard as ever >> >> I'm interested to know what 'architecture' means to you both; I know what >> _I_ mean by the term, but I'm not sure the field as a whole has a >> consistent, >> well-understood meaning, yet. >> >> Noel >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20130415/dfe16adc/attachment.html From detlef.bosau at web.de Mon Apr 15 02:10:51 2013 From: detlef.bosau at web.de (Detlef Bosau) Date: Mon, 15 Apr 2013 11:10:51 +0200 Subject: [e2e] Why do we need congestion control? In-Reply-To: <60CC5ED9-45A2-465F-A6F6-15C580226D65@cs.ucsd.edu> References: <0037066628D6FC449C61186553CAE11D032D43A83ED9@njfpsrvexg2.research.att.com> <515AD4DD.4030809@web.de> <515B4B93.5060702@web.de> <515BEFDC.8040105@web.de> <515C16B9.3070007@isae.fr> <515C313E.6090205@web.de> <515C4E29.8090205@web.de> <60CC5ED9-45A2-465F-A6F6-15C580226D65@cs.ucsd.edu> Message-ID: <516BC41B.1020002@web.de> After quite some time, I once again thought about your paper. Even the name "decongestion" is misguiding. As DPR stated: Erasure codes do not obviate the need of congestion control. And the "decongestion" in your paper does not "decongest" the net - i.e. deliver the network from load which cannot be handled. Actually, it is some kind of degradation, because in case of TCP, the goodputs are throttled. Congestion is not a goodput issue but actually a throughput issue. -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From jeanjour at comcast.net Mon Apr 15 06:00:22 2013 From: jeanjour at comcast.net (John Day) Date: Mon, 15 Apr 2013 09:00:22 -0400 Subject: [e2e] Internet "architecture" In-Reply-To: References: <20130414203531.5D10818C105@mercury.lcs.mit.edu> Message-ID: Well, I am more a Frank Lloyd Wright fan myself. ;-) At 7:17 AM +0100 4/15/13, Jon Crowcroft wrote: >that's pretty much how i'd use it too (having spent 30 years meeting >people who design styles of construction of living spaces, but dont >often actually build buildings, i'm stuck with the le courbusier, >gaudi, foster, rogers, gehry meaning:) > > >On Sun, Apr 14, 2013 at 11:07 PM, John Day ><jeanjour at comcast.net> wrote: > >I basically use the dictionary definition of "a style of >construction." The important distinction being between an >architecture and buildings built to that architecture. (I don't >remember what dictionary I found that in. It was 30 years ago.) > >I would say that 90% of the usage in the field refers buildings, >rather than *architectures.* > >For example, the 7-layer OSI model is a building, not an architecture. > >Take care, >John > > >At 4:35 PM -0400 4/14/13, Noel Chiappa wrote: > > > From: Jon Crowcroft ><jon.crowcroft at cl.cam.ac.uk> > > > architecure remains as hard as ever > >I'm interested to know what 'architecture' means to you both; I know what >_I_ mean by the term, but I'm not sure the field as a whole has a consistent, >well-understood meaning, yet. > > Noel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20130415/933b3a50/attachment.html From jeanjour at comcast.net Mon Apr 15 06:13:59 2013 From: jeanjour at comcast.net (John Day) Date: Mon, 15 Apr 2013 09:13:59 -0400 Subject: [e2e] Internet "architecture" In-Reply-To: References: <516786AE.5020009@dcrocker.net> <8C48B86A895913448548E6D15DA7553B80B149@xmb-rcd-x09.cisco.com> <1365957620.324222272@apps.rackspace.com> Message-ID: To my mind there are two parts of computer science: the mathematics and the science. The mathematics part is, and always has been, doing quite well. It inherited its traditions from math and they are firmly in place. The science portion of CS has faired far less well and is for the most part degenerated into craft. Many people have complained to me that one sees the same papers on about 5 year cycle with different time constants. I don't quite get your reference to verifying device drivers. I guess I should go look at their work. But a device driver has the same structure as a protocol layer. They are basically the same problem and verifying protocols and their implementations has been well-understood for 30 years. The big problem with device drivers (as we all know) is figuring out what the darn thing actually does. ;-) The documentation is never accurate. That is more a test problem. Once you have that verification, is straightforward, tedious, but straightforward. At 8:16 PM +0100 4/14/13, Jon Crowcroft wrote: >your work on ML and active nets is the ancestor of our work on >verifiable control plane stuff, so i was referring to the broader >stream of less well formulated work in this space > >i am disappointed at people being pessimistic about the fruits of >computer science (science, not just engineering) in practice > >we;ve made great strides (e.g. in information flow, and symbolic >execution) and people unaware of work on verfying device drivers by >byron cook and others need to get up to speed a bit more ... > >cheers! > >In missive , >"Jonathan M. S >mith" typed: > > >>Jon: > >> How exactly did AN go wrong? > >> > = > >> -JMS > >> > >>On Apr 14, 2013, at 12:51 PM, Jon Crowcroft = > >>wrote: > >> > >>> I'm not claiming CS can architect things better - I am claiming that = > >>people architecting things today should assimilatethe idea that we have = > >>differt CS tools at our disposal - this is quite a different.claim > >>>=20 > >>> architecure remains as hard as ever, and as rare in any discipline = > >>(except maybe norman foster's :-) > >>>=20 > >>> I totally agree that things could go either way - SDN (like active = > >>nets before it) could go horribly horribly wrong.... > >>>=20 > >>> on the other hand, i suppose, it would then not get adopted much... > >>>=20 > >>>=20 > >>> On Sun, Apr 14, 2013 at 5:40 PM, wrote: > >>> Jon - I strongly disagree with your views that SDN *will* solve the = > >>problem of simplifying network architecture and that computer scientists = > >>today are capable of architecting systems much better than those 40 = > >>years ago. I don't have a problem with SDN technology per se, but it = > >>changes very little in regard to most aspects of quality network design = > >>and architecture. > >>> [usual disclaimer about my posts being blocked to the full e2e list, = > >>but I invited to the conversation some people who might agree or = > >>disagree, because I think it's an interesting question] > >>> =20 > >>> As someone who has worked on SDN (with McKeown's own code, at HP = > >>Labs), I think it can go either way - > >>> =20 > >>> 1) do a better job of moving flexibility and function to the edges, or > >>> 2) create a vast nightmarish terrain of virtual middleboxes that do = > >>unpredictable and random things to traffic packets. > >>> =20 > >>> Having seen what the deployers of middleboxes get wrong, I'm not sure = > >>that a virtualization platform for middleboxes will do to reduce the = > >>problems. It's a sociopolitical problem, not a technical one. > >>> =20 > >>> Inside a company, where the fabric is completely owned and operated by = > >>a unified IT dept. (there is much evidence that IT dept's in large = > >>companies are hardly unified, though), SDN's can be extremely helpful - = > >>precisely because the network is virtualized by SDN. You can roll out = > >>changes in a coordinated fashion, orchestrate resilience in the face of = > >>faults and signficant load changes, etc. All that is quite doable, even = > >>while preserving the essential separation between transport and = > >>heterogeneous infrastructure. That separation is quite important to the = > >>long-term nature of the systems that use any network. > >>> =20 > >>> However, the mess that is evolving in IPv4 comes from poorly thought = > >>out regulations (wiretapping and "firewall" mechanisms that try to = > >>operate at a level where there is no end-point semantics, for example) = > >>and a struggle to create business "control points" that can be = > >>monopolized. > >>> =20 > >>> Merely emulating that mess (perfectly feasible with SDN) creates the = > >>opportunity to ramify the process of chaotic evolution of the network. > >>> =20 > >>> As far as your view that modern computer science and computer = > >>scientists can now do what we couldn't do 40 years ago, I'm = > >>extraordinarily skeptical. Modern computer scientists (the people) are = > >>much less capable of clean architectural thinking on the average, and = > >>being faced with problems with a vast increase in interactions among = > >>uncontrollable factors. > >>> =20 > >>> This is why I continue to complain about network pedagogy that starts = > >>with the idea that networks somehow live in a world of stationary random = > >>processes that are all Gaussian, and that there is a "central limit = > >>theorem" that therefore makes aggregation reduce complexity. I've even = > >>heard someone say that there may be a little bit of "fractal" structure, = > >>but that it is "drowned out" by Gaussian stationary traffic. Anyone who = > >>understood the actual math would be appalled, but computer scientists = > >>*pretend* to be mathematicians for the most part, applying cookbook = > >>formulas and "gut instincts" that they got by solving simple textbook = > >>exercises and watching lectures without questioning assumptions, and = > >>never challenging their professors. > >>> =20 > >>> 40 years ago, there was not so much teachiing of "things that we know = > >>that 'taint so" as the phrase goes. So in that sense, today's computer = > >>scientists have a herd instinct that never questions anything, and = > >>worse, feels completely empowered to disregard those who don't agree = > >>with the consensus, no matter how well they put the alternative forth. > >>> =20 > >>> How else did we end up in a place where nearly every access network = > >>has key links where "bufferbloat" can allow a single person to run an = > >>application that builds up a blockage in either the downlink or the = > >>uplink, creating latencies of 1-4 seconds when the nominal latency is on = > >>the order of < 10 msec and the cross-country latency including all hops = > >>is around 30 msec? Was this "expertise by computer scientists"? = > >>Hardly. It was vastly ramified result of ignorance, not expertise. > >>> =20 > >>> And worse, NO ONE in the community bothers to actually measure the = > >>real Internet in any detail. That would make their publications in = > >>academic journals be suspect, and eliminate the cozy world of = > >>conferences that seem to be more like a mutual admiration society among = > >>an isolated elite. > >>> =20 > >>> So I'm skeptical that there is this wonderful world of computer = > >>scientists that have mastered anything. > >>> =20 > >>> Some people in the community are pretty damn smart. Too few. Most are = > >>mis-employed. > >>> =20 > >>> So, in the case of SDN, I'm pretty sure that the mess will continue to = > >>get worse due precisely to the ease with which SDN enables the blind = > >>deployment of bad ideas, and does not enhance the ability to detect the = > >>effects of bad ideas, measure their problems, and chuck the bad ideas. > >>> =20 > >>> SDN becomes an accelerator of a network Gresham's Law, if that is the = > >>way things go. > >>> =20 > >>> Nonetheless, SDN is a really helpful concept, put in its place - = > >>virtualization can be enormously helpful when it creates a simple = > >>abstraction without "cross-layer optimization". > >>> =20 > >>> And don't get me started on the academic fascination in computer = > >>science with how "great" cross-layer optimizations are. Next we'll have = > >>thousands of papers talking about the wonders of kludges and crocks in = > >>network designs. > >>> =20 > >>>=20 > >>>=20 > >>> On Sunday, April 14, 2013 6:04am, "Jon Crowcroft" = > >> said: > >>>=20 > >>> I think you can look at it a different way - SDN lets you move even = > >>more smarts out of the network into end systems - as far as we implement = > >>it, that looks even less like the ITU than the current = > >>ancient-route-computation/firewall/middlebox ridden IPv4 ossification of = > >>today > >>> so i can see that you could cast SDN in the Wicked Witch of the ITU = > >>role, but equally, I think of it as not being in Kansas anymore.... > >>> cheers > >>> jon > >>>=20 > >>>=20 > >>> On Sat, Apr 13, 2013 at 10:39 PM, John Day = > >>wrote: > >>> Yea, I have seen their stuff too, pretty amusing. about as disruptive = > >>as a speed bump. ;-) > >>>=20 > >>> Actually you have it backwards, we *are* using the reactionary designs = > >>of 40 years ago and that is what is holding things back, rather than the = > >>forward looking designs that were being pursued. > >>>=20 > >>> Those weren't the answer, but it was on the way to the answer, that is = > >>clear now and they would have found it if they had been able to keep = > >>going. > >>>=20 > >>> Things become much simpler once you are out of the ITU model that SDN = > >>and Open Flow are locked into. > >>>=20 > >>> Have fun, > >>> John > >>>=20 > >>>=20 > >>>=20 > >>> At 8:25 PM +0100 4/13/13, Jon Crowcroft wrote: > >>> well i've seen scott shenker do his SDN vision talk a couple of times, > >>> and I know nick mckeown's work pretty well, and I do not think they > >>> are bell heads > >>>=20 > >>> one point is that computer science has grown up slightly since 40+ > >>> years ago, so we are capabile of building way more flexible safe, > >>> secure and performant systems that in the past, when the design > >>> constraints on protocol stacks were set by 1960s ideas of s/w... > >>>=20 > >>> so the stuff out of berkeley, stanford, princeton, gatech etc > >>> in this space is not constrained by the old rules > >>>=20 > >>> it is deconstrained by new capabilities... > >>>=20 > >>> [slightly stolen from John Doyle's cool idea of de-constraining > >>> constraints] > >>>=20 > >>>=20 > >>> so the realpolitik of openflow is (as it was with GSMP) to get arms > >>> length from the legacy router biz, and move the functionality somwhere > >>> where we can do disruptive innovation > >>>=20 > >>> but that is another chapter... > >>>=20 > >>> In missive , John Day typed: > >>>=20 > >>>=20 > >>> >>Jon. > >>> >> > >>> >>Yes, precisely. The first place it shows up is in ISDN, then Frame > >>> >>Relay, ATM, and MPLS. All those CCITT-like connection oriented > >>> >>solutions. And you undoubtedly are correct, it was brought into the > >>> >>Internet by the Europeans where the new model was largely ignored > >>> >>after the suppression of CYCLADES and the completion other early = > >>work > >>> >>such as the Cambridge DS. (As near as I can tell the vast majority > >>> >>of European universities never strayed too far from the traditional > >>> >>ITU model during the 70s to 90s. In fact most of the research still > >>> >>bears a strong mark of it with an Internet veneer.) > >>> >> > >>> >>Yes, it did arrive sometime back and has been a constant source of > >>> >>humor since the ATM lunacy. In fact, this is what makes it so > >>> >>wonderful that OpenFlow and SDN have embraced the ITU world view so > >>> >>completely. The Internet becomes about as anti-Internet as it can > >>> >>get. The Bell-heads have taken over. You have to admit it is = > >>pretty > >>> >>amusing. > >>> >> > >>> >>Take care, > >>> >>John > >>> >> > >>> >> > >>> >>At 12:29 PM +0100 4/13/13, Jon Crowcroft wrote: > >>> >>>so the dogma here was that the business of manageing the net was = > >>just > >>> >>>another distributed system (see the Cambridge Distributed System) > >>> >>>wherre name services, router services, security services were > >>> >>>implemented in exactly the same way as any other distributred = > >>system > >>> >>>(file systems, transaction services, distributed computation = > >>tools)... > >>> >>> > >>> >>>but the control plane model of the net arrived in internet-land = > >>some > >>> >>>time back - for example simon crosby took ideas (this was around = > >>the > >>> >>>time when everyone was trying to do IP over ATM, which morphed into > >>> >>>mpls) from "switchlet" territory with remote computation as > >>> >>>controlplanestechnology... other people, e.g. ipsilon, also took = > >>the > >>>=20 > >>> >>>seperation of concerns that are > >>> >>>forwarding packets as fast as you can, > >>> >>>from > >>> >>>working out where they should and shouldn't go > >>> >>>and put them on different boxes, originally to be coordinated via = > >>the > >>> >>>Generic Switch Management Protocol > >>> >>>later re-discoverd as Software Definted Networkign and Openflow... > >>> >>> > >>> >>>plus ca change... > >>> >>>In missive , John Day typed: > >>>=20 > >>> >>> > >>> >>> >>The whole distinction of data plane and control plane arises = > >>with > >>> >>> >>ISDN. It is a CCITT concept and was never used to describe = > >>anything > >>> >>> >>Internet related, either in the US or Europe. Such distinctions = > >>only > >>> >>> >>make sense in the beads-on-a-string models of the ITU. = > >>Routing, > >>> >>> >>ICMP, DHCP, etc. type functions were characterized as layer > >>> >>> >>management, which can exist to greater or lesser degree in all = > >>layers > >>> >>> >>and must be within the layer owing to the different scopes of = > >>the > >>> >>> >>layers. > >>> >>> >> > >>> >>> >>Take care, > >>> >>> >>John Day > >>> >>> >> > >>> >>> >>> > >>> >>> >>>the post-hoc rationalisation phrase is way too = > >>glib....certainly not > >>> >>> >>>intended to be rude to people that created this cool stuff we = > >>all > >>> >>> >>>use - in fact i was conflating three things > >>> >>> >>> > >>> >>> >>>1. a bunch of work fairly recently on optimal protocols and = > >>narrow > >>> >>> >>>waist of the hour glass... > >>> >>> >>>2. the ordering of constrints on the design of the internet > >>> >>> >>>protocols (as per dave clarks 88 paper) > >>> >>> >>>and > >>> >>> >>>3. the apparent simplicity of IP - my missing point was that = > >>the > >>> >>> >>>complexity pops out somewhere, and that place is in the = > >>control > >>> >>> >>>plane....as we've since disovered... > >>> >>> >>> > >>> >>> >>>of course, there were people that ran dynamic distributed = > >>routing > >>> >>> >>>for VC networks (X.25 for example - we had switches in the = > >>JANET > >>> >>> >>>network that did this) so they were even more complex in both = > >>data > >>> >>> >>>and control plane (what with crankback etc etc:) > >>> >>> >>> > >>> >>> >>>so yes, a bit glib really...sorry > >>> >>> >>> > >>> >>> >>>normal service will be resumed as soon as I get my IPTV QoS = > >>back :) > >>> >>> >>> > >>> >>> >>>j. > >>> >>> >>> > >>> >>> >>> > >>> >>> >>>On Fri, Apr 12, 2013 at 3:07 PM, Fred Baker (fred) > >>> >>> >>><fre d at cisco.com> wrote: > >>> >>> >>> > >>> >>> >>>I'd suggest running the assertion by Vint. I made a similar > >>> >>> >>>assertion in a document not too long ago, which I ran by him = > >>for > >>> >>> >>>comment, and he told me I was flatly wrong. Yes, the circuit = > >>switch > >>> >>> >>>folks were using the term "catenet" to refer to networks that > >>> >>> >>>interoperated through translation, such as frame relay/ATM > >>> >>> >>>interoperation, he asserted, but at least some (he?) was using = > >>the > >>> >>> >>>term "Internet" as early as the mid 1970's. > >>> >>> >>> > >>> >>> >>> > >>> >>> >>>On Apr 11, 2013, at 8:59 PM, Dave Crocker > >>> >>> >>><dhc2 at dcrocker.net> wrote: > >>> >>> >>> > >>> >>> >>>> This is a risky query. There have been previous threads = > >>about > >>> >>> >>>>such things as the "start" of the Internet. Instead, I want = > >>to ask > >>> >>> >>>>about the "architecture" of the Internet. > >>> >>> >>>> > >>> >>> >>>> Here's a comment that I sent earlier today, to a = > >>non-technical > >>> >>> >>>>person who is aware of the overall Internet timeline, but I = > >>believe > >>> >>> >>>>does not understand what is distinctive about Internet > >>> >>> >>>>'architecture'. I'm curious about reactions on this list, = > >>and any > >>> >>> >>>>possible improvements -- including complete replacement -- = > >>but more > >>> >>> >>>>importantly I'm interested in filling in the details: > >>> >>> >>> > > >>> >>> >>>> The original use of the term Internet was to describe a > >>> >>> >>>>distinctive technical design for a distributed, scalable data > >>> >>> >>>>exchange fabric. Its design characteristics differ = > >>dramatically > >>> >>> >>>>from those of its predecessor, the Arpanet, and from other = > >>related > >>> >>> >>>>efforts. > >>> >>> >>>> > >>> >>> >>>> That's what I sent. To prime the pump for the detail: > >>> >>> >>>> > >>> >>> >>>> By saying 'fabric' I meant to distinguish the mechanism = > >>for > >>> >>> >>>>moving raw data from the applications that used it. What I'd = > >>class > >>> >>> >>>>as distinctive were the TCP/IP separation, the remarkably = > >>modest > >>> >>> >>>>functionality of IP, even to the point of moving it's control = > >>plane > >>> >>> >>>>to the next level up with ICMP, and continuing with modest > >>> >>> >>>>expectations the layer below (which made it possible to = > >>operate > >>> >>> >>>>over any medium including birds.) This is usually = > >>characterized as > >>> >>> >>>>moving robustness to the edges. > >>> >>> >>>> > >>> >>> >>>> > >>> >>> >>>> Thoughts? > >>> >>> >>>> > >>> >>> >>>> d/ > >>> >>> >>>> > >>> >>> >>>> -- > >>> >>> >>>> Dave Crocker > >>> >>> >>>> Brandenburg InternetWorking > >>> >>> >>>> bbiw.net > >>> >>> >> > >>> >>> >>>--=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D_-846339397=3D=3D_ma=3D=3D=3D= > >>=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>> >>> >>Content-Type: text/html; charset=3D"us-ascii" > >>> >>> >> > >>> >>> >> > >>> >>> >>Re: [e2e] Internet > >>> >>> >>"architecture" > >>> >>> >>
This is a can of worms, but. . .
> >>> >>> >>

> >>> >>> >>
At 4:23 PM +0200 4/12/13, Jon Crowcroft wrote:
> >>> >>> >>
the folks who called it catenet = > >>included > >>> >>> >>bob braden who was working at UCL when i was there - of course, = > >>we > >>> >>> >>were concatenating networks that ran other protocols (Cambridge = > >>Ring, > >>> >>> >>X.25 (transport layer relays) and so on...so perhaps I'm = > >>conflating > >>> >>> >>two things - the interconnection of multiple disprate protocol > >>> >>> >>systems, and the IP interconenction of multiple IP networks = > >>with > >>> >>> >>disparete layer 2 and below....
> >>> >>> >>

> >>> >>> >>
Early on the term catenet was applied without respect to > >>> >>> >>connection or connectionless, but only with respect to = > >>forwarding vs. > >>> >>> >>translation (if necessary).
> >>> >>> >>

> >>> >>> >>

> >>> >>> >>
it is the case (as some other = > >>folks > >>> >>> >>privately pointed out to me) that IENs (including IEN 1 written = > >>at > >>> >>> >>UCL) are Internet Experiment Notes, and go back to mid 1970s, = > >>so i'm > >>> >>> >>wrong to say "internet"
> >>> >>> >>

> >>> >>> >>
however, my point about = > >>parsimony is > >>> >>> >>really over compressed - IP trades off simplicity in the data = > >>plane, > >>> >>> >>for complexity in the control plane - its not a pure trade off = > >>(it can > >>> >>> >>be seen partly as a win-win, as signaling protocols for VC = > >>networks > >>> >>> >>can be nearly as complex (or in X.25 and B-ISDN's Q.2931's = > >>cases, more > >>> >>> >>complex) as routing protocols....nevertheless, getting routing = > >>right > >>> >>> >>and all associated components is seriously non-trivial - other = > >>systems > >>> >>> >>(the aforesaid cambridge ring protocol stack) represent a = > >>different > >>> >>> >>trade off that is also quite elegant.
> >>> >>> >>

> >>> >>> >>
The whole distinction of data plane and control plane = > >>arises with > >>> >>> >>ISDN. It is a CCITT concept and was never used to describe = > >>anything > >>> >>> >>Internet related, either in the US or Europe. Such distinctions = > >>only > >>> >>> >>make sense in the beads-on-a-string models of the ITU.  = > >>Routing, > >>> >>> >>ICMP, DHCP, etc. type functions were characterized as layer > >>> >>> >>management, which can exist to greater or lesser degree in all = > >>layers > >>> >>> >>and must be within the layer owing to the different scopes of = > >>the > >>> >>> >>layers.
> >>> >>> >>

> >>> >>> >>
Take care,
> >>> >>> >>
John Day
> >>> >>> >>

> >>> >>> >>

> >>> >>> >>
the post-hoc rationalisation = > >>phrase is > >>> >>> >>way too glib....certainly not intended to be rude to people = > >>that > >>> >>> >>created this cool stuff we all use - in fact i was conflating = > >>three > >>> >>> >>things
> >>> >>> >>

> >>> >>> >>
1. a bunch of work fairly = > >>recently on > >>> >>> >>optimal protocols and narrow waist of the hour = > >>glass...
> >>> >>> >>
2. the ordering of constrints on = > >>the > >>> >>> >>design of the internet protocols (as per dave clarks 88 > >>> >>> >>paper)
> >>> >>> >>
and
> >>> >>> >>
3. the apparent simplicity of IP = > >>- my > >>> >>> >>missing point was that the complexity pops out somewhere, and = > >>that > >>> >>> >>place is in the control plane....as we've since > >>> >>> >>disovered...
> >>> >>> >>

> >>> >>> >>
of course, there were people = > >>that ran > >>> >>> >>dynamic distributed routing for VC networks (X.25 for example - = > >>we had > >>> >>> >>switches in the JANET network that did this) so they were even = > >>more > >>> >>> >>complex in both data and control plane (what with crankback etc > >>> >>> >>etc:)
> >>> >>> >>

> >>> >>> >>
so yes, a bit glib > >>> >>> >>really...sorry
> >>> >>> >>

> >>> >>> >>
normal service will be resumed = > >>as soon as > >>> >>> >>I get my IPTV QoS back :)
> >>> >>> >>

> >>> >>> >>
j.
> >>> >>> >>

> >>> >>> >>
> >>> >>> >>
> >>> >>> >>
On Fri, Apr 12, 2013 at 3:07 PM, = > >>Fred > >>> >>> >>Baker (fred) < >>href=3D"mailto:fred at cisco.com">fred at cisco.com> > >>> >>> >>wrote:
> >>> >>> >>
I'd suggest running the assertion by Vint. I made a > >>> >>> >>similar assertion in a document not too long ago, which I ran = > >>by him > >>> >>> >>for comment, and he told me I was flatly wrong. Yes, the = > >>circuit > >>> >>> >>switch folks were using the term "catenet" to refer = > >>to > >>> >>> >>networks that interoperated through translation, such as frame > >>> >>> >>relay/ATM interoperation, he asserted, but at least some (he?) = > >>was > >>> >>> >>using the term "Internet" as early as the mid = > >>1970's.
> >>> >>> >>
> >>> >>> >>

> >>> >>> >>On Apr 11, 2013, at 8:59 PM, Dave Crocker < >>> >>> >>href=3D"mailto:dhc2 at dcrocker.net">dhc2 at dcrocker.net> = > >>wrote:
> >>> >>> >>
> >>> >>> >>> This is a risky query.  There have been previous = > >>threads > >>> >>> >>about such things as the "start" of the Internet. > >>> >>> >> Instead, I want to ask about the "architecture" = > >>of the > >>> >>> >>Internet.
> >>> >>> >>>
> >>> >>> >>> Here's a comment that I sent earlier today, to a = > >>non-technical > >>> >>> >>person who is aware of the overall Internet timeline, but I = > >>believe > >>> >>> >>does not understand what is distinctive about Internet = > >>'architecture'. > >>> >>> >> I'm curious about reactions on this list, and any = > >>possible > >>> >>> >>improvements -- including complete replacement -- but more = > >>importantly > >>> >>> >>I'm interested in filling in the details:
> >>> >>> >>
>
> >>> >>> >>>     The original use of the term = > >>Internet was > >>> >>> >>to describe a distinctive technical design for a distributed, = > >>scalable > >>> >>> >>data exchange fabric.  Its design characteristics differ > >>> >>> >>dramatically from those of its predecessor, the Arpanet, and = > >>from > >>> >>> >>other related efforts.
> >>> >>> >>>
> >>> >>> >>> That's what I sent.  To prime the pump for the = > >>detail:
> >>> >>> >>>
> >>> >>> >>>     By saying 'fabric' I meant to = > >>distinguish > >>> >>> >>the mechanism for moving raw data from the applications that = > >>used it. > >>> >>> >> What I'd class as distinctive were the TCP/IP separation, = > >>the > >>> >>> >>remarkably modest functionality of IP, even to the point of = > >>moving > >>> >>> >>it's control plane to the next level up with ICMP, and = > >>continuing with > >>> >>> >>modest expectations the layer below (which made it possible to = > >>operate > >>> >>> >>over any medium including birds.)  This is usually = > >>characterized > >>> >>> >>as moving robustness to the edges.
> >>> >>> >>>
> >>> >>> >>>
> >>> >>> >>> Thoughts?
> >>> >>> >>>
> >>> >>> >>> d/
> >>> >>> >>>
> >>> >>> >>> --
> >>> >>> >>> Dave Crocker
> >>> >>> >>> Brandenburg InternetWorking
> >>> >>> >>> bbiw.net
> >>> >>> >>
> >>> >>> >>

> >>> >>> >> > >>> >>> >> > >>> >>> >>>--=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D_-846339397=3D=3D_ma=3D=3D=3D= > >>=3D=3D=3D=3D=3D=3D=3D=3D=3D-- > >>> >>> > >>> >>> cheers > >>> >>> > >>> >>> jon > >>> >> > >>>=20 > >>> cheers > >>>=20 > >>> jon > >>>=20 > >> > > cheers > > jon From dhc2 at dcrocker.net Mon Apr 15 06:38:01 2013 From: dhc2 at dcrocker.net (Dave Crocker) Date: Mon, 15 Apr 2013 06:38:01 -0700 Subject: [e2e] Internet "architecture" In-Reply-To: References: <20130414203531.5D10818C105@mercury.lcs.mit.edu> Message-ID: <516C02B9.9030400@dcrocker.net> On 4/14/2013 11:17 PM, Jon Crowcroft wrote: > that's pretty much how i'd use it too (having spent 30 years meeting > people who design styles of construction of living spaces, but dont > often actually build buildings, i'm stuck with the le courbusier, gaudi, > foster, rogers, gehry meaning:) > > On Sun, Apr 14, 2013 at 11:07 PM, John Day > wrote: > > I basically use the dictionary definition of "a style of > construction." The important distinction being between an > architecture and buildings built to that architecture. Though I'm now finding the wording painfully awkward, here's what I used to explain the word, for the Email Architecture RFC: An architecture specifies how the protocols implement the service by defining the logical components of a service and the relationships among them. From that logical view, a service defines what is being done, an architecture defines where the pieces are (in relation to each other), and a protocol defines how particular capabilities are performed. That is, I'm finding the concept useful for defining components, structure and relationships, and mostly I try to stay away from more abstract or conceptual views of architecture, lest discussion get lost in labels of unclear meaning. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From christian.tschudin at unibas.ch Mon Apr 15 09:25:40 2013 From: christian.tschudin at unibas.ch (christian.tschudin@unibas.ch) Date: Mon, 15 Apr 2013 18:25:40 +0200 (CEST) Subject: [e2e] Internet "architecture" In-Reply-To: References: <20130414203531.5D10818C105@mercury.lcs.mit.edu> Message-ID: With everbody talking about architectures in plural, your "style of construction" definition could be misunderstood that net arch has more to do with personal preferences or artistic trait rather than science. But the nice part is that it says: architecture is here even if the engineer is not aware of it. Which is quite true for the Internet or SDN where we (still) try to understand what is going on, and at which level: is it a masterplan (or meta-architecture, ? la Hausmann's plan for Paris)? is it a set of concepts (layering, e2e, CO/CL, globally unique addr) is it a set of mechanisms (TCP plus IP, OF)? The meta-architecture discussion is interesting: why for example the Internet fails to be one, that there aren't more radical approaches to this than AN, or whether a meta-arch at the end is a set of mechanisms ? la ANA, RNA or SDN. In 2009 I helped organize the netarch2009.net symposium, currently I'm pondering to have a follow up event 5 years later. Writing this up is just another way of saying: yes, we should. best, christian On Mon, 15 Apr 2013, John Day wrote: > I basically use the dictionary definition of "a style of construction." The > important distinction being between an architecture and buildings built to > that architecture. (I don't remember what dictionary I found that in. It > was 30 years ago.) > > I would say that 90% of the usage in the field refers buildings, rather than > *architectures.* > > For example, the 7-layer OSI model is a building, not an architecture. > > Take care, > John > > At 4:35 PM -0400 4/14/13, Noel Chiappa wrote: >> > From: Jon Crowcroft >> >> > architecure remains as hard as ever >> >> I'm interested to know what 'architecture' means to you both; I know what >> _I_ mean by the term, but I'm not sure the field as a whole has a >> consistent, >> well-understood meaning, yet. >> >> Noel > > From jnc at mercury.lcs.mit.edu Mon Apr 15 11:40:56 2013 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 15 Apr 2013 14:40:56 -0400 (EDT) Subject: [e2e] Internet "architecture" Message-ID: <20130415184056.189FD18C12B@mercury.lcs.mit.edu> > From: John Day Well, I see that we are indeed, as suspected, all over the place on the meaning of the term. (I'll give mine below, along with some thoughts provoked by this dicsussion.) I'm not sure we can reach agreement on a meaning, but I so think it was/is useful to bring out just how 'undefined' this term is. > I basically use the dictionary definition of "a style of construction". > The important distinction being between an architecture and buildings > built to that architecture. I'm going to diagree with this one a bit, because I think one can speak of 'the architecture of "Fallingwater"' as well as 'the architecture of FLLW' - although I would use the term 'architectural style of FLLW', reserving the singular term for i) specific instances, and ii) the field itself. So Wright's 'architectural style' would include such features as greater integration of the building and the setting (both from an external viewpoint, as well as from an internal one); greater integration of the interior spaces (large openings between major spaces); etc. But that's a style, and some of his buildings have aspects which are only in a very few of his buildings (e.g. cantilevering), but are part of their 'architecture'. So I would continue to make what I think is a useful distinction, between an overall style, and the 'architecture' of a particular instance. To me, in the information systems area, the 'architecture' of a particular system has three main aspects: i) The overall form of the system, i.e. the service model it presents to its users. This may be viewed as a 'requirements list', but in good architectures, I think this goes beyond mere requirements (which are often transitory), into something deeper: I have this aphorism that: "The hallmark of great architecture is not how well it does the things it was designed to do, but how well it does things it was never expected to handle." which is speaking of things that are, in some sense, explicitly outside any list of requirements that were known at the time it was drawn up. ii) The classes of objects in the system, their properties, etc; and the classes of names (and their properties, how they apply to the objects, and how they inter-relate to each other) for those objects. iii) How a system is broken up into pieces; where the functionality boundaries are, and how, when and what information is passed over the interfaces among the pieces. I was pondering the difference between 'architecture' and 'engineering', and I'm not sure there'a a hard and fast line between the two. I think it's more of a spectrum, and while many things are clearly at one end, or the other, sometimes you get into some gray. For instance, in TCP/IP, the notion that the hosts are responsible for retransmissions is clearly (to me, at least :-) 'architectural', whereas the specific algorithm used is 'engineering', and those both seem pretty clearly to be at one end or the other. But I suspect there are things which aren't so clear (although my brain is working a bit slowly today, and can't cough one up on demand). Noel From jeanjour at comcast.net Mon Apr 15 11:54:53 2013 From: jeanjour at comcast.net (John Day) Date: Mon, 15 Apr 2013 14:54:53 -0400 Subject: [e2e] Internet "architecture" In-Reply-To: References: <20130414203531.5D10818C105@mercury.lcs.mit.edu> Message-ID: At 6:25 PM +0200 4/15/13, christian.tschudin at unibas.ch wrote: >With everbody talking about architectures in >plural, your "style of construction" definition >could be misunderstood that net arch has more to >do with personal preferences or artistic trait >rather than science. There are many methods of generating an architecture. The definition I quoted was of course referring to buildings, etc. My own approach has always been firmly rooted in science as opposed to natural history. > >But the nice part is that it says: architecture >is here even if the engineer is not aware of it. Yes, I have referred to some as Karnack architectures, but Johnny Carson has probably been gone too long for that to be meaningful. Take care, John > >Which is quite true for the Internet or SDN >where we (still) try to understand what is going >on, and at which level: > > is it a masterplan (or meta-architecture, ? la Hausmann's plan for Paris)? > is it a set of concepts (layering, e2e, CO/CL, globally unique addr) > is it a set of mechanisms (TCP plus IP, OF)? > >The meta-architecture discussion is interesting: >why for example the Internet fails to be one, >that there aren't more radical approaches to >this than AN, or whether a meta-arch at the end >is a set of mechanisms ? la ANA, RNA or SDN. > >In 2009 I helped organize the netarch2009.net >symposium, currently I'm pondering to have a >follow up event 5 years later. Writing this up >is just another way of saying: yes, we should. > >best, christian > > >On Mon, 15 Apr 2013, John Day wrote: > >>I basically use the dictionary definition of "a >>style of construction." The important >>distinction being between an architecture and >>buildings built to that architecture. (I don't >>remember what dictionary I found that in. It >>was 30 years ago.) >> >>I would say that 90% of the usage in the field >>refers buildings, rather than *architectures.* >> >>For example, the 7-layer OSI model is a building, not an architecture. >> >>Take care, >>John >> >>At 4:35 PM -0400 4/14/13, Noel Chiappa wrote: >>> > From: Jon Crowcroft >>> >>> > architecure remains as hard as ever >>> >>>I'm interested to know what 'architecture' means to you both; I know what >>>_I_ mean by the term, but I'm not sure the >>>field as a whole has a consistent, >>>well-understood meaning, yet. >>> >>> Noel From jon.crowcroft at cl.cam.ac.uk Tue Apr 16 00:20:36 2013 From: jon.crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Tue, 16 Apr 2013 08:20:36 +0100 Subject: [e2e] Internet "architecture" In-Reply-To: <1366071641.379610195@apps.rackspace.com> References: <20130414203531.5D10818C105@mercury.lcs.mit.edu> <1366071641.379610195@apps.rackspace.com> Message-ID: i like colin cherry's book on human communication + dunbar's Gossip, Grooming and the evolution of language plus bateson's steps towards an ecology of mind, and possibly even Lakhoff's women fire and dangerous things (if you want intutionist stuff on category theory) recent stuff on graphs (Christakis and Fowler's connected is nice and accessible but you probably want something that covers resilience as well as cascades) cheers jon (p..s 2ndary purpose of this email to the list is to get dave's list of v. useful references to others on e2e] On Tue, Apr 16, 2013 at 1:20 AM, wrote: > As a series of references, I would suggest David Parnas's famous paper on > modularization, Butler Lampson's famous paper on layering in operating > systems, and Herbert Simon's famous book: The Sciences of the Artificial. > Also, Donald Schon's book entitled The Reflective Practitioner (which talks > about the process of folks like engineers, lawyers, doctors, etc. in > defining their field), and the well known book about building architecture > "A Pattern Language" by Chris Alexander, who created the idea of "design > patterns" that now has been adopted by software designers. > > > > [Please note that this will not actually get delivered to the e2e list, as > I am permanently blocked from posting there by Joe Touch] > > > > > > On Monday, April 15, 2013 2:54pm, "John Day" said: > > > At 6:25 PM +0200 4/15/13, christian.tschudin at unibas.ch wrote: > > >With everbody talking about architectures in > > >plural, your "style of construction" definition > > >could be misunderstood that net arch has more to > > >do with personal preferences or artistic trait > > >rather than science. > > > > There are many methods of generating an > > architecture. The definition I quoted was of > > course referring to buildings, etc. > > > > My own approach has always been firmly rooted in > > science as opposed to natural history. > > > > > > > >But the nice part is that it says: architecture > > >is here even if the engineer is not aware of it. > > > > Yes, I have referred to some as Karnack > > architectures, but Johnny Carson has probably > > been gone too long for that to be meaningful. > > > > Take care, > > John > > > > > > > >Which is quite true for the Internet or SDN > > >where we (still) try to understand what is going > > >on, and at which level: > > > > > > is it a masterplan (or meta-architecture, ? la Hausmann's plan for > > Paris)? > > > is it a set of concepts (layering, e2e, CO/CL, globally unique addr) > > > is it a set of mechanisms (TCP plus IP, OF)? > > > > > >The meta-architecture discussion is interesting: > > >why for example the Internet fails to be one, > > >that there aren't more radical approaches to > > >this than AN, or whether a meta-arch at the end > > >is a set of mechanisms ? la ANA, RNA or SDN. > > > > > >In 2009 I helped organize the netarch2009.net > > >symposium, currently I'm pondering to have a > > >follow up event 5 years later. Writing this up > > >is just another way of saying: yes, we should. > > > > > >best, christian > > > > > > > > >On Mon, 15 Apr 2013, John Day wrote: > > > > > >>I basically use the dictionary definition of "a > > >>style of construction." The important > > >>distinction being between an architecture and > > >>buildings built to that architecture. (I don't > > >>remember what dictionary I found that in. It > > >>was 30 years ago.) > > >> > > >>I would say that 90% of the usage in the field > > >>refers buildings, rather than *architectures.* > > >> > > >>For example, the 7-layer OSI model is a building, not an architecture. > > >> > > >>Take care, > > >>John > > >> > > >>At 4:35 PM -0400 4/14/13, Noel Chiappa wrote: > > >>> > From: Jon Crowcroft > > >>> > > >>> > architecure remains as hard as ever > > >>> > > >>>I'm interested to know what 'architecture' means to you both; I know > > what > > >>>_I_ mean by the term, but I'm not sure the > > >>>field as a whole has a consistent, > > >>>well-understood meaning, yet. > > >>> > > >>> Noel > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20130416/f88007bd/attachment.html From detlef.bosau at web.de Tue Apr 16 05:38:39 2013 From: detlef.bosau at web.de (Detlef Bosau) Date: Tue, 16 Apr 2013 14:38:39 +0200 Subject: [e2e] VJCC vs. Keshav Message-ID: <516D464F.7090006@web.de> I'm curious, why the proposal by Keshav (his PhD thesis on Internet Congestion Control) was not widely adopted but VJCC instead. The main difference is that VJCC is purely end to end, while Keshav proposes schedulers on each node. Was this decision made for scalability reasons? -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From Jon.Crowcroft at cl.cam.ac.uk Tue Apr 16 06:18:24 2013 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Tue, 16 Apr 2013 14:18:24 +0100 Subject: [e2e] VJCC vs. Keshav In-Reply-To: <516D464F.7090006@web.de> References: <516D464F.7090006@web.de> Message-ID: In missive <516D464F.7090006 at web.de>, Detlef Bosau typed: >>I'm curious, why the proposal by Keshav (his PhD thesis on Internet >>Congestion Control) was not widely adopted but VJCC instead. >>The main difference is that VJCC is purely end to end, while Keshav >>proposes schedulers on each node. >>Was this decision made for scalability reasons? "half" the deployment complexity: keshav's thesis involves changing all routers & all hosts all routers have to do RR instead of FIFO all hosts have to do packet pair VJ's scheme just involved hosts downloading the BSD TCP update or cloning it for irix and the other 2.5 OSs that had m/cs on the internet in 87/88 was a bit easier, plus this is 5 years before prime time commercial ISPs, so you had a chance to run experimental transport but still had to be Cisco if you wanted to run experimental forwarding/scheduling at scale... cheers jon From detlef.bosau at web.de Tue Apr 16 06:55:48 2013 From: detlef.bosau at web.de (Detlef Bosau) Date: Tue, 16 Apr 2013 15:55:48 +0200 Subject: [e2e] VJCC vs. Keshav In-Reply-To: References: <516D464F.7090006@web.de> Message-ID: <516D5864.9070307@web.de> Am 16.04.2013 15:18, schrieb Jon Crowcroft: > "half" the deployment complexity: > > keshav's thesis involves changing all routers & all hosts > all routers have to do RR instead of FIFO > all hosts have to do packet pair > > VJ's scheme just involved hosts > downloading the BSD TCP update or cloning it for > irix and the other 2.5 OSs that had m/cs on the internet in 87/88 > was a bit easier, plus this is 5 years before prime time > commercial ISPs, so you had a chance to run experimental transport > but still had to be Cisco if you wanted to run experimental > forwarding/scheduling at scale... > > cheers > > jon > O.k., these are practical reasons. Are there, however, structural, scientific ones as well? -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From jeanjour at comcast.net Tue Apr 16 07:28:52 2013 From: jeanjour at comcast.net (John Day) Date: Tue, 16 Apr 2013 10:28:52 -0400 Subject: [e2e] VJCC vs. Keshav In-Reply-To: References: <516D464F.7090006@web.de> Message-ID: > >VJ's scheme just involved hosts > downloading the BSD TCP update or cloning it for > irix and the other 2.5 OSs that had m/cs on the internet in 87/88 > was a bit easier, plus this is 5 years before prime time > commercial ISPs, so you had a chance to run experimental transport > but still had to be Cisco if you wanted to run experimental > forwarding/scheduling at scale... So that solution was picked because they expected the experimental stage to last far longer than the operational use? Interesting. From emmanuel.lochin at isae.fr Tue Apr 16 07:33:44 2013 From: emmanuel.lochin at isae.fr (Emmanuel Lochin) Date: Tue, 16 Apr 2013 16:33:44 +0200 Subject: [e2e] VJCC vs. Keshav In-Reply-To: <516D464F.7090006@web.de> References: <516D464F.7090006@web.de> Message-ID: <516D6148.3030107@isae.fr> Hi Detlef, I think this is a deployment problem. XCP would be a better solution too but the deployment is complex. Emmanuel On 16/04/2013 14:38, Detlef Bosau wrote: > I'm curious, why the proposal by Keshav (his PhD thesis on Internet > Congestion Control) was not widely adopted but VJCC instead. > > The main difference is that VJCC is purely end to end, while Keshav > proposes schedulers on each node. > > Was this decision made for scalability reasons? > -- Emmanuel Lochin Professeur ISAE - OSSI Institut Sup?rieur de l'A?ronautique et de l'Espace (ISAE) Issu du rapprochement SUPAERO et ENSICA 10 avenue Edouard Belin - BP 54032 - 31055 Toulouse cedex 4 Tel : 05 61 33 91 85 - Fax : 05 61 33 91 88 Web : http://personnel.isae.fr/emmanuel-lochin/ --- "This email and any attachments are confidential. They may contain legally privileged information or copyright material. You should not read, copy, use or disclose them without authorisation. If you are not an intended recipient, please contact us at once by return email and then delete both messages. We do not accept liability in connection with computer virus, data corruption, delay, interruption, unauthorised access or unauthorised amendment. This notice should not be removed" From rik at rikwade.com Tue Apr 16 19:16:12 2013 From: rik at rikwade.com (Richard Wade) Date: Wed, 17 Apr 2013 09:16:12 +0700 Subject: [e2e] VJCC vs. Keshav In-Reply-To: <516D5864.9070307@web.de> References: <516D464F.7090006@web.de> <516D5864.9070307@web.de> Message-ID: On 16 April 2013 20:55, Detlef Bosau wrote: > O.k., these are practical reasons. > > Are there, however, structural, scientific ones as well? I did quite a bit of work in ns-2 and other tools with Keshav's Packet Pair techniques when I was looking at potential improvements to Slow Start and steady state reliable transport performance. I only had the time to do simulation work, but in my experience, the Packet Pair (Packet Train actually, as I achieved more accurate and reliable results from using a number of packets in the initial probe) provided an efficient (in terms of time to steady state) and accurate (in terms of setting an appropriate initial transfer rate for the session) estimation of the available bandwidth on a path. While I understand the theoretical requirements for scheduling changes in intermediate routers, my simulations indicated that this technique provided a "good enough" "finger-in-the-air" estimation of available bandwidth on a path. However, I never got the time/opportunity to do live network tests. -- r -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20130417/b14ed70b/attachment.html From szz at cs.nott.ac.uk Mon Apr 15 15:21:29 2013 From: szz at cs.nott.ac.uk (Sameh R A Zakhary) Date: Mon, 15 Apr 2013 23:21:29 +0100 Subject: [e2e] MoWNet 2013 - April 30 - Third International Conference on Selected Topics in Mobile & Wireless Networking Message-ID: <516C7D69.2010204@cs.nott.ac.uk> [Apologies if you receive multiple copies of this message] ------ ========================================================== CALL FOR PAPERS ****************************************************************** Third International Conference on Selected Topics in Mobile & Wireless Networking (MoWNet 2013) August 19-21, 2013, Montreal, Canada http://www.mownet.org/ -- Technical co-Sponsorship of IEEE and IEEE Communications Society: http://www.ieee.org/conferences_events/conferences/conferencedetails/index.html?Conf_ID=31068 -- Proceedings will be published with IEEE Xplore. -- Special issue of journals: http://mownet.org/news.html ****************************************************************** SCOPE The Third International Conference on Selected Topics in Mobile & Wireless Networking (MoWNet'2013) will be held in Montreal, Canada. It follows two editions of iCOST 2011 and 2012 which were held in Shanghai - China and Avignon - France, respectively. The ever increasing market penetration of smart-phones, tablets, and netbooks, along with the ubiquitous availability of wireless networks are deeply influencing the way people live, work, interact, and socialize. However, the broad popularity and diffusion of innovative services and applications tailored at mobile users is also raising challenging research issues that require us to rethink available mobile technology solutions to meet the emerging needs of a broader and ever growing user base. MoWNet'2013 aims at addressing recent research results on selected topics in Mobile & Wireless Networking and to present their methodologies, models, technologies, systems, tools, applications, work in progress and experiences. Suggested topics include but are not restricted to: - Cloud computing support for mobile services and applications - Data center architectures and protocols - Green communications models, architectures, and networking solutions - Self-* networks, services and applications - Content distribution networks - Social networking solutions for pervasive and mobile environments - Vehicular communications and vehicular ad-hoc networks - Wireless-enabled Peer to Peer services and applications - Internet of Things - Machine type communications - Context-aware middleware design, services and applications - Long Term Evolution Engineering and Femtocells - Emerging topics in wireless and mobile computing and communications - Security, trust, and privacy in wireless/mobile communications - Heterogeneous networks - Communication networks and architectures for smart grids - Resource allocation and interference management in Smart Grid networks IMPORTANT DATES Submission of papers: April 30, 2013 Notification to authors: May 30, 2013 Camera ready copies: June 20, 2013 INSTRUCTIONS FOR PAPER SUBMISSION Authors are required to submit fully formatted, original papers (PDF), with graphs, images, and other special areas arranged as intended for the final publication. Papers should be written in English conforming to the IEEE standard conference format (8.5" x 11" - US letter, Two-Column). The initial submission for review will be limited to 6 pages. The final manuscript for publication will be limited to 6 IEEE pages. Additional charges may apply for additional pages with the limit of 8 pages. The conference proceedings will be indexed and archived through IEEExplore. Each accepted paper must be presented at the conference by one of the co-authors or a third party. Only timely submissions through EDAS at http://edas.info will be accepted. For more details, please visit the MoWNet'2013 official website ( http://www.mownet.org/ ). Facebook page for MoWNet 2013: http://www.facebook.com/pages/MoWNet-2013/376726545744553 From detlef.bosau at web.de Wed Apr 17 11:59:15 2013 From: detlef.bosau at web.de (Detlef Bosau) Date: Wed, 17 Apr 2013 20:59:15 +0200 Subject: [e2e] VJCC vs. Keshav In-Reply-To: <1366205545.911620165@apps.rackspace.com> References: <516D464F.7090006@web.de> <516D5864.9070307@web.de> <1366205545.911620165@apps.rackspace.com> Message-ID: <516EF103.1030300@web.de> It's however not really surprising that packet pair techniques and the like yield exactly the result, which was implemented in the NS2 code. That's a proof by repeated assertion. -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From Jon.Crowcroft at cl.cam.ac.uk Wed Apr 17 13:54:17 2013 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Wed, 17 Apr 2013 21:54:17 +0100 Subject: [e2e] VJCC vs. Keshav In-Reply-To: <516EF103.1030300@web.de> References: <516D464F.7090006@web.de> <516D5864.9070307@web.de> <1366205545.911620165@apps.rackspace.com> <516EF103.1030300@web.de> Message-ID: more history 1. keshav wrote his own simulator (a variant maybe of the mit x sim system) 2. other people verified fq results in other simulators 3. some people have implemented lots of variants of fq and packet probe pair/trains as well maybe you could read the source materials properly, rather than just snippets of this maillist... that's what we call "peer review" In missive <516EF103.1030300 at web.de>, Detlef Bosau typed: >>It's however not really surprising that packet pair techniques and the=20 >>like yield exactly the result, which was implemented in the NS2 code. >> >> >>That's a proof by repeated assertion. >> >>--=20 >>------------------------------------------------------------------ >>Detlef Bosau >>Galileistra=C3=9Fe 30 >>70565 Stuttgart Tel.: +49 711 5208031 >> mobile: +49 172 6819937 >> skype: detlef.bosau >> ICQ: 566129673 >>detlef.bosau at web.de http://www.detlef-bosau.de >> cheers jon From detlef.bosau at web.de Thu Apr 18 02:20:02 2013 From: detlef.bosau at web.de (Detlef Bosau) Date: Thu, 18 Apr 2013 11:20:02 +0200 Subject: [e2e] VJCC vs. Keshav In-Reply-To: References: <516D464F.7090006@web.de> <516D5864.9070307@web.de> <1366205545.911620165@apps.rackspace.com> <516EF103.1030300@web.de> Message-ID: <516FBAC2.3020603@web.de> Am 17.04.2013 22:54, schrieb Jon Crowcroft: > more history > 1. keshav wrote his own simulator (a variant maybe of the mit x sim > system) t so did I, although the thing is not published. And of course, I did not reinvent the wheel but used concepts known from the ns 2. > 2. other people verified fq results in other simulators > 3. some people have implemented lots of variants of fq and packet > probe pair/trains as well > > maybe you could read the source materials properly, > rather than just snippets of this maillist... Jon, I did. So, there is no need to blame me here. However: When you look at the source material, particularly the program sources of simulators, you become aware of quite some simplifications frequently made. That's why I made a critical remark on "packet pair" techniques and the ns2. Simply and frankly spoken: Proving packet pair techniques with a simulator proves absolutely nothing. Because the program code in the simulator is nothing else than the system model used in the papers. E.g. in the ns2 you have some kind of "bandwidth" and a serialization delay which packet size / bandwidth. Fine. Now, you send a number of packets, this needs a (cumulative) serialization delay = Sum over all packets (packet length/Bandwidth) and this is divided by the cumulative packet length - and renders what? Exactly. And because each and any simulator uses the same approach, they prove each other. Unfortunately, these nasty CSMA/CD Ethernets or these disgusting CSMA/CA WLANs or these horrible mobile networks dare not always to behave simulator compliant.... Simulators are nice. However they are, to a certain degree, GIGO systems. (GIGO: Garbage In, Garbage Out.) This is not to criticize simulators, but to be aware of their limitations. How do we simulate CSMA/CD Ethernets with all gory details? I really don't know if this is possible at all. Keeping this in mind, I have no problems with simulators. It is necessary, however, to keep in mind possible limitations. And the simplifications, whe made. Detlef -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From Jon.Crowcroft at cl.cam.ac.uk Thu Apr 18 02:45:25 2013 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Thu, 18 Apr 2013 10:45:25 +0100 Subject: [e2e] VJCC vs. Keshav In-Reply-To: <516FBAC2.3020603@web.de> References: <516D464F.7090006@web.de> <516D5864.9070307@web.de> <1366205545.911620165@apps.rackspace.com> <516EF103.1030300@web.de> <516FBAC2.3020603@web.de> Message-ID: I wasn't clear (as usual) keshav wrote a simulator (somewhat before NS[123] exists I suppose since it pre-dates them and even Tcl) called REAL, which I suppose he used for his PhD - this is all online here: http://blizzard.cs.uwaterloo.ca/keshav/wiki/index.php/Paper-chron#1988 The REAL simulator is rather nice... I guess it was the basis later for the startup he had called Ensim (maybe he'll notice this and comment here) I think the point i was trying to convey was that packet pair (and packet train) and fair queuing (and other more active queue management algorithms) have seen evaluation by many people using many tools (including measurement as well as simulation -- and also even analytical models (adversarial queuing, network calculi etc) and (once you get away from fifo, fluid approx stuff works, so lots of things get easier theoretically) but yes, something only ever done in ns2 is hardly convincing. there are other simualtors, however and some have detailed models of physical layer - a nice trick to consider is uing hybrid systems such as Matlab to generate a box of code which models CSMA/CD or what have you, including a detailed scattering/fading model and then plug that in to a discrete event simulator such as NS2 - or you could use opnet, which has detailed models of quite a lot of low level systems .... the world is full of wondrous things j. In missive <516FBAC2.3020603 at web.de>, Detlef Bosau typed: >>Am 17.04.2013 22:54, schrieb Jon Crowcroft: >>> more history >>> 1. keshav wrote his own simulator (a variant maybe of the mit x sim >>> system) >>t >>so did I, although the thing is not published. And of course, I did not >>reinvent the wheel but used concepts known from the ns 2. >> >> >>> 2. other people verified fq results in other simulators >>> 3. some people have implemented lots of variants of fq and packet >>> probe pair/trains as well >>> >>> maybe you could read the source materials properly, >>> rather than just snippets of this maillist... >> >>Jon, I did. So, there is no need to blame me here. >> >>However: When you look at the source material, particularly the program >>sources of simulators, you become aware of quite some simplifications >>frequently made. That's why I made a critical remark on "packet pair" >>techniques and the ns2. >> >> >>Simply and frankly spoken: Proving packet pair techniques with a >>simulator proves absolutely nothing. Because the program code in the >>simulator is nothing else than the system model used in the papers. >> >>E.g. in the ns2 you have some kind of "bandwidth" and a serialization >>delay which packet size / bandwidth. Fine. >> >>Now, you send a number of packets, this needs a (cumulative) >>serialization delay = Sum over all packets (packet length/Bandwidth) >>and this is divided by the cumulative packet length - and renders what? >> >>Exactly. >> >>And because each and any simulator uses the same approach, they prove >>each other. >> >>Unfortunately, these nasty CSMA/CD Ethernets or these disgusting CSMA/CA >>WLANs or these horrible mobile networks dare not always to behave >>simulator compliant.... >> >>Simulators are nice. However they are, to a certain degree, GIGO >>systems. (GIGO: Garbage In, Garbage Out.) >> >>This is not to criticize simulators, but to be aware of their limitations. >> >>How do we simulate CSMA/CD Ethernets with all gory details? I really >>don't know if this is possible at all. >> >>Keeping this in mind, I have no problems with simulators. It is >>necessary, however, to keep in mind possible limitations. And the >>simplifications, whe made. >> >>Detlef >> >> >> >>-- >>------------------------------------------------------------------ >>Detlef Bosau >>Galileistra?e 30 >>70565 Stuttgart Tel.: +49 711 5208031 >> mobile: +49 172 6819937 >> skype: detlef.bosau >> ICQ: 566129673 >>detlef.bosau at web.de http://www.detlef-bosau.de >> cheers jon From Martin.Heusse at imag.fr Thu Apr 18 04:05:57 2013 From: Martin.Heusse at imag.fr (Martin Heusse) Date: Thu, 18 Apr 2013 13:05:57 +0200 Subject: [e2e] VJCC vs. Keshav In-Reply-To: <516FBAC2.3020603@web.de> References: <516D464F.7090006@web.de> <516D5864.9070307@web.de> <1366205545.911620165@apps.rackspace.com> <516EF103.1030300@web.de> <516FBAC2.3020603@web.de> Message-ID: Detlef, NS2 simulates all that. So in you view CSMA/CA is "disgusting"? No less? ? Martin Le 18 avr. 2013 ? 11:20, Detlef Bosau a ?crit : > Unfortunately, these nasty CSMA/CD Ethernets or these disgusting CSMA/CA WLANs or these horrible mobile networks dare not always to behave simulator compliant.... > > Simulators are nice. However they are, to a certain degree, GIGO systems. (GIGO: Garbage In, Garbage Out.) > > This is not to criticize simulators, but to be aware of their limitations. > > How do we simulate CSMA/CD Ethernets with all gory details? I really don't know if this is possible at all. From detlef.bosau at web.de Thu Apr 18 05:06:50 2013 From: detlef.bosau at web.de (Detlef Bosau) Date: Thu, 18 Apr 2013 14:06:50 +0200 Subject: [e2e] VJCC vs. Keshav In-Reply-To: References: <516D464F.7090006@web.de> <516D5864.9070307@web.de> <1366205545.911620165@apps.rackspace.com> <516EF103.1030300@web.de> <516FBAC2.3020603@web.de> Message-ID: <516FE1DA.9050708@web.de> Am 18.04.2013 11:45, schrieb Jon Crowcroft: > > I think the point i was trying to convey was that > packet pair (and packet train) and fair queuing (and other more active > queue management algorithms) have seen evaluation by > many people using many tools (including measurement as well as Yes. And being short and frankly: When it comes to mobile networks, I don't believe a word of the packet-pair and packet-train stuff. Even for the radio interface, it simply doesn't make sense to talk about an "average bit rate" in this case, when this is associated with both, a reasonable hight throughput and a reasonably low block corruption rate. However, you can well implement packet pair and packet train stuff and observe some funny numbers in real networks. That's nice, other people collect stamps..... . But when we put those numbers in c-code and derive "serialization delays" from them, the result is simply fictional. It took me years to learn this lessen and perhaps, it was one of my most difficult lessons ever. So, the question is: What is the reality, which really corresponds to our simulators? When I started my work in a project called COMCAR 13 years ago, and I talked about QoS, the EE colleagues ridiculed at me "You dealt with wired networks up to now, right?" and a colleague from CE simply answered my question concerning bit error rates simply and harsh: "There is nothing like bit error rates." What I learnt meanwhile: Both were right. And as there is no such thing like a "bit error rate", there is no such thing like a (more or less or at least quasi more or less stationary) bit rate. And therefore, all this packet pair stuff and packet train stuff is interesting stuff inspired by the behaviour of wired networks, but with respect to mobile networks, we talk about pure fiction and artefacts here. -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From detlef.bosau at web.de Thu Apr 18 05:25:12 2013 From: detlef.bosau at web.de (Detlef Bosau) Date: Thu, 18 Apr 2013 14:25:12 +0200 Subject: [e2e] VJCC vs. Keshav In-Reply-To: References: <516D464F.7090006@web.de> <516D5864.9070307@web.de> <1366205545.911620165@apps.rackspace.com> <516EF103.1030300@web.de> <516FBAC2.3020603@web.de> Message-ID: <516FE628.4080900@web.de> Am 18.04.2013 13:05, schrieb Martin Heusse: > Detlef, > NS2 simulates all that. > > So in you view CSMA/CA is "disgusting"? No less? ? Disgusting is a hard word, perhaps I should say: "funny". However: Simply not realistic. That's not an ns2 problem. It's simply extremely hard to provide a sound CSMA/CA simulation. Honestly: I'm not fully convinced that a convincing CSMA/CA simulation is possible at all. This is particularly a question to communication engineers. I don't mind estimating a possible throughput on a rough average basis as a "rule of thumb" in a particular simulation. However, we must not take those long term averages as a justification to predict or to simulate the link/network behaviour for individual packets with a time resolution in the area of milliseconds or less. -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From Jon.Crowcroft at cl.cam.ac.uk Thu Apr 18 05:53:08 2013 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Thu, 18 Apr 2013 13:53:08 +0100 Subject: [e2e] VJCC vs. Keshav In-Reply-To: <516FE1DA.9050708@web.de> References: <516D464F.7090006@web.de> <516D5864.9070307@web.de> <1366205545.911620165@apps.rackspace.com> <516EF103.1030300@web.de> <516FBAC2.3020603@web.de> <516FE1DA.9050708@web.de> Message-ID: In missive <516FE1DA.9050708 at web.de>, Detlef Bosau typed: >>Yes. And being short and frankly: When it comes to mobile networks, I >>don't believe a word of the packet-pair and packet-train stuff. >>Even for the radio interface, it simply doesn't make sense to talk about >>an "average bit rate" in this case, when this is associated with both, a >>reasonable hight throughput and a reasonably low block corruption rate. this depends on the model and simulator - if you model the signal propagation and do it with fine grain enough discrete event rate, then you can work out the fate of packets based o nthe fate of the signal, and the bits in the packet - some simulation models let you do this, but usually you simplify to make sure the simulations can run in human lifetimes, if you are interested in packet level results, so then you reduce the physical and link layer details to averages/aggreagtes and run a black box sim for them that produces the overal right stats... >>However, you can well implement packet pair and packet train stuff and >>observe some funny numbers in real networks. That's nice, other people >>collect stamps..... . and some people build simulations that aren't wrong. >>But when we put those numbers in c-code and derive "serialization >>delays" from them, the result is simply fictional. and some people put models in matlab (or other toolkits) and generate code that produces the right aggregate results and use that code as a module in a higher level simulator ...as above.. >>It took me years to learn this lessen and perhaps, it was one of my most >>difficult lessons ever. >>So, the question is: What is the reality, which really corresponds to >>our simulators? >> >>When I started my work in a project called COMCAR 13 years ago, and I=20 >>talked about QoS, the EE colleagues ridiculed at me "You dealt with=20 >>wired networks up to now, right?" and a colleague from CE simply=20 >>answered my question concerning bit error rates simply and harsh: "There=20 >>is nothing like bit error rates." >> >>What I learnt meanwhile: Both were right. >> >>And as there is no such thing like a "bit error rate", there is no such=20 >>thing like a (more or less or at least quasi more or less stationary)=20 >>bit rate. >> >>And therefore, all this packet pair stuff and packet train stuff is >>interesting stuff inspired by the behaviour of wired networks, but with >>respect to mobile networks, we talk about pure fiction and artefacts here. you could use packet pair to investigate whether the delay in a MAC Layer (RTS/CTS or CPOD) was giving you indication of contention for the media - this would be geniune measure for some wireless nets - or you could map collisions into contention (and threfore L2 congestion ) signals also for a scheduled mac (TDMA) , you could just measure the delay caused by the number of session demands made to the scheduler... gosh, i think we did... >> >> >> >>--=20 >>------------------------------------------------------------------ >>Detlef Bosau >>Galileistra=DFe 30 >>70565 Stuttgart Tel.: +49 711 5208031 >> mobile: +49 172 6819937 >> skype: detlef.bosau >> ICQ: 566129673 >>detlef.bosau at web.de http://www.detlef-bosau.de >> cheers jon From detlef.bosau at web.de Thu Apr 18 08:05:26 2013 From: detlef.bosau at web.de (Detlef Bosau) Date: Thu, 18 Apr 2013 17:05:26 +0200 Subject: [e2e] VJCC vs. Keshav In-Reply-To: References: <516D464F.7090006@web.de> <516D5864.9070307@web.de> <1366205545.911620165@apps.rackspace.com> <516EF103.1030300@web.de> <516FBAC2.3020603@web.de> <516FE1DA.9050708@web.de> Message-ID: <51700BB6.2080606@web.de> Am 18.04.2013 14:53, schrieb Jon Crowcroft: > In missive <516FE1DA.9050708 at web.de>, Detlef Bosau typed: > > >>Yes. And being short and frankly: When it comes to mobile networks, I > >>don't believe a word of the packet-pair and packet-train stuff. > > >>Even for the radio interface, it simply doesn't make sense to talk about > >>an "average bit rate" in this case, when this is associated with both, a > >>reasonable hight throughput and a reasonably low block corruption rate. > > this depends on the model and simulator - if you model the signal > propagation and do it with fine grain enough discrete event rate, then Jon, I once attended a talk where the speaker proposes to do ray traicing... And please keep in mind the GEOMETRIC "period" of minima and maxima in Rayleigh-fading. IIRC: Rule of thumb: half of the bearer frequencies wavelength. I.e. with GSM, round abouht 1 GHz, wavelength round about 30 centimetres. I.e. 15 centimetres between two points of maximum receiving power. It was exactly that moment, where I stopped giggling about the persons who I've seen "mobile phone callisthenics" by shifting around their phones 5 cm to the left or 10 cm to the right in order to increase their WWW browsers throughput. And you want to simulate that, perhaps with ray tracing and perhaps a temporal resolution of say 1 ms and a geometric resolution of say 1 cm? Sorry, I cannot take this seriously. -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From Jon.Crowcroft at cl.cam.ac.uk Thu Apr 18 08:18:29 2013 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Thu, 18 Apr 2013 16:18:29 +0100 Subject: [e2e] VJCC vs. Keshav In-Reply-To: <51700BB6.2080606@web.de> References: <516D464F.7090006@web.de> <516D5864.9070307@web.de> <1366205545.911620165@apps.rackspace.com> <516EF103.1030300@web.de> <516FBAC2.3020603@web.de> <516FE1DA.9050708@web.de> <51700BB6.2080606@web.de> Message-ID: yes, actually we can simulate that - in fact i was on the committee of a very smart PhD student (Gregor Gaertner)in Trinity College Dublin who did a bunch of empirical studies of wifi propagation in the streets and then built exactly the hybrid matlab+ns2 simulation I am describing [note wifi is wideband radio in a sense so this is notionally harder than a single narrow band scheme)) yes, it has to do something like the spatial resolution of the 1/2 wavelength of the radio and temporal resolution of the movement of people/devices over that space (actually it turns out it doesnt for various interesting reasons) - the simulator and measurements matched well... no humour involved at all In missive <51700BB6.2080606 at web.de>, Detlef Bosau typed: >>Am 18.04.2013 14:53, schrieb Jon Crowcroft: >>> In missive <516FE1DA.9050708 at web.de>, Detlef Bosau typed: >>> >>> >>Yes. And being short and frankly: When it comes to mobile networks, I >>> >>don't believe a word of the packet-pair and packet-train stuff. >>> >>> >>Even for the radio interface, it simply doesn't make sense to talk about >>> >>an "average bit rate" in this case, when this is associated with both, a >>> >>reasonable hight throughput and a reasonably low block corruption rate. >>> >>> this depends on the model and simulator - if you model the signal >>> propagation and do it with fine grain enough discrete event rate, then >> >>Jon, I once attended a talk where the speaker proposes to do ray traicing... >> >>And please keep in mind the GEOMETRIC "period" of minima and maxima in >>Rayleigh-fading. >> >>IIRC: Rule of thumb: half of the bearer frequencies wavelength. I.e. >>with GSM, round abouht 1 GHz, wavelength round about 30 centimetres. >> >>I.e. 15 centimetres between two points of maximum receiving power. >> >>It was exactly that moment, where I stopped giggling about the persons >>who I've seen "mobile phone callisthenics" by shifting around their >>phones 5 cm to the left or 10 cm to the right in order to increase their >>WWW browsers throughput. >> >>And you want to simulate that, perhaps with ray tracing and perhaps a >>temporal resolution of say 1 ms and a geometric resolution of say 1 cm? >> >>Sorry, I cannot take this seriously. >> >>-- >>------------------------------------------------------------------ >>Detlef Bosau >>Galileistra?e 30 >>70565 Stuttgart Tel.: +49 711 5208031 >> mobile: +49 172 6819937 >> skype: detlef.bosau >> ICQ: 566129673 >>detlef.bosau at web.de http://www.detlef-bosau.de >> cheers jon From keshav at uwaterloo.ca Thu Apr 18 12:27:53 2013 From: keshav at uwaterloo.ca (Srinivasan Keshav) Date: Thu, 18 Apr 2013 19:27:53 +0000 Subject: [e2e] end2end-interest Digest, Vol 108, Issue 24 In-Reply-To: References: Message-ID: Some clarifications and comments on this thread: 1. I wrote the REAL simulator (by heavily modifying the NEST simulator from Columbia) [1] in 1988 as a summer intern at Xerox PARC, working for Scott Shenker. REAL's many failings served to inspire Steve McCanne to write ns around 1991 [2]. I released several versions of REAL into the public domain; the source code is probably still floating around somewhere. 2. REAL stands for 'realistic and large,' my design goals. I guess these goals still hold true for more recent simulators. I think we all recognize that 'to simulate' means 'to lie,' and every simulator is only a model of reality, so naturally excludes some aspects of reality. A simulator that excludes aspects of reality that are relevant to the system being studied will generate incorrect results. REAL did not model wireless links, so any results I obtained from REAL (for example for packet-pair) do not necessarily hold for wireless links, in general. For the specific case of today's wireless links, i.e., CSMA/CA and cellular links, its trivial to observe that packet-pair won't work, because you can't send two packets back-to-back over any real wireless link that uses either CSMA/CA or RRM (Radio Resource Management in cellular networks). 3. I do not believe in proof by simulation: having done many simulations myself, I am well aware of their shortcomings. I hold with Hamming, who famously said: "The purpose of computing is intuition, not numbers."(*) with s/computing/simulation/ 4. My thesis 'validated' packet pair using simulations because no networks of FQ schedulers existed at that time and I didn't feel like building one of my own. I don't think this is good validation, but couldn't think of any other way to test my ideas. 5. There are two reasons why people think packet-pair style congestion control did not (and will not) work in the real world. One is a myth, one is a reality. First, the myth: it advocates per-flow WFQ, which does not scale well, requiring per-flow state in routers. Later work by Stoica et al [3] showed how to remove this need for per-flow state in the Internet core, and large-scale TCAMs allow quite a large amount of per-flow state these days. So, in practice, per-flow WFQ is quite feasible today (and is supported by Cisco, for example [4]). Second, the reality: it requires all routers on the path to support WFQ. This seems straightforward at first glance, but has a big problem: how is an end point to pay for choosing a large(r) scheduling weight? To whom does it pay? And how does this payment get distributed amongst the entities along the path? These fundamental issues are part of the reason why Internet QoS exists only in paper form (see [5] for some other very good reasons) *other than in private networks*. 6. In contrast, an end-system based control that responds quickly to packet reorderings and drops and makes no assumptions on scheduling disciplines is legacy compatible, hence the success of VJCC and its successors. thanks, keshav *Preface to Numerical Methods for Scientists and Engineers. 1962. [1] Dupuy, Alexander, et al. "NEST: A network simulation and prototyping testbed." Communications of the ACM 33.10 (1990): 63-74. [2] Bajaj, Sandeep, Lee Breslau, Deborah Estrin, Kevin Fall, Sally Floyd, Padma Haldar, Mark Handley et al. "Improving simulation for network research." USC TR 99-702, 1999. [3] Stoica, Ion, Scott Shenker, and Hui Zhang. Core-stateless fair queueing: Achieving approximately fair bandwidth allocations in high speed networks. Proceedings of the ACM SIGCOMM '98 conference on Applications, technologies, architectures, and protocols for computer communication, ACM SIGCOMM Computer Communication Review Volume 28 Issue 4, Oct. 1998. [4]http://www.cisco.com/en/US/docs/ios/12_2/qos/configuration/guide/qcfwfq_ps1835_TSD_Products_Configuration_Guide_Chapter.html [5] Crowcroft, Jon, et al. "QoS's Downfall: At the bottom, or not at all!." Proceedings of the ACM SIGCOMM workshop on Revisiting IP QoS: What have we learned, why do we care?. ACM, 2003. > I wasn't clear (as usual) > > keshav wrote a simulator (somewhat before NS[123] exists I suppose > since it pre-dates them and even Tcl) called > REAL, which I suppose he used for his PhD - this is all online here: > http://blizzard.cs.uwaterloo.ca/keshav/wiki/index.php/Paper-chron#1988 > > The REAL simulator is rather nice... > > I guess it was the basis later for the startup he had called Ensim > (maybe he'll notice this and comment here) > > I think the point i was trying to convey was that > packet pair (and packet train) and fair queuing (and other more active > queue management algorithms) have seen evaluation by > many people using many tools (including measurement as well as > simulation -- and also even analytical models (adversarial queuing, > network calculi etc) > and (once you get away from fifo, fluid approx stuff works, so lots of > things get easier theoretically) > > but yes, something only ever done in ns2 is hardly convincing. > > there are other simualtors, however and some have detailed models > of physical layer - a nice trick to consider is uing hybrid systems such as Matlab to generate a box > of code which models CSMA/CD or what have you, including a detailed scattering/fading model > and then plug that in to a discrete event simulator such as NS2 - or you could use opnet, which has detailed models > of quite a lot of low level systems .... > > the world is full of wondrous things > > j. > From detlef.bosau at web.de Thu Apr 18 13:53:06 2013 From: detlef.bosau at web.de (Detlef Bosau) Date: Thu, 18 Apr 2013 22:53:06 +0200 Subject: [e2e] VJCC vs. Keshav In-Reply-To: References: <516D464F.7090006@web.de> <516D5864.9070307@web.de> <1366205545.911620165@apps.rackspace.com> <516EF103.1030300@web.de> <516FBAC2.3020603@web.de> <516FE1DA.9050708@web.de> <51700BB6.2080606@web.de> Message-ID: <51705D32.5070303@web.de> Am 18.04.2013 17:18, schrieb Jon Crowcroft: > > yes, it has to do something like the spatial resolution of the 1/2 wavelength of the radio > and temporal resolution of the movement of people/devices over that space (actually it turns out it doesnt for > various interesting reasons) - the simulator and measurements matched well... so, one's favourite pet is Rayleigh-Fading here ;-) As I said in my criticism on the pet "free space attenuation" - in my flat I "hear" currently (looking) 7 WLANs, which necessarily overlap. And I didn't look for other sources of disturbance. Can you really simulate that? -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From detlef.bosau at web.de Thu Apr 18 15:38:04 2013 From: detlef.bosau at web.de (Detlef Bosau) Date: Fri, 19 Apr 2013 00:38:04 +0200 Subject: [e2e] VJCC vs. Keshav In-Reply-To: <1366323746.07313097@apps.rackspace.com> References: <516D464F.7090006@web.de> <516D5864.9070307@web.de> <1366205545.911620165@apps.rackspace.com> <516EF103.1030300@web.de> <516FBAC2.3020603@web.de> <516FE1DA.9050708@web.de> <51700BB6.2080606@web.de> <51705D32.5070303@web.de> <1366323746.07313097@apps.rackspace.com> Message-ID: <517075CC.4040804@web.de> Am 19.04.2013 00:22, schrieb dpreed at reed.com: > > 7 WiFi LANs tend to interact in interesting ways. I do believe you can > probably model the physics if you have the complete physical model of > the environment, including the motion of people, objects, etc. and > also a model of the specific antenna locations and positions, as well > as precise timings and indices of refraction. > O.k., that's difficult. > But this is not the real problem. The real problem is that the > programs and humans that generate the traffic generate that traffic > dependent on the communications performance they observe. > Don't blame my neighbours ;-) However, I agree. That's the real problem. I cannot simulate my neighbours, neither their behaviour. > That is, I don't usually click on a link until I've received the page > and had it displayed, but not always - sometimes I interrupt the > process and go on to the next link. Similarly, the low level MAC > protocol involves several components of behavior. If, for example, > noise is detected at a certain level (way below the signalling levels) > in the 4 microseconds before a transceiver is about to send a packet, > the packet will not be sent. But during this interval other stations > will hear *different* noise, because noise is not equi-potential > simultaneously across the stations on the 7 WLANs. So small > variation during intervals as short as 4 microseconds can have > amplified effects. > In this context, I remember a recent discussion in the German part of the usenet: There are apparently different strategies how WLAN AP choose their channel, particularly when adapting to a certain channel load situation. From that, I conclude, we would have to simulate not only different brands and different software releases. -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20130419/3be3760f/attachment.html From l.wood at surrey.ac.uk Thu Apr 18 20:46:11 2013 From: l.wood at surrey.ac.uk (l.wood@surrey.ac.uk) Date: Fri, 19 Apr 2013 04:46:11 +0100 Subject: [e2e] VJCC vs. Keshav In-Reply-To: References: <516D464F.7090006@web.de> <516D5864.9070307@web.de> <1366205545.911620165@apps.rackspace.com> <516EF103.1030300@web.de> <516FBAC2.3020603@web.de>, Message-ID: <290E20B455C66743BE178C5C84F12408223F494E6E@EXMB01CMS.surrey.ac.uk> Ns2's idea of "gory details" is the Packet Error Rate, where bit error rate varies with packet length. Lloyd Wood http://sat-net.com/L.Wood/ ________________________________________ From: end2end-interest-bounces at postel.org [end2end-interest-bounces at postel.org] On Behalf Of Martin Heusse [Martin.Heusse at imag.fr] Sent: 18 April 2013 12:05 To: end2end-interest at postel.org Subject: Re: [e2e] VJCC vs. Keshav Detlef, NS2 simulates all that. So in you view CSMA/CA is "disgusting"? No less? ? Martin Le 18 avr. 2013 ? 11:20, Detlef Bosau a ?crit : > Unfortunately, these nasty CSMA/CD Ethernets or these disgusting CSMA/CA WLANs or these horrible mobile networks dare not always to behave simulator compliant.... > > Simulators are nice. However they are, to a certain degree, GIGO systems. (GIGO: Garbage In, Garbage Out.) > > This is not to criticize simulators, but to be aware of their limitations. > > How do we simulate CSMA/CD Ethernets with all gory details? I really don't know if this is possible at all. From giuseppe.bianchi at uniroma2.it Fri Apr 19 00:42:27 2013 From: giuseppe.bianchi at uniroma2.it (Giuseppe Bianchi) Date: Fri, 19 Apr 2013 09:42:27 +0200 Subject: [e2e] VJCC vs. Keshav In-Reply-To: <517075CC.4040804@web.de> References: <516D464F.7090006@web.de> <516D5864.9070307@web.de> <1366205545.911620165@apps.rackspace.com> <516EF103.1030300@web.de> <516FBAC2.3020603@web.de> <516FE1DA.9050708@web.de> <51700BB6.2080606@web.de> <51705D32.5070303@web.de> <1366323746.07313097@apps.rackspace.com> <517075CC.4040804@web.de> Message-ID: <5170F563.1090608@uniroma2.it> > In this context, I remember a recent discussion in the German part of > the usenet: There are apparently different strategies how WLAN AP > choose their channel, particularly when adapting to a certain channel > load situation. From that, I conclude, we would have to simulate not > only different brands and different software releases. A conclusion which not only restricts to "AP-level" mechanisms, where of course solutions may be highly customized, but which appears to affect also"card-level" operation where we would rather expect the very same standard behavior. see e.g. Infocom 2007: Experimental Assessment of the Backoff Behavior of Commercial IEEE 802.11b Network Cards. At least in the WLAN domain, firmware twists, vendors' customizations not publicly disclosed, and even implementation bugs, make such that claiming representativity of one own real world experimental setting is not as straightforward as it would seem to the layman person. Giuseppe. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20130419/edd6b914/attachment.html From detlef.bosau at web.de Sat Apr 20 13:50:49 2013 From: detlef.bosau at web.de (Detlef Bosau) Date: Sat, 20 Apr 2013 22:50:49 +0200 Subject: [e2e] VJCC vs. Keshav In-Reply-To: <290E20B455C66743BE178C5C84F12408223F494E6E@EXMB01CMS.surrey.ac.uk> References: <516D464F.7090006@web.de> <516D5864.9070307@web.de> <1366205545.911620165@apps.rackspace.com> <516EF103.1030300@web.de> <516FBAC2.3020603@web.de>, <290E20B455C66743BE178C5C84F12408223F494E6E@EXMB01CMS.surrey.ac.uk> Message-ID: <5172FFA9.4020805@web.de> Am 19.04.2013 05:46, schrieb l.wood at surrey.ac.uk: > Ns2's idea of "gory details" is the Packet Error Rate, where bit error rate varies with packet length. > > Lloyd Wood > http://sat-net.com/L.Wood/ > > When I started my research with mobile networks, I once asked a colleague about bit error rates in mobile networks. The simple answer was: "There is no such thing like bit errors." It took me years to admit to myself: My ideas about mobile networks have been completely oversimplified that time. My ideas about mobile networks today are certainly not better. But I'm better aware of their limits. -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From braden at isi.edu Tue Apr 23 12:24:46 2013 From: braden at isi.edu (Bob Braden) Date: Tue, 23 Apr 2013 12:24:46 -0700 Subject: [e2e] Port numbers in the network layer? Message-ID: <5176DFFE.50404@isi.edu> During the development of TCP during the 1977-1980 period, the original C&K TCP layer was divided into a transport layer (TCP) and an internetwork layer (IP). One of the key decisions in this split was which layer should inherit the port numbers. At the time I simply accepted the group decision to put ports into the transport layer without taking time to think through the architectural implications. Has anyone ever thought through how the architecture would have been changed had ports ended up in the internetwork layer, i.e., in IP? Bob Braden From jnc at mercury.lcs.mit.edu Tue Apr 23 13:05:31 2013 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Tue, 23 Apr 2013 16:05:31 -0400 (EDT) Subject: [e2e] Port numbers in the network layer? Message-ID: <20130423200531.4DDD718C0E8@mercury.lcs.mit.edu> > From: Bob Braden > Has anyone ever thought through how the architecture would have been > changed had ports ended up in the internetwork layer There were certainly people who did this (XNS - and, IIRC, PUP too). I think there are decent (i.e. not earthshaking) arguments both ways, and I also honestly don't think it really makes that much difference which way one goes! Noel From Jon.Crowcroft at cl.cam.ac.uk Tue Apr 23 23:06:11 2013 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Wed, 24 Apr 2013 07:06:11 +0100 Subject: [e2e] Port numbers in the network layer? In-Reply-To: <20130423200531.4DDD718C0E8@mercury.lcs.mit.edu> References: <20130423200531.4DDD718C0E8@mercury.lcs.mit.edu> Message-ID: well, if you have the 5-tuple that became the de facto flow id, all in the ip layer, than transport layer security (e.g. tcpcrypt) would mean ipsec was completely obsolete rather than just fairly pointless which might be a good thing otoh, what would the ports _mean_ in multicast ip? (actually, what do they really signify in multicast anyhow?) In missive <20130423200531.4DDD718C0E8 at mercury.lcs.mit.edu>, Noel Chiappa typed : >> > From: Bob Braden >> >> > Has anyone ever thought through how the architecture would have been >> > changed had ports ended up in the internetwork layer >> >>There were certainly people who did this (XNS - and, IIRC, PUP too). >> >>I think there are decent (i.e. not earthshaking) arguments both ways, and I >>also honestly don't think it really makes that much difference which way one >>goes! >> >> Noel cheers jon From jeanjour at comcast.net Wed Apr 24 04:55:54 2013 From: jeanjour at comcast.net (John Day) Date: Wed, 24 Apr 2013 07:55:54 -0400 Subject: [e2e] Port numbers in the network layer? In-Reply-To: <5176DFFE.50404@isi.edu> References: <5176DFFE.50404@isi.edu> Message-ID: After delving into it fairly deeply, it is clear that port-ids are the crucial piece required for proper (and useful) layer isolation. Decoupling port allocation from synchronization as indicated by Watson's work is key in constructing a well-formed layer. Watson clearly recognized the importance of distinguishing port-ids (a local handle) from Connection-endpoint-ids (CEP-ids that are carried in protocol). Both the Internet and the OSI Models conflate port allocation and synchronization and so have one identifier where two are required. Cleanly distinguishing them has major implications for security. A layer without port-ids leads to all sorts of problems, the least of which are the so-called protocol-id fields to identify the syntax of the encapsulated header. Take care, John At 12:24 PM -0700 4/23/13, Bob Braden wrote: >During the development of TCP during the 1977-1980 period, the >original C&K TCP layer was divided into a transport layer (TCP) and >an internetwork layer (IP). One of the key decisions in this split >was which layer should inherit the port numbers. At the time I >simply accepted the group decision to put ports into the transport >layer without taking time to think through the architectural >implications. Has anyone ever thought through how the architecture >would have been changed had ports ended up in the internetwork >layer, i.e., in IP? > >Bob Braden From jeanjour at comcast.net Thu Apr 25 05:52:22 2013 From: jeanjour at comcast.net (John Day) Date: Thu, 25 Apr 2013 08:52:22 -0400 Subject: [e2e] Port numbers in the network layer? In-Reply-To: <1366853677.483822482@apps.rackspace.com> References: <5176DFFE.50404@isi.edu> <1366853677.483822482@apps.rackspace.com> Message-ID: The question is why is a protocol-id field required in some protocols and not others. If it is to identify the protocol in the layer above, then how many thousand SCTP instances can I identify on top of a single IP instance. If it identifies the protocol, then that should be possible. Obviously it isn't what it is intended for. Knowing what kind of protocol it is is not required for multiplexing. All that is needed is to distinguish different collections of related packets. sometimes called "flows" or "connections." So while an additional multiplexing field might be useful, it would be more useful if wasn't tied to the kind of protocol. In protocols with port-ids, there is no need to know what protocol is encapsulated (and interestingly there are no protocol-id fields in these protocols) because the ends of the flow were involved in creating the port-ids and hence know what to expect when packets are delivered on that port-id. That would seem to indicate that the purpose of the Protocol-id field is to identify the syntax of the protocol being encapsulated so that the receiver knows how to interpret (at least some of) the data in the packets that are delivered to it. If it is also used as another multiplexing field that is secondary. Take care, John At 9:34 PM -0400 4/24/13, dpreed at reed.com wrote: >John & Bob - I don't concur. The value of having a protocol ID >that is separate from port numbers is that there *is* a namespace >that allows alternative multiplexing/demultiplexing models in the >overall internetwork. And one obvious (but by no means the >simplest) example is the potential to create namespaces that are >much larger and more stable than the 16 bits currently allocated for >port numbers. > > > >This was *all* screwed up when NAT was allowed to happen (rather >than fixing the shortage of routable addresses by doing IPv6 >quickly). NAT was a disaster because it conflated port numbers >with endpoint names for autonomous destinations. > > > >At the time, I was told that "NAT was temporary", and that one >should not worry about the companies that proposed it as an IETF >standard. It was not "standards track". But Cisco, in particular, >sidelined Scott Deering away from its commercial planning, and put >some product managers in charge, who felt no desire to evolve using >IETF processes, and (like Chambers), just wanted to go "proprietary" >to lock in dominance that they had achieved. > > > >Of course, NAT was not temporary - it was Milo Medin and @Home that >wanted to charge per-device in a home that created architectural >warts all over the place, including the idea that "port numbers" >could be blocked to attempt to prevent "servers in the home". > > > >So it really had little to do with thoughtful architecture or the >IETF. That period was when IETF lost its way completely, not >understanding what the vendors were attempting to do by balkanizing >the design space and eliminating interoperability as much as they >dared. > > > >But back to the main point: the protocol number has served a role >precisely because it allows higher level multiplexing to be extended >and evolved. Had all protocols had port numbers, that flexibility >would have been lost. There's no obvious reason why, for example, >that SCTP should have the same port number space as TCP, and >certainly UDP's demultiplexing is quite different from TCP, even if >the field size is the same - we don't send UDP datagrams to the same >place that we send TCP segments, and ICMP would not be able to talk >to a protocol-independent "control plane", but instead would be >delivered to the endpoints. > > > >One of the key things about the Internet design was its openness to >unanticipated future evolution, without asking for "permission" from >a standards committee like 3GPP. That played out in the >demultiplexing layer. Not all hosts are "operating systems" that >look like TENEX or Unix, and have those goals, so the demultiplexing >and packet parsing goals might not have anything to do with >"processes" logged into a machine. > > > >Of course, if your view is that you just design a protocol from a >clean slate, and then throw it away and start again from a new clean >slate - you can wean the design down to a highly brittle framework >that does *exactly* what you plan for, and nothing more. That way >you get SNA, with 8-bit addresses and protocols for every device >type that don't have any commonality. > > > >Caveat: Joe Touch prevents me from posting. > > > > > >On Wednesday, April 24, 2013 7:55am, "John Day" said: > > > After delving into it fairly deeply, it is clear that port-ids are >> the crucial piece required for proper (and useful) layer isolation. >> >> Decoupling port allocation from synchronization as indicated by >> Watson's work is key in constructing a well-formed layer. Watson >> clearly recognized the importance of distinguishing port-ids (a local >> handle) from Connection-endpoint-ids (CEP-ids that are carried in >> protocol). >> >> Both the Internet and the OSI Models conflate port allocation and >> synchronization and so have one identifier where two are required. >> Cleanly distinguishing them has major implications for security. A >> layer without port-ids leads to all sorts of problems, the least of >> which are the so-called protocol-id fields to identify the syntax of >> the encapsulated header. >> >> Take care, >> John >> >> At 12:24 PM -0700 4/23/13, Bob Braden wrote: >> >During the development of TCP during the 1977-1980 period, the >> >original C&K TCP layer was divided into a transport layer (TCP) and >> >an internetwork layer (IP). One of the key decisions in this split >> >was which layer should inherit the port numbers. At the time I >> >simply accepted the group decision to put ports into the transport >> >layer without taking time to think through the architectural >> >implications. Has anyone ever thought through how the architecture >> >would have been changed had ports ended up in the internetwork >> >layer, i.e., in IP? >> > >> >Bob Braden >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20130425/6b7125a0/attachment.html From touch at isi.edu Thu Apr 25 11:46:38 2013 From: touch at isi.edu (Joe Touch) Date: Thu, 25 Apr 2013 11:46:38 -0700 Subject: [e2e] Port numbers in the network layer? In-Reply-To: References: <5176DFFE.50404@isi.edu> <1366853677.483822482@apps.rackspace.com> Message-ID: <51797A0E.5050608@isi.edu> One issue is the need for ports; there's a summary of that here: http://tools.ietf.org/html/draft-ietf-tsvwg-port-use-01 Its use evolved to overload: - part of the stream identifier used to associate groups of packets (with IP addresses) - an identifier for the upper layer protocol (service) (the dest port, in all UDP packets or in the TCP SYN) FWIW, one way to decouple these two was described here: http://www.isi.edu/touch/pubs/draft-touch-tcp-portnames-00.txt It seems fairly clear that a layered architecture needs agreement on what the layers are. Indications of a particular layer sequence can occur anywhere - in band at any layer, or out of band. Consider that ethernet ethertype 0x0800 was originally intended to mean "IP", allowing the IP version number to be determined at the IP layer, but packet demuxing efficiency concerns resulted in a new ethertype for IPv6 (0x86DD). So the ethertype includes not only the upper layer protocol, but it's redundant with the version at the next layer. Similarly we could allocate a new ethertype to "IPv4:TCP" or "IPv4:SCTP". So any "mix and match" architecture needs to have some indication of what the particular mix is, but it need not be cascaded layer-by-layer. Joe From detlef.bosau at web.de Thu Apr 25 12:32:53 2013 From: detlef.bosau at web.de (Detlef Bosau) Date: Thu, 25 Apr 2013 21:32:53 +0200 Subject: [e2e] Port numbers in the network layer? In-Reply-To: References: <5176DFFE.50404@isi.edu> <1366853677.483822482@apps.rackspace.com> Message-ID: <517984E5.2000906@web.de> Am 25.04.2013 14:52, schrieb John Day: > Re: [e2e] Port numbers in the network layer? > The question is why is a protocol-id field required in some protocols > and not others. > > If it is to identify the protocol in the layer above, then how many > thousand SCTP instances can I identify on top of a single IP > instance. If it identifies the protocol, then that should be > possible. Obviously it isn't what it is intended for. So, what is, concisely, the problem and your proposed solution? Up to know, each individual TCP connection is uniquely identified by an address quadruple (node 1, port 1, node 2, port2). Why doesn't this work? And which solution works better? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20130425/7d4e0cf0/attachment.html From hagen at jauu.net Thu Apr 25 12:56:25 2013 From: hagen at jauu.net (Hagen Paul Pfeifer) Date: Thu, 25 Apr 2013 21:56:25 +0200 Subject: [e2e] Port numbers in the network layer? In-Reply-To: <51797A0E.5050608@isi.edu> References: <5176DFFE.50404@isi.edu> <1366853677.483822482@apps.rackspace.com> <51797A0E.5050608@isi.edu> Message-ID: <20130425195625.GI10307@virgo.local> * Joe Touch | 2013-04-25 11:46:38 [-0700]: >Consider that ethernet ethertype 0x0800 was originally intended to >mean "IP", allowing the IP version number to be determined at the IP >layer, but packet demuxing efficiency concerns resulted in a new >ethertype for IPv6 (0x86DD). So the ethertype includes not only the >upper layer protocol, but it's redundant with the version at the next >layer. > >Similarly we could allocate a new ethertype to "IPv4:TCP" or "IPv4:SCTP". > >So any "mix and match" architecture needs to have some indication of >what the particular mix is, but it need not be cascaded >layer-by-layer. In theory, but in practice this do not work because not every link is Ethernet and you may end up re-parsing the packet to determine the transport protocol at each hop. Limit the ethertype to the next layer was fine. The redundant information in Ethernet/IP header comes from the fact that we don't life in a perfect world and things evolve over time. Hagen From touch at isi.edu Thu Apr 25 13:12:26 2013 From: touch at isi.edu (Joe Touch) Date: Thu, 25 Apr 2013 13:12:26 -0700 Subject: [e2e] Port numbers in the network layer? In-Reply-To: <20130425195625.GI10307@virgo.local> References: <5176DFFE.50404@isi.edu> <1366853677.483822482@apps.rackspace.com> <51797A0E.5050608@isi.edu> <20130425195625.GI10307@virgo.local> Message-ID: <51798E2A.4030201@isi.edu> On 4/25/2013 12:56 PM, Hagen Paul Pfeifer wrote: > * Joe Touch | 2013-04-25 11:46:38 [-0700]: >> Consider that ethernet ethertype 0x0800 was originally intended to >> mean "IP", allowing the IP version number to be determined at the IP >> layer, but packet demuxing efficiency concerns resulted in a new >> ethertype for IPv6 (0x86DD). So the ethertype includes not only the >> upper layer protocol, but it's redundant with the version at the next >> layer. >> >> Similarly we could allocate a new ethertype to "IPv4:TCP" or "IPv4:SCTP". >> >> So any "mix and match" architecture needs to have some indication of >> what the particular mix is, but it need not be cascaded >> layer-by-layer. > > In theory, but in practice this do not work because not every link is Ethernet > and you may end up re-parsing the packet to determine the transport protocol > at each hop. Routers translate between different link layers; you're suggesting that how the layers are encoding affects translation efficiency. That's true, and a good argument for pushing information up the stack as late as possible, however doing so makes some kinds of multilayer decisions more complex - it's a trade-off. > Limit the ethertype to the next layer was fine. The redundant information in > Ethernet/IP header comes from the fact that we don't life in a perfect world > and things evolve over time. IMO, it comes from a bad decision to support a short-term fix based on the hardware limits at the time (which couldn't keep up with parsing multiple layers in hardware), vs. keeping a cleaner architecture. However, as you note, in this case it resulted in redundancy (rather than an either-or decision), so it 'just' wasted space and processing. ;-) Joe From calvert at netlab.uky.edu Thu Apr 25 14:30:43 2013 From: calvert at netlab.uky.edu (Ken Calvert) Date: Thu, 25 Apr 2013 17:30:43 -0400 Subject: [e2e] Port numbers in the network layer? In-Reply-To: <5176DFFE.50404@isi.edu> References: <5176DFFE.50404@isi.edu> Message-ID: <8E086747-C8B6-4F59-B22E-EEAB6DABAA11@netlab.uky.edu> When I think about Bob's question in today's world of virtualization, delivering a datagram to a particular Sub-Network Point of Attachment seems kind of anachronistic. Isn't the idea that a destination (application) resides on a particular computer, behind a particular interface, at best a [in]convenient fiction in many data centers? The advantage of hiding the higher-level demux handle from IP was presumably so the network layer infrastructure could deal with smaller addresses. That need has clearly vanished. Thought experiment: suppose we simply declare tomorrow that the protocol and source-destination port pair are henceforth part of the destination IP address, and that the IP layer's job is to deliver a datagram to the application socket identified by the 5-tuple. The result would still be smaller than an IPv6 destination address :-). More importantly, I can't think of anything in the routing/forwarding infrastructure that would have to change immediately: a /32 would be just another prefix. (Of course, this only makes sense in a world with CIDR.) And we've known for quite a long time that layered demux at the destination has disadvantages [1]. Having the network layer deliver packets to application queues rather than "hosts" seems like it would offer advantages in terms of virtualization and mobility (the latter maybe not so much in the current architecture). [1] Tennenhouse, D. "Layered Multiplexing Considered Harmful", in Protocols for High-Speed Networks, Rudin and Williamson (Editors), North Holland, Amsterdam, 1989. Based on a presentation at IFIP WG 6.1/WG6.4 International Workshop on Protocols for High-Speed Networks, Zurich, May 1989. http://www.tns.lcs.mit.edu/publications/multiplexing89.html KC On 23 Apr 2013, at 15:24 PM, Bob Braden wrote: > During the development of TCP during the 1977-1980 period, the original C&K TCP layer was divided into a transport layer (TCP) and an internetwork layer (IP). One of the key decisions in this split was which layer should inherit the port numbers. At the time I simply accepted the group decision to put ports into the transport layer without taking time to think through the architectural implications. Has anyone ever thought through how the architecture would have been changed had ports ended up in the internetwork layer, i.e., in IP? > > Bob Braden > > From detlef.bosau at web.de Thu Apr 25 15:17:05 2013 From: detlef.bosau at web.de (Detlef Bosau) Date: Fri, 26 Apr 2013 00:17:05 +0200 Subject: [e2e] Port numbers in the network layer? In-Reply-To: <20130425195625.GI10307@virgo.local> References: <5176DFFE.50404@isi.edu> <1366853677.483822482@apps.rackspace.com> <51797A0E.5050608@isi.edu> <20130425195625.GI10307@virgo.local> Message-ID: <5179AB61.2080507@web.de> Am 25.04.2013 21:56, schrieb Hagen Paul Pfeifer: > > In theory, but in practice this do not work because not every link is Ethernet > and you may end up re-parsing the packet to determine the transport protocol > at each hop. In German, I would say: "Jein". ;-) Unfortunately, not everyone on the list understands German ;-) So: Yes and no. On the one hand you point to an interesting issue: We are a bit mixing up architectural considerations with implementation issues here. So, we shouldn't discriminate IPv4 and IPv6 by Ethertypes because other network technologies exist. On the other hand: Do you know a current technology which is actually being used that does not use Ethertypes? I don't. Even Token Ring adopted Ethertypes, if indirectly using SNAP, years ago. The more interesing observation is that TCP and IP "divorced" rather late. And from my point of view, I'm interested in congestion control, the very issue here is: Is congestion a phenomenon for transport protocols? Or is congestion a network issue? Actually, there are different positions here on this issue in literature. This becomes quite obvious in the congavoid paper, where VJ talks about TCP (or it's DecNET or OSI equivalents repsectively) and keeps quiet about the existence of other protocols. While in the same paper congestion is actually a network issue. When we investigate where congestion occurs, congestion occurs in buffers. Particularly in those which belong to the network layer. So we carefully fix a problem on the network layer by means of the transport layer - and discuss "proper layering" in this thread. The major strategy in the congavoid paper is the "conservation principle". And where the conservation principle may hold on a certain network link - however, VJ obeys this principle by pursuing an "equilibrium" there mere existence of which is highly questionable in some cases, while he (not knowing it's existence at all) asks the question how large a "sending window" may be - simply ignoring that the sending window on transport layer is not necessarily the capacity of the link (in the sense of the often mentioned "bandwidth delay product"....) on the network layer. We have a certain mess here. BTW, in Keshav's thesis (I'm still to read some parts) congestion as such is a network layer issue while on the transport layer, a flow defines a congestion criterion. In my opinion it would have been better not to talk about "congestion" here but to talk about "resource scheduling" on the network layer here and to talk about "expectations to the network by the application" on transport layer here. The very interesting point here is, that we do routing on network layer. And talk about path transparency from the transport layer's view point. That's, in decent words, a bit unfortunate: Of course, I have absolutely no interest to route packets belonging to the same stream along a path which doesn't match my requirements! To determine a path without the least consideration of the application's requirements is at least questionable. (It's StarTrek networking: "To boldly go.....") (To our non German friends: In Germany, it's about to be called "Throttlekom Networking", with respect to one of our major ISPs in Germany, called "Throttlekom". Formerly known as "German Telekom" which is about to change it's traffic policies and SLA ... This is particularly important for network simulation and underlines DPR's emphasis on user's behaviour. German Telekom is about to change a user's access link's properties depending on the user's download behaviour..., Refer to http://www.spiegel.de/international/business/government-wary-of-telekom-limits-on-flat-rate-dsl-access-a-896435.html for details) So I see our next loss differentiation problem: I loss a consequence of congestion, corruption or are "spurious timeouts" perhaps a consequence of the German Throttlekom reconfiguring my Internet access link? However, I think that the TCP/IP separation and the layering together with VJCC raises some questions which perhaps leave room for some research. From l.wood at surrey.ac.uk Thu Apr 25 18:00:39 2013 From: l.wood at surrey.ac.uk (l.wood@surrey.ac.uk) Date: Fri, 26 Apr 2013 02:00:39 +0100 Subject: [e2e] Port numbers in the network layer? In-Reply-To: <5179AB61.2080507@web.de> References: <5176DFFE.50404@isi.edu> <1366853677.483822482@apps.rackspace.com> <51797A0E.5050608@isi.edu> <20130425195625.GI10307@virgo.local>,<5179AB61.2080507@web.de> Message-ID: <290E20B455C66743BE178C5C84F12408223F494E82@EXMB01CMS.surrey.ac.uk> > On the other hand: Do you know a current technology which is actually > being used that does not use Ethertypes? CANbus, SpaceWire, CCSDS, RapidIO, (A)X.25... But you can always layer (Cisco) HDLC or HDLC/ Frame Relay across any of these to get an Ethertype. Or lobby SpaceWire to put a value in their single-byte not-an-Ethertype field. (The CCSDS community finds the thought of layering HDLC over CCSDS especially abhorrent, because it cuts down their custom engineering, and any layering or modularity is considered to be inefficiency.) Lloyd Wood http://sat-net.com/L.Wood/ From detlef.bosau at web.de Fri Apr 26 03:01:14 2013 From: detlef.bosau at web.de (Detlef Bosau) Date: Fri, 26 Apr 2013 12:01:14 +0200 Subject: [e2e] Port numbers in the network layer? In-Reply-To: <290E20B455C66743BE178C5C84F12408223F494E82@EXMB01CMS.surrey.ac.uk> References: <5176DFFE.50404@isi.edu> <1366853677.483822482@apps.rackspace.com> <51797A0E.5050608@isi.edu> <20130425195625.GI10307@virgo.local>, <5179AB61.2080507@web.de> <290E20B455C66743BE178C5C84F12408223F494E82@EXMB01CMS.surrey.ac.uk> Message-ID: <517A506A.8090401@web.de> Am 26.04.2013 03:00, schrieb l.wood at surrey.ac.uk: >> On the other hand: Do you know a current technology which is actually >> being used that does not use Ethertypes? > CANbus, SpaceWire, CCSDS, RapidIO, (A)X.25... Oh, yes :-) I'm sorry about that... Additional question: Can you tell me which car uses TCP over CANbus, e.g. to control his lamps? ;-) But you made an important point: My view on this matter is too simplistic. > > But you can always layer (Cisco) HDLC or HDLC/ Frame Relay across any > of these to get an Ethertype. Or lobby SpaceWire to put a value in > their single-byte not-an-Ethertype field. At least we have do agree on talking about "packet switching networks" in a quite narrow sense here, when it comes to Ethertypes. E.g. X.25 to my understanding is circuit switched. The packet switching view is mounted upon the top ;-) The same holds true for Frame Relay in a sense, however in FR the whole packets are switched IIRC and not subdivided into smaller pieces. However, this is in fact a discussion of implementation issues. > > (The CCSDS community finds the thought of layering HDLC over CCSDS > especially abhorrent, because it cuts down their custom engineering, > and any layering or modularity is considered to be inefficiency.) At least, it is not a "holy cow". Layers should assist network design. And not the other way round. > > > > From jnc at mercury.lcs.mit.edu Fri Apr 26 06:26:19 2013 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Fri, 26 Apr 2013 09:26:19 -0400 (EDT) Subject: [e2e] Port numbers in the network layer? Message-ID: <20130426132619.F30E518C0FB@mercury.lcs.mit.edu> > From: Detlef Bosau > X.25 to my understanding is circuit switched. ... The same holds true > for Frame Relay in a sense, however in FR the whole packets are switched > IIRC and not subdivided into smaller pieces. That's not the most important characteristic of 'circuit switched', and in fact, to me 'circuit switched' is characterized by a number of things (i.e. it's not a single characteristic, but a suite of them). So, for instance, when I head 'circuit switched', I think of things like 'per-connection state _in the network_ (not just at the hosts)', 'setup required _in the network_ before communication can happen', 'reliability is _in the network_, not done by the hosts'. An important corollary is that there are a whole range of different things which are not "circuit switched", but still have _some_ of the characteristics that define that model. So Frame Relay has some of these aspects - but so did the ARPANET. At one point, Dave Clark started this concept that 'pure packet switched models have some advantages, but some disadvantges, and pure circuit switched models have some advantages, but some disadvantges, and the way to get all the advantages and (mostly) none of the disadvantages is to have something which is mid-way between the two'. So things like RSVP, for instance, bring some (not all!) of the hallmarks of circuit switching into the packet switching world. But "circuit switched" != "not packet switched"! The world is bigger than that... Noel From jon.crowcroft at cl.cam.ac.uk Fri Apr 26 07:33:47 2013 From: jon.crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Fri, 26 Apr 2013 09:33:47 -0500 Subject: [e2e] Port numbers in the network layer? In-Reply-To: <517A506A.8090401@web.de> References: <5176DFFE.50404@isi.edu> <1366853677.483822482@apps.rackspace.com> <51797A0E.5050608@isi.edu> <20130425195625.GI10307@virgo.local> <5179AB61.2080507@web.de> <290E20B455C66743BE178C5C84F12408223F494E82@EXMB01CMS.surrey.ac.uk> <517A506A.8090401@web.de> Message-ID: x.25 provides a network service which is modelled as a non multiplexed, in-order loss-less, flow controlled packet delivery which is known as a "virtual" circuit - in fact, from the end host perspective, that looks very much like the service that a stream socket gives except that you need a multiplexing layer if you want multiple host associations...(i.e. iso tp0) inside the network, you do NOT have to preserve e2e packet ordering or reliability (i.e. you don't HAVE to do hop by hop ordering, loss recovery or flow control, although layer 2 flow control can help with the latter micro-protocol part of the X.25 service) - some implemenations of X.25 actually did a datagram network inside the network, and did end-to-end protocol work (strictly. NIC-to-NIC) to fix up missing packets and ordering etc... most x.25 switches, tho, did do op-by-hop work, which made them cumbersome, slow, expensive, and also, remember back in the 1970s, people wrote a lot of code in very low level languages (macro 11, various uglier assembers...later on perhaps C) which made software incredibly hard to get right so having a lot of complex protocol code in a switch in the net was a v. bad idea then (nowadays you might get away with it, hence SDN/Openflow and the proliferation of middle boxen- not all there for bad reasons)... note the model of "end2end" being NIC-to-NIC (rather than host to host) means that you don't get real e2e reliability out of X.25 since the semantics are (as per telephone semantics) delivery to the "socket on the wall" not to the ear of the human (i.e. a phone with a broken mike&speaker, or a host that has errorered memory ) note this is not especialyl bad since TCP (when used by an app) delivers data to the socket queue - if the app fails to write it to disk (or render to screen) correctly, TCP can't know (of course, the person holding the phone handset might be deaf, dumb or not speak the same language as the speaker at the other end:) hence the semantics of ends are in the eye of the beholder imho On Fri, Apr 26, 2013 at 5:01 AM, Detlef Bosau wrote: > Am 26.04.2013 03:00, schrieb l.wood at surrey.ac.uk: > > On the other hand: Do you know a current technology which is actually >>> being used that does not use Ethertypes? >>> >> CANbus, SpaceWire, CCSDS, RapidIO, (A)X.25... >> > > Oh, yes :-) > > I'm sorry about that... > > Additional question: Can you tell me which car uses TCP over CANbus, e.g. > to control his lamps? ;-) > > > But you made an important point: My view on this matter is too simplistic. > > >> But you can always layer (Cisco) HDLC or HDLC/ Frame Relay across any >> of these to get an Ethertype. Or lobby SpaceWire to put a value in >> their single-byte not-an-Ethertype field. >> > > At least we have do agree on talking about "packet switching networks" in > a quite narrow sense here, when it comes to Ethertypes. > > E.g. X.25 to my understanding is circuit switched. The packet switching > view is mounted upon the top ;-) The same holds true for Frame Relay in a > sense, however in FR the whole packets are switched IIRC and not subdivided > into smaller pieces. > > However, this is in fact a discussion of implementation issues. > > >> (The CCSDS community finds the thought of layering HDLC over CCSDS >> especially abhorrent, because it cuts down their custom engineering, >> and any layering or modularity is considered to be inefficiency.) >> > > At least, it is not a "holy cow". Layers should assist network design. And > not the other way round. > >> >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20130426/4864f11b/attachment.html From detlef.bosau at web.de Fri Apr 26 07:45:55 2013 From: detlef.bosau at web.de (Detlef Bosau) Date: Fri, 26 Apr 2013 16:45:55 +0200 Subject: [e2e] Port numbers in the network layer? In-Reply-To: <20130426132619.F30E518C0FB@mercury.lcs.mit.edu> References: <20130426132619.F30E518C0FB@mercury.lcs.mit.edu> Message-ID: <517A9323.9050902@web.de> Am 26.04.2013 15:26, schrieb Noel Chiappa: > > From: Detlef Bosau > > > X.25 to my understanding is circuit switched. ... The same holds true > > for Frame Relay in a sense, however in FR the whole packets are switched > > IIRC and not subdivided into smaller pieces. > > That's not the most important characteristic of 'circuit switched', and in > fact, to me 'circuit switched' is characterized by a number of things (i.e. > it's not a single characteristic, but a suite of them). > > So, for instance, when I head 'circuit switched', I think of things like > 'per-connection state _in the network_ (not just at the hosts)', 'setup > required _in the network_ before communication can happen', 'reliability is > _in the network_, not done by the hosts'. Exactly. And AFAIK exactly this holds true for X.25 and FR. And yes, as far as I dealt with FR, any connection was to be set up throughout the whole network before it could be used. There was no such thing like a "routing table" but there was a per connection switching table. > > An important corollary is that there are a whole range of different things > which are not "circuit switched", but still have _some_ of the characteristics > that define that model. So Frame Relay has some of these aspects - but so did > the ARPANET. > > At one point, Dave Clark started this concept that 'pure packet switched > models have some advantages, but some disadvantges, and pure circuit switched > models have some advantages, but some disadvantges, and the way to get all the > advantages and (mostly) none of the disadvantages is to have something which > is mid-way between the two'. So it is a trade off ;-) As always ;-) > > So things like RSVP, for instance, bring some (not all!) of the hallmarks of > circuit switching into the packet switching world. But "circuit switched" != > "not packet switched"! The world is bigger than that... Of course. Your point to RSVP is interesting here, particularly from the aspect that RSVP did not really invent something that ground breaking new, but mapped existing mechanisms into the world of packet switching. And with respect to the context of our discussion, we talked about Ethertypes here and to which degree some (switching) node must analyze packet headers in order to properly process a packet, and in a somewhat broader context the discussion was whether port numbers should be placed on transport layer or on network layer, it shows that perhaps not only me tends to oversimplify things - while at the same time dealing with too much details wouldn't make thins easier. Sometimes, we have to make agreements. And, e.g., port numbers on the transport layer have worked fine for about 35 years now. (Is this correct?) So there must be extremely compelling reasons to restart this discussion. From detlef.bosau at web.de Fri Apr 26 09:22:02 2013 From: detlef.bosau at web.de (Detlef Bosau) Date: Fri, 26 Apr 2013 18:22:02 +0200 Subject: [e2e] Port numbers in the network layer? In-Reply-To: References: <5176DFFE.50404@isi.edu> <1366853677.483822482@apps.rackspace.com> <51797A0E.5050608@isi.edu> <20130425195625.GI10307@virgo.local> <5179AB61.2080507@web.de> <290E20B455C66743BE178C5C84F12408223F494E82@EXMB01CMS.surrey.ac.uk> <517A506A.8090401@web.de> Message-ID: <517AA9AA.7060906@web.de> Am 26.04.2013 16:33, schrieb Jon Crowcroft: > x.25 provides a network service which is modelled as a non > multiplexed, in-order loss-less, flow controlled packet delivery which > is known as a "virtual" circuit - in fact, from the end host > perspective, that looks very much like the service that a stream > socket gives except that you need a multiplexing layer if you want > multiple host associations...(i.e. iso tp0) > > inside the network, you do NOT have to preserve e2e packet ordering or > reliability (i.e. you don't HAVE to do hop by hop ordering, loss > recovery or flow control, although layer 2 flow control can help with > the latter micro-protocol part of the X.25 service) - some > implemenations of X.25 actually did a datagram network inside the > network, and did end-to-end protocol work (strictly. NIC-to-NIC) to > fix up missing packets and ordering etc... Q: Was loss recovery (although being rarely necessary due to very robust line- and channel coding) done only hop to hop? Including the possibility of a head-of-line blocking for the flow? (If I may ask, but to find this in the specification is extremely cumbersome....) .... > > note the model of "end2end" being NIC-to-NIC (rather than host to > host) means that you don't get real e2e reliability out of X.25 since > the semantics are (as per telephone semantics) delivery to the "socket > on the wall" not to the ear of the human (i.e. a phone with a broken > mike&speaker, or a host that has errorered memory ) Interesting point, however the model in TCP is "socket-to-socket". There is no means to detect (or even correct) errors between application and socket, neither at the sender nor at the receiver. (I well know that the residual risk of errors here is /extremely/ small.) > > note this is not especialyl bad since TCP (when used by an app) > delivers data to the socket queue - if the app fails to write it to > disk (or render to screen) correctly, TCP can't know Absolutely. And for this reason, we often find md5 checksums for huge files on file servers. So, when I reinstall my ubuntu from CD, I ususally dowload the iso and the md5 files and to a md5 check before burning the CD ;-) > > (of course, the person holding the phone handset might be deaf, dumb > or not speak the same language as the speaker at the other end:) Ok., so the one person speaks English, the other one American? ;-) But in that very case I would like to ad a remark on speach. (Recovery from my COMCAR experience.) In speach / voice over mobile, you don't care for a QoS in terms of bit errors or something similar, but typically for a MOS, Mean Opinon Score, which is assessed by field tests and questionnaires because you are not interested in a bit error free stream but the listener should clearly understand the speaker. > > hence the semantics of ends are in the eye of the beholder imho > > > Or in the ear ;-) Absolutely. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20130426/03cd21e4/attachment.html From jeanjour at comcast.net Fri Apr 26 10:29:58 2013 From: jeanjour at comcast.net (John Day) Date: Fri, 26 Apr 2013 13:29:58 -0400 Subject: [e2e] Port numbers in the network layer? In-Reply-To: References: <5176DFFE.50404@isi.edu> <1366853677.483822482@apps.rackspace.com> <51797A0E.5050608@isi.edu> <20130425195625.GI10307@virgo.local> <5179AB61.2080507@web.de> <290E20B455C66743BE178C5C84F12408223F494E82@EXMB01CMS.surrey.ac.uk> <517A506A.8090401@web.de> Message-ID: As Jon indicated the reliability semantics of X.25 were a bit complicated to some degree by perceived constraints on the economic desires of its supporters. Its supporters claimed that it was reliable and therefore a Transport Protocol was unnecessary. However, X.25 would under certain conditions do a Reset which would cause the loss of data, which was not recovered. This and the degree to which some believed the claims of reliability lead to OSI Transport Classes 0, 1 and 2. (Class 0, was for Study Group VIII and had the minimal placeholder header;' Class 1 was for Study Group VII, that believed users should pay for each connection and so did not support multiplexing; and Class 2, for users of X.25, who didn't want to be charged for every connection and believed that X.25 was sufficiently reliable that simpler error recovery could be used as opposed to the full capabilities of a TP4 or TCP (this latter view was in fact incorrect)). The supporters instead supported an *Application Protocol* called RTSE (Jon, do you remember the X. number?). The supporter claimed that this was a checkpoint recovery-like service for something like file transfer. This strategy met the constraints (or at least they thought so) to let them pursue their economic desires. However, if one looked at the specifics of the protocol (time constants, etc.), it was clear that this was a Transport Protocol in the Application Layer. Take care, John At 9:33 AM -0500 4/26/13, Jon Crowcroft wrote: >x.25 provides a network service which is modelled as a non >multiplexed, in-order loss-less, flow controlled packet delivery >which is known as a "virtual" circuit - in fact, from the end host >perspective, that looks very much like the service that a stream >socket gives except that you need a multiplexing layer if you want >multiple host associations...(i.e. iso tp0) > >inside the network, you do NOT have to preserve e2e packet ordering >or reliability (i.e. you don't HAVE to do hop by hop ordering, loss >recovery or flow control, although layer 2 flow control can help >with the latter micro-protocol part of the X.25 service) - some >implemenations of X.25 actually did a datagram network inside the >network, and did end-to-end protocol work (strictly. NIC-to-NIC) to >fix up missing packets and ordering etc... > >most x.25 switches, tho, did do op-by-hop work, which made them >cumbersome, slow, expensive, and also, remember back in the 1970s, >people wrote a lot of code in very low level languages (macro 11, >various uglier assembers...later on perhaps C) which made software >incredibly hard to get right so having a lot of complex protocol >code in a switch in the net was a v. bad idea then (nowadays you >might get away with it, hence SDN/Openflow and the proliferation of >middle boxen- not all there for bad reasons)... > >note the model of "end2end" being NIC-to-NIC (rather than host to >host) means that you don't get real e2e reliability out of X.25 >since the semantics are (as per telephone semantics) delivery to the >"socket on the wall" not to the ear of the human (i.e. a phone with >a broken mike&speaker, or a host that has errorered memory ) > >note this is not especialyl bad since TCP (when used by an app) >delivers data to the socket queue - if the app fails to write it to >disk (or render to screen) correctly, TCP can't know > >(of course, the person holding the phone handset might be deaf, dumb >or not speak the same language as the speaker at the other end:) > >hence the semantics of ends are in the eye of the beholder imho > > > > >On Fri, Apr 26, 2013 at 5:01 AM, Detlef Bosau ><detlef.bosau at web.de> wrote: > >Am 26.04.2013 03:00, schrieb >l.wood at surrey.ac.uk: > >On the other hand: Do you know a current technology which is actually >being used that does not use Ethertypes? > >CANbus, SpaceWire, CCSDS, RapidIO, (A)X.25... > > >Oh, yes :-) > >I'm sorry about that... > >Additional question: Can you tell me which car uses TCP over CANbus, >e.g. to control his lamps? ;-) > > >But you made an important point: My view on this matter is too simplistic. > > >But you can always layer (Cisco) HDLC or HDLC/ Frame Relay across any >of these to get an Ethertype. Or lobby SpaceWire to put a value in >their single-byte not-an-Ethertype field. > > >At least we have do agree on talking about "packet switching >networks" in a quite narrow sense here, when it comes to Ethertypes. > >E.g. X.25 to my understanding is circuit switched. The packet >switching view is mounted upon the top ;-) The same holds true for >Frame Relay in a sense, however in FR the whole packets are switched >IIRC and not subdivided into smaller pieces. > >However, this is in fact a discussion of implementation issues. > > >(The CCSDS community finds the thought of layering HDLC over CCSDS >especially abhorrent, because it cuts down their custom engineering, >and any layering or modularity is considered to be inefficiency.) > > >At least, it is not a "holy cow". Layers should assist network >design. And not the other way round. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20130426/293dac48/attachment-0001.html From detlef.bosau at web.de Fri Apr 26 12:27:38 2013 From: detlef.bosau at web.de (Detlef Bosau) Date: Fri, 26 Apr 2013 21:27:38 +0200 Subject: [e2e] Port numbers in the network layer? In-Reply-To: References: <5176DFFE.50404@isi.edu> <1366853677.483822482@apps.rackspace.com> <51797A0E.5050608@isi.edu> <20130425195625.GI10307@virgo.local> <5179AB61.2080507@web.de> <290E20B455C66743BE178C5C84F12408223F494E82@EXMB01CMS.surrey.ac.uk> <517A506A.8090401@web.de> Message-ID: <517AD52A.9050600@web.de> So, x.25 lacks the required e-2-e reliability. Correct? Am 26.04.2013 19:29, schrieb John Day: > Re: [e2e] Port numbers in the network layer? > As Jon indicated the reliability semantics of X.25 were a bit > complicated to some degree by perceived constraints on the economic > desires of its supporters. > > Its supporters claimed that it was reliable and therefore a Transport > Protocol was unnecessary. However, X.25 would under certain conditions > do a Reset which would cause the loss of data, which was not > recovered. This and the degree to which some believed the claims of > reliability lead to OSI Transport Classes 0, 1 and 2. (Class 0, was > for Study Group VIII and had the minimal placeholder header;' Class 1 > was for Study Group VII, that believed users should pay for each > connection and so did not support multiplexing; and Class 2, for users > of X.25, who didn't want to be charged for every connection and > believed that X.25 was sufficiently reliable that simpler error > recovery could be used as opposed to the full capabilities of a TP4 or > TCP (this latter view was in fact incorrect)). > > The supporters instead supported an *Application Protocol* called RTSE > (Jon, do you remember the X. number?). The supporter claimed that > this was a checkpoint recovery-like service for something like file > transfer. This strategy met the constraints (or at least they thought > so) to let them pursue their economic desires. > > However, if one looked at the specifics of the protocol (time > constants, etc.), it was clear that this was a Transport Protocol in > the Application Layer. > > Take care, > John > > At 9:33 AM -0500 4/26/13, Jon Crowcroft wrote: >> x.25 provides a network service which is modelled as a non >> multiplexed, in-order loss-less, flow controlled packet delivery >> which is known as a "virtual" circuit - in fact, from the end host >> perspective, that looks very much like the service that a stream >> socket gives except that you need a multiplexing layer if you want >> multiple host associations...(i.e. iso tp0) >> >> inside the network, you do NOT have to preserve e2e packet ordering >> or reliability (i.e. you don't HAVE to do hop by hop ordering, loss >> recovery or flow control, although layer 2 flow control can help with >> the latter micro-protocol part of the X.25 service) - some >> implemenations of X.25 actually did a datagram network inside the >> network, and did end-to-end protocol work (strictly. NIC-to-NIC) to >> fix up missing packets and ordering etc... >> >> most x.25 switches, tho, did do op-by-hop work, which made them >> cumbersome, slow, expensive, and also, remember back in the 1970s, >> people wrote a lot of code in very low level languages (macro 11, >> various uglier assembers...later on perhaps C) which made software >> incredibly hard to get right so having a lot of complex protocol code >> in a switch in the net was a v. bad idea then (nowadays you might get >> away with it, hence SDN/Openflow and the proliferation of middle >> boxen- not all there for bad reasons)... >> >> note the model of "end2end" being NIC-to-NIC (rather than host to >> host) means that you don't get real e2e reliability out of X.25 since >> the semantics are (as per telephone semantics) delivery to the >> "socket on the wall" not to the ear of the human (i.e. a phone with a >> broken mike&speaker, or a host that has errorered memory ) >> >> note this is not especialyl bad since TCP (when used by an app) >> delivers data to the socket queue - if the app fails to write it to >> disk (or render to screen) correctly, TCP can't know >> >> (of course, the person holding the phone handset might be deaf, dumb >> or not speak the same language as the speaker at the other end:) >> >> hence the semantics of ends are in the eye of the beholder imho >> >> >> >> >> On Fri, Apr 26, 2013 at 5:01 AM, Detlef Bosau > > wrote: >> >> Am 26.04.2013 03 :00, schrieb >> l.wood at surrey.ac.uk : >> >> >> On the other hand: Do you know a current technology which >> is actually >> being used that does not use Ethertypes? >> >> >> CANbus, SpaceWire, CCSDS, RapidIO, (A)X.25... >> >> >> Oh, yes :-) >> >> I'm sorry about that... >> >> Additional question: Can you tell me which car uses TCP over >> CANbus, e.g. to control his lamps? ;-) >> >> >> But you made an important point: My view on this matter is too >> simplistic. >> >> >> >> But you can always layer (Cisco) HDLC or HDLC/ Frame Relay >> across any >> of these to get an Ethertype. Or lobby SpaceWire to put a >> value in >> their single-byte not-an-Ethertype field. >> >> >> At least we have do agree on talking about "packet switching >> networks" in a quite narrow sense here, when it comes to Ethertypes. >> >> E.g. X.25 to my understanding is circuit switched. The packet >> switching view is mounted upon the top ;-) The same holds true >> for Frame Relay in a sense, however in FR the whole packets are >> switched IIRC and not subdivided into smaller pieces. >> >> However, this is in fact a discussion of implementation issues. >> >> >> >> (The CCSDS community finds the thought of layering HDLC over >> CCSDS >> especially abhorrent, because it cuts down their custom >> engineering, >> and any layering or modularity is considered to be inefficiency.) >> >> >> At least, it is not a "holy cow". Layers should assist network >> design. And not the other way round. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20130426/0348690c/attachment.html From jeanjour at comcast.net Fri Apr 26 12:39:12 2013 From: jeanjour at comcast.net (John Day) Date: Fri, 26 Apr 2013 15:39:12 -0400 Subject: [e2e] Port numbers in the network layer? In-Reply-To: <517AD52A.9050600@web.de> References: <5176DFFE.50404@isi.edu> <1366853677.483822482@apps.rackspace.com> <51797A0E.5050608@isi.edu> <20130425195625.GI10307@virgo.local> <5179AB61.2080507@web.de> <290E20B455C66743BE178C5C84F12408223F494E82@EXMB01CMS.surrey.ac.uk> <517A506A.8090401@web.de> <517AD52A.9050600@web.de> Message-ID: X.25 does not provide the same reliability that TCP or TP4 does. As Jon described, it is important to note that X.25 is an *interface* protocol in the ITU sense of interface. It only specifies behavior between the DTE (host) and DCE (first router). For some implementations (e.g. the French Transpac) this meant only that an ack meant that first DCE (router) got your packet; in Datapac (the Canadian offereing) an ack meant that the last DCE (router) got your packet; and in Telenet (the US offering), an ack meant that the remote host had acked the packet. However, even with the Telenet interpretation, a Reset would cause the loss of packets that were not recovered. At 9:27 PM +0200 4/26/13, Detlef Bosau wrote: >So, x.25 lacks the required e-2-e reliability. Correct? > > > >Am 26.04.2013 19:29, schrieb John Day: > >>Re: [e2e] Port numbers in the network layer? >>As Jon indicated the reliability semantics of X.25 were a bit >>complicated to some degree by perceived constraints on the economic >>desires of its supporters. >> >>Its supporters claimed that it was reliable and therefore a >>Transport Protocol was unnecessary. However, X.25 would under >>certain conditions do a Reset which would cause the loss of data, >>which was not recovered. This and the degree to which some >>believed the claims of reliability lead to OSI Transport Classes 0, >>1 and 2. (Class 0, was for Study Group VIII and had the minimal >>placeholder header;' Class 1 was for Study Group VII, that believed >>users should pay for each connection and so did not support >>multiplexing; and Class 2, for users of X.25, who didn't want to be >>charged for every connection and believed that X.25 was >>sufficiently reliable that simpler error recovery could be used as >>opposed to the full capabilities of a TP4 or TCP (this latter view >>was in fact incorrect)). >> >>The supporters instead supported an *Application Protocol* called >>RTSE (Jon, do you remember the X. number?). The supporter claimed >>that this was a checkpoint recovery-like service for something like >>file transfer. This strategy met the constraints (or at least they >>thought so) to let them pursue their economic desires. >> >>However, if one looked at the specifics of the protocol (time >>constants, etc.), it was clear that this was a Transport Protocol >>in the Application Layer. >> >>Take care, >>John >> >>At 9:33 AM -0500 4/26/13, Jon Crowcroft wrote: >> >>>x.25 provides a network service which is modelled as a non >>>multiplexed, in-order loss-less, flow controlled packet delivery >>>which is known as a "virtual" circuit - in fact, from the end host >>>perspective, that looks very much like the service that a stream >>>socket gives except that you need a multiplexing layer if you want >>>multiple host associations...(i.e. iso tp0) >>> >>> >>>inside the network, you do NOT have to preserve e2e packet >>>ordering or reliability (i.e. you don't HAVE to do hop by hop >>>ordering, loss recovery or flow control, although layer 2 flow >>>control can help with the latter micro-protocol part of the X.25 >>>service) - some implemenations of X.25 actually did a datagram >>>network inside the network, and did end-to-end protocol work >>>(strictly. NIC-to-NIC) to fix up missing packets and ordering >>>etc... >>> >>> >>>most x.25 switches, tho, did do op-by-hop work, which made them >>>cumbersome, slow, expensive, and also, remember back in the 1970s, >>>people wrote a lot of code in very low level languages (macro 11, >>>various uglier assembers...later on perhaps C) which made software >>>incredibly hard to get right so having a lot of complex protocol >>>code in a switch in the net was a v. bad idea then (nowadays you >>>might get away with it, hence SDN/Openflow and the proliferation >>>of middle boxen- not all there for bad reasons)... >>> >>> >>>note the model of "end2end" being NIC-to-NIC (rather than host to >>>host) means that you don't get real e2e reliability out of X.25 >>>since the semantics are (as per telephone semantics) delivery to >>>the "socket on the wall" not to the ear of the human (i.e. a phone >>>with a broken mike&speaker, or a host that has errorered memory ) >>> >>> >>>note this is not especialyl bad since TCP (when used by an app) >>>delivers data to the socket queue - if the app fails to write it >>>to disk (or render to screen) correctly, TCP can't know >>> >>> >>>(of course, the person holding the phone handset might be deaf, >>>dumb or not speak the same language as the speaker at the other >>>end:) >>> >>> >>>hence the semantics of ends are in the eye of the beholder imho >>> >>> >>> >>> >>> >>>On Fri, Apr 26, 2013 at 5:01 AM, Detlef Bosau >>><detlef.bosau at web.de> wrote: >>> >>>Am 26.04.2013 03:00, schrieb >>>l.wood at surrey.ac.uk: >>> >>> >>>On the other hand: Do you know a current technology which is actually >>>being used that does not use Ethertypes? >>> >>> >>>CANbus, SpaceWire, CCSDS, RapidIO, (A)X.25... >>> >>> >>>Oh, yes :-) >>> >>>I'm sorry about that... >>> >>>Additional question: Can you tell me which car uses TCP over >>>CANbus, e.g. to control his lamps? ;-) >>> >>> >>>But you made an important point: My view on this matter is too simplistic. >>> >>> >>> >>>But you can always layer (Cisco) HDLC or HDLC/ Frame Relay across any >>>of these to get an Ethertype. Or lobby SpaceWire to put a value in >>>their single-byte not-an-Ethertype field. >>> >>> >>>At least we have do agree on talking about "packet switching >>>networks" in a quite narrow sense here, when it comes to >>>Ethertypes. >>> >>>E.g. X.25 to my understanding is circuit switched. The packet >>>switching view is mounted upon the top ;-) The same holds true for >>>Frame Relay in a sense, however in FR the whole packets are >>>switched IIRC and not subdivided into smaller pieces. >>> >>>However, this is in fact a discussion of implementation issues. >>> >>> >>> >>>(The CCSDS community finds the thought of layering HDLC over CCSDS >>>especially abhorrent, because it cuts down their custom engineering, >>>and any layering or modularity is considered to be inefficiency.) >>> >>> >>>At least, it is not a "holy cow". Layers should assist network >>>design. And not the other way round. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20130426/7b5dc5fb/attachment-0001.html From christian.tschudin at unibas.ch Fri Apr 26 14:01:41 2013 From: christian.tschudin at unibas.ch (christian.tschudin@unibas.ch) Date: Fri, 26 Apr 2013 23:01:41 +0200 (CEST) Subject: [e2e] flat (was Re: Port numbers in the network layer? In-Reply-To: <517A9323.9050902@web.de> References: <20130426132619.F30E518C0FB@mercury.lcs.mit.edu> <517A9323.9050902@web.de> Message-ID: On Fri, 26 Apr 2013, Detlef Bosau wrote: > ... port numbers on the transport layer have worked fine for about 35 > years now. (Is this correct?) So there must be extremely compelling > reasons to restart this discussion. the past not being the reason, the reason must lie in the future, which is: no ports at all, and names instead of port numbers. If at Bob's time ports were chosen to be encoded in ASCIZ instead of a 16 bit integer, many nice conflations would have been possible, architectural IP oddities cleaned up, connectionless web servers at IP level could have emerged and the bang path would still be with us. Some fun addr+"port" examples for such a one-layer IP network: 10.0.0.1:ping?reply-to=my_asciz_name_instead_of_port_here 10.0.0.2:echo?say=look at me look at me I'm on e2e 127.0.0.1:/index.html 0.0.0.0:arp?who-has=192.168.1.1&tell=eth(27:18:28:18:28:45):me 192.168.1.1:dns?www.google.com&t=mx 192.168.1.1:!my:path!to:the!open:dns?holy.cow 192.168.1.1:eval(dns?www.google.com)!i_feel_lucky?but I forgot the question Port-less is not really new and links back to Bob: it's an instance of a role based architecture, makes the world look flat again, like SDN. best, christian --- Prof. Dr. Christian F. Tschudin Uni Basel | Head of Dept of Mathematics and Computer Science From jeanjour at comcast.net Fri Apr 26 15:30:11 2013 From: jeanjour at comcast.net (John Day) Date: Fri, 26 Apr 2013 18:30:11 -0400 Subject: [e2e] Port numbers in the network layer? In-Reply-To: <51797A0E.5050608@isi.edu> References: <5176DFFE.50404@isi.edu> <1366853677.483822482@apps.rackspace.com> <51797A0E.5050608@isi.edu> Message-ID: At 11:46 AM -0700 4/25/13, Joe Touch wrote: >One issue is the need for ports; there's a summary of that here: > >http://tools.ietf.org/html/draft-ietf-tsvwg-port-use-01 > >Its use evolved to overload: > > - part of the stream identifier used to associate groups > of packets (with IP addresses) The source and destination port-ids form a connection(flow)-identifier. There had been experimentation with this in various protocols at the time. Some had a single field, where the source numbered from one end and the destination from the other end hoping they would not meet in the middle. The idea of simply concatenating locally unique identifiers became the common usage. > > - an identifier for the upper layer protocol (service) > (the dest port, in all UDP packets or in the TCP SYN) Actually, it does not identify the upper protocol or application, but a path to the upper protocol or application. It is significant that this identified the type but there was no means (unless application specific) to establish communication with a particular instance of an application. The use as a so-called well-known port was carried over from an early ARPANET shortcut. This is equivalent to the early OS practice of reserving memory locations in low memory as jump points for applications. OSs got beyond this. Networks never did. As the reference above indicates there was consideration of names for applications and a "telephone book" or directory, which corroborates that most of us knew well-known ports were a kludge when we did them 40 years ago. It is just too bad, they weren't retired when we had a chance to. As I have said, they are the OS equivalent of jump points in low memory! How incredibly primitive! ;-) That was a bad idea in OSs even way back when I started!! >FWIW, one way to decouple these two was described here: > >http://www.isi.edu/touch/pubs/draft-touch-tcp-portnames-00.txt > >It seems fairly clear that a layered architecture needs agreement on >what the layers are. Indications of a particular layer sequence can >occur anywhere - in band at any layer, or out of band. Actually it doesn't. A complete layered architecture can create layers on the fly as necessary. Actually this proposal would have still made them rooted on the IP address, i.e. the portname was a path to the application, not the name of the application. > >Consider that ethernet ethertype 0x0800 was originally intended to >mean "IP", allowing the IP version number to be determined at the IP >layer, but packet demuxing efficiency concerns resulted in a new >ethertype for IPv6 (0x86DD). So the ethertype includes not only the >upper layer protocol, but it's redundant with the version at the >next layer. Or perhaps IEEE was noting that since the only common fields between IPv4 and IPv6 was the version field that for all practical purposes they were different protocols. ;-) >Similarly we could allocate a new ethertype to "IPv4:TCP" or "IPv4:SCTP". What about IPv4:TCP1 thru IPv4:TCP1000? > >So any "mix and match" architecture needs to have some indication of >what the particular mix is, but it need not be cascaded >layer-by-layer. If I understand what you mean by "some indication" I would have to say no it is not required. Take care, John > >Joe From jeanjour at comcast.net Fri Apr 26 15:30:24 2013 From: jeanjour at comcast.net (John Day) Date: Fri, 26 Apr 2013 18:30:24 -0400 Subject: [e2e] Port numbers in the network layer? In-Reply-To: <517984E5.2000906@web.de> References: <5176DFFE.50404@isi.edu> <1366853677.483822482@apps.rackspace.com> <517984E5.2000906@web.de> Message-ID: At 9:32 PM +0200 4/25/13, Detlef Bosau wrote: >Am 25.04.2013 14:52, schrieb John Day: > >>Re: [e2e] Port numbers in the network layer? >>The question is why is a protocol-id field required in some >>protocols and not others. >> >>If it is to identify the protocol in the layer above, then how many >>thousand SCTP instances can I identify on top of a single IP >>instance. If it identifies the protocol, then that should be >>possible. Obviously it isn't what it is intended for. >> > >So, what is, concisely, the problem and your proposed solution? Problem? What problem? No one suggested there was a problem. The question was about the distinction between protocol-id fields and port-ids. I explained the difference and what the function of the protocol-id field was as opposed to the purpose of source and destination port-ids. It is the case that the protocol-id field does have the rather disturbing property of requiring an (N)-protocol to have information about (N+1)-protocols, while port-ids provide better isolation. One of the implications of Watson's work is that port-id and connection-endpoint-ids should be distinct. This has a number of benefits. > >Up to know, each individual TCP connection is uniquely identified by >an address quadruple (node 1, port 1, node 2, port2). > >Why doesn't this work? For what value of "work"? ;-) The current practice in TCP has certain security problems. These stem from the fact that port-ids and connection-endpoint ids are conflated and the use of well-known ports. The TCP server must rely on source port to distinguish connections to a well-known port. This is a number it did not generate and can be spoofed and hence creates a security vulnerability. > >And which solution works better? Taking the lessons from delta-t noted above and eliminating the need for well-known ports avoids a number of security vulnerabilities. see G. Boddapati, L. Chitkushev, J. Day, and I. Matta "Assessing the Security of a Clean-Slate Internet Architecture," Seventh Workshop on Secure Network Protocols (NPSec) October 30th, 2012. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20130426/e3d7dab8/attachment.html From touch at isi.edu Fri Apr 26 17:42:52 2013 From: touch at isi.edu (Joe Touch) Date: Fri, 26 Apr 2013 17:42:52 -0700 Subject: [e2e] Port numbers in the network layer? In-Reply-To: References: <5176DFFE.50404@isi.edu> <1366853677.483822482@apps.rackspace.com> <51797A0E.5050608@isi.edu> Message-ID: <517B1F0C.3080604@isi.edu> On 4/26/2013 3:30 PM, John Day wrote: > At 11:46 AM -0700 4/25/13, Joe Touch wrote: >> One issue is the need for ports; there's a summary of that here: >> >> http://tools.ietf.org/html/draft-ietf-tsvwg-port-use-01 >> >> Its use evolved to overload: >> >> - part of the stream identifier used to associate groups >> of packets (with IP addresses) > > The source and destination port-ids form a connection(flow)-identifier. In the Internet, the IP addresses are part of that connection ID, called the socket pair. >> - an identifier for the upper layer protocol (service) >> (the dest port, in all UDP packets or in the TCP SYN) > > Actually, it does not identify the upper protocol or application, but a > path to the upper protocol or application. It is significant that this > identified the type but there was no means (unless application specific) > to establish communication with a particular instance of an application. No protocol has a "means" to initiate connection with anything that isn't waiting for it on the other end. In this case, it would be an application listening on the socket. The assumption is both that the application is listening AND that the service (application protocol) is as expected. >> FWIW, one way to decouple these two was described here: >> >> http://www.isi.edu/touch/pubs/draft-touch-tcp-portnames-00.txt >> >> It seems fairly clear that a layered architecture needs agreement on >> what the layers are. Indications of a particular layer sequence can >> occur anywhere - in band at any layer, or out of band. > > Actually it doesn't. A complete layered architecture can create layers > on the fly as necessary. You have to have agreement on the method for doing that. Otherwise you're assigning meaning to bit patterns arbitrarily or reading minds. > Actually this proposal would have still made > them rooted on the IP address, i.e. the portname was a path to the > application, not the name of the application. The portname is the name of the protocol and the application you expect to interpret it on the other end, just as a destination port is. Yes, the resulting connections still use the current socket pair as the connection identifier, and yes, that still includes IP addresses. This was intended to be compatible with the existing Internet architecture, as noted therein. >> Consider that ethernet ethertype 0x0800 was originally intended to >> mean "IP", allowing the IP version number to be determined at the IP >> layer, but packet demuxing efficiency concerns resulted in a new >> ethertype for IPv6 (0x86DD). So the ethertype includes not only the >> upper layer protocol, but it's redundant with the version at the next >> layer. > > Or perhaps IEEE was noting that since the only common fields between > IPv4 and IPv6 was the version field that for all practical purposes they > were different protocols. ;-) That's the feature of such a version field. >> Similarly we could allocate a new ethertype to "IPv4:TCP" or "IPv4:SCTP". > > What about IPv4:TCP1 thru IPv4:TCP1000? I was clearly trying to extrapolate only different protocol stack combinations. If you're referring to variants of TCP, those could either be in a single ethertype or 1000 different ones. If you're referring to specific connections, that's a different semantic that doesn't map to my example about ethertypes. >> So any "mix and match" architecture needs to have some indication of >> what the particular mix is, but it need not be cascaded layer-by-layer. > > If I understand what you mean by "some indication" I would have to say > no it is not required. "some indication" means either a preexisting agreement at the endpoints or a label either in-band or out-of-band. You can't differentiate various types of stack combinations without any information. Joe From jeanjour at comcast.net Fri Apr 26 21:11:52 2013 From: jeanjour at comcast.net (John Day) Date: Sat, 27 Apr 2013 00:11:52 -0400 Subject: [e2e] Port numbers in the network layer? In-Reply-To: <517B1F0C.3080604@isi.edu> References: <5176DFFE.50404@isi.edu> <1366853677.483822482@apps.rackspace.com> <51797A0E.5050608@isi.edu> <517B1F0C.3080604@isi.edu> Message-ID: At 5:42 PM -0700 4/26/13, Joe Touch wrote: >On 4/26/2013 3:30 PM, John Day wrote: >>At 11:46 AM -0700 4/25/13, Joe Touch wrote: >>>One issue is the need for ports; there's a summary of that here: >>> >>>http://tools.ietf.org/html/draft-ietf-tsvwg-port-use-01 >>> >>>Its use evolved to overload: >>> >>> - part of the stream identifier used to associate groups >>> of packets (with IP addresses) >> >>The source and destination port-ids form a connection(flow)-identifier. > >In the Internet, the IP addresses are part of that connection ID, >called the socket pair. I was speaking generally. With point to point links, you can have multiple connections but no need for addresses. But a connection-id is still necessary. Strictly speaking, the proper way to define connection-id is the concatenation of the port-ids to form a connection-id that is unique within the scope of the pair of source/destination addresses. Given that IP is in a different layer than TCP that would seem to be the definition that is consistent with that construction. According to this socket pair definition then, is the connection id a Network Layer identifier or a Transport Layer identifier? > >>> - an identifier for the upper layer protocol (service) >>> (the dest port, in all UDP packets or in the TCP SYN) >> >>Actually, it does not identify the upper protocol or application, but a >>path to the upper protocol or application. It is significant that this >>identified the type but there was no means (unless application specific) >>to establish communication with a particular instance of an application. > >No protocol has a "means" to initiate connection with anything that >isn't waiting for it on the other end. In this case, it would be an >application listening on the socket. The assumption is both that the >application is listening AND that the service (application protocol) >is as expected. Do you mean the something has to be listening before the requesting application initiates the connection? In that case, it is not true. It is possible to do and there are protocols operating today that do it. Admittedly, they are not Internet protocols but that doesn't matter. > >>>FWIW, one way to decouple these two was described here: >>> >>>http://www.isi.edu/touch/pubs/draft-touch-tcp-portnames-00.txt >>> >>>It seems fairly clear that a layered architecture needs agreement on >>>what the layers are. Indications of a particular layer sequence can >>>occur anywhere - in band at any layer, or out of band. >> >>Actually it doesn't. A complete layered architecture can create layers >>on the fly as necessary. > >You have to have agreement on the method for doing that. Otherwise >you're assigning meaning to bit patterns arbitrarily or reading >minds. If you have a complete architecture handles all three phases of communication. This is possible and has been demonstrated. Again, not in the Internet, but it has been done. > >>Actually this proposal would have still made >>them rooted on the IP address, i.e. the portname was a path to the >>application, not the name of the application. > >The portname is the name of the protocol and the application you >expect to interpret it on the other end, just as a destination port >is. > >Yes, the resulting connections still use the current socket pair as >the connection identifier, and yes, that still includes IP >addresses. This was intended to be compatible with the existing >Internet architecture, as noted therein. Correct. I assumed that it was trying preserve its limitations. > >>>Consider that ethernet ethertype 0x0800 was originally intended to >>>mean "IP", allowing the IP version number to be determined at the IP >>>layer, but packet demuxing efficiency concerns resulted in a new >>>ethertype for IPv6 (0x86DD). So the ethertype includes not only the >>>upper layer protocol, but it's redundant with the version at the next >>>layer. >> >>Or perhaps IEEE was noting that since the only common fields between >>IPv4 and IPv6 was the version field that for all practical purposes they >>were different protocols. ;-) > >That's the feature of such a version field. ;-) > >>>Similarly we could allocate a new ethertype to "IPv4:TCP" or "IPv4:SCTP". >> >>What about IPv4:TCP1 thru IPv4:TCP1000? > >I was clearly trying to extrapolate only different protocol stack >combinations. If you're referring to variants of TCP, those could >either be in a single ethertype or 1000 different ones. If you're >referring to specific connections, that's a different semantic that >doesn't map to my example about ethertypes. If Protocol-id is to identify the Protocol in the layer above (and not just the syntax), then I would assume that I should be able to have multiple instances of the same protocol. For example, I might want a different one for different security domains or something like that. So why not have a few hundred of the same protocol? > >>>So any "mix and match" architecture needs to have some indication of >>>what the particular mix is, but it need not be cascaded layer-by-layer. >> >>If I understand what you mean by "some indication" I would have to say >>no it is not required. > >"some indication" means either a preexisting agreement at the >endpoints or a label either in-band or out-of-band. You can't >differentiate various types of stack combinations without any >information. You would be surprised what can happen. Take care, John >Joe From detlef.bosau at web.de Sat Apr 27 08:24:24 2013 From: detlef.bosau at web.de (Detlef Bosau) Date: Sat, 27 Apr 2013 17:24:24 +0200 Subject: [e2e] Port numbers in the network layer? In-Reply-To: References: <5176DFFE.50404@isi.edu> <1366853677.483822482@apps.rackspace.com> <51797A0E.5050608@isi.edu> <20130425195625.GI10307@virgo.local> <5179AB61.2080507@web.de> <290E20B455C66743BE178C5C84F12408223F494E82@EXMB01CMS.surrey.ac.uk> <517A506A.8090401@web.de> <517AD52A.9050600@web.de> Message-ID: <517BEDA8.8090703@web.de> Am 26.04.2013 21:39, schrieb John Day: > Re: [e2e] Port numbers in the network layer? > X.25 does not provide the same reliability that TCP or TP4 does. What is the difference? > > As Jon described, it is important to note that X.25 is an *interface* > protocol in the ITU sense of interface. In Germany, you could order an x.25 connection between site A and site B. I don't know whether this is still possible, but a few years ago, it was. To my understanding, from the user's point of view, this was a reliable character stream. Is this correct? Or do I miss something? So, where is the precise difference to what I get, when I use a "Stream Socket" in Unix? I'm just trying to figure out the system model used in the congavoid paper. That's why I'm interested in these things. -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20130427/2c243f83/attachment.html From detlef.bosau at web.de Sat Apr 27 08:27:22 2013 From: detlef.bosau at web.de (Detlef Bosau) Date: Sat, 27 Apr 2013 17:27:22 +0200 Subject: [e2e] Port numbers in the network layer? In-Reply-To: References: <5176DFFE.50404@isi.edu> <1366853677.483822482@apps.rackspace.com> <517984E5.2000906@web.de> Message-ID: <517BEE5A.2070602@web.de> Am 27.04.2013 00:30, schrieb John Day: > > One of the implications of Watson's work is that port-id and > connection-endpoint-ids should be distinct. This has a number of benefits. > Watson's work is the delta-t protocol, right? And your problem is that TCP is widely in use instead of delta-t, right? Why is delta-t better than TCP? From detlef.bosau at web.de Sun Apr 28 08:42:17 2013 From: detlef.bosau at web.de (Detlef Bosau) Date: Sun, 28 Apr 2013 17:42:17 +0200 Subject: [e2e] flat (was Re: Port numbers in the network layer? In-Reply-To: References: <20130426132619.F30E518C0FB@mercury.lcs.mit.edu> <517A9323.9050902@web.de> Message-ID: <517D4359.2000604@web.de> Am 26.04.2013 23:01, schrieb christian.tschudin at unibas.ch: > On Fri, 26 Apr 2013, Detlef Bosau wrote: > >> ... port numbers on the transport layer have worked fine for about 35 >> years now. (Is this correct?) So there must be extremely compelling >> reasons to restart this discussion. > > the past not being the reason, the reason must lie in the future, > which is: no ports at all, and names instead of port numbers. > Hang on. Neither the past nor the future is the "reason". A reason for doing something may be: - a problem, I want to solve, - a goal, I want to achieve. Although I think, that I'm quite well educated in math, to me, CS in general and in particular networking, networking is an engineering science, not pure science. So we don't create more or less useful phantasies, which some person may hopefully find useful. So, when we think about an architectural change (particularly a heavy weight change like moving port numbers to a different layer and hence changing encapsulations) we should give valid reasons for this. > If at Bob's time ports were chosen to be encoded in ASCIZ instead > of a 16 bit integer, many nice conflations would have been possible, > architectural IP oddities cleaned up, connectionless web servers > at IP level could have emerged and the bang path would still be > with us. > > Some fun addr+"port" examples for such a one-layer IP network: > > 10.0.0.1:ping?reply-to=my_asciz_name_instead_of_port_here > 10.0.0.2:echo?say=look at me look at me I'm on e2e > 127.0.0.1:/index.html > 0.0.0.0:arp?who-has=192.168.1.1&tell=eth(27:18:28:18:28:45):me > 192.168.1.1:dns?www.google.com&t=mx > 192.168.1.1:!my:path!to:the!open:dns?holy.cow > 192.168.1.1:eval(dns?www.google.com)!i_feel_lucky?but I forgot the > question > O.k., I have to admit that I just listened to VJ's talk "A new way on to look at networking". I presume VJ would lough at our discussion. While VJ tells us, we should "address" contents by name, we are nit picking about port numbers ;-) (Even more important: E.g. Van's comments on security, which has simply a different view on this issue than John who wants to armor individual conversations.) > Port-less is not really new and links back to Bob: it's an instance > of a role based architecture, makes the world look flat again, > like SDN. > Yes. However, I think we mix up perspectives here. While John misses the forest for the trees, VJ's outlook in the future and other things are, in a sense, a forest as a tree replacement ;-) As said before: CS is engineering. And we should keep the balance between nit picking on the one hand and hovering above the clouds on the other ;-) Detlef -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From kevin at masonke.com Sun Apr 28 12:11:22 2013 From: kevin at masonke.com (Kevin Mason) Date: Sun, 28 Apr 2013 15:11:22 -0400 Subject: [e2e] flat (was Re: Port numbers in the network layer? In-Reply-To: References: <20130426132619.F30E518C0FB@mercury.lcs.mit.edu> <517A9323.9050902@web.de> Message-ID: <840351FE-C8C4-4DB2-925F-92C274C8EDC6@masonke.com> While interesting, what would be the absolute benefit? The possibilities for confusion by mis-spelling alone would negate most of the gain. Plus switching variable length, essentially random character socket indicators would be a huge overhead. ~Kevin On Apr 26, 2013, at 5:01 PM, christian.tschudin at unibas.ch wrote: > On Fri, 26 Apr 2013, Detlef Bosau wrote: > >> ... port numbers on the transport layer have worked fine for about 35 years now. (Is this correct?) So there must be extremely compelling reasons to restart this discussion. > > the past not being the reason, the reason must lie in the future, > which is: no ports at all, and names instead of port numbers. > > If at Bob's time ports were chosen to be encoded in ASCIZ instead > of a 16 bit integer, many nice conflations would have been possible, > architectural IP oddities cleaned up, connectionless web servers > at IP level could have emerged and the bang path would still be > with us. > > Some fun addr+"port" examples for such a one-layer IP network: > > 10.0.0.1:ping?reply-to=my_asciz_name_instead_of_port_here > 10.0.0.2:echo?say=look at me look at me I'm on e2e > 127.0.0.1:/index.html > 0.0.0.0:arp?who-has=192.168.1.1&tell=eth(27:18:28:18:28:45):me > 192.168.1.1:dns?www.google.com&t=mx > 192.168.1.1:!my:path!to:the!open:dns?holy.cow > 192.168.1.1:eval(dns?www.google.com)!i_feel_lucky?but I forgot the question > > Port-less is not really new and links back to Bob: it's an instance > of a role based architecture, makes the world look flat again, > like SDN. > > best, christian > > --- > Prof. Dr. Christian F. Tschudin > Uni Basel | Head of Dept of Mathematics and Computer Science From touch at isi.edu Sun Apr 28 20:27:03 2013 From: touch at isi.edu (Joe Touch) Date: Sun, 28 Apr 2013 20:27:03 -0700 Subject: [e2e] Port numbers in the network layer? In-Reply-To: References: <5176DFFE.50404@isi.edu> <1366853677.483822482@apps.rackspace.com> <51797A0E.5050608@isi.edu> <517B1F0C.3080604@isi.edu> Message-ID: <517DE887.5060709@isi.edu> On 4/26/2013 9:11 PM, John Day wrote: > At 5:42 PM -0700 4/26/13, Joe Touch wrote: >> On 4/26/2013 3:30 PM, John Day wrote: >>> At 11:46 AM -0700 4/25/13, Joe Touch wrote: >>>> One issue is the need for ports; there's a summary of that here: >>>> >>>> http://tools.ietf.org/html/draft-ietf-tsvwg-port-use-01 >>>> >>>> Its use evolved to overload: >>>> >>>> - part of the stream identifier used to associate groups >>>> of packets (with IP addresses) >>> >>> The source and destination port-ids form a connection(flow)-identifier. >> >> In the Internet, the IP addresses are part of that connection ID, >> called the socket pair. > > I was speaking generally. With point to point links, you can have > multiple connections but no need for addresses. But a connection-id is > still necessary. If you want to go that far off the map, connection-id would be needed only if that multipoint link supported different connections, either concurrently or in series. > Strictly speaking, the proper way to define connection-id is the > concatenation of the port-ids to form a connection-id that is unique > within the scope of the pair of source/destination addresses. Your definition implies that a connection ID differentiates connections only within one pair of source/destination addresses. That definition precludes connections that span multiple addresses, e.g., striping, or those that can shift addresses. > Given that IP is in a different layer than TCP that would seem to be the > definition that is consistent with that construction. The TCP header includes the IP pseudoheader - notably for the purpose of connection identification. So TCP is already inconsistent with your proposed definition (it includes addresses in its connection ID, not merely as context for its connection ID), and consistent with the way I already described connections. > According to this socket pair definition then, is the connection id a > Network Layer identifier or a Transport Layer identifier? Transport layer ID that is based on a transport header that subsumes a subset of the network header. >>>> - an identifier for the upper layer protocol (service) >>>> (the dest port, in all UDP packets or in the TCP SYN) >>> >>> Actually, it does not identify the upper protocol or application, but a >>> path to the upper protocol or application. It is significant that this >>> identified the type but there was no means (unless application specific) >>> to establish communication with a particular instance of an application. >> >> No protocol has a "means" to initiate connection with anything that >> isn't waiting for it on the other end. In this case, it would be an >> application listening on the socket. The assumption is both that the >> application is listening AND that the service (application protocol) >> is as expected. > > Do you mean the something has to be listening before the requesting > application initiates the connection? In that case, it is not true. It > is possible to do and there are protocols operating today that do it. > Admittedly, they are not Internet protocols but that doesn't matter. Something has to listen in order for communication to proceed. That event need not precede the request to initiate from the other end, but it does precede the connection. ... >>>> Similarly we could allocate a new ethertype to "IPv4:TCP" or >>>> "IPv4:SCTP". >>> >>> What about IPv4:TCP1 thru IPv4:TCP1000? >> >> I was clearly trying to extrapolate only different protocol stack >> combinations. If you're referring to variants of TCP, those could >> either be in a single ethertype or 1000 different ones. If you're >> referring to specific connections, that's a different semantic that >> doesn't map to my example about ethertypes. > > If Protocol-id is to identify the Protocol in the layer above (and not > just the syntax), then I would assume that I should be able to have > multiple instances of the same protocol. It might be informative for you to explain that logic. > For example, I might want a > different one for different security domains or something like that. So > why not have a few hundred of the same protocol? It's a protocol-type, not a protocol-ID; types to not typically indicate instances. If you want an instance ID at that layer (i.e., within IP to demux different TCP instances rather than connections within one instance) you would need another field for that purpose. >>>> So any "mix and match" architecture needs to have some indication of >>>> what the particular mix is, but it need not be cascaded layer-by-layer. >>> >>> If I understand what you mean by "some indication" I would have to say >>> no it is not required. >> >> "some indication" means either a preexisting agreement at the >> endpoints or a label either in-band or out-of-band. You can't >> differentiate various types of stack combinations without any >> information. > > You would be surprised what can happen. Assertions do not surprise me; only counterexamples. ;-) Joe From touch at isi.edu Mon Apr 29 14:58:40 2013 From: touch at isi.edu (Joe Touch) Date: Mon, 29 Apr 2013 14:58:40 -0700 Subject: [e2e] flat (was Re: Port numbers in the network layer? In-Reply-To: References: <20130426132619.F30E518C0FB@mercury.lcs.mit.edu> <517A9323.9050902@web.de> Message-ID: <517EED10.30703@isi.edu> See http://www.isi.edu/touch/pubs/draft-touch-tcp-portnames-00.txt Port numbers are still useful to demultiplex multiple connections to the same service, e.g., multiple concurrent HTTP sessions. But there's no reason to couple the destination demultiplexer with the service name. Joe On 4/26/2013 2:01 PM, christian.tschudin at unibas.ch wrote: > On Fri, 26 Apr 2013, Detlef Bosau wrote: > >> ... port numbers on the transport layer have worked fine for about 35 >> years now. (Is this correct?) So there must be extremely compelling >> reasons to restart this discussion. > > the past not being the reason, the reason must lie in the future, > which is: no ports at all, and names instead of port numbers. > > If at Bob's time ports were chosen to be encoded in ASCIZ instead > of a 16 bit integer, many nice conflations would have been possible, > architectural IP oddities cleaned up, connectionless web servers > at IP level could have emerged and the bang path would still be > with us. > > Some fun addr+"port" examples for such a one-layer IP network: > > 10.0.0.1:ping?reply-to=my_asciz_name_instead_of_port_here > 10.0.0.2:echo?say=look at me look at me I'm on e2e > 127.0.0.1:/index.html > 0.0.0.0:arp?who-has=192.168.1.1&tell=eth(27:18:28:18:28:45):me > 192.168.1.1:dns?www.google.com&t=mx > 192.168.1.1:!my:path!to:the!open:dns?holy.cow > 192.168.1.1:eval(dns?www.google.com)!i_feel_lucky?but I forgot the question > > Port-less is not really new and links back to Bob: it's an instance > of a role based architecture, makes the world look flat again, > like SDN. > > best, christian > > --- > Prof. Dr. Christian F. Tschudin > Uni Basel | Head of Dept of Mathematics and Computer Science From touch at isi.edu Mon Apr 29 15:00:22 2013 From: touch at isi.edu (Joe Touch) Date: Mon, 29 Apr 2013 15:00:22 -0700 Subject: [e2e] flat (was Re: Port numbers in the network layer? In-Reply-To: <840351FE-C8C4-4DB2-925F-92C274C8EDC6@masonke.com> References: <20130426132619.F30E518C0FB@mercury.lcs.mit.edu> <517A9323.9050902@web.de> <840351FE-C8C4-4DB2-925F-92C274C8EDC6@masonke.com> Message-ID: <517EED76.1080604@isi.edu> The benefit of decoupling the service name from the destination port - in the current Internet - is an increased number of potential concurrent (or recently closed) connections. That's described in the draft I posted earlier. The overhead need apply only to the first packet of a TCP connection. Joe On 4/28/2013 12:11 PM, Kevin Mason wrote: > While interesting, what would be the absolute benefit? The possibilities for confusion by mis-spelling alone would negate most of the gain. Plus switching variable length, essentially random character socket indicators would be a huge overhead. > > ~Kevin > > > On Apr 26, 2013, at 5:01 PM, christian.tschudin at unibas.ch wrote: > >> On Fri, 26 Apr 2013, Detlef Bosau wrote: >> >>> ... port numbers on the transport layer have worked fine for about 35 years now. (Is this correct?) So there must be extremely compelling reasons to restart this discussion. >> >> the past not being the reason, the reason must lie in the future, >> which is: no ports at all, and names instead of port numbers. >> >> If at Bob's time ports were chosen to be encoded in ASCIZ instead >> of a 16 bit integer, many nice conflations would have been possible, >> architectural IP oddities cleaned up, connectionless web servers >> at IP level could have emerged and the bang path would still be >> with us. >> >> Some fun addr+"port" examples for such a one-layer IP network: >> >> 10.0.0.1:ping?reply-to=my_asciz_name_instead_of_port_here >> 10.0.0.2:echo?say=look at me look at me I'm on e2e >> 127.0.0.1:/index.html >> 0.0.0.0:arp?who-has=192.168.1.1&tell=eth(27:18:28:18:28:45):me >> 192.168.1.1:dns?www.google.com&t=mx >> 192.168.1.1:!my:path!to:the!open:dns?holy.cow >> 192.168.1.1:eval(dns?www.google.com)!i_feel_lucky?but I forgot the question >> >> Port-less is not really new and links back to Bob: it's an instance >> of a role based architecture, makes the world look flat again, >> like SDN. >> >> best, christian >> >> --- >> Prof. Dr. Christian F. Tschudin >> Uni Basel | Head of Dept of Mathematics and Computer Science >