From michael.scharf at ikr.uni-stuttgart.de Tue Jul 1 00:31:07 2008 From: michael.scharf at ikr.uni-stuttgart.de (Michael Scharf) Date: Tue, 1 Jul 2008 09:31:07 +0200 Subject: [e2e] Why do we need TCP flow control (rwnd)? In-Reply-To: <48699984.9000809@reed.com> References: <20080626073836.GA13918@ikr.uni-stuttgart.de> <20080626115235.7DA0A28E155@aland.bbn.com> <20080627080835.GA14740@ikr.uni-stuttgart.de> <4868F0CA.6000602@web.de> <48692FDE.10909@reed.com> <48693A1E.90403@web.de> <83F80BF7-B927-419D-9E47-FC8C1C61A265@cisco.com> <48699984.9000809@reed.com> Message-ID: <20080701073107.GA24723@ikr.uni-stuttgart.de> On Mon, 30 Jun 2008 at 22:42:12, David P. Reed wrote: > The rwnd question (one simple question that considers the flow control part > of TCP) is interesting, as I said. But to consider it one has to consider > externalities that this group and more generally the researchers in the > field of "networking" have no good models for. As just one example: does > a server version of Linux running a mix of server applications manage its > kernel buffer pool in any way similarly to a laptop version of MacOSX > running a mix of client applications? I absolutely agree that the "networking" community has difficulties to model these issues. Actually, this is another excellent motivation for my original question: If we can't model flow control, why we don't we just get rid of it? Just joking... Michael BTW: I wonder how all those TCP simulators out there address this problem. From Jon.Crowcroft at cl.cam.ac.uk Tue Jul 1 02:08:01 2008 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Tue, 01 Jul 2008 10:08:01 +0100 Subject: [e2e] Why do we need TCP flow control (rwnd)? In-Reply-To: <20080701073107.GA24723@ikr.uni-stuttgart.de> References: <20080626073836.GA13918@ikr.uni-stuttgart.de> <20080626115235.7DA0A28E155@aland.bbn.com> <20080627080835.GA14740@ikr.uni-stuttgart.de> <4868F0CA.6000602@web.de> <48692FDE.10909@reed.com> <48693A1E.90403@web.de> <83F80BF7-B927-419D-9E47-FC8C1C61A265@cisco.com> <48699984.9000809@reed.com> <20080701073107.GA24723@ikr.uni-stuttgart.de> Message-ID: on the duality of flow control & congestion control and the real "end" in end-to-end: so i think keshav made a useful point - one could have a predictive rwnd window scheme - for example, if a TCP receiver is delivering to a printer or to a screen, then there is a predicatable output rate (modulo printer running out of paper, or human running out of eyes) 1. so in this situation one can send a receive window that gets a sensible rate. on the other hand, one could ALSO send a gratuitious ECN instead from the end point. since the end point of the session (not transport) is a hop away from the tcp end point (not such a rare occurance in these wireless spliced days:) then this seems entirely the same as a router sending an ECN (or dropping a packet:) 2. corrollary: of course, routers could also change the receive window on returned packets (If the route was symmetric) and recompute the checksum appropriately, instead of using precious ECN bits or dropping packets:) mind you, a router has a harder task to predict things than a host. so maybe the tcp/ip people got things roughly right, eh? j. From detlef.bosau at web.de Tue Jul 1 06:24:10 2008 From: detlef.bosau at web.de (Detlef Bosau) Date: Tue, 01 Jul 2008 15:24:10 +0200 Subject: [e2e] Looking for SNR traces. Message-ID: <486A2FFA.6000906@web.de> Hi to all. I'm looking for HSDPA / UMTS SNR traces. I was already pointed to http://crawdad.cs.dartmouth.edu/data.php and now, I'm looking what I will find there. My concern with "calculated" traces is that the loss due to Raileyh-fading seems to be quite artificial in some cases and does not really take into account - sudden velocity changes, - sudden changes of user direction, - sudden environment changes. I'm greatful for any hints. Detlef -- Detlef Bosau Mail: detlef.bosau at web.de Galileistrasse 30 Web: http://www.detlef-bosau.de 70565 Stuttgart Skype: detlef.bosau Mobile: +49 172 681 9937 From dpreed at reed.com Tue Jul 1 06:20:33 2008 From: dpreed at reed.com (David P. Reed) Date: Tue, 01 Jul 2008 09:20:33 -0400 Subject: [e2e] Why do we need TCP flow control (rwnd)? In-Reply-To: <20080701073107.GA24723@ikr.uni-stuttgart.de> References: <20080626073836.GA13918@ikr.uni-stuttgart.de> <20080626115235.7DA0A28E155@aland.bbn.com> <20080627080835.GA14740@ikr.uni-stuttgart.de> <4868F0CA.6000602@web.de> <48692FDE.10909@reed.com> <48693A1E.90403@web.de> <83F80BF7-B927-419D-9E47-FC8C1C61A265@cisco.com> <48699984.9000809@reed.com> <20080701073107.GA24723@ikr.uni-stuttgart.de> Message-ID: <486A2F21.3070701@reed.com> Michael Scharf wrote: > I absolutely agree that the "networking" community has difficulties to > model these issues. Actually, this is another excellent motivation for > my original question: If we can't model flow control, why we don't we > just get rid of it? > > Just joking... > > I'm serious, though. In the case of POP3, there is an application layer "flow control" in the handshakes. This *partly* would obviate the need for rwnd - if messages were all shorter than a threshold. My conclusion when I studied this is that TCP flow control and POP3 handshakes actually get in each others' way. If we implemented end-to-end flow control in such a way that apps could dynamically adjust rwnd directly, I'm sure many would. The current "conservative" approach is neither fish nor fowl. Note that "tuning" an application often involves running a high priority application thread to accept data as it arrives, storing it into app-layer buffers, thus using a very indirect means to achieve better "impedance matching" of apps to the rwnd based, excessively conservative flow control. (doing this in POP3 is hard, because you can't "send ahead" acknowledgments too safely, though hacks can be done). Basically, an app would like to "pipeline" the transfer so that at the time it is ready for a new data unit, that data unit arrives. Flow control should be studied in the context of app-layer pipelining. (One can also do app-layer pipelining by using multiple TCP connections concurrently, essentially using a "rotary" protocol at the app layer that "fetches ahead in parallel"). From detlef.bosau at web.de Tue Jul 1 06:29:27 2008 From: detlef.bosau at web.de (Detlef Bosau) Date: Tue, 01 Jul 2008 15:29:27 +0200 Subject: [e2e] Why do we need TCP flow control (rwnd)? In-Reply-To: <20080701073107.GA24723@ikr.uni-stuttgart.de> References: <20080626073836.GA13918@ikr.uni-stuttgart.de> <20080626115235.7DA0A28E155@aland.bbn.com> <20080627080835.GA14740@ikr.uni-stuttgart.de> <4868F0CA.6000602@web.de> <48692FDE.10909@reed.com> <48693A1E.90403@web.de> <83F80BF7-B927-419D-9E47-FC8C1C61A265@cisco.com> <48699984.9000809@reed.com> <20080701073107.GA24723@ikr.uni-stuttgart.de> Message-ID: <486A3137.7050200@web.de> Michael Scharf wrote: > BTW: I wonder how all those TCP simulators out there address this > problem. > Do they? I remember some old discussion about NS2 simulations. And IIRC, Dave Reed exactly pointed out the problem of missing application models. I did not follow the NS3 discussion, but despite of some experimental work, the NS2 did not address the flow control problem at all. -- Detlef Bosau Mail: detlef.bosau at web.de Galileistrasse 30 Web: http://www.detlef-bosau.de 70565 Stuttgart Skype: detlef.bosau Mobile: +49 172 681 9937 From dpreed at reed.com Tue Jul 1 06:26:25 2008 From: dpreed at reed.com (David P. Reed) Date: Tue, 01 Jul 2008 09:26:25 -0400 Subject: [e2e] Why do we need TCP flow control (rwnd)? In-Reply-To: <20080701073107.GA24723@ikr.uni-stuttgart.de> References: <20080626073836.GA13918@ikr.uni-stuttgart.de> <20080626115235.7DA0A28E155@aland.bbn.com> <20080627080835.GA14740@ikr.uni-stuttgart.de> <4868F0CA.6000602@web.de> <48692FDE.10909@reed.com> <48693A1E.90403@web.de> <83F80BF7-B927-419D-9E47-FC8C1C61A265@cisco.com> <48699984.9000809@reed.com> <20080701073107.GA24723@ikr.uni-stuttgart.de> Message-ID: <486A3081.2070909@reed.com> Michael Scharf wrote: > > BTW: I wonder how all those TCP simulators out there address this > problem. > > Trivial arrival models: e.g. the wondrous Poisson model, with all its huge flaws of assuming that the sender will keep banging away despite getting no app-layer results. This is awful: most predictions of "congestion collapse" (though not all) were created by mindlessly presuming Poisson arrival. No human that I know of *ever* generates a Poisson distribution. We use them on student problem sets because they are analytically easy, not because they are realistic in any way. Then a whole generation of theory students grow up thinking that network traffic is best thought of as Poisson. And they dominate the conversation, blasting out any more thoughtful approaches by generating minimum publishable units and reviewing each others' papers as if they were problem sets to be graded. From dpreed at reed.com Tue Jul 1 06:43:06 2008 From: dpreed at reed.com (David P. Reed) Date: Tue, 01 Jul 2008 09:43:06 -0400 Subject: [e2e] Looking for SNR traces. In-Reply-To: <486A2FFA.6000906@web.de> References: <486A2FFA.6000906@web.de> Message-ID: <486A346A.1000708@reed.com> SNR is a derived number that you probably don't want to use for analyses. You might want to just ask a simpler question: has anyone got a trace of N for realistic activity patterns of a cellphone that is held up to the ear or mounted in a vehicle, for the bands (and receiver front-end) in question. I think you will find the answer is no. Regarding signal, this is so highly dependent on "tower" placement that it's best dealt with by declaring a minimum acceptable signal above the "standard noise floor in dBm", then moving the "towers" around to achieve the desired signal. Perhaps you are interested in the PDF describing the derivative of "signal level". The PDF would allow you to fit a single-parameter gaussian to it, and then verify the Rayleigh-fading parameter. In general, this fails the sensible scientific approach of measuring given controllable. Thus, despite all the math, the models are witchcraft, slightly above Astrology in validity. Detlef Bosau wrote: > Hi to all. > > I'm looking for HSDPA / UMTS SNR traces. I was already pointed to > http://crawdad.cs.dartmouth.edu/data.php > and now, I'm looking what I will find there. > > My concern with "calculated" traces is that the loss due to > Raileyh-fading seems to be quite artificial in some cases and does not > really take into account > - sudden velocity changes, > - sudden changes of user direction, > - sudden environment changes. > > I'm greatful for any hints. > > Detlef > From detlef.bosau at web.de Tue Jul 1 08:39:53 2008 From: detlef.bosau at web.de (Detlef Bosau) Date: Tue, 01 Jul 2008 17:39:53 +0200 Subject: [e2e] Looking for SNR traces. In-Reply-To: <486A346A.1000708@reed.com> References: <486A2FFA.6000906@web.de> <486A346A.1000708@reed.com> Message-ID: <486A4FC9.5040703@web.de> David P. Reed wrote: > SNR is a derived number that you probably don't want to use for analyses. > Why not? At least, it is used for theorems like Shannon-Hartley ;-) Although you might object, that the Shannon rate is a theoretical upper limit for a bit rate, that there are quite a few reasons why this is hardly achieved in reality and that the simple "signal to noise ratio" is not the only factor which determines whether a Transbort Block / Burst / however it is called is successfully deflifered or not. At least, it is a point to start. And, as you know from many of my posts on the list, it took me several wrong tracks to _stop_ trying to understand all the gory details of RLC etc., and now I think it is at least a reasonable way to model some aspects (not all, but some) of mobile networks to simply _assume_ that we can send packtes / blocks / burts - with Shannon rate - error free. Of course, this model is wrong. Like any other model. Otherwise, it wouldn't be a model :-) I simply got bogged down in too much details of simulation and simulators of mobile networs during the last few months, and I'm (frankly spoken) somewhat fed up of looking for explanations why one simulator yields other results than another. Although it may be worthwile to compare simulator artifacts, you do not learn very much about your problem that way. So, when Lachlan suggested, to use Shannon rates some weeks ago, I first was rather upset and thought, he were pulling my leg. But some days later I understood: That's indeed a reasonable way to go. > You might want to just ask a simpler question: has anyone got a trace > of N for realistic activity patterns of a cellphone that is held up to > the ear or mounted in a vehicle, for the bands (and receiver > front-end) in question. This is a simpler question. Yes. And admittedly, those patterns are hard to find as well. > I think you will find the answer is no. > > Regarding signal, this is so highly dependent on "tower" placement > that it's best dealt with by declaring a minimum acceptable signal > above the "standard noise floor in dBm", then moving the "towers" > around to achieve the desired signal. > I know. However, what I'm interested in is the question: Is the PF algorithm (Jalali, Tse, Hosein, Holtzmann, ...) ressoure fair (wrt to STTI considred as ressources) or not? From Holtzmann's papers, I understand that PF is ressource fair if the Raleigh Fading part in all competing channles is i.i.d. And although I did not read each simulator code line by line, I think in many models based upon Jakes Model the simulated Rayleigh fading _is_ i.i.d. Personally, I strongly doubt that the PF algorithm is ressource fair. (Maybe, someone can convince me that I'm wrong?) but from my simulations, it _is_. And now, I'm looking for the problem: Some possibilities: 1.: Me. (Always a valid guess :-)) 2.: The simulated scenraios: These might be scenarios, where PF works pretty fine. > Perhaps you are interested in the PDF describing the derivative of > "signal level". The PDF would allow you to fit a single-parameter > gaussian to it, and then verify the Rayleigh-fading parameter. No, I'm certainly not interested in the PDF but in the time series itself. And because some authors claim that the PF scheduling algorithm _is_ ressource fair for all scenarious, it would be sufficient to find one (or some very few) counterexampels to justify more investigation in this field. > > In general, this fails the sensible scientific approach of measuring > given controllable. Absolutely, however for a _counterexample_, this should be sufficient as long as the traces are can be reproduced. At least, the other way round, providing some examples where an approach holds and use them as a proof is not really better... > Thus, despite all the math, the models are witchcraft, slightly above > Astrology in validity. You are sooooooooooo right ;-) (However, I somewhat lost the belief, everything in computer networks can be "proven" in a reliable manner. I think, some degree of wichcraft or Stonehenge or Nazca or crystall skull will always remain.) Detlef -- Detlef Bosau Mail: detlef.bosau at web.de Galileistrasse 30 Web: http://www.detlef-bosau.de 70565 Stuttgart Skype: detlef.bosau Mobile: +49 172 681 9937 From lachlan.andrew at gmail.com Tue Jul 1 08:54:01 2008 From: lachlan.andrew at gmail.com (Lachlan Andrew) Date: Tue, 1 Jul 2008 08:54:01 -0700 Subject: [e2e] Why do we need TCP flow control (rwnd)? In-Reply-To: <486A3081.2070909@reed.com> References: <20080626073836.GA13918@ikr.uni-stuttgart.de> <20080626115235.7DA0A28E155@aland.bbn.com> <20080627080835.GA14740@ikr.uni-stuttgart.de> <4868F0CA.6000602@web.de> <48692FDE.10909@reed.com> <48693A1E.90403@web.de> <83F80BF7-B927-419D-9E47-FC8C1C61A265@cisco.com> <48699984.9000809@reed.com> <20080701073107.GA24723@ikr.uni-stuttgart.de> <486A3081.2070909@reed.com> Message-ID: Greetings David, 2008/7/1 David P. Reed : > No human that I know > of *ever* generates a Poisson distribution. I might be one of the brainwashed, but I think that your (correct) observation misses the point. An individual human produces one or two connections. The Poisson process comes from thousands or millions of users each generating their connections independently. On an access link dominated by a small number of users, the Poisson model certainly fails. On an edge or core link, I haven't seen the evidence that it does. (Pointers to the literature would be welcomed.) That raises the question: should we model access links or edge links, or have separate models of each? Cheers, Lachlan -- Lachlan Andrew Dept of Computer Science, Caltech 1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125, USA Ph: +1 (626) 395-8820 Fax: +1 (626) 568-3603 http://netlab.caltech.edu/lachlan From fred at cisco.com Tue Jul 1 08:22:35 2008 From: fred at cisco.com (Fred Baker) Date: Tue, 1 Jul 2008 08:22:35 -0700 Subject: [e2e] Why do we need TCP flow control (rwnd)? In-Reply-To: <486A3081.2070909@reed.com> References: <20080626073836.GA13918@ikr.uni-stuttgart.de> <20080626115235.7DA0A28E155@aland.bbn.com> <20080627080835.GA14740@ikr.uni-stuttgart.de> <4868F0CA.6000602@web.de> <48692FDE.10909@reed.com> <48693A1E.90403@web.de> <83F80BF7-B927-419D-9E47-FC8C1C61A265@cisco.com> <48699984.9000809@reed.com> <20080701073107.GA24723@ikr.uni-stuttgart.de> <486A3081.2070909@reed.com> Message-ID: <1EF15A66-D69A-4DB1-9F95-A10FEAC1EF9E@cisco.com> On Jul 1, 2008, at 6:26 AM, David P. Reed wrote: > This is awful: most predictions of "congestion collapse" (though not > all) were created by mindlessly presuming Poisson arrival. No human > that I know of *ever* generates a Poisson distribution. No argument with you on the idiocy of using the poisson model to model traffic; applications are not white noise generators. but... We have not just predicted congestive collapse, we have experienced it. Those events, the most well-known one being the collapse of the 56 KBPS NSFNet in 1987-1988 and the more recent instances being local phenomena with under-provisioned networks, don't result from silly assumptions. They originate from traffic from real applications with real humans behind them on real networks. From dpreed at reed.com Tue Jul 1 09:03:42 2008 From: dpreed at reed.com (David P. Reed) Date: Tue, 01 Jul 2008 12:03:42 -0400 Subject: [e2e] Why do we need TCP flow control (rwnd)? In-Reply-To: <1EF15A66-D69A-4DB1-9F95-A10FEAC1EF9E@cisco.com> References: <20080626073836.GA13918@ikr.uni-stuttgart.de> <20080626115235.7DA0A28E155@aland.bbn.com> <20080627080835.GA14740@ikr.uni-stuttgart.de> <4868F0CA.6000602@web.de> <48692FDE.10909@reed.com> <48693A1E.90403@web.de> <83F80BF7-B927-419D-9E47-FC8C1C61A265@cisco.com> <48699984.9000809@reed.com> <20080701073107.GA24723@ikr.uni-stuttgart.de> <486A3081.2070909@reed.com> <1EF15A66-D69A-4DB1-9F95-A10FEAC1EF9E@cisco.com> Message-ID: <486A555E.1070408@reed.com> Fred Baker wrote: > We have not just predicted congestive collapse, we have experienced > it. Those events, the most well-known one being the collapse of the 56 > KBPS NSFNet in 1987-1988 and the more recent instances being local > phenomena with under-provisioned networks, don't result from silly > assumptions. They originate from traffic from real applications with > real humans behind them on real networks. > I love real data. From studying actual congestive collapses, one can figure out how to prevent them. And this is exactly my point. We need to understand what we understand, and explore what we don't yet understand. Too often the "understanding we have" is based on the flimsiest of models, argued loudly by theorists whose only stake in the real is that they get paid per article published. (this is not a slam on *all* theorists, just the ones who don't seek to validate their theories except by peer review by other theorists). And often the "understanding we don't have" is disparaged by our community by declaring/defining it out of scope. Thus, almost no one tries to understand app-level behavior because it's too hard to "standardize" the measurements. Instead, we have the absurdity of publications by theorists of "optimal ... algorithms" where the scope of the word "optimal" is limited to unnatural assumptions about unnatural acts. But hey, it gets tenure. From detlef.bosau at web.de Tue Jul 1 09:29:12 2008 From: detlef.bosau at web.de (Detlef Bosau) Date: Tue, 01 Jul 2008 18:29:12 +0200 Subject: [e2e] Why do we need TCP flow control (rwnd)? In-Reply-To: <486A3081.2070909@reed.com> References: <20080626073836.GA13918@ikr.uni-stuttgart.de> <20080626115235.7DA0A28E155@aland.bbn.com> <20080627080835.GA14740@ikr.uni-stuttgart.de> <4868F0CA.6000602@web.de> <48692FDE.10909@reed.com> <48693A1E.90403@web.de> <83F80BF7-B927-419D-9E47-FC8C1C61A265@cisco.com> <48699984.9000809@reed.com> <20080701073107.GA24723@ikr.uni-stuttgart.de> <486A3081.2070909@reed.com> Message-ID: <486A5B58.4000506@web.de> David P. Reed wrote: > Michael Scharf wrote: >> >> BTW: I wonder how all those TCP simulators out there address this >> problem. >> >> > Trivial arrival models: e.g. the wondrous Poisson model, with all its > huge flaws of assuming that the sender will keep banging away despite > getting no app-layer results. > Actually, this introcudes a second flow control mechanism. The first one, Michael is talking about, is TCP flow control which is achieved by propagating the rwnd. The second one, which you just mentioned, is on the application layer: "Helo 10.1.1.1" watiing for the SMTP server, waiting, waiting, waiting. "O.K." "RCPT TO: someone.who.loves at me" waiting watinng.... "O.K". .... Actually, receivers can (and do) control senders that way. And even worse: Human beings exist. So, when I'm chatting with somebody, the anwer at my peer's site may hang - not because of network problems or because of wrong application models but simply because I'm going for a mug of coffee instead of typing an answer. > This is awful: most predictions of "congestion collapse" (though not > all) were created by mindlessly presuming Poisson arrival. No human > that I know of *ever* generates a Poisson distribution. We use them > on student problem sets because they are analytically easy, not > because they are realistic in any way. Then a whole generation of > theory students grow up thinking that network traffic is best thought > of as Poisson. And they dominate the conversation, blasting out any > more thoughtful approaches by generating minimum publishable units and > reviewing each others' papers as if they were problem sets to be graded. -- Detlef Bosau Mail: detlef.bosau at web.de Galileistrasse 30 Web: http://www.detlef-bosau.de 70565 Stuttgart Skype: detlef.bosau Mobile: +49 172 681 9937 From faber at ISI.EDU Tue Jul 1 09:22:06 2008 From: faber at ISI.EDU (Ted Faber) Date: Tue, 1 Jul 2008 09:22:06 -0700 Subject: [e2e] Why do we need TCP flow control (rwnd)? In-Reply-To: References: <20080626073836.GA13918@ikr.uni-stuttgart.de> <20080626115235.7DA0A28E155@aland.bbn.com> <20080627080835.GA14740@ikr.uni-stuttgart.de> <4868F0CA.6000602@web.de> <48692FDE.10909@reed.com> <48693A1E.90403@web.de> <83F80BF7-B927-419D-9E47-FC8C1C61A265@cisco.com> <48699984.9000809@reed.com> <20080701073107.GA24723@ikr.uni-stuttgart.de> Message-ID: <20080701162206.GB9254@zod.isi.edu> On Tue, Jul 01, 2008 at 10:08:01AM +0100, Jon Crowcroft wrote: > on the duality of flow control & congestion control > and the real "end" in end-to-end: > > so i think keshav made a useful point - > one could have a predictive rwnd window scheme - Keshav's right as usual, both about how one could extend receiver window and that it's basically a simple concept. > 1. > so in this situation one can send a receive window that gets a > sensible rate. on the other hand, one could ALSO send a gratuitious > ECN instead from the end point. > > since the end point of the session (not transport) is a hop away from > the tcp end point (not such a rare occurance in these wireless spliced > days:) then this seems entirely the same as a router sending an ECN > (or dropping a packet:) This is true as far as it goes, and it's pedagogically interesting, which I'm sure is your point. But for all the folks who think there's some engineering reason to substitute ECN for receiver window: using ECN this way is foolish. It sends less information to the endpoint ("something got lost" vs. "I can accomodate x more bytes") at exactly the same speed. The receiver window parameter is there to address this common case in the simplest manner possible. Use it. One of the biggest problems in TCP congestion control is lack of information. When you have a channel to communicate with precision, use it. > > 2. > corrollary: > of course, routers could also change the receive window on returned packets > (If the route was symmetric) and recompute the checksum appropriately, > instead of using precious ECN bits or dropping packets:) > > > mind you, a router has a harder task to predict things than a host. As I recall there were a set of network appliances in the 1990's that manipulated the receiver window to do traffic shaping. Packeteer comes to mind, but that name may be my foggy memory. So folks have played with this, though I think it's a misuse of the field. Your concerns about symmetry are spot on. > so maybe the tcp/ip people got things roughly right, eh? As far as the receiver window, I agree. -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20080701/c26440b6/attachment-0001.bin From jg at laptop.org Tue Jul 1 10:38:43 2008 From: jg at laptop.org (Jim Gettys) Date: Tue, 01 Jul 2008 13:38:43 -0400 Subject: [e2e] Why do we need TCP flow control (rwnd)? In-Reply-To: References: <20080626073836.GA13918@ikr.uni-stuttgart.de> <20080626115235.7DA0A28E155@aland.bbn.com> <20080627080835.GA14740@ikr.uni-stuttgart.de> <4868F0CA.6000602@web.de> <48692FDE.10909@reed.com> <48693A1E.90403@web.de> <83F80BF7-B927-419D-9E47-FC8C1C61A265@cisco.com> <48699984.9000809@reed.com> <20080701073107.GA24723@ikr.uni-stuttgart.de> <486A3081.2070909@reed.com> Message-ID: <1214933923.22930.52.camel@jg-vaio> On Tue, 2008-07-01 at 08:54 -0700, Lachlan Andrew wrote: > Greetings David, > > 2008/7/1 David P. Reed : > > No human that I know > > of *ever* generates a Poisson distribution. > > I might be one of the brainwashed, but I think that your (correct) > observation misses the point. An individual human produces one or two > connections. The Poisson process comes from thousands or millions of > users each generating their connections independently. > Heh. The individual human pokes a web browser to visit another page. Embedded on that page are often tons of images or other objects, not necessarily at the same web site. So an individual human often initiates anywhere from one, to many, many, many TCP connections all at once. - Jim > -- Jim Gettys One Laptop Per Child From michael.scharf at ikr.uni-stuttgart.de Tue Jul 1 10:48:41 2008 From: michael.scharf at ikr.uni-stuttgart.de (Michael Scharf) Date: Tue, 1 Jul 2008 19:48:41 +0200 Subject: [e2e] Why do we need TCP flow control (rwnd)? In-Reply-To: <486A2F21.3070701@reed.com> References: <20080626073836.GA13918@ikr.uni-stuttgart.de> <20080626115235.7DA0A28E155@aland.bbn.com> <20080627080835.GA14740@ikr.uni-stuttgart.de> <4868F0CA.6000602@web.de> <48692FDE.10909@reed.com> <48693A1E.90403@web.de> <83F80BF7-B927-419D-9E47-FC8C1C61A265@cisco.com> <48699984.9000809@reed.com> <20080701073107.GA24723@ikr.uni-stuttgart.de> <486A2F21.3070701@reed.com> Message-ID: <20080701174841.GA30311@ikr.uni-stuttgart.de> On Tue, 01 Jul 2008 at 09:20:33, David P. Reed wrote: > In the case of POP3, there is an application layer "flow control" in the > handshakes. This *partly* would obviate the need for rwnd - if messages > were all shorter than a threshold. My conclusion when I studied this is > that TCP flow control and POP3 handshakes actually get in each others' way. > > If we implemented end-to-end flow control in such a way that apps could > dynamically adjust rwnd directly, I'm sure many would. The current > "conservative" approach is neither fish nor fowl. Just to better understand this: If the app provided frequently a "perfect" value for rwnd, the network stack would still have to "allocate" a buffer of size rwnd for this connection, since it cannot be sure when the app will exactly read the data, right? So, this ends up more or less in a dynamic app-driven adjustment if the "receive buffer size"? Providing such an API to apps should not be very complex (e. g., socket option), to some extent it may even exist today. I may be wrong once again, but I think it would take quite a long time until app developers would become aware of it... Michael From day at std.com Tue Jul 1 10:54:51 2008 From: day at std.com (John Day) Date: Tue, 1 Jul 2008 13:54:51 -0400 Subject: [e2e] Why do we need TCP flow control (rwnd)? In-Reply-To: <486A3081.2070909@reed.com> References: <20080626073836.GA13918@ikr.uni-stuttgart.de> <20080626115235.7DA0A28E155@aland.bbn.com> <20080627080835.GA14740@ikr.uni-stuttgart.de> <4868F0CA.6000602@web.de> <48692FDE.10909@reed.com> <48693A1E.90403@web.de> <83F80BF7-B927-419D-9E47-FC8C1C61A265@cisco.com> <48699984.9000809@reed.com> <20080701073107.GA24723@ikr.uni-stuttgart.de> <486A3081.2070909@reed.com> Message-ID: No kidding. There are some textbook authors who have helped with this too. I was shocked to see Stallings say in one of his books, something to the effect of 'In the early 90s we discovered network traffic wasn't Poisson.' (!) We had known *that* since the 70s!!! I remember prior to 1976 scouring the literature looking for work that was closer to real, i.e. didn't assume Poisson, or would give us the tools to get closer to real. I also think that there has been a lot of sloppy teaching out there. Or maybe it is sloppy learning. The attitude of 'just tell me what I need to know to get through this course.' Well, you need to know the assumptions. Makes you wonder what other misconceptions people are operating under. Take care, John At 9:26 -0400 2008/07/01, David P. Reed wrote: >Michael Scharf wrote: >> >>BTW: I wonder how all those TCP simulators out there address this >>problem. >> >> >Trivial arrival models: e.g. the wondrous Poisson model, with all >its huge flaws of assuming that the sender will keep banging away >despite getting no app-layer results. > >This is awful: most predictions of "congestion collapse" (though not >all) were created by mindlessly presuming Poisson arrival. No human >that I know of *ever* generates a Poisson distribution. We use >them on student problem sets because they are analytically easy, not >because they are realistic in any way. Then a whole generation of >theory students grow up thinking that network traffic is best >thought of as Poisson. And they dominate the conversation, blasting >out any more thoughtful approaches by generating minimum publishable >units and reviewing each others' papers as if they were problem sets >to be graded. From michael.scharf at ikr.uni-stuttgart.de Tue Jul 1 11:05:12 2008 From: michael.scharf at ikr.uni-stuttgart.de (Michael Scharf) Date: Tue, 1 Jul 2008 20:05:12 +0200 Subject: [e2e] Why do we need TCP flow control (rwnd)? In-Reply-To: <20080701162206.GB9254@zod.isi.edu> References: <20080626115235.7DA0A28E155@aland.bbn.com> <20080627080835.GA14740@ikr.uni-stuttgart.de> <4868F0CA.6000602@web.de> <48692FDE.10909@reed.com> <48693A1E.90403@web.de> <83F80BF7-B927-419D-9E47-FC8C1C61A265@cisco.com> <48699984.9000809@reed.com> <20080701073107.GA24723@ikr.uni-stuttgart.de> <20080701162206.GB9254@zod.isi.edu> Message-ID: <20080701180512.GB30311@ikr.uni-stuttgart.de> On Tue, 01 Jul 2008 at 09:22:06, Ted Faber wrote: > But for all the folks who think there's some engineering reason to > substitute ECN for receiver window: using ECN this way is foolish. Agreed, ECN is no reasonable solution for flow control. But what would be the role of rwnd if we indeed had one of these router-assisted congestion control schemes that aim at providing more precise feedback than ECN? Or e. g. re-ECN? Michael From detlef.bosau at web.de Tue Jul 1 11:26:45 2008 From: detlef.bosau at web.de (Detlef Bosau) Date: Tue, 01 Jul 2008 20:26:45 +0200 Subject: [e2e] Why do we need TCP flow control (rwnd)? In-Reply-To: References: <20080626073836.GA13918@ikr.uni-stuttgart.de> <20080626115235.7DA0A28E155@aland.bbn.com> <20080627080835.GA14740@ikr.uni-stuttgart.de> <4868F0CA.6000602@web.de> <48692FDE.10909@reed.com> <48693A1E.90403@web.de> <83F80BF7-B927-419D-9E47-FC8C1C61A265@cisco.com> <48699984.9000809@reed.com> <20080701073107.GA24723@ikr.uni-stuttgart.de> <486A3081.2070909@reed.com> Message-ID: <486A76E5.1010900@web.de> Lachlan Andrew wrote: > > That raises the question: should we model access links or edge links, > or have separate models of each? > > We should read the chapter "introduction" which can be found in an arbitratry textbook on stochastic processes :-) Tyically, there are two statements. 1.: Markov processes and Poisson processes are nice, because they are easy do deal with. 2.: Nature and reality are naughty, because both are neither markovian nor poissonian. However, that's not only a problem for networkers :-) BTW: That's one of the reasons for my strong doubts against PF scheduling. It is the "canonical set of assumptions:" CSOA: "Anything is i.i.d, markovian, possonian, gaussian distributed and stationary. Proof: We cannot deal with anything else." From that, we have the main goal of CSOA: If reality is not compliant to theory, drop reality, start a redesign :-) (BTW: This is a well proven principle. The German government resolves our unemployment problem that way - for decades now.) SCNR Detlef -- Detlef Bosau Mail: detlef.bosau at web.de Galileistrasse 30 Web: http://www.detlef-bosau.de 70565 Stuttgart Skype: detlef.bosau Mobile: +49 172 681 9937 From mascolo at poliba.it Tue Jul 1 11:19:28 2008 From: mascolo at poliba.it (Saverio Mascolo) Date: Tue, 1 Jul 2008 20:19:28 +0200 Subject: [e2e] Why do we need TCP flow control (rwnd)? Message-ID: <000601c8dba7$05d78190$723bccc1@HPSM> On Tue, Jul 1, 2008 at 8:05 PM, Michael Scharf wrote: On Tue, 01 Jul 2008 at 09:22:06, Ted Faber wrote: > But for all the folks who think there's some engineering reason to > substitute ECN for receiver window: using ECN this way is foolish. Agreed, ECN is no reasonable solution for flow control. But what would be the role of rwnd if we indeed had one of these router-assisted congestion control schemes that aim at providing more precise feedback than ECN? Or e. g. re-ECN? Michael you know what would happen? that also the routers would use the flow control algorithm, exactly like the receiver already does! saverio -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20080701/9eabacf1/attachment.html From dpreed at reed.com Tue Jul 1 12:31:07 2008 From: dpreed at reed.com (David P. Reed) Date: Tue, 01 Jul 2008 15:31:07 -0400 Subject: [e2e] Why do we need TCP flow control (rwnd)? In-Reply-To: <1214933923.22930.52.camel@jg-vaio> References: <20080626073836.GA13918@ikr.uni-stuttgart.de> <20080626115235.7DA0A28E155@aland.bbn.com> <20080627080835.GA14740@ikr.uni-stuttgart.de> <4868F0CA.6000602@web.de> <48692FDE.10909@reed.com> <48693A1E.90403@web.de> <83F80BF7-B927-419D-9E47-FC8C1C61A265@cisco.com> <48699984.9000809@reed.com> <20080701073107.GA24723@ikr.uni-stuttgart.de> <486A3081.2070909@reed.com> <1214933923.22930.52.camel@jg-vaio> Message-ID: <486A85FB.1050802@reed.com> Humans respond to the network getting slow by going to get coffee. Mobs of humans acting independently also respond to slowness by *all* getting coffee or doing something else. It's well known that before Superbowl commercials became more interesting than the game, the plumbing systems of cities showed major spikes of effluent highly correlated with commercial breaks. :-) My general point was not against "random arrivals" but against the assumption that those arrivals are independent of service rate changes. Jim Gettys wrote: > On Tue, 2008-07-01 at 08:54 -0700, Lachlan Andrew wrote: > >> Greetings David, >> >> 2008/7/1 David P. Reed : >> >>> No human that I know >>> of *ever* generates a Poisson distribution. >>> >> I might be one of the brainwashed, but I think that your (correct) >> observation misses the point. An individual human produces one or two >> connections. The Poisson process comes from thousands or millions of >> users each generating their connections independently. >> >> > > Heh. > > The individual human pokes a web browser to visit another page. > > Embedded on that page are often tons of images or other objects, not > necessarily at the same web site. > > So an individual human often initiates anywhere from one, to many, many, > many TCP connections all at once. > - Jim > > From dpreed at reed.com Tue Jul 1 12:36:06 2008 From: dpreed at reed.com (David P. Reed) Date: Tue, 01 Jul 2008 15:36:06 -0400 Subject: [e2e] Why do we need TCP flow control (rwnd)? In-Reply-To: References: <20080626073836.GA13918@ikr.uni-stuttgart.de> <20080626115235.7DA0A28E155@aland.bbn.com> <20080627080835.GA14740@ikr.uni-stuttgart.de> <4868F0CA.6000602@web.de> <48692FDE.10909@reed.com> <48693A1E.90403@web.de> <83F80BF7-B927-419D-9E47-FC8C1C61A265@cisco.com> <48699984.9000809@reed.com> <20080701073107.GA24723@ikr.uni-stuttgart.de> <486A3081.2070909@reed.com> <1EF15A66-D69A-4DB1-9F95-A10FEAC1EF9E@cisco.com> <486A555E.1070408@reed.com> Message-ID: <486A8726.4070708@reed.com> I think of this kind of stuff as *real* network research, Fred. Good stuff. Fred Baker wrote: > On Jul 1, 2008, at 9:03 AM, David P. Reed wrote: >> From studying actual congestive collapses, one can figure out how to >> prevent them. > > OK, glad to hear it. I apologize for the form of the data I will > offer; it is of the rawest type. But you may find it illuminating. > Before I start, please understand that the network I am about to > discuss had a very serious problem at one time and has fixed it since. > So while the charts are a great example of a bad issue, this > discussion should not reflect negatively on the present network in > question. > > The scenario is a network in Africa that connected at the time to the > great wide world via VSAT. It is a university, and at the time had > O(20K) students behind a pair of links from two companies, one at 512 > KBPS and one at 1 MBPS. I was there in 2004 and had a file (my annual > performance review) that I needed to upload. The process took all day > and even at the end of it failed to complete. I wondered why, whipped > out that great little bit of Shareware named PingPlotter (which I > found very useful back when I ran on a Windows system) and took this > picture: > > ftp://ftpeng.cisco.com/fred/collapse/ams3-dmzbb-gw1.cisco.com.gif > > The second column from the left is the loss rate; as you can see, it > was between 30 and 40%. The little red lines across the bottom are > indicative of individual losses, and indicate that they were ongoing. > > Based on this data, I convinced the school to increase its bandwidth > by an order of magnitude. It had the same two links, but now at 5 and > 10 MBPS. Six months later I repeated the experiment but from the other > end, this time not using PingPlotter because I had changed computers > and PingPlotter doesn't run on my Mac (wah!). The difference between > the raw file and the "edited" file is 22 data points that were clear > outliers. In this, I ran simultaneous pings to the system's two > addresses, and in so doing measured the ping RTT on both the 5 and 10 > MBPS path. You will see very clearly that the 10 MBPS path was not > overloaded and didn't experience significant queuing delays (although > the satellite delay is pretty obvious), while the 5 MBPS path was > heavily loaded throughout the day and many samples were in the 2000 ms > ballpark. > > ftp://ftpeng.cisco.com/fred/collapse/Makerere-April-4-2005-edited.pdf > ftp://ftpeng.cisco.com/fred/collapse/Makerere-April-4-2005.pdf > > The delay distribution, for all that high delay on the 5 MBPS path, is > surprisingly similar to what one finds on any other link. Visually, it > could be confused with a Poisson distribution. > > > ftp://ftpeng.cisco.com/fred/collapse/Makerere-April-4-2005-delay-distribution.pdf > > > Looking at it in log-linear, however, the difference between the two > links becomes pretty obvious. The overprovisioned link looks pretty > normal, but the saturated link has a clear bimodal behavior. When it's > not all that busy, delays are nominal, but it has a high density > around 2000 ms RTT and a scattering in between. When it is saturated - > which it is much of the day - TCP is driving to the cliff, and the > link's timing reflects the fact. > > > ftp://ftpeng.cisco.com/fred/collapse/Makerere-April-4-2005-log-linear-delay-distribution.pdf > > > A sample space of one is an example, not a study - data, not > information. But I think the example, coupled with our knowledge of > queuing theory and general experience, supports four comments: > > (1) there ain't nothin' quite like having enough bandwidth. If the > offered load vastly exceeds capacity, nobody gets anything done. This > is the classic congestive collapse scenario as predicted in rfcs 896 > and 970. A review of Nagle's game theory discussion in 970 is > illuminating. > > (2) there ain't nothin' quite like having enough bandwidth. In a > statistical network, if the offered load approximates capacity, delay > is maximized, and loss (which is the extreme case of delay) erodes the > network's effectiveness. > > (3) TCP's congestion control algorithms seek to maximize throughput, > but will work with whatever capacity they find available. If a link is > in a congestive collapse scenario, increasing capacity by an order of > magnitude results in TCP being released to increase its windows and, > through the "fast retransmit" heuristic, recover from occasional > losses in stride. It will do so, and the result will be to use the > available capacity regardless of what it is. > > (4) congestion control algorithms that tune to the cliff obtain no > better throughput than algorithms that tune to the knee. That is by > definition: both the knee and the cliff maximize throughput, but the > cliff also maximizes queue depth at the bottleneck. Hence, algorithms > that tune to the knee are no worse for the individual end system, but > better for the network and the aggregate of its users. The difference > between a link that is overprovisioned and one on which offered load > approximates capacity is that on one TCP moves data freely while on > the other TCP works around the fragility in the network to provide > adequate service in the face of performance issues. > From detlef.bosau at web.de Tue Jul 1 13:58:07 2008 From: detlef.bosau at web.de (Detlef Bosau) Date: Tue, 01 Jul 2008 22:58:07 +0200 Subject: [e2e] Why do we need TCP flow control (rwnd)? In-Reply-To: <20080701174841.GA30311@ikr.uni-stuttgart.de> References: <20080626073836.GA13918@ikr.uni-stuttgart.de> <20080626115235.7DA0A28E155@aland.bbn.com> <20080627080835.GA14740@ikr.uni-stuttgart.de> <4868F0CA.6000602@web.de> <48692FDE.10909@reed.com> <48693A1E.90403@web.de> <83F80BF7-B927-419D-9E47-FC8C1C61A265@cisco.com> <48699984.9000809@reed.com> <20080701073107.GA24723@ikr.uni-stuttgart.de> <486A2F21.3070701@reed.com> <20080701174841.GA30311@ikr.uni-stuttgart.de> Message-ID: <486A9A5F.60901@web.de> Michael Scharf wrote: > On Tue, 01 Jul 2008 at 09:20:33, David P. Reed wrote: > >> In the case of POP3, there is an application layer "flow control" in the >> handshakes. This *partly* would obviate the need for rwnd - if messages >> were all shorter than a threshold. My conclusion when I studied this is >> that TCP flow control and POP3 handshakes actually get in each others' way. >> >> If we implemented end-to-end flow control in such a way that apps could >> dynamically adjust rwnd directly, I'm sure many would. The current >> "conservative" approach is neither fish nor fowl. >> > > Just to better understand this: If the app provided frequently a > "perfect" value for rwnd, the network stack would still have to > "allocate" a buffer of size rwnd for this connection, since it cannot > be sure when the app will exactly read the data, right? So, this ends > up more or less in a dynamic app-driven adjustment if the "receive > buffer size"? > > Providing such an API to apps should not be very complex (e. g., > socket option), to some extent it may even exist today. I may be wrong > once again, but I think it would take quite a long time until app > developers would become aware of it... > > Michael > As David wrote: It _partly_ obviates the problem. Think of SMTP. When you agree upon a mail size of several 100 kByte, which is possible in ESMTP, you will not get an acknowledgement by the application before the whole mail data is successfully submitted. Howver, the receiving application may well read the mail data from the receiving sockets in several read requests, thus the flow control problem at socket layer still remains. -- Detlef Bosau Mail: detlef.bosau at web.de Galileistrasse 30 Web: http://www.detlef-bosau.de 70565 Stuttgart Skype: detlef.bosau Mobile: +49 172 681 9937 From faber at ISI.EDU Tue Jul 1 13:53:44 2008 From: faber at ISI.EDU (Ted Faber) Date: Tue, 1 Jul 2008 13:53:44 -0700 Subject: [e2e] Why do we need TCP flow control (rwnd)? In-Reply-To: <20080701180512.GB30311@ikr.uni-stuttgart.de> References: <20080627080835.GA14740@ikr.uni-stuttgart.de> <4868F0CA.6000602@web.de> <48692FDE.10909@reed.com> <48693A1E.90403@web.de> <83F80BF7-B927-419D-9E47-FC8C1C61A265@cisco.com> <48699984.9000809@reed.com> <20080701073107.GA24723@ikr.uni-stuttgart.de> <20080701162206.GB9254@zod.isi.edu> <20080701180512.GB30311@ikr.uni-stuttgart.de> Message-ID: <20080701205344.GB24051@zod.isi.edu> On Tue, Jul 01, 2008 at 08:05:12PM +0200, Michael Scharf wrote: > On Tue, 01 Jul 2008 at 09:22:06, Ted Faber wrote: > > But for all the folks who think there's some engineering reason to > > substitute ECN for receiver window: using ECN this way is foolish. > > Agreed, ECN is no reasonable solution for flow control. > > But what would be the role of rwnd if we indeed had one of these > router-assisted congestion control schemes that aim at providing more > precise feedback than ECN? Or e. g. re-ECN? It would continue to provide flow control. The receiver window is a simple (to understand and implement) and inexpensive (16-bits of header and an if in the code) mechanism that provides a useful end-to-end coordination between transports. Why combine it with a related but separate feature? The savings is minimal and the benefits unclear. -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20080701/73ddd7d6/attachment.bin From mfisk at lanl.gov Tue Jul 1 14:55:15 2008 From: mfisk at lanl.gov (Mike Fisk) Date: Tue, 01 Jul 2008 15:55:15 -0600 Subject: [e2e] Why do we need TCP flow control (rwnd)? In-Reply-To: <4868EB46.5040000@web.de> References: <20080626073836.GA13918@ikr.uni-stuttgart.de> <4868EB46.5040000@web.de> Message-ID: <486AA7C3.7040102@lanl.gov> Detlef Bosau wrote: > Well, the path does not know anything about a receiver's capacity - > and vice versa the receiver does not know anything about the path's > capacity. In their Auto-Tuning paper, Mathis, et al essentially disable flow-control. In our Dynamic Right-Sizing papers, I made the argument that the receiver would probably like to have more information so that it can manage its buffers and not let an arbitrarily slow receiving app consume an arbitrarily large amount of memory. That implies that there is still a need for flow control. In our work for large delay-bandwidth connections, we set the receive window capacity at twice the observed delay-throughput product (throughput being congestion controlled, used bandwidth, not channel capacity bandwidth). We added code to estimate the round-trip time based on ACK-pacing and measure the throughput during that rtt directly. This is in stock Linux kernels now. If the bottleneck is the receiving app, then it will fail to drain the receive buffer and the receive window will fill up, resulting in flow control. If the bottleneck is the sending app or congestion, that will affect the delay-throughput product and therefore result in smaller receive buffers. Linux doesn't statically pre-allocate receive buffers, so there is a (perverse) opportunity for a bunch of open connections to over-commit total receive windows larger than the memory capacity of the machine. There is no logic to specifically prevent this situation, but I believe packet loss and retransmissions would be the only penalty in such a case. -- Mike Fisk Technical Director Advanced Computing Solutions Program From slblake at petri-meat.com Tue Jul 1 15:52:40 2008 From: slblake at petri-meat.com (slblake@petri-meat.com) Date: Tue, 01 Jul 2008 18:52:40 -0400 Subject: [e2e] Why do we need TCP flow control (rwnd)? In-Reply-To: References: <20080626073836.GA13918@ikr.uni-stuttgart.de> <20080626115235.7DA0A28E155@aland.bbn.com> <20080627080835.GA14740@ikr.uni-stuttgart.de> <4868F0CA.6000602@web.de> <48692FDE.10909@reed.com> <48693A1E.90403@web.de> <83F80BF7-B927-419D-9E47-FC8C1C61A265@cisco.com> <48699984.9000809@reed.com> <20080701073107.GA24723@ikr.uni-stuttgart.de> <486A3081.2070909@reed.com> Message-ID: <20080701185240.46w2ouhggk8oso84@petri-meat.com> Quoting John Day : > No kidding. There are some textbook authors who have helped with this > too. I was shocked to see Stallings say in one of his books, something > to the effect of 'In the early 90s we discovered network traffic wasn't > Poisson.' (!) We had known *that* since the 70s!!! I remember prior > to 1976 scouring the literature looking for work that was closer to > real, i.e. didn't assume Poisson, or would give us the tools to get > closer to real. The following paper may be of interest to those following this thread: T. Karagiannis, M. Molle, M. Faloutsos, and A. Broido, "A Nonstationary Poisson View of Internet Traffic", IEEE Infocom 2004. http://www.ieee-infocom.org/2004/Papers/33_3.PDF Regards, // Steve From faber at ISI.EDU Tue Jul 1 17:14:26 2008 From: faber at ISI.EDU (Ted Faber) Date: Tue, 1 Jul 2008 17:14:26 -0700 Subject: [e2e] Why do we need TCP flow control (rwnd)? In-Reply-To: <000601c8dba7$05d78190$723bccc1@HPSM> References: <000601c8dba7$05d78190$723bccc1@HPSM> Message-ID: <20080702001426.GF2454@zod.isi.edu> On Tue, Jul 01, 2008 at 08:19:28PM +0200, Saverio Mascolo wrote: > On Tue, Jul 1, 2008 at 8:05 PM, Michael Scharf wrote: > But what would be the role of rwnd if we indeed had one of these > router-assisted congestion control schemes that aim at providing more > precise feedback than ECN? Or e. g. re-ECN? > > you know what would happen? that also the routers would use the flow > control algorithm, exactly like the receiver already does! Not unless the routers had per-flow buffer allocations. This is a key difference between flow and congestion control. Routers are multiplexing resources across an unknown set of clients; endpoints are allocating to one. They're different problems. -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20080701/8011c908/attachment.bin From dpreed at reed.com Tue Jul 1 18:31:02 2008 From: dpreed at reed.com (David P. Reed) Date: Tue, 01 Jul 2008 21:31:02 -0400 Subject: [e2e] Why do we need TCP flow control (rwnd)? In-Reply-To: <20080701185240.46w2ouhggk8oso84@petri-meat.com> References: <20080626073836.GA13918@ikr.uni-stuttgart.de> <20080626115235.7DA0A28E155@aland.bbn.com> <20080627080835.GA14740@ikr.uni-stuttgart.de> <4868F0CA.6000602@web.de> <48692FDE.10909@reed.com> <48693A1E.90403@web.de> <83F80BF7-B927-419D-9E47-FC8C1C61A265@cisco.com> <48699984.9000809@reed.com> <20080701073107.GA24723@ikr.uni-stuttgart.de> <486A3081.2070909@reed.com> <20080701185240.46w2ouhggk8oso84@petri-meat.com> Message-ID: <486ADA56.1030108@reed.com> I am reminded of the fact that one can fit an exponential curve to any two points, and that with enough epicycles, one can keep the earth stationary. Curve fitting ex post is hardly following the scientific method. Is there any reason to believe that the *actual* process by which packets arrive at the network are driven by a Poisson-style process? Of course not. So the value of having curve-fit a Poisson model to some range of time scales is merely ease of model fitting. That's not trivial, but it's hardly worthy of suggesting to students of networking that they *ought* persist in such assumptions. One can just as easily presume a hidden Markov model of some structure, tuned to "curve fit" the data. The advantage being that one *might* imagine a "learning algorithm" based on Viterbi or some such that would let the system adapt by measurement and prediction of the load variation over time. Just a thought on the meta process of science as exploration of the *unknown* vs. orthodoxy driven by mathematical presumptions. We'd be arrogant to assume that network applications will always henceforth be modeled by the curves we fit today. slblake at petri-meat.com wrote: > Quoting John Day : > >> No kidding. There are some textbook authors who have helped with this >> too. I was shocked to see Stallings say in one of his books, something >> to the effect of 'In the early 90s we discovered network traffic wasn't >> Poisson.' (!) We had known *that* since the 70s!!! I remember prior >> to 1976 scouring the literature looking for work that was closer to >> real, i.e. didn't assume Poisson, or would give us the tools to get >> closer to real. > > The following paper may be of interest to those following this thread: > > T. Karagiannis, M. Molle, M. Faloutsos, and A. Broido, > "A Nonstationary Poisson View of Internet Traffic", > IEEE Infocom 2004. > http://www.ieee-infocom.org/2004/Papers/33_3.PDF > > > Regards, > > // Steve > > From detlef.bosau at web.de Wed Jul 2 03:10:54 2008 From: detlef.bosau at web.de (Detlef Bosau) Date: Wed, 02 Jul 2008 12:10:54 +0200 Subject: [e2e] Why do we need TCP flow control (rwnd)? In-Reply-To: <486A85FB.1050802@reed.com> References: <20080626073836.GA13918@ikr.uni-stuttgart.de> <20080626115235.7DA0A28E155@aland.bbn.com> <20080627080835.GA14740@ikr.uni-stuttgart.de> <4868F0CA.6000602@web.de> <48692FDE.10909@reed.com> <48693A1E.90403@web.de> <83F80BF7-B927-419D-9E47-FC8C1C61A265@cisco.com> <48699984.9000809@reed.com> <20080701073107.GA24723@ikr.uni-stuttgart.de> <486A3081.2070909@reed.com> <1214933923.22930.52.camel@jg-vaio> <486A85FB.1050802@reed.com> Message-ID: <486B542E.3010907@web.de> David P. Reed wrote: > Humans respond to the network getting slow by going to get coffee. > Mobs of humans acting independently also respond to slowness by *all* > getting coffee or doing something else. So, is this more one of the exercises for a TOEFFL? (Example question: What's the meaning of "Mrs. Jones is out of coffee.") Or do we have a congestion problem at the coffee machine? And how should we implement a "packet drop" then? > > It's well known that before Superbowl commercials became more > interesting than the game, the plumbing systems of cities showed major > spikes of effluent highly correlated with commercial breaks. :-) O.k., this story circulated here for the little break at 8.15 pm after the evening news and the murder story on TV on sunday evening ;-) > > My general point was not against "random arrivals" but against the > assumption that those arrivals are independent of service rate changes. > Hm. The "randomness", which is offen assumed is exactly one of the problems in wireless networks and the expectation to find a formula which renders a "Bitrate" depending on a "SNR". Particularly noise is often highly correlated and symbol drops are anything but "random arrival on rare occasions". -- Detlef Bosau Mail: detlef.bosau at web.de Galileistrasse 30 Web: http://www.detlef-bosau.de 70565 Stuttgart Skype: detlef.bosau Mobile: +49 172 681 9937 From dpreed at reed.com Wed Jul 2 04:28:08 2008 From: dpreed at reed.com (David P. Reed) Date: Wed, 02 Jul 2008 07:28:08 -0400 Subject: [e2e] Why do we need TCP flow control (rwnd)? In-Reply-To: <486B542E.3010907@web.de> References: <20080626073836.GA13918@ikr.uni-stuttgart.de> <20080626115235.7DA0A28E155@aland.bbn.com> <20080627080835.GA14740@ikr.uni-stuttgart.de> <4868F0CA.6000602@web.de> <48692FDE.10909@reed.com> <48693A1E.90403@web.de> <83F80BF7-B927-419D-9E47-FC8C1C61A265@cisco.com> <48699984.9000809@reed.com> <20080701073107.GA24723@ikr.uni-stuttgart.de> <486A3081.2070909@reed.com> <1214933923.22930.52.camel@jg-vaio> <486A85FB.1050802@reed.com> <486B542E.3010907@web.de> Message-ID: <486B6648.9040503@reed.com> Detlef Bosau wrote: > > So, is this more one of the exercises for a TOEFFL? (Example question: > What's the meaning of "Mrs. Jones is out of coffee.") Or do we have a > congestion problem at the coffee machine? And how should we implement > a "packet drop" then? > Forgive my cultural insensitivity, Detlef. I don't know how or if the Superbowl in the US translates to an analogous experience in, say, Gernany. Or what a culture that might drink coffee in small highly concentrated cups made only one at a time via steam might do that is analogously synchronized. It would be presumptuous of me to assume that the World Cup of Soccer (Football) has inspired television centered parties where women don't watch but just serve unending streams of ice-cold beer in cans to "their men" sitting on couches, who then converge on the single bathroom in the apartment for rapid elimination. (My naive American centered view is that Europeans don't sit around in parties in the same way - many seem to hang out in bars, where TV commercial breaks are far less bottlenecked at the toilet). From detlef.bosau at web.de Wed Jul 2 05:36:25 2008 From: detlef.bosau at web.de (Detlef Bosau) Date: Wed, 02 Jul 2008 14:36:25 +0200 Subject: [e2e] Why do we need TCP flow control (rwnd)? In-Reply-To: <486B6648.9040503@reed.com> References: <20080626073836.GA13918@ikr.uni-stuttgart.de> <20080626115235.7DA0A28E155@aland.bbn.com> <20080627080835.GA14740@ikr.uni-stuttgart.de> <4868F0CA.6000602@web.de> <48692FDE.10909@reed.com> <48693A1E.90403@web.de> <83F80BF7-B927-419D-9E47-FC8C1C61A265@cisco.com> <48699984.9000809@reed.com> <20080701073107.GA24723@ikr.uni-stuttgart.de> <486A3081.2070909@reed.com> <1214933923.22930.52.camel@jg-vaio> <486A85FB.1050802@reed.com> <486B542E.3010907@web.de> <486B6648.9040503@reed.com> Message-ID: <486B7649.40902@web.de> David P. Reed wrote: > Detlef Bosau wrote: >> >> So, is this more one of the exercises for a TOEFFL? (Example >> question: What's the meaning of "Mrs. Jones is out of coffee.") Or do >> we have a congestion problem at the coffee machine? And how should we >> implement a "packet drop" then? >> > Forgive my cultural insensitivity, Detlef. I don't know how or if the > Superbowl in the US translates to an analogous experience in, say, Gernany ;-) > . Or what a culture that might drink coffee in small highly > concentrated cups made only one at a time via steam might do that is > analogously synchronized. I don't know. I use to drink tea, so perhaps a person more experienced with coffee can help us out here. (There is some rumour, that there have been central coffee machines in some academic institutes in Stuttgart, but I don't know for sure....) > > It would be presumptuous of me to assume that the World Cup of Soccer > (Football) has inspired television centered parties where women don't > watch but just serve unending streams of ice-cold beer in cans to > "their men" sitting on couches, who then converge on the single > bathroom in the apartment for rapid elimination. At least, our chancelor, Dr. Merkel, does not serve those streams. Angela Merkel typically attends the game in the stadium, and when there happens something interesting, she jumps up and claps here hands and all TV stations send the picture of rejoicing Angela and she is frequently recommended as the ideal coach for our national soccer team then. To my knowledge, this is called "emancipation". > > (My naive American centered view is that Europeans don't sit around in > parties in the same way - many seem to hang out in bars, where TV > commercial breaks are far less bottlenecked at the toilet). For some years now, we have something called "public viewing", where some thousands of people (outside the stadium, bars and appartments) share a common screen. And a common toilet. Perhaps, that's what inspired to think about congestion control using "fluid flow models". But I'm afraid, we're getting off topic here ;-) (Didn't Michael talk about _flow_ control? ;-)) -- Detlef Bosau Mail: detlef.bosau at web.de Galileistrasse 30 Web: http://www.detlef-bosau.de 70565 Stuttgart Skype: detlef.bosau Mobile: +49 172 681 9937 From jg at laptop.org Wed Jul 2 07:06:58 2008 From: jg at laptop.org (Jim Gettys) Date: Wed, 02 Jul 2008 10:06:58 -0400 Subject: [e2e] Why do we need TCP flow control (rwnd)? In-Reply-To: <1EF15A66-D69A-4DB1-9F95-A10FEAC1EF9E@cisco.com> References: <20080626073836.GA13918@ikr.uni-stuttgart.de> <20080626115235.7DA0A28E155@aland.bbn.com> <20080627080835.GA14740@ikr.uni-stuttgart.de> <4868F0CA.6000602@web.de> <48692FDE.10909@reed.com> <48693A1E.90403@web.de> <83F80BF7-B927-419D-9E47-FC8C1C61A265@cisco.com> <48699984.9000809@reed.com> <20080701073107.GA24723@ikr.uni-stuttgart.de> <486A3081.2070909@reed.com> <1EF15A66-D69A-4DB1-9F95-A10FEAC1EF9E@cisco.com> Message-ID: <1215007618.22930.93.camel@jg-vaio> On Tue, 2008-07-01 at 08:22 -0700, Fred Baker wrote: > We have not just predicted congestive collapse, we have experienced > it. Those events, the most well-known one being the collapse of the 56 > KBPS NSFNet in 1987-1988 and the more recent instances being local > phenomena with under-provisioned networks, don't result from silly > assumptions. They originate from traffic from real applications with > real humans behind them on real networks. Heh. Some of us still have scars on their backs from this experience: it caused the formation of the X Consortium (since we no longer believed distributed development was viable), which in the long term was to X11's detriment. Congestion collapse is not just a predicted phenomena, but one which we've experienced. It got so bad we were reduced to FEDX of mag tapes for a while. - Jim -- Jim Gettys One Laptop Per Child From lachlan.andrew at gmail.com Tue Jul 1 11:02:18 2008 From: lachlan.andrew at gmail.com (Lachlan Andrew) Date: Tue, 1 Jul 2008 11:02:18 -0700 Subject: [e2e] Why do we need TCP flow control (rwnd)? In-Reply-To: <1214933923.22930.52.camel@jg-vaio> References: <20080626073836.GA13918@ikr.uni-stuttgart.de> <4868F0CA.6000602@web.de> <48692FDE.10909@reed.com> <48693A1E.90403@web.de> <83F80BF7-B927-419D-9E47-FC8C1C61A265@cisco.com> <48699984.9000809@reed.com> <20080701073107.GA24723@ikr.uni-stuttgart.de> <486A3081.2070909@reed.com> <1214933923.22930.52.camel@jg-vaio> Message-ID: 2008/7/1 Jim Gettys : > On Tue, 2008-07-01 at 08:54 -0700, Lachlan Andrew wrote: > The individual human pokes a web browser to visit another page. > > Embedded on that page are often tons of images or other objects, not > necessarily at the same web site. > > So an individual human often initiates anywhere from one, to many, many, > many TCP connections all at once. True. I wasn't addressing the question of *what* arrives as a Poisson process: It may be TCP connections, or batches of TCP connections like you mention. I was meaning to address the statement that it is bad to model congestion collapse by people continuing to pound a congested link with Poisson traffic. My point was that, for a core/edge link, individuals each only need to pound once, and we can still have a (batch) Poisson process during the congestion interval. An individual leaving the system because of congestion doesn't stop the Poisson-ish arrivals of new individuals (flows, bursts, ...) coming. Again, this only applies to edge/core links. Whenever a single individual produces a significant fraction of the traffic, I entirely agree that the Poisson model doesn't apply. Cheers, Lachlan -- Lachlan Andrew Dept of Computer Science, Caltech 1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125, USA Ph: +1 (626) 395-8820 Fax: +1 (626) 568-3603 http://netlab.caltech.edu/lachlan From fred at cisco.com Tue Jul 1 11:26:17 2008 From: fred at cisco.com (Fred Baker) Date: Tue, 1 Jul 2008 11:26:17 -0700 Subject: [e2e] Why do we need TCP flow control (rwnd)? In-Reply-To: <486A555E.1070408@reed.com> References: <20080626073836.GA13918@ikr.uni-stuttgart.de> <20080626115235.7DA0A28E155@aland.bbn.com> <20080627080835.GA14740@ikr.uni-stuttgart.de> <4868F0CA.6000602@web.de> <48692FDE.10909@reed.com> <48693A1E.90403@web.de> <83F80BF7-B927-419D-9E47-FC8C1C61A265@cisco.com> <48699984.9000809@reed.com> <20080701073107.GA24723@ikr.uni-stuttgart.de> <486A3081.2070909@reed.com> <1EF15A66-D69A-4DB1-9F95-A10FEAC1EF9E@cisco.com> <486A555E.1070408@reed.com> Message-ID: On Jul 1, 2008, at 9:03 AM, David P. Reed wrote: > From studying actual congestive collapses, one can figure out how to > prevent them. OK, glad to hear it. I apologize for the form of the data I will offer; it is of the rawest type. But you may find it illuminating. Before I start, please understand that the network I am about to discuss had a very serious problem at one time and has fixed it since. So while the charts are a great example of a bad issue, this discussion should not reflect negatively on the present network in question. The scenario is a network in Africa that connected at the time to the great wide world via VSAT. It is a university, and at the time had O(20K) students behind a pair of links from two companies, one at 512 KBPS and one at 1 MBPS. I was there in 2004 and had a file (my annual performance review) that I needed to upload. The process took all day and even at the end of it failed to complete. I wondered why, whipped out that great little bit of Shareware named PingPlotter (which I found very useful back when I ran on a Windows system) and took this picture: ftp://ftpeng.cisco.com/fred/collapse/ams3-dmzbb-gw1.cisco.com.gif The second column from the left is the loss rate; as you can see, it was between 30 and 40%. The little red lines across the bottom are indicative of individual losses, and indicate that they were ongoing. Based on this data, I convinced the school to increase its bandwidth by an order of magnitude. It had the same two links, but now at 5 and 10 MBPS. Six months later I repeated the experiment but from the other end, this time not using PingPlotter because I had changed computers and PingPlotter doesn't run on my Mac (wah!). The difference between the raw file and the "edited" file is 22 data points that were clear outliers. In this, I ran simultaneous pings to the system's two addresses, and in so doing measured the ping RTT on both the 5 and 10 MBPS path. You will see very clearly that the 10 MBPS path was not overloaded and didn't experience significant queuing delays (although the satellite delay is pretty obvious), while the 5 MBPS path was heavily loaded throughout the day and many samples were in the 2000 ms ballpark. ftp://ftpeng.cisco.com/fred/collapse/Makerere-April-4-2005-edited.pdf ftp://ftpeng.cisco.com/fred/collapse/Makerere-April-4-2005.pdf The delay distribution, for all that high delay on the 5 MBPS path, is surprisingly similar to what one finds on any other link. Visually, it could be confused with a Poisson distribution. ftp://ftpeng.cisco.com/fred/collapse/Makerere-April-4-2005-delay-distribution.pdf Looking at it in log-linear, however, the difference between the two links becomes pretty obvious. The overprovisioned link looks pretty normal, but the saturated link has a clear bimodal behavior. When it's not all that busy, delays are nominal, but it has a high density around 2000 ms RTT and a scattering in between. When it is saturated - which it is much of the day - TCP is driving to the cliff, and the link's timing reflects the fact. ftp://ftpeng.cisco.com/fred/collapse/Makerere-April-4-2005-log-linear-delay-distribution.pdf A sample space of one is an example, not a study - data, not information. But I think the example, coupled with our knowledge of queuing theory and general experience, supports four comments: (1) there ain't nothin' quite like having enough bandwidth. If the offered load vastly exceeds capacity, nobody gets anything done. This is the classic congestive collapse scenario as predicted in rfcs 896 and 970. A review of Nagle's game theory discussion in 970 is illuminating. (2) there ain't nothin' quite like having enough bandwidth. In a statistical network, if the offered load approximates capacity, delay is maximized, and loss (which is the extreme case of delay) erodes the network's effectiveness. (3) TCP's congestion control algorithms seek to maximize throughput, but will work with whatever capacity they find available. If a link is in a congestive collapse scenario, increasing capacity by an order of magnitude results in TCP being released to increase its windows and, through the "fast retransmit" heuristic, recover from occasional losses in stride. It will do so, and the result will be to use the available capacity regardless of what it is. (4) congestion control algorithms that tune to the cliff obtain no better throughput than algorithms that tune to the knee. That is by definition: both the knee and the cliff maximize throughput, but the cliff also maximizes queue depth at the bottleneck. Hence, algorithms that tune to the knee are no worse for the individual end system, but better for the network and the aggregate of its users. The difference between a link that is overprovisioned and one on which offered load approximates capacity is that on one TCP moves data freely while on the other TCP works around the fragility in the network to provide adequate service in the face of performance issues. From lachlan.andrew at gmail.com Tue Jul 1 11:35:44 2008 From: lachlan.andrew at gmail.com (Lachlan Andrew) Date: Tue, 1 Jul 2008 11:35:44 -0700 Subject: [e2e] Why do we need TCP flow control (rwnd)? In-Reply-To: <486A76E5.1010900@web.de> References: <20080626073836.GA13918@ikr.uni-stuttgart.de> <4868F0CA.6000602@web.de> <48692FDE.10909@reed.com> <48693A1E.90403@web.de> <83F80BF7-B927-419D-9E47-FC8C1C61A265@cisco.com> <48699984.9000809@reed.com> <20080701073107.GA24723@ikr.uni-stuttgart.de> <486A3081.2070909@reed.com> <486A76E5.1010900@web.de> Message-ID: Greetings Detlef, 2008/7/1 Detlef Bosau : >> >> That raises the question: should we model access links or edge links, >> or have separate models of each? > > We should read the chapter "introduction" which can be found in an > arbitratry textbook on stochastic processes :-) > > Tyically, there are two statements. > > 1.: Markov processes and Poisson processes are nice, because they are easy > do deal with. > 2.: Nature and reality are naughty, because both are neither markovian nor > poissonian. Nature certainly isn't Markovian, but we're surrounded by laws of large numbers. I certainly agree that we shouldn't build networks on beautiful theory just because it is beautiful. However, when the Poisson issue comes up, I'm always reminded of the measurement study "Cluster Processes, a Natural Language for Network Traffic" by Hohn, Veitch and Abry , which supports the model of Poisson flow arrivals. These measurements were for a lightly loaded link, but I haven't seen any contradictory evidence on a heavily loaded (and highly multiplexed) link. As always, I'd be grateful for references to some. Cheers, Lachlan -- Lachlan Andrew Dept of Computer Science, Caltech 1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125, USA Ph: +1 (626) 395-8820 Fax: +1 (626) 568-3603 http://netlab.caltech.edu/lachlan From fred at cisco.com Tue Jul 1 16:56:01 2008 From: fred at cisco.com (Fred Baker) Date: Tue, 1 Jul 2008 16:56:01 -0700 Subject: [e2e] Why do we need TCP flow control (rwnd)? In-Reply-To: <20080701185240.46w2ouhggk8oso84@petri-meat.com> References: <20080626073836.GA13918@ikr.uni-stuttgart.de> <20080626115235.7DA0A28E155@aland.bbn.com> <20080627080835.GA14740@ikr.uni-stuttgart.de> <4868F0CA.6000602@web.de> <48692FDE.10909@reed.com> <48693A1E.90403@web.de> <83F80BF7-B927-419D-9E47-FC8C1C61A265@cisco.com> <48699984.9000809@reed.com> <20080701073107.GA24723@ikr.uni-stuttgart.de> <486A3081.2070909@reed.com> <20080701185240.46w2ouhggk8oso84@petri-meat.com> Message-ID: On Jul 1, 2008, at 3:52 PM, slblake at petri-meat.com wrote: > Quoting John Day : >> No kidding. There are some textbook authors who have helped with this >> too. I was shocked to see Stallings say in one of his books, >> something >> to the effect of 'In the early 90s we discovered network traffic >> wasn't >> Poisson.' (!) We had known *that* since the 70s!!! I remember prior >> to 1976 scouring the literature looking for work that was closer to >> real, i.e. didn't assume Poisson, or would give us the tools to get >> closer to real. > > The following paper may be of interest to those following this thread: > > T. Karagiannis, M. Molle, M. Faloutsos, and A. Broido, > "A Nonstationary Poisson View of Internet Traffic", > IEEE Infocom 2004. > http://www.ieee-infocom.org/2004/Papers/33_3.PDF As the paper notes, the Poisson model tends to be a limiting case - its results will be similar to but more conservative than one would expect in reality. I use the equations too, because they are simple, but with that caveat very explicitly in place. The thing that I find a little hard to grasp is why folks might have thought the network was Poisson in the first place. A model such as M/M/1 says that traffic arrives completely randomly with no effect by one transmission on another, and departs equally randomly. By implication, packet size is random, whether uniformly distributed or gaussian distributed. Now think about the applications you know of. In TCP traffic, I once read that 40% of all traffic was pure Acks and therefore 40 bytes long, and mss-sized packets were another perhaps 35%, with the remainder being randomly distributed between the two. And TCP has three linkages between transmissions: the arrival of data generally triggers the transmission of an Ack, the arrival of an Ack generally triggers the transmission of more data, and data, when transmitted, is usually in bursts of 2-3 packets. It's not random, plain and simple. It is ack-clocked, and in many cases is somewhat deterministic. Further, if there was a random process generating data, it would be at one interface. After the data went through the queuing structures of that interface, it would go to another interface, and another. Traffic that goes through multiple queuing systems even if it was Poisson in the beginning, has a different distribution. It is by definition an *erlang* distribution. I think the thing that makes Gaussian and Poisson models attractive is the relative simplicity of their math. With Gaussian models we can discuss standard deviations, and with poisson models we can pull formulae out of textbooks. But in both cases, they are more conservative than we observe, and have predictive only to the extent that they are used as conceptual limits. From fred at cisco.com Tue Jul 1 19:11:31 2008 From: fred at cisco.com (Fred Baker) Date: Tue, 1 Jul 2008 19:11:31 -0700 Subject: [e2e] Why do we need TCP flow control (rwnd)? In-Reply-To: <1e41a3230806300846r766ff44cs86923efb6bd4e3ff@mail.gmail.com> References: <20080626073836.GA13918@ikr.uni-stuttgart.de> <7335583a0806272113r53fea014n8ce8f99f404d0310@mail.gmail.com> <1e41a3230806300846r766ff44cs86923efb6bd4e3ff@mail.gmail.com> Message-ID: <67FB0326-2C3E-4320-9B9A-9BAE8278085F@cisco.com> On Jun 30, 2008, at 8:46 AM, John Heffner wrote: > This is only mostly true -- TCP can maintain a zero window > indefinitely, but the receiver is dropping segments, the sender cannot > distinguish between the network's and the receiver's drops, and will > eventually time out and reset the connection. it gets worse. You might enjoy http://tools.ietf.org/html/draft-ananth-tcpm-persist "Clarification of sender behaviour in persist condition.", Murali Bashyam, Mahesh Jethanandani, Anantha Ramaiah, 28-Jun-08, From huitema at windows.microsoft.com Wed Jul 2 10:27:57 2008 From: huitema at windows.microsoft.com (Christian Huitema) Date: Wed, 2 Jul 2008 10:27:57 -0700 Subject: [e2e] Why do we need TCP flow control (rwnd)? In-Reply-To: References: <20080626073836.GA13918@ikr.uni-stuttgart.de> <4868F0CA.6000602@web.de> <48692FDE.10909@reed.com> <48693A1E.90403@web.de> <83F80BF7-B927-419D-9E47-FC8C1C61A265@cisco.com> <48699984.9000809@reed.com> <20080701073107.GA24723@ikr.uni-stuttgart.de> <486A3081.2070909@reed.com> <1214933923.22930.52.camel@jg-vaio> Message-ID: <8EFB68EAE061884A8517F2A755E8B60A0AA1603280@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> > I was meaning to address the statement that it is bad to model > congestion collapse by people continuing to pound a congested link > with Poisson traffic. My point was that, for a core/edge link, > individuals each only need to pound once, and we can still have a > (batch) Poisson process during the congestion interval. An individual > leaving the system because of congestion doesn't stop the Poisson-ish > arrivals of new individuals (flows, bursts, ...) coming. Actually, the arrival of individuals in the system does not appear to match the Poisson hypothesis. Part of the heavy tail behavior seems to be due precisely to correlations in the arrival process. A given individual is more likely to become active if he or she was recently active; multiple individuals are more likely to become active if other individuals are already active. This "piling up" effect contributes to the heavy tail effect, or to power law distributions. The problem with Poisson modeling is not that it overestimate congestion. On the contrary, the Poisson hypothesis tends to underestimate the variability of the aggregate, which leads to underestimating the risk of congestion. Basically, the Poisson hypothesis says that arrivals are independent, and thus that aggregates will be smooth. The "self correlation" hypothesis says that more arrivals are likely if many arrivals are already observed, and thus that peaks of traffic are not likely to be smooth. -- Christian Huitema From L.Wood at surrey.ac.uk Wed Jul 2 11:16:41 2008 From: L.Wood at surrey.ac.uk (Lloyd Wood) Date: Wed, 2 Jul 2008 19:16:41 +0100 Subject: [e2e] Why do we need TCP flow control (rwnd)? In-Reply-To: References: <20080626073836.GA13918@ikr.uni-stuttgart.de> <20080626115235.7DA0A28E155@aland.bbn.com> <20080627080835.GA14740@ikr.uni-stuttgart.de> <4868F0CA.6000602@web.de> <48692FDE.10909@reed.com> <48693A1E.90403@web.de> <83F80BF7-B927-419D-9E47-FC8C1C61A265@cisco.com> <48699984.9000809@reed.com> <20080701073107.GA24723@ikr.uni-stuttgart.de> <486A3081.2070909@reed.com> <20080701185240.46w2ouhggk8oso84@petri-meat.com> Message-ID: <4E44F683-8AAB-451F-BC39-0ECA9A6F688F@surrey.ac.uk> On 2 Jul 2008, at 00:56, Fred Baker wrote: > The thing that I find a little hard to grasp is why folks might have > thought the network was Poisson in the first place. I doubt they did; it was chosen because it made the arithmetic tractable. "First, assume a spherical cow..." L. [..] > I think the thing that makes Gaussian and Poisson models attractive > is the relative simplicity of their math. With Gaussian models we > can discuss standard deviations, and with poisson models we can pull > formulae out of textbooks. But in both cases, they are more > conservative than we observe, and have predictive only to the extent > that they are used as conceptual limits. DTN work: http://info.surrey.ac.uk/Personal/L.Wood/saratoga/ From dennis at juniper.net Wed Jul 2 13:14:16 2008 From: dennis at juniper.net (Dennis Ferguson) Date: Wed, 2 Jul 2008 13:14:16 -0700 Subject: [e2e] Why do we need TCP flow control (rwnd)? In-Reply-To: References: <20080626073836.GA13918@ikr.uni-stuttgart.de> <7335583a0806272113r53fea014n8ce8f99f404d0310@mail.gmail.com> <20080628090015.GA1399@ikr.uni-stuttgart.de> <4866A286.4080904@reed.com> Message-ID: On 29 Jun 2008, at 15:53 , Lachlan Andrew wrote: > 2008/6/28 David P. Reed : >> >> Without fantasizing about possible imaginary justifications for >> which there >> is no evidence, what real problem exists? > > Perhaps the biggest current problem is the one that David Wei > mentioned, which occurs when the buffer is small relative the the BDP, > but the receiver is fast. For what it is worth, whether this is a "problem" or a "feature" is still highly dependent on the application. For some applications severely limiting the amount of in-flight data even in the presence of a large path BDP can be exactly what is desired. In large networks these days most routing protocol data is carried over TCP. This is done primarily to take advantage of TCP flow control (this wasn't the original reason TCP was used but in retrospect it looks like a plan). When the more real-time parts of the routing system come under stress and it needs to free up processing resources to take care of the immediate needs, it can shed substantial load by simply ceasing to read incoming data from the TCP sockets. The closed window will signal the sender not to bother to format and send more data which the receiver has no time to process, hence limiting the amount of routing data which sits around in transport buffers getting increasingly stale and irrelevant. So in this application the receive window not only acts as a limit on how fast data can be transfered when things are going well, but also as a limit on the amount of time it takes for a sender to learn of a receiver's problems, and a limit on the amount of routing data which won't be processed in a timely fashion, when things are going badly. Since the behaviour when things are going badly is generally much more important to routing then ensuring that data moves at maximum speed when things are going well, the routing implementations I'm familiar with generally set the receive window to be quite small to optimize that bit. Sometimes the receive window size has implications beyond just the BDP and the amount of memory that is available. Dennis Ferguson From crovella at cs.bu.edu Wed Jul 2 13:26:15 2008 From: crovella at cs.bu.edu (Mark Crovella) Date: Wed, 2 Jul 2008 16:26:15 -0400 Subject: [e2e] Why do we need TCP flow control (rwnd)? In-Reply-To: <8EFB68EAE061884A8517F2A755E8B60A0AA1603280@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> Message-ID: > -----Original Message----- > From: end2end-interest-bounces at postel.org > [mailto:end2end-interest-bounces at postel.org] On Behalf Of > Christian Huitema > Sent: Wednesday, July 02, 2008 1:28 PM > To: Lachlan Andrew; jg at laptop.org > Cc: David P. Reed; end2end-interest list > Subject: Re: [e2e] Why do we need TCP flow control (rwnd)? > > > I was meaning to address the statement that it is bad to model > > congestion collapse by people continuing to pound a congested link > > with Poisson traffic. My point was that, for a core/edge link, > > individuals each only need to pound once, and we can still have a > > (batch) Poisson process during the congestion interval. An > individual > > leaving the system because of congestion doesn't stop the > Poisson-ish > > arrivals of new individuals (flows, bursts, ...) coming. > > Actually, the arrival of individuals in the system does not > appear to match the Poisson hypothesis. The story is actually rather complicated. If the "individuals" we are talking about are TCP connections, or flows, then the arrivals are often correlated. The only validated explanations I'm aware of for correlated flow arrivals are the presence of session-level structure (as in web browsing, p2p downloads, and in older cases, separate downloads of web page components). However -- the only studies I've seen of *session* arrivals show that session arrivals *are* typically well modeled as Poisson. All of this is conditioned on data analysis being done over a timeperiod of an hour or less, when statistics appear stable enough that they can be modeled as stationary. Over time periods of more than an hour, statistics like the mean change noticeably and then one can see correlations in session arrivals because of exogenous driving factors, i.e., diurnal human activity, day of week, etc. There's lots of cites to give here (many are in Ch 6 of "Internet Measurement" by me and Bala Krishnamurthy). > Part of the heavy > tail behavior seems to be due precisely to correlations in > the arrival process. A given individual is more likely to > become active if he or she was recently active; multiple > individuals are more likely to become active if other > individuals are already active. This "piling up" effect > contributes to the heavy tail effect, or to power law distributions. > I've never seen good, validated evidence for this claim (that "piling up" contributes to power law distributions). Pointers would be welcome. > The problem with Poisson modeling is not that it overestimate > congestion. On the contrary, the Poisson hypothesis tends to > underestimate the variability of the aggregate, which leads > to underestimating the risk of congestion. Basically, the > Poisson hypothesis says that arrivals are independent, and > thus that aggregates will be smooth. The "self correlation" > hypothesis says that more arrivals are likely if many > arrivals are already observed, and thus that peaks of traffic > are not likely to be smooth. Absolutely! > > -- Christian Huitema > Some more notes: really what we are talking about here are closed vs. open systems. An open system, such as one driven by Poisson arrivals, is essentially the limit of a closed system when the population size gets very large while the utilization stays constant, so that delays in the system do not feed back noticeably to the population (senders). In some cases this can be a good model for network traffic, not so in others. The limit example shows that an open system is a reasonable model when the population size is very large compared to the rate work is put into the system and the timescale of interest. This can be the case for highly multiplexed links in the Internet core, I would expect. It's probably not the case for less utilized links at the edge. So the extent to which correlations in arrivals are present, and Poisson vs something else is needed to describe flow arrivals, depends a lot on the nature of the link in question. And of course, whether flow arrivals are Poisson or not, the heavy-tailed nature of flow lengths will serve to make traffic at the packet level highly correlated. From dpreed at reed.com Wed Jul 2 14:21:39 2008 From: dpreed at reed.com (David P. Reed) Date: Wed, 02 Jul 2008 17:21:39 -0400 Subject: [e2e] Why do we need TCP flow control (rwnd)? In-Reply-To: References: Message-ID: <486BF163.3040607@reed.com> I can't resist critiquing the following, because it captures a serious thinking difficulty that really, seriously harms research in most fields where random processes are involved: Mark Crovella wrote: > > However -- the only studies I've seen of > *session* arrivals show that session arrivals *are* typically well > modeled as Poisson. > > We've already mentioned that there are times and places when session arrivals are definitely NOT Poisson, even if sometimes they seem so. So if arrivals seem Poisson, except when they are not, what is the person claiming? Well, it seems that they are discarding the data that disagrees with their hypothesis! In the US, scientists who do that get *prosecuted for fraud* in many cases. And when they do not, are they doing good science? If you clean that statement up - "except under condition X, arrivals are well modeled as Poisson", you must first have a sufficient and defensible precondition X that you can write down without using the idea "under the conditions that arrivals are Poisson, they can be modeled as Poisson", which is circular reasoning: assuming that which is to be proved. And there is another problem in this statement: the phrase "*are* ... well modeled as .." cannot be true in any serious statistical publication. The reason is simple: You need to specify the purpose to which the model will be put. That's another precondition that must be explicitly made, if one is to avoid egregious error. Consider an easier to understand example - that of a pseudo-random number generation (PRNG) algorithm. Does the output model a random process? Of course not. It's completely deterministic and predictable. Yet for *some* limited purposes, we treat the output as if it were actually random. But in each case, one must determine whether the use of a PRNG rather than randomness is valid and safe. We can use PRNG's in some analyses without bad results instead of random numbers. But we all know that PRNG's make bad one-time-pads for encryption. Thus, the *use* matters. From detlef.bosau at web.de Wed Jul 2 15:38:52 2008 From: detlef.bosau at web.de (Detlef Bosau) Date: Thu, 03 Jul 2008 00:38:52 +0200 Subject: [e2e] Why do we need TCP flow control (rwnd)? In-Reply-To: <486BF163.3040607@reed.com> References: <486BF163.3040607@reed.com> Message-ID: <486C037C.4060300@web.de> Good rant. And I coudln't agree more. Only one problem remains.... And that's a very honest question: If we agree upon some facts: - Poisson processes and Markov prossesses are of little use in networking research, - Analysis is not really helpful (and frankly spoken, I hardly believe those analytical TCP models, which are around), - Simulation can prove anything and nothing, - Observation is not reproducible and not systematic, so, if we agree upon the fact, that research on networking is basically impossible, _how_ can we accomplish research on networking then? It's of course allowed - and it's always scientifically correct to do so - to put in question anything we have. But if we only see blind alleys, how do we find a way out? -- Detlef Bosau Mail: detlef.bosau at web.de Galileistrasse 30 Web: http://www.detlef-bosau.de 70565 Stuttgart Skype: detlef.bosau Mobile: +49 172 681 9937 From detlef.bosau at web.de Wed Jul 2 23:51:19 2008 From: detlef.bosau at web.de (Detlef Bosau) Date: Thu, 03 Jul 2008 08:51:19 +0200 Subject: [e2e] Why do we need TCP flow control (rwnd)? In-Reply-To: References: <486BF163.3040607@reed.com> <486C037C.4060300@web.de> Message-ID: <486C76E7.5000404@web.de> Fred Baker wrote: > As witness my note the other day, it is always appropriate to describe > what we see. No argument about this. We only should not forget to find / propose useful approaches to increase our knowledge. It may well be that actual ones have shortcomings. But then, we should not only identify the shortcomings but find better approaches as well. -- Detlef Bosau Mail: detlef.bosau at web.de Galileistrasse 30 Web: http://www.detlef-bosau.de 70565 Stuttgart Skype: detlef.bosau Mobile: +49 172 681 9937 From guol at cs.bu.edu Thu Jul 3 07:10:40 2008 From: guol at cs.bu.edu (guol@cs.bu.edu) Date: Thu, 3 Jul 2008 10:10:40 -0400 (EDT) Subject: [e2e] Why do we need TCP flow control (rwnd)? In-Reply-To: <486C037C.4060300@web.de> References: <486BF163.3040607@reed.com> <486C037C.4060300@web.de> Message-ID: <40361.136.182.158.145.1215094240.squirrel@cs-squirrelmail.bu.edu> > Good rant. > > And I coudln't agree more. > > Only one problem remains.... And that's a very honest question: > If we agree upon some facts: > - Poisson processes and Markov prossesses are of little use in > networking research, I don't think this has been agreed upon. I believe the concensus is that Markovian model under-estimates variability existing in the current Internet/human behavior. But these processes are definitely very valuable in that they give ways to estimate, at least qualitatively, the effect of variability to networking systems. > - Analysis is not really helpful (and frankly spoken, I hardly believe > those analytical TCP models, which are around), Again I think they are very helpful to get insights > - Simulation can prove anything and nothing, Simulation is for validating results or for discovering problems, not for proving something. > - Observation is not reproducible and not systematic, > so, if we agree upon the fact, that research on networking is basically > impossible, _how_ can we accomplish research on networking then? > > It's of course allowed - and it's always scientifically correct to do so > - to put in question anything we have. > But if we only see blind alleys, how do we find a way out? > > > > -- > Detlef Bosau Mail: detlef.bosau at web.de > Galileistrasse 30 Web: http://www.detlef-bosau.de > 70565 Stuttgart Skype: detlef.bosau > Mobile: +49 172 681 9937 > From dpreed at reed.com Thu Jul 3 07:32:18 2008 From: dpreed at reed.com (David P. Reed) Date: Thu, 03 Jul 2008 10:32:18 -0400 Subject: [e2e] Why do we need TCP flow control (rwnd)? In-Reply-To: <40361.136.182.158.145.1215094240.squirrel@cs-squirrelmail.bu.edu> References: <486BF163.3040607@reed.com> <486C037C.4060300@web.de> <40361.136.182.158.145.1215094240.squirrel@cs-squirrelmail.bu.edu> Message-ID: <486CE2F2.1090001@reed.com> I think all mathematical + tools are useful... I hope I have not given an impression to the contrary. What is not useful is "cookbook thinking" that is often characterized by using such models without understanding their limitations, or worse, by people who assume they are "correct" in any sense other than being self-consistent mathematical systems. In the late nineteenth century, the bulk of practicing physicists (and essentially ALL EE's) acted as if the world were linear (in the sense that all physical laws were linear systems of differential equations). Such models were very useful, and when used in their domain of applicability, made much progress - essentially curve-fitting linear models piecewise to reality. This is the modern version of "epicycles". As a simple thought experiment: we assume in radio or optical communications that the world is characterized by Gaussian white noise. But if you look outside your window on a sunny day, do you see a Gaussian optical field? I would argue that to see the world as a Gaussian optical field you have to be wearing a blindfold. I hope you agree. Scientists who stand blindfolded in the world are making the most fundamental scientific error. Presuming their models are more correct than the world of experience and experiment. Choosing to see the world of a network as a Poisson process is wearing a blindfold of the same sort. guol at cs.bu.edu wrote: >> Good rant. >> >> And I coudln't agree more. >> >> Only one problem remains.... And that's a very honest question: >> If we agree upon some facts: >> - Poisson processes and Markov prossesses are of little use in >> networking research, >> > > I don't think this has been agreed upon. I believe the concensus is that > Markovian model under-estimates variability existing in the current > Internet/human behavior. But these processes are definitely very valuable > in that they give ways to estimate, at least qualitatively, the effect of > variability to networking systems. > > >> - Analysis is not really helpful (and frankly spoken, I hardly believe >> those analytical TCP models, which are around), >> > > Again I think they are very helpful to get insights > > >> - Simulation can prove anything and nothing, >> > > Simulation is for validating results or for discovering problems, not for > proving something. > > >> - Observation is not reproducible and not systematic, >> so, if we agree upon the fact, that research on networking is basically >> impossible, _how_ can we accomplish research on networking then? >> >> It's of course allowed - and it's always scientifically correct to do so >> - to put in question anything we have. >> But if we only see blind alleys, how do we find a way out? >> >> >> >> -- >> Detlef Bosau Mail: detlef.bosau at web.de >> Galileistrasse 30 Web: http://www.detlef-bosau.de >> 70565 Stuttgart Skype: detlef.bosau >> Mobile: +49 172 681 9937 >> >> > > > From touch at ISI.EDU Wed Jul 2 08:22:54 2008 From: touch at ISI.EDU (Joe Touch) Date: Wed, 02 Jul 2008 08:22:54 -0700 Subject: [e2e] reminder about reply-to-all Message-ID: <486B9D4E.9050501@isi.edu> Hi, all, As a reminder, please trim your recipient lists where possible, to avoid having your posts held for review. Joe (as list admin) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20080702/79f44403/signature-0001.bin From fred at cisco.com Wed Jul 2 16:23:05 2008 From: fred at cisco.com (Fred Baker) Date: Wed, 2 Jul 2008 16:23:05 -0700 Subject: [e2e] Why do we need TCP flow control (rwnd)? In-Reply-To: <486C037C.4060300@web.de> References: <486BF163.3040607@reed.com> <486C037C.4060300@web.de> Message-ID: As witness my note the other day, it is always appropriate to describe what we see. On Jul 2, 2008, at 3:38 PM, Detlef Bosau wrote: > Good rant. > > And I coudln't agree more. > > Only one problem remains.... And that's a very honest question: > If we agree upon some facts: > - Poisson processes and Markov prossesses are of little use in > networking research, > - Analysis is not really helpful (and frankly spoken, I hardly > believe those analytical TCP models, which are around), > - Simulation can prove anything and nothing, > - Observation is not reproducible and not systematic, > so, if we agree upon the fact, that research on networking is > basically impossible, _how_ can we accomplish research on networking > then? > > It's of course allowed - and it's always scientifically correct to > do so - to put in question anything we have. > But if we only see blind alleys, how do we find a way out? > > > > -- > Detlef Bosau Mail: detlef.bosau at web.de > Galileistrasse 30 Web: http://www.detlef- > bosau.de > 70565 Stuttgart Skype: detlef.bosau > Mobile: +49 172 681 9937 > From yzhang at cs.utexas.edu Wed Jul 2 19:10:23 2008 From: yzhang at cs.utexas.edu (Yin Zhang) Date: Wed, 2 Jul 2008 21:10:23 -0500 (CDT) Subject: [e2e] ACM SIGCOMM 2008 -- Call for Participation Message-ID: The organizing committee is delighted to invite you to ACM SIGCOMM 2008, to be held at the Grand Hyatt Regency in Seattle, WA, USA between August 17-22, 2008. SIGCOMM is the flagship annual conference of the Special Interest Group on Data Communications, a special interest group of the Association for Computing Machinery. For more information, please visit the conference web site: http://www.sigcomm.org/sigcomm2008/ As in previous years, SIGCOMM 2008 will feature a series of workshops collocated with the main conference: - Networked Systems for Developing Regions [NSDR] - Online Social Networks [WOSN] - Mobility in the Evolving Internet Architecture [MobiArch] - Economics of Networks, Systems, and Computation [NetEcon] - Programmable Routers for Extensible Services of Tomorrow [PRESTO] SIGCOMM 2008 will also feature a pair of tutorials: - Building Gigabit-rate Routers with the NetFPGA - Spectral Algorithms for Networks Important Dates --------------- - Hotel reservation cut-off date: Tuesday, July 15, 2008 Booking information available online at: http://www.sigcomm.org/sigcomm2008/hotel.php - Early registration deadline: Friday, August 1, 2008 Online registration through: http://www.sigcomm.org/sigcomm2008/registration.php We hope to see you in Seattle! On behalf of the organizing committee: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Yin Zhang, Assistant Professor Department of Computer Sciences University of Texas at Austin 1 University Station C0500 Austin, TX 78712-0233, USA http://www.cs.utexas.edu/~yzhang/ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From detlef.bosau at web.de Thu Jul 3 14:01:08 2008 From: detlef.bosau at web.de (Detlef Bosau) Date: Thu, 03 Jul 2008 23:01:08 +0200 Subject: [e2e] Why do we need TCP flow control (rwnd)? In-Reply-To: <40361.136.182.158.145.1215094240.squirrel@cs-squirrelmail.bu.edu> References: <486BF163.3040607@reed.com> <486C037C.4060300@web.de> <40361.136.182.158.145.1215094240.squirrel@cs-squirrelmail.bu.edu> Message-ID: <486D3E14.9070409@web.de> guol at cs.bu.edu wrote: >> Good rant. >> >> And I coudln't agree more. >> >> Only one problem remains.... And that's a very honest question: >> If we agree upon some facts: >> - Poisson processes and Markov prossesses are of little use in >> networking research, >> > > I don't think this has been agreed upon. Change the words to: "If we agreed upon...." However, I think the meaning of my comment can be understood. > I believe the concensus is that > Markovian model under-estimates variability existing in the current > Internet/human behavior. But these processes are definitely very valuable > in that they give ways to estimate, at least qualitatively, the effect of > variability to networking systems. > I don't have the precise definition of a Markov-process in mind. However: When you consider the complete definition and carefully study each detail, you may understand my doubts about this model. The parts of the definition are indeed quite strong. "Being markovian" is nothing what happens by chance. > >> - Analysis is not really helpful (and frankly spoken, I hardly believe >> those analytical TCP models, which are around), >> > > Again I think they are very helpful to get insights > The most obvious flaw, I've seen in all analytical models I've seen so far is that I do not see, how packet loss and missing ACKs are modeled. In addition, often you'll find infinite queues. My point was that there is no simple, obviously correct "single" way to go, when we want to understand networks. -- Detlef Bosau Mail: detlef.bosau at web.de Galileistrasse 30 Web: http://www.detlef-bosau.de 70565 Stuttgart Skype: detlef.bosau Mobile: +49 172 681 9937 From day at std.com Fri Jul 4 18:05:36 2008 From: day at std.com (John Day) Date: Fri, 4 Jul 2008 21:05:36 -0400 Subject: [e2e] Why do we need TCP flow control (rwnd)? In-Reply-To: References: <20080626073836.GA13918@ikr.uni-stuttgart.de> <7335583a0806272113r53fea014n8ce8f99f404d0310@mail.gmail.com> <20080628090015.GA1399@ikr.uni-stuttgart.de> <4866A286.4080904@reed.com> Message-ID: > >Also, as Michael pointed out, OSes (at least Linux) currently allocate >individual buffers per flow, wasting a lot of memory. (Perhaps the >small-buffer problem would go away if a large common buffer was >allocated, in which case it is an implementation rather than protocol >problem...) Good grief. Did anyone ever read, Denning, Peter. "A Statistical Model for Console Behavior in Multiuser Computers" CACM, Vol.11, No.9 p.605, Sept 1968. The closest thing to a no-brainer in CS we will probably ever find. (Sorry to be so late catching up) From day at std.com Fri Jul 4 18:23:40 2008 From: day at std.com (John Day) Date: Fri, 4 Jul 2008 21:23:40 -0400 Subject: [e2e] Why do we need TCP flow control (rwnd)? In-Reply-To: References: <20080626073836.GA13918@ikr.uni-stuttgart.de> <20080626115235.7DA0A28E155@aland.bbn.com> <20080627080835.GA14740@ikr.uni-stuttgart.de> <4868F0CA.6000602@web.de> <48692FDE.10909@reed.com> <48693A1E.90403@web.de> <83F80BF7-B927-419D-9E47-FC8C1C61A265@cisco.com> <48699984.9000809@reed.com> <20080701073107.GA24723@ikr.uni-stuttgart.de> <486A3081.2070909@reed.com> <20080701185240.46w2ouhggk8oso84@petri-meat.com> Message-ID: At 16:56 -0700 2008/07/01, Fred Baker wrote: >On Jul 1, 2008, at 3:52 PM, slblake at petri-meat.com wrote: >>Quoting John Day : >>>No kidding. There are some textbook authors who have helped with this >>>too. I was shocked to see Stallings say in one of his books, something >>>to the effect of 'In the early 90s we discovered network traffic wasn't >>>Poisson.' (!) We had known *that* since the 70s!!! I remember prior >>>to 1976 scouring the literature looking for work that was closer to >>>real, i.e. didn't assume Poisson, or would give us the tools to get >>>closer to real. >> >>The following paper may be of interest to those following this thread: >> >>T. Karagiannis, M. Molle, M. Faloutsos, and A. Broido, >>"A Nonstationary Poisson View of Internet Traffic", >>IEEE Infocom 2004. >>http://www.ieee-infocom.org/2004/Papers/33_3.PDF > >As the paper notes, the Poisson model tends to be a limiting case - >its results will be similar to but more conservative than one would >expect in reality. I use the equations too, because they are simple, >but with that caveat very explicitly in place. > >The thing that I find a little hard to grasp is why folks might have >thought the network was Poisson in the first place. snip > >I think the thing that makes Gaussian and Poisson models attractive >is the relative simplicity of their math. With Gaussian models we >can discuss standard deviations, and with poisson models we can pull >formulae out of textbooks. But in both cases, they are more >conservative than we observe, and have predictive only to the extent >that they are used as conceptual limits. And herein lies the rub. If I had to guess, I would say that pre-76, we didn't think it was Poisson but it was the only math we could do and we couldn't simulate very large networks then. There were also those just infatuated with queuing theory and insisted it was the only way to attack the problem. As the field grew, some researchers forgot the "we assume Poisson although we know it isn't" proviso or assumed everyone knew it and others started to believe it. Take care, John From keshav at uwaterloo.ca Wed Jul 9 18:36:54 2008 From: keshav at uwaterloo.ca (S. Keshav) Date: Wed, 9 Jul 2008 21:36:54 -0400 Subject: [e2e] end2end-interest Digest, Vol 53, Issue 10 In-Reply-To: References: Message-ID: <51183BA6-4D6C-4814-BF58-CD1D24A42CB8@uwaterloo.ca> On Jul 5, 2008, at 3:00 PM, John Day wrote: > As the field grew, some researchers > forgot the "we assume Poisson although we know it isn't" proviso or > assumed everyone knew it and others started to believe it. If you want to get a quick estimate of the number of cows in a field, assuming spherical--or oblate spheroidal--cows is perfectly reasonable. But then, other papers will cite yours and (mis)use this assumption to compute how much to feed them and how loud they moo. When enough papers make this assumption, some misguided soul will be unable to imagine non-spherical cows. Moral: Beware of sacred cows. keshav From day at std.com Wed Jul 9 20:02:39 2008 From: day at std.com (John Day) Date: Wed, 9 Jul 2008 23:02:39 -0400 Subject: [e2e] end2end-interest Digest, Vol 53, Issue 10 In-Reply-To: <51183BA6-4D6C-4814-BF58-CD1D24A42CB8@uwaterloo.ca> References: <51183BA6-4D6C-4814-BF58-CD1D24A42CB8@uwaterloo.ca> Message-ID: At 21:36 -0400 2008/07/09, S. Keshav wrote: >On Jul 5, 2008, at 3:00 PM, John Day wrote: > >> As the field grew, some researchers >>forgot the "we assume Poisson although we know it isn't" proviso or >>assumed everyone knew it and others started to believe it. > >If you want to get a quick estimate of the number of cows in a >field, assuming spherical--or oblate spheroidal--cows is perfectly >reasonable. But then, other papers will cite yours and (mis)use this >assumption to compute how much to feed them and how loud they moo. >When enough papers make this assumption, some misguided soul will be >unable to imagine non-spherical cows. > >Moral: Beware of sacred cows. Not sure how you made that leap. Are spheres somehow sacred? I thought they were merely round. So what you are telling me is that by and large networking researchers can not be assumed to be competent researchers? Tell me something new. Sometime ago, I noticed that I didn't find anything the IETF was doing interesting, and I found very little in the literature that was interesting. I found this disturbing. As I thought about it, I realized I had had this experience before. In the 80s, I would be asked if I was supposed to be such a big network expert, how come I didn't know anything about SNA (then 80% of the networking market). I would reply that I had enough trouble remembering the right ways to build networks without trying to remember the wrong ways too. What sacred cows? We never had any. Sacred cows are a "second generation effect" and a prime contributor to the current groupthink. The big problem early on was countering the arguments of the dominant "beads on a string" model of the PTTs. It was easy to recognize the supporters in those days, they were the old guys.;-) It is harder today to recognize the fifth columnists of the "beads-on-a-string" faction. Now there are young ones, who are "beads-on-a-string" advocates masquerading as Internet proponents. Makes things more confusing than ever. But it seems to be working, they seem to be wearing down the Internet proponents into accepting that the PTTs were right all along. Have fun, John From dpreed at reed.com Thu Jul 10 07:51:57 2008 From: dpreed at reed.com (David P. Reed) Date: Thu, 10 Jul 2008 10:51:57 -0400 Subject: [e2e] end2end-interest Digest, Vol 53, Issue 10 In-Reply-To: References: <51183BA6-4D6C-4814-BF58-CD1D24A42CB8@uwaterloo.ca> Message-ID: <4876220D.5040302@reed.com> Day and Keshav's exchanges remind me that we do have to worry about scared cows, since they might stampede, splashing into the Poisson pond. SNAp! From Jon.Crowcroft at cl.cam.ac.uk Thu Jul 10 08:23:26 2008 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Thu, 10 Jul 2008 16:23:26 +0100 Subject: [e2e] end2end-interest Digest, s/Vol 53, Issue 10 / sacred cows, sacre bleu/ In-Reply-To: <4876220D.5040302@reed.com> References: <51183BA6-4D6C-4814-BF58-CD1D24A42CB8@uwaterloo.ca> <4876220D.5040302@reed.com> Message-ID: speaking of sacred cows, why are their source addresses in IP Packets? http://www.cl.cam.ac.uk/~jac22/out/sna.pdf In missive <4876220D.5040302 at reed.com>, "David P. Reed" typed: >>Day and Keshav's exchanges remind me that we do have to worry about >>scared cows, since they might stampede, splashing into the Poisson pond. >> >>SNAp! cheers jon From pekka.nikander at nomadiclab.com Thu Jul 10 10:22:22 2008 From: pekka.nikander at nomadiclab.com (Pekka Nikander) Date: Thu, 10 Jul 2008 20:22:22 +0300 Subject: [e2e] end2end-interest Digest, s/Vol 53, Issue 10 / sacred cows, sacre bleu/ In-Reply-To: References: <51183BA6-4D6C-4814-BF58-CD1D24A42CB8@uwaterloo.ca> <4876220D.5040302@reed.com> Message-ID: <6653E694-91D2-4AE9-A1F9-1DA21718EDDF@nomadiclab.com> Indeed, http://www.tml.tkk.fi/~pnr/publications/nordsec2001.pdf, as you refer. Or, if you want to go to the other extreme, why do we need destination addresses? Aren't them the source of all evil, including DDoS and SPAM? --Pekka On 10 Jul 2008, at 18:23, Jon Crowcroft wrote: > speaking of sacred cows, > why are their source addresses in IP Packets? > http://www.cl.cam.ac.uk/~jac22/out/sna.pdf > > In missive <4876220D.5040302 at reed.com>, "David P. Reed" typed: > >>> Day and Keshav's exchanges remind me that we do have to worry about >>> scared cows, since they might stampede, splashing into the Poisson >>> pond. >>> >>> SNAp! > > cheers > > jon > > From touch at ISI.EDU Thu Jul 10 14:50:29 2008 From: touch at ISI.EDU (Joe Touch) Date: Thu, 10 Jul 2008 14:50:29 -0700 Subject: [e2e] end2end-interest Digest, s/Vol 53, Issue 10 / sacred cows, sacre bleu/ In-Reply-To: References: <51183BA6-4D6C-4814-BF58-CD1D24A42CB8@uwaterloo.ca> <4876220D.5040302@reed.com> Message-ID: <48768425.4000801@isi.edu> Jon Crowcroft wrote: > speaking of sacred cows, > why are their source addresses in IP Packets? > http://www.cl.cam.ac.uk/~jac22/out/sna.pdf The same reason letters have return addresses; for errors (e.g., ICMPs). Not all errors signal the transport layer; some signal the network layer (e.g., too-big, redirect, etc.) PS - burying them in the TCP header eats option space from TCP, which isn't exactly in abundance either ;-) Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20080710/7a57edff/signature.bin From touch at ISI.EDU Thu Jul 10 14:52:49 2008 From: touch at ISI.EDU (Joe Touch) Date: Thu, 10 Jul 2008 14:52:49 -0700 Subject: [e2e] end2end-interest Digest, s/Vol 53, Issue 10 / sacred cows, sacre bleu/ In-Reply-To: <6653E694-91D2-4AE9-A1F9-1DA21718EDDF@nomadiclab.com> References: <51183BA6-4D6C-4814-BF58-CD1D24A42CB8@uwaterloo.ca> <4876220D.5040302@reed.com> <6653E694-91D2-4AE9-A1F9-1DA21718EDDF@nomadiclab.com> Message-ID: <487684B1.50404@isi.edu> Pekka Nikander wrote: > Indeed, http://www.tml.tkk.fi/~pnr/publications/nordsec2001.pdf, as you > refer. > > Or, if you want to go to the other extreme, why do we need destination > addresses? Aren't them the source of all evil, including DDoS and SPAM? Yup. We need to use the IP Omniscience Option. IP-OO omits the need for source or destination addresses in IP headers, allowing that space to be used for a variety of things, including extra data. The nice thing about OO is that you don't need to consume option space or set a flag to indicate its presence; any device that is capable of handling it knew you were going to use it, and so doesn't need to examine the packet for that info. Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20080710/a1f04a94/signature.bin From Jon.Crowcroft at cl.cam.ac.uk Fri Jul 11 01:11:35 2008 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Fri, 11 Jul 2008 09:11:35 +0100 Subject: [e2e] end2end-interest Digest, s/Vol 53, Issue 10 / sacred cows, sacre bleu/ In-Reply-To: <48768425.4000801@isi.edu> References: <51183BA6-4D6C-4814-BF58-CD1D24A42CB8@uwaterloo.ca> <4876220D.5040302@reed.com> <48768425.4000801@isi.edu> Message-ID: a perfect example of people responding to email that they havnt actually read properly - the internet is dead as a human channel since users prefer to write things in response to the control signal rather than the data in the channel please read the paper which actually disusses responses, icmpo and tcp option problems before creating more noise. also, without even reading the paper, you could consider who sent the message and the fact that they might actually have spent some time thinking about a problem and so might actually have considered a few OBVIOUS things such as you mention below.... in fact some other people (e.g. pekka) have also thought about this a bit more so perhaps you could read their work too....this supports the idea that this is not pointless, half baked daft work......at leasr more than being knee jerk dismissiove about it this is exactly why io dont go to ietf meetings or read any lists any more associated with WGs its full of "write only" repetition. if human communiation needed this level of forward error correction all the time language would be very different - it is a shame that email has turned into such a simplex channel cheers j. In missive <48768425.4000801 at isi.edu>, Joe Touch typed: >>This is an OpenPGP/MIME signed message (RFC 2440 and 3156) >>--------------enig163A833E39F238C5F60A48CF >>Content-Type: text/plain; charset=ISO-8859-1; format=flowed >>Content-Transfer-Encoding: quoted-printable >> >> >> >>Jon Crowcroft wrote: >>> speaking of sacred cows, >>> why are their source addresses in IP Packets? >>> http://www.cl.cam.ac.uk/~jac22/out/sna.pdf >> >>The same reason letters have return addresses; for errors (e.g., ICMPs). = >> >> Not all errors signal the transport layer; some signal the network=20 >>layer (e.g., too-big, redirect, etc.) >> >>PS - burying them in the TCP header eats option space from TCP, which=20 >>isn't exactly in abundance either ;-) >> >>Joe >> >> >>--------------enig163A833E39F238C5F60A48CF >>Content-Type: application/pgp-signature; name="signature.asc" >>Content-Description: OpenPGP digital signature >>Content-Disposition: attachment; filename="signature.asc" >> >>-----BEGIN PGP SIGNATURE----- >>Version: GnuPG v1.4.7 (MingW32) >>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org >> >>iD8DBQFIdoQmE5f5cImnZrsRAnC9AKDrvpZ2kzV9rzrT8NN1NWkTEsWdYQCdF9Ok >>W8nN+CrIaW3+dENfI/qDyaw= >>=o5Lq >>-----END PGP SIGNATURE----- >> >>--------------enig163A833E39F238C5F60A48CF-- cheers jon From craig at aland.bbn.com Fri Jul 11 07:05:15 2008 From: craig at aland.bbn.com (Craig Partridge) Date: Fri, 11 Jul 2008 10:05:15 -0400 Subject: [e2e] Why do we need TCP flow control (rwnd)? In-Reply-To: Your message of "Wed, 02 Jul 2008 19:16:41 BST." <4E44F683-8AAB-451F-BC39-0ECA9A6F688F@surrey.ac.uk> Message-ID: <20080711140515.5BDAD28E155@aland.bbn.com> In message <4E44F683-8AAB-451F-BC39-0ECA9A6F688F at surrey.ac.uk>, Lloyd Wood writ es: > >On 2 Jul 2008, at 00:56, Fred Baker wrote: >> The thing that I find a little hard to grasp is why folks might have >> thought the network was Poisson in the first place. > >I doubt they did; it was chosen because it made the arithmetic >tractable. > >"First, assume a spherical cow..." I think this is unfair to the legions of statisticians that got us to making Poisson models work in the first place. The reason folks thought that data networks would be Poisson was that 1. Phone networks were demonstrably Poisson 2. They had nothing else in the arsenal (that is, if you were going to do anything non-trivial, you lacked an analytic alternative) I had long discussions with folks who did statistical modeling in the late 1980s, as it was increasingly clear Poisson was a mistake. Up to that point, network traffic was in small enough networks that one could, and many did, imagine that as the Internet matured, it would start to behave like the existing big network -- the telephone network. But the Internet growth took off and the disparities between what Poisson predicted and measurements showed became too large to shrug off. Statistical folks were deeply puzzled and frustrated. Craig From touch at ISI.EDU Fri Jul 11 07:33:14 2008 From: touch at ISI.EDU (Joe Touch) Date: Fri, 11 Jul 2008 07:33:14 -0700 Subject: [e2e] end2end-interest Digest, s/Vol 53, Issue 10 / sacred cows, sacre bleu/ In-Reply-To: References: <51183BA6-4D6C-4814-BF58-CD1D24A42CB8@uwaterloo.ca> <4876220D.5040302@reed.com> <48768425.4000801@isi.edu> Message-ID: <48776F2A.8030405@isi.edu> Jon, You asked why the Internet had source addresses. I provided an answer, based on my understanding of the historical context for the decision. I apologize for being too terse for that to be clear, or for being too glib to belie a thoughful consideration of the contents of your paper. That, however, does not mean that I did not read your paper. My response of your (IMO, historical) question has nothing to do with your proposal for removing them, as is discussed below. Jon Crowcroft wrote: > a perfect example of people responding to email that they haven't > actually read properly I urge posters to read the mail they *write* as well as those others post. ;-) Please read my more detailed note below before concluding how properly I've read your work. Joe -- You assert that: > Remember this (RFC 791)? Let?s think about the line marked > by Xs. So why is there a source address there? The naive answer > is that some receivers might want to reply. That is a historically consistent answer. > It?s a Datagram, > Stupid. Not all higher layers want to send something back! The > end-to-end argument says that we do not put a function in a lower > layer, unless it is required by the majority of upper layer users E2E argument allows designers to "put things in a layer that THAT layer actually needs". Later, your doc says that: > a better place to send advisory > information in the future Internet is onwards to the receiver, not > backwards to the sender. Obviously the unreachable cases need > to be considered more carefully, although if an end system is not > reachable, a SNA-RK might be still reachable. Host and net unreachables can't be fixed at all, as you note later. Other messages require the receiver know the source, which - if this is one of those higher layers that doesn't want to send something back - won't happen either. The fact that further discussion asserts that error notifications were always a bad idea I find naive as well. And MTU discovery will NEVER happen if the receiver has no notion of who the sender is. --- > In missive <48768425.4000801 at isi.edu>, Joe Touch typed: > > >>This is an OpenPGP/MIME signed message (RFC 2440 and 3156) > >>--------------enig163A833E39F238C5F60A48CF > >>Content-Type: text/plain; charset=ISO-8859-1; format=flowed > >>Content-Transfer-Encoding: quoted-printable > >> > >> > >> > >>Jon Crowcroft wrote: > >>> speaking of sacred cows, > >>> why are their source addresses in IP Packets? > >>> http://www.cl.cam.ac.uk/~jac22/out/sna.pdf > >> > >>The same reason letters have return addresses; for errors (e.g., ICMPs). = > >> > >> Not all errors signal the transport layer; some signal the network=20 > >>layer (e.g., too-big, redirect, etc.) > >> > >>PS - burying them in the TCP header eats option space from TCP, which=20 > >>isn't exactly in abundance either ;-) > >> > >>Joe > >> > >> > >>--------------enig163A833E39F238C5F60A48CF > >>Content-Type: application/pgp-signature; name="signature.asc" > >>Content-Description: OpenPGP digital signature > >>Content-Disposition: attachment; filename="signature.asc" > >> > >>-----BEGIN PGP SIGNATURE----- > >>Version: GnuPG v1.4.7 (MingW32) > >>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > >> > >>iD8DBQFIdoQmE5f5cImnZrsRAnC9AKDrvpZ2kzV9rzrT8NN1NWkTEsWdYQCdF9Ok > >>W8nN+CrIaW3+dENfI/qDyaw= > >>=o5Lq > >>-----END PGP SIGNATURE----- > >> > >>--------------enig163A833E39F238C5F60A48CF-- > > cheers > > jon -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20080711/02b22e29/signature.bin From Jon.Crowcroft at cl.cam.ac.uk Fri Jul 11 07:40:59 2008 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Fri, 11 Jul 2008 15:40:59 +0100 Subject: [e2e] end2end-interest Digest, s/Vol 53, Issue 10 / sacred cows, sacre bleu/ In-Reply-To: <48776F2A.8030405@isi.edu> References: <51183BA6-4D6C-4814-BF58-CD1D24A42CB8@uwaterloo.ca> <4876220D.5040302@reed.com> <48768425.4000801@isi.edu> <48776F2A.8030405@isi.edu> Message-ID: as discussed in the note which i referenced : icmp advisories are sent to the receiver who knows how to turn them around - this is no more silly than (say) ecn. icmp errors can be sent, but icmp in routers would have to parse the TCP sna option ((it has to include the header in the icmp error any how so a bit of parsing in what is always on the slow path anyhow, is not a big burden) since most of these ICMP response are meant as a response to a transport entity, this is semantically reasoanble. your move. In missive <48776F2A.8030405 at isi.edu>, Joe Touch typed: >>This is an OpenPGP/MIME signed message (RFC 2440 and 3156) >>--------------enigFDD94A1CA6B765ED0E2F3126 >>Content-Type: text/plain; charset=windows-1252; format=flowed >>Content-Transfer-Encoding: quoted-printable >> >>Jon, >> >>You asked why the Internet had source addresses. I provided an answer, >>based on my understanding of the historical context for the decision. I >>apologize for being too terse for that to be clear, or for being too >>glib to belie a thoughful consideration of the contents of your paper. >> >>That, however, does not mean that I did not read your paper. >> >>My response of your (IMO, historical) question has nothing to do with >>your proposal for removing them, as is discussed below. >> >>Jon Crowcroft wrote: >> > a perfect example of people responding to email that they haven't >> > actually read properly >> >>I urge posters to read the mail they *write* as well as those others >>post. ;-) Please read my more detailed note below before concluding how >>properly I've read your work. >> >>-- >> >>You assert that: >> >>> Remember this (RFC 791)? Let=92s think about the line marked >>> by Xs. So why is there a source address there? The naive answer >>> is that some receivers might want to reply. >> >>That is a historically consistent answer. >> >>> It;s a Datagram, >>> Stupid. Not all higher layers want to send something back! The >>> end-to-end argument says that we do not put a function in a lower >>> layer, unless it is required by the majority of upper layer users >> >>E2E argument allows designers to "put things in a layer that THAT layer >>actually needs". >> >>Later, your doc says that: >> >>> a better place to send advisory >>> information in the future Internet is onwards to the receiver, not >>> backwards to the sender. Obviously the unreachable cases need >>> to be considered more carefully, although if an end system is not >>> reachable, a SNA-RK might be still reachable. >> >>Host and net unreachables can't be fixed at all, as you note later. >>Other messages require the receiver know the source, which - if this is >>one of those higher layers that doesn't want to send something back - >>won't happen either. >> >>The fact that further discussion asserts that error notifications were >>always a bad idea I find naive as well. And MTU discovery will NEVER >>happen if the receiver has no notion of who the sender is. >> >>--- >> >>> In missive <48768425.4000801 at isi.edu>, Joe Touch typed: >>> >>> >>This is an OpenPGP/MIME signed message (RFC 2440 and 3156) >>> >>--------------enig163A833E39F238C5F60A48CF >>> >>Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed >>> >>Content-Transfer-Encoding: quoted-printable >>> >> >>> >> >>> >> >>> >>Jon Crowcroft wrote: >>> >>> speaking of sacred cows, >>> >>> why are their source addresses in IP Packets? >>> >>> http://www.cl.cam.ac.uk/~jac22/out/sna.pdf >>> >> >>> >>The same reason letters have return addresses; for errors (e.g., ICM= >>Ps). =3D >>> >> >>> >> Not all errors signal the transport layer; some signal the network= >>=3D20 >>> >>layer (e.g., too-big, redirect, etc.) >>> >> >>> >>PS - burying them in the TCP header eats option space from TCP, whic= >>h=3D20 >>> >>isn't exactly in abundance either ;-) >>> >> >>> >>Joe >>> >> >>> >> >>> >>--------------enig163A833E39F238C5F60A48CF >>> >>Content-Type: application/pgp-signature; name=3D"signature.asc" >>> >>Content-Description: OpenPGP digital signature >>> >>Content-Disposition: attachment; filename=3D"signature.asc" >>> >> >>> >>-----BEGIN PGP SIGNATURE----- >>> >>Version: GnuPG v1.4.7 (MingW32) >>> >>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org >>> >> >>> >>iD8DBQFIdoQmE5f5cImnZrsRAnC9AKDrvpZ2kzV9rzrT8NN1NWkTEsWdYQCdF9Ok >>> >>W8nN+CrIaW3+dENfI/qDyaw=3D >>> >>=3Do5Lq >>> >>-----END PGP SIGNATURE----- >>> >> >>> >>--------------enig163A833E39F238C5F60A48CF-- >>> >>> cheers From touch at ISI.EDU Fri Jul 11 07:48:17 2008 From: touch at ISI.EDU (Joe Touch) Date: Fri, 11 Jul 2008 07:48:17 -0700 Subject: [e2e] end2end-interest Digest, s/Vol 53, Issue 10 / sacred cows, sacre bleu/ In-Reply-To: References: <51183BA6-4D6C-4814-BF58-CD1D24A42CB8@uwaterloo.ca> <4876220D.5040302@reed.com> <48768425.4000801@isi.edu> <48776F2A.8030405@isi.edu> Message-ID: <487772B1.8090302@isi.edu> Jon Crowcroft wrote: > as discussed in the note which i referenced : > > icmp advisories are sent to the receiver who knows how to turn them around - this > is no more silly than (say) ecn. Consider a packet whose transport lacks a destination address altogether, as you note should be possible. Receivers of those packets have no way to turn them around. > icmp errors can be sent, but icmp in routers would have to parse the TCP sna option So basically the need for the *network* layer to signal the source is accommodated in packets using the TCP sna option by layer violation. Moving the source address in that case didn't make it go away, so that's just shuffling the deck chairs. If you wanted more space for IP, it's just as logical to leave the current IP header alone and place the extra forwarding info in the TCP header - if you're violating layers for ICMP, why not for forwarding? ... > since most of these ICMP response are meant as a response to a transport entity, > this is semantically reasoanble. Your system posits transports might not ever need source addresses. Those transports no longer benefit from ICMP information from the network. Joe > In missive <48776F2A.8030405 at isi.edu>, Joe Touch typed: > > >>This is an OpenPGP/MIME signed message (RFC 2440 and 3156) > >>--------------enigFDD94A1CA6B765ED0E2F3126 > >>Content-Type: text/plain; charset=windows-1252; format=flowed > >>Content-Transfer-Encoding: quoted-printable > >> > >>Jon, > >> > >>You asked why the Internet had source addresses. I provided an answer, > >>based on my understanding of the historical context for the decision. I > >>apologize for being too terse for that to be clear, or for being too > >>glib to belie a thoughful consideration of the contents of your paper. > >> > >>That, however, does not mean that I did not read your paper. > >> > >>My response of your (IMO, historical) question has nothing to do with > >>your proposal for removing them, as is discussed below. > >> > >>Jon Crowcroft wrote: > >> > a perfect example of people responding to email that they haven't > >> > actually read properly > >> > >>I urge posters to read the mail they *write* as well as those others > >>post. ;-) Please read my more detailed note below before concluding how > >>properly I've read your work. > > >> > >>-- > >> > >>You assert that: > >> > >>> Remember this (RFC 791)? Let=92s think about the line marked > >>> by Xs. So why is there a source address there? The naive answer > >>> is that some receivers might want to reply. > >> > >>That is a historically consistent answer. > >> > >>> It;s a Datagram, > >>> Stupid. Not all higher layers want to send something back! The > >>> end-to-end argument says that we do not put a function in a lower > >>> layer, unless it is required by the majority of upper layer users > >> > >>E2E argument allows designers to "put things in a layer that THAT layer > >>actually needs". > >> > >>Later, your doc says that: > >> > >>> a better place to send advisory > >>> information in the future Internet is onwards to the receiver, not > >>> backwards to the sender. Obviously the unreachable cases need > >>> to be considered more carefully, although if an end system is not > >>> reachable, a SNA-RK might be still reachable. > >> > >>Host and net unreachables can't be fixed at all, as you note later. > >>Other messages require the receiver know the source, which - if this is > >>one of those higher layers that doesn't want to send something back - > >>won't happen either. > >> > >>The fact that further discussion asserts that error notifications were > >>always a bad idea I find naive as well. And MTU discovery will NEVER > >>happen if the receiver has no notion of who the sender is. > >> > >>--- > >> > >>> In missive <48768425.4000801 at isi.edu>, Joe Touch typed: > >>> > >>> >>This is an OpenPGP/MIME signed message (RFC 2440 and 3156) > >>> >>--------------enig163A833E39F238C5F60A48CF > >>> >>Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed > >>> >>Content-Transfer-Encoding: quoted-printable > >>> >> > >>> >> > >>> >> > >>> >>Jon Crowcroft wrote: > >>> >>> speaking of sacred cows, > >>> >>> why are their source addresses in IP Packets? > >>> >>> http://www.cl.cam.ac.uk/~jac22/out/sna.pdf > >>> >> > >>> >>The same reason letters have return addresses; for errors (e.g., ICM= > >>Ps). =3D > >>> >> > >>> >> Not all errors signal the transport layer; some signal the network= > >>=3D20 > >>> >>layer (e.g., too-big, redirect, etc.) > >>> >> > >>> >>PS - burying them in the TCP header eats option space from TCP, whic= > >>h=3D20 > >>> >>isn't exactly in abundance either ;-) > >>> >> > >>> >>Joe > >>> >> > >>> >> > >>> >>--------------enig163A833E39F238C5F60A48CF > >>> >>Content-Type: application/pgp-signature; name=3D"signature.asc" > >>> >>Content-Description: OpenPGP digital signature > >>> >>Content-Disposition: attachment; filename=3D"signature.asc" > >>> >> > >>> >>-----BEGIN PGP SIGNATURE----- > >>> >>Version: GnuPG v1.4.7 (MingW32) > >>> >>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > >>> >> > >>> >>iD8DBQFIdoQmE5f5cImnZrsRAnC9AKDrvpZ2kzV9rzrT8NN1NWkTEsWdYQCdF9Ok > >>> >>W8nN+CrIaW3+dENfI/qDyaw=3D > >>> >>=3Do5Lq > >>> >>-----END PGP SIGNATURE----- > >>> >> > >>> >>--------------enig163A833E39F238C5F60A48CF-- > >>> > >>> cheers -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20080711/7fe349f3/signature-0001.bin From touch at ISI.EDU Fri Jul 11 07:50:57 2008 From: touch at ISI.EDU (Joe Touch) Date: Fri, 11 Jul 2008 07:50:57 -0700 Subject: [e2e] end2end-interest Digest, s/Vol 53, Issue 10 / sacred cows, sacre bleu/ In-Reply-To: <487772B1.8090302@isi.edu> References: <51183BA6-4D6C-4814-BF58-CD1D24A42CB8@uwaterloo.ca> <4876220D.5040302@reed.com> <48768425.4000801@isi.edu> <48776F2A.8030405@isi.edu> <487772B1.8090302@isi.edu> Message-ID: <48777351.3090701@isi.edu> Joe Touch wrote: > > > Jon Crowcroft wrote: >> as discussed in the note which i referenced : >> >> icmp advisories are sent to the receiver who knows how to turn them >> around - this >> is no more silly than (say) ecn. > > Consider a packet whose transport lacks a destination address > altogether, as you note should be possible. Receivers of those packets > have no way to turn them around. FWIW, some of these packets never get to a receiver as well... (e.g., net/host unreachable)... Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20080711/eb63e1d5/signature.bin From Jon.Crowcroft at cl.cam.ac.uk Fri Jul 11 07:55:20 2008 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Fri, 11 Jul 2008 15:55:20 +0100 Subject: [e2e] end2end-interest Digest, s/Vol 53, Issue 10 / sacred cows, sacre bleu/ In-Reply-To: <487772B1.8090302@isi.edu> References: <51183BA6-4D6C-4814-BF58-CD1D24A42CB8@uwaterloo.ca> <4876220D.5040302@reed.com> <48768425.4000801@isi.edu> <48776F2A.8030405@isi.edu> <487772B1.8090302@isi.edu> Message-ID: In missive <487772B1.8090302 at isi.edu>, Joe Touch typed: >>Consider a packet whose transport lacks a destination address >>altogether, as you note should be possible. Receivers of those packets >>have no way to turn them around. >>> icmp errors can be sent, but icmp in routers would have to parse the TCP sna option >>So basically the need for the *network* layer to signal the source is >>accommodated in packets using the TCP sna option by layer violation. ICMP is layered on top of ip as is tcp - icmp talking to tcp is not a layer violation. by the way, i dont put an _address_ in the transport - i put an identifier - this is then used receivers to lookup an address to the originator. i _might_ put a routing hint (e.g. a care of adddress) in the transport too - this is not the same as putting in an actual address (which i am getting rid of as it is invalid MOST of the time... >>Moving the source address in that case didn't make it go away, so that's >>just shuffling the deck chairs. If you wanted more space for IP, it's >>just as logical to leave the current IP header alone and place the extra >>forwarding info in the TCP header - if you're violating layers for ICMP, = this is either a semantic quibble or confusing. 1. i havnt changed the IP header ast aal - i 've changed the meaning of a field - thishas some very nice legacy interworking properties (as noted in my note) as above, I am not violating layers. not as i understand their functions. >>why not for forwarding? >>> since most of these ICMP response are meant as a response to a transpo= >>rt entity, >>> this is semantically reasoanble. >> >>Your system posits transports might not ever need source addresses. >>Those transports no longer benefit from ICMP information from the network= > indeed since there is no information theoretic or control theoertic reason they should want fedback from the net if thewy didnt want it from the end. - i am just bringing some consistency to a design error of the internet. >> >>> In missive <48776F2A.8030405 at isi.edu>, Joe Touch typed: >>>=20 >>> >>This is an OpenPGP/MIME signed message (RFC 2440 and 3156) >>> >>--------------enigFDD94A1CA6B765ED0E2F3126 >>> >>Content-Type: text/plain; charset=3Dwindows-1252; format=3Dflowed >>> >>Content-Transfer-Encoding: quoted-printable >>> >> >>> >>Jon, >>> >> >>> >>You asked why the Internet had source addresses. I provided an answe= >>r,=20 >>> >>based on my understanding of the historical context for the decision= >>=2E I=20 >>> >>apologize for being too terse for that to be clear, or for being too= >>=20 >>> >>glib to belie a thoughful consideration of the contents of your pape= >>r. >>> >> >>> >>That, however, does not mean that I did not read your paper. >>> >> >>> >>My response of your (IMO, historical) question has nothing to do wit= >>h=20 >>> >>your proposal for removing them, as is discussed below. >>> >> >>> >>Jon Crowcroft wrote: >>> >> > a perfect example of people responding to email that they haven't= >> >>> >> > actually read properly >>> >> >>> >>I urge posters to read the mail they *write* as well as those others= >>=20 >>> >>post. ;-) Please read my more detailed note below before concluding= >> how=20 >>> >>properly I've read your work. >>> =20 >>> >> >>> >>-- >>> >> >>> >>You assert that: >>> >> >>> >>> Remember this (RFC 791)? Let=3D92s think about the line marked >>> >>> by Xs. So why is there a source address there? The naive answer >>> >>> is that some receivers might want to reply. >>> >> >>> >>That is a historically consistent answer. >>> >> >>> >>> It;s a Datagram, >>> >>> Stupid. Not all higher layers want to send something back! The >>> >>> end-to-end argument says that we do not put a function in a lower >>> >>> layer, unless it is required by the majority of upper layer users >>> >> >>> >>E2E argument allows designers to "put things in a layer that THAT la= >>yer >>> >>actually needs". >>> >> >>> >>Later, your doc says that: >>> >> >>> >>> a better place to send advisory >>> >>> information in the future Internet is onwards to the receiver, not= >> >>> >>> backwards to the sender. Obviously the unreachable cases need >>> >>> to be considered more carefully, although if an end system is not >>> >>> reachable, a SNA-RK might be still reachable. >>> >> >>> >>Host and net unreachables can't be fixed at all, as you note later. = >> >>> >>Other messages require the receiver know the source, which - if this= >> is=20 >>> >>one of those higher layers that doesn't want to send something back = >>-=20 >>> >>won't happen either. >>> >> >>> >>The fact that further discussion asserts that error notifications we= >>re=20 >>> >>always a bad idea I find naive as well. And MTU discovery will NEVER= >>=20 >>> >>happen if the receiver has no notion of who the sender is. >>> >> >>> >>--- >>> >> >>> >>> In missive <48768425.4000801 at isi.edu>, Joe Touch typed: >>> >>>=20 >>> >>> >>This is an OpenPGP/MIME signed message (RFC 2440 and 3156) >>> >>> >>--------------enig163A833E39F238C5F60A48CF >>> >>> >>Content-Type: text/plain; charset=3D3DISO-8859-1; format=3D3Dfl= >>owed >>> >>> >>Content-Transfer-Encoding: quoted-printable >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> >>Jon Crowcroft wrote: >>> >>> >>> speaking of sacred cows, >>> >>> >>> why are their source addresses in IP Packets? >>> >>> >>> http://www.cl.cam.ac.uk/~jac22/out/sna.pdf >>> >>> >> >>> >>> >>The same reason letters have return addresses; for errors (e.g.= >>, ICM=3D >>> >>Ps). =3D3D >>> >>> >> >>> >>> >> Not all errors signal the transport layer; some signal the ne= >>twork=3D >>> >>=3D3D20 >>> >>> >>layer (e.g., too-big, redirect, etc.) >>> >>> >> >>> >>> >>PS - burying them in the TCP header eats option space from TCP,= >> whic=3D >>> >>h=3D3D20 >>> >>> >>isn't exactly in abundance either ;-) >>> >>> >> >>> >>> >>Joe >>> >>> >> >>> >>> >> >>> >>> >>--------------enig163A833E39F238C5F60A48CF >>> >>> >>Content-Type: application/pgp-signature; name=3D3D"signature.as= >>c" >>> >>> >>Content-Description: OpenPGP digital signature >>> >>> >>Content-Disposition: attachment; filename=3D3D"signature.asc" >>> >>> >> >>> >>> >>-----BEGIN PGP SIGNATURE----- >>> >>> >>Version: GnuPG v1.4.7 (MingW32) >>> >>> >>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org >>> >>> >> >>> >>> >>iD8DBQFIdoQmE5f5cImnZrsRAnC9AKDrvpZ2kzV9rzrT8NN1NWkTEsWdYQCdF9O= >>k >>> >>> >>W8nN+CrIaW3+dENfI/qDyaw=3D3D >>> >>> >>=3D3Do5Lq >>> >>> >>-----END PGP SIGNATURE----- >>> >>> >> >>> >>> >>--------------enig163A833E39F238C5F60A48CF-- >>> >>>=20 >>> >>> cheers >> >> >>--------------enig841B4237908E688C7D411F39 >>Content-Type: application/pgp-signature; name="signature.asc" >>Content-Description: OpenPGP digital signature >>Content-Disposition: attachment; filename="signature.asc" >> >>-----BEGIN PGP SIGNATURE----- >>Version: GnuPG v1.4.7 (MingW32) >>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org >> >>iD8DBQFId3KxE5f5cImnZrsRAl1GAJ4m5yLUosDO/kb7TwPLTa3Wi8GOWQCfbX8Y >>mhEpJZ+jr+qMgMXMe3xEFtQ= >>=xV8K >>-----END PGP SIGNATURE----- >> >>--------------enig841B4237908E688C7D411F39-- cheers jon From touch at ISI.EDU Fri Jul 11 08:10:09 2008 From: touch at ISI.EDU (Joe Touch) Date: Fri, 11 Jul 2008 08:10:09 -0700 Subject: [e2e] end2end-interest Digest, s/Vol 53, Issue 10 / sacred cows, sacre bleu/ In-Reply-To: References: <51183BA6-4D6C-4814-BF58-CD1D24A42CB8@uwaterloo.ca> <4876220D.5040302@reed.com> <48768425.4000801@isi.edu> <48776F2A.8030405@isi.edu> <487772B1.8090302@isi.edu> Message-ID: <487777D1.6090001@isi.edu> Jon (et al.), Jon Crowcroft wrote: > In missive <487772B1.8090302 at isi.edu>, Joe Touch typed: > > >>Consider a packet whose transport lacks a destination address > >>altogether, as you note should be possible. Receivers of those packets > >>have no way to turn them around. > > >>> icmp errors can be sent, but icmp in routers would have to parse the TCP sna option > > >>So basically the need for the *network* layer to signal the source is > >>accommodated in packets using the TCP sna option by layer violation. > > ICMP is layered on top of ip as is tcp - icmp talking to tcp is not a layer > violation. If you call ICMP a transport layer (fair enough), you haven't explained why one transport should peek into the headers of another. ICMP can talk to TCP, but having ICMP parse TCP headers would be layer violation IMO. > by the way, i dont put an _address_ in the transport - i put an identifier - this > is then used receivers to lookup an address to the originator. i _might_ put a > routing hint (e.g. a care of adddress) in the transport too - this is > not the same as putting in an actual address (which i am getting rid of as it is > invalid MOST of the time... Understood. That difference isn't key to my responses, so I've just referred to it as an address, but didn't mean to confuse that issue. > >>Moving the source address in that case didn't make it go away, so that's > >>just shuffling the deck chairs. If you wanted more space for IP, it's > >>just as logical to leave the current IP header alone and place the extra > >>forwarding info in the TCP header - if you're violating layers for ICMP, = > > this is either a semantic quibble or confusing. > > 1. i havnt changed the IP header ast aal - i 've changed the meaning of a field - > thishas some very nice legacy interworking properties (as noted in my note) Changing the meaning of a field changes the header. I.e., you can't pass that packet through a legacy router usefully - it could generate ICMPs to the wrong place, and won't interpret the source address field as an extension of the destination address. My view is that: change IP src address to mean destination realm add source identifier to TCP header (e.g., as an option) is just as usefully accomplished as: leave IP as-is add destination realm to the TCP header (as an option) (the only remaining difference is that your source identifier isn't the same as IP's source address; I could just as easily put the source ID in the TCP header too if you prefer). Further, your paper and emails have not addressed the fact that TCP headers don't exactly have lots of space - especially the SYN packet, which is where the source identifier for a connection would need to be established. ... > >>why not for forwarding? > >>> since most of these ICMP response are meant as a response to a transpo= > >>rt entity, > >>> this is semantically reasoanble. > >> > >>Your system posits transports might not ever need source addresses. > >>Those transports no longer benefit from ICMP information from the network= > > indeed since there is no information theoretic or control theoertic reason they > should want fedback from the net if thewy didnt want it from the end. - i am just > bringing some consistency to a design error of the internet. I agree that unidirectional packets don't necessarily need network feedback. That implies: 1. that your entire supposition that the IP packet doesn't need a source address because the transport layer is unacknowledged may be true, but actually implies that all transport layers should be bidirectional (rather than implying that you don't need a source address). 2. bidirectional packets need network address info in the network header, because the network needs to respond to that information. if I leave this to the transport layer, then every time I deploy a new transport protocol (SCTP, DCCP, etc.), I need to recode all my routers to know where to peek to get information for ICMP to respond to. Again, as noted, many ICMP messages originate from the network, not the end host. The need for source addresses in the header in the Internet is to enable network-based error indicators. It's not clear at all why that is something we can/should want to get rid of entirely. Joe > >> > >>> In missive <48776F2A.8030405 at isi.edu>, Joe Touch typed: > >>>=20 > >>> >>This is an OpenPGP/MIME signed message (RFC 2440 and 3156) > >>> >>--------------enigFDD94A1CA6B765ED0E2F3126 > >>> >>Content-Type: text/plain; charset=3Dwindows-1252; format=3Dflowed > >>> >>Content-Transfer-Encoding: quoted-printable > >>> >> > >>> >>Jon, > >>> >> > >>> >>You asked why the Internet had source addresses. I provided an answe= > >>r,=20 > >>> >>based on my understanding of the historical context for the decision= > >>=2E I=20 > >>> >>apologize for being too terse for that to be clear, or for being too= > >>=20 > >>> >>glib to belie a thoughful consideration of the contents of your pape= > >>r. > >>> >> > >>> >>That, however, does not mean that I did not read your paper. > >>> >> > >>> >>My response of your (IMO, historical) question has nothing to do wit= > >>h=20 > >>> >>your proposal for removing them, as is discussed below. > >>> >> > >>> >>Jon Crowcroft wrote: > >>> >> > a perfect example of people responding to email that they haven't= > >> > >>> >> > actually read properly > >>> >> > >>> >>I urge posters to read the mail they *write* as well as those others= > >>=20 > >>> >>post. ;-) Please read my more detailed note below before concluding= > >> how=20 > >>> >>properly I've read your work. > >>> =20 > >>> >> > >>> >>-- > >>> >> > >>> >>You assert that: > >>> >> > >>> >>> Remember this (RFC 791)? Let=3D92s think about the line marked > >>> >>> by Xs. So why is there a source address there? The naive answer > >>> >>> is that some receivers might want to reply. > >>> >> > >>> >>That is a historically consistent answer. > >>> >> > >>> >>> It;s a Datagram, > >>> >>> Stupid. Not all higher layers want to send something back! The > >>> >>> end-to-end argument says that we do not put a function in a lower > >>> >>> layer, unless it is required by the majority of upper layer users > >>> >> > >>> >>E2E argument allows designers to "put things in a layer that THAT la= > >>yer > >>> >>actually needs". > >>> >> > >>> >>Later, your doc says that: > >>> >> > >>> >>> a better place to send advisory > >>> >>> information in the future Internet is onwards to the receiver, not= > >> > >>> >>> backwards to the sender. Obviously the unreachable cases need > >>> >>> to be considered more carefully, although if an end system is not > >>> >>> reachable, a SNA-RK might be still reachable. > >>> >> > >>> >>Host and net unreachables can't be fixed at all, as you note later. = > >> > >>> >>Other messages require the receiver know the source, which - if this= > >> is=20 > >>> >>one of those higher layers that doesn't want to send something back = > >>-=20 > >>> >>won't happen either. > >>> >> > >>> >>The fact that further discussion asserts that error notifications we= > >>re=20 > >>> >>always a bad idea I find naive as well. And MTU discovery will NEVER= > >>=20 > >>> >>happen if the receiver has no notion of who the sender is. > >>> >> > >>> >>--- > >>> >> > >>> >>> In missive <48768425.4000801 at isi.edu>, Joe Touch typed: > >>> >>>=20 > >>> >>> >>This is an OpenPGP/MIME signed message (RFC 2440 and 3156) > >>> >>> >>--------------enig163A833E39F238C5F60A48CF > >>> >>> >>Content-Type: text/plain; charset=3D3DISO-8859-1; format=3D3Dfl= > >>owed > >>> >>> >>Content-Transfer-Encoding: quoted-printable > >>> >>> >> > >>> >>> >> > >>> >>> >> > >>> >>> >>Jon Crowcroft wrote: > >>> >>> >>> speaking of sacred cows, > >>> >>> >>> why are their source addresses in IP Packets? > >>> >>> >>> http://www.cl.cam.ac.uk/~jac22/out/sna.pdf > >>> >>> >> > >>> >>> >>The same reason letters have return addresses; for errors (e.g.= > >>, ICM=3D > >>> >>Ps). =3D3D > >>> >>> >> > >>> >>> >> Not all errors signal the transport layer; some signal the ne= > >>twork=3D > >>> >>=3D3D20 > >>> >>> >>layer (e.g., too-big, redirect, etc.) > >>> >>> >> > >>> >>> >>PS - burying them in the TCP header eats option space from TCP,= > >> whic=3D > >>> >>h=3D3D20 > >>> >>> >>isn't exactly in abundance either ;-) > >>> >>> >> > >>> >>> >>Joe > >>> >>> >> > >>> >>> >> > >>> >>> >>--------------enig163A833E39F238C5F60A48CF > >>> >>> >>Content-Type: application/pgp-signature; name=3D3D"signature.as= > >>c" > >>> >>> >>Content-Description: OpenPGP digital signature > >>> >>> >>Content-Disposition: attachment; filename=3D3D"signature.asc" > >>> >>> >> > >>> >>> >>-----BEGIN PGP SIGNATURE----- > >>> >>> >>Version: GnuPG v1.4.7 (MingW32) > >>> >>> >>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > >>> >>> >> > >>> >>> >>iD8DBQFIdoQmE5f5cImnZrsRAnC9AKDrvpZ2kzV9rzrT8NN1NWkTEsWdYQCdF9O= > >>k > >>> >>> >>W8nN+CrIaW3+dENfI/qDyaw=3D3D > >>> >>> >>=3D3Do5Lq > >>> >>> >>-----END PGP SIGNATURE----- > >>> >>> >> > >>> >>> >>--------------enig163A833E39F238C5F60A48CF-- > >>> >>>=20 > >>> >>> cheers > >> > >> > >>--------------enig841B4237908E688C7D411F39 > >>Content-Type: application/pgp-signature; name="signature.asc" > >>Content-Description: OpenPGP digital signature > >>Content-Disposition: attachment; filename="signature.asc" > >> > >>-----BEGIN PGP SIGNATURE----- > >>Version: GnuPG v1.4.7 (MingW32) > >>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > >> > >>iD8DBQFId3KxE5f5cImnZrsRAl1GAJ4m5yLUosDO/kb7TwPLTa3Wi8GOWQCfbX8Y > >>mhEpJZ+jr+qMgMXMe3xEFtQ= > >>=xV8K > >>-----END PGP SIGNATURE----- > >> > >>--------------enig841B4237908E688C7D411F39-- > > cheers > > jon -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20080711/255cfe61/signature.bin From Jon.Crowcroft at cl.cam.ac.uk Fri Jul 11 08:23:37 2008 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Fri, 11 Jul 2008 16:23:37 +0100 Subject: [e2e] end2end-interest Digest, s/Vol 53, Issue 10 / sacred cows, sacre bleu/ In-Reply-To: <487777D1.6090001@isi.edu> References: <51183BA6-4D6C-4814-BF58-CD1D24A42CB8@uwaterloo.ca> <4876220D.5040302@reed.com> <48768425.4000801@isi.edu> <48776F2A.8030405@isi.edu> <487772B1.8090302@isi.edu> <487777D1.6090001@isi.edu> Message-ID: you say i should put the realm info as a tcp option and then say there isnt much space for tcp options. i say sna does it in a way that is more flexible, doesnt need a lot of routers to change just yet, and provides a lot of what people have done in mobile ipv6 (with route optimisation) without the pain of turning on full internet wide v6 routing. admittedly there's a little tweaking of some icmp code - this is not performance critical and one could easily (as per shim6) do the transport/icmp interworking cleanly across all transports hosts already peak into ICMP errors to see for what Transport they might be useful; i dont see why ICMP looking in transport to figure out whether its useful to send something at all and to whome is any different in terms of religions like "layer violation" and its a whole lot more efficient In missive <487777D1.6090001 at isi.edu>, Joe Touch typed: >>This is an OpenPGP/MIME signed message (RFC 2440 and 3156) >>--------------enigD0DFC0254F721440EFF890E4 >>Content-Type: text/plain; charset=ISO-8859-1; format=flowed >>Content-Transfer-Encoding: quoted-printable >> >>Jon (et al.), >> >>Jon Crowcroft wrote: >>> In missive <487772B1.8090302 at isi.edu>, Joe Touch typed: >>>=20 >>> >>Consider a packet whose transport lacks a destination address >>> >>altogether, as you note should be possible. Receivers of those packe= >>ts >>> >>have no way to turn them around. >>> =20 >>> >>> icmp errors can be sent, but icmp in routers would have to parse t= >>he TCP sna option >>>=20 >>> >>So basically the need for the *network* layer to signal the source i= >>s >>> >>accommodated in packets using the TCP sna option by layer violation.= >> >>>=20 >>> ICMP is layered on top of ip as is tcp - icmp talking to tcp is not a l= >>ayer >>> violation. >> >>If you call ICMP a transport layer (fair enough), you haven't explained=20 >>why one transport should peek into the headers of another. ICMP can talk = >> >>to TCP, but having ICMP parse TCP headers would be layer violation IMO. >> >>> by the way, i dont put an _address_ in the transport - i put an identif= >>ier - this >>> is then used receivers to lookup an address to the originator. i _might= >>_ put a >>> routing hint (e.g. a care of adddress) in the transport too - this is = >> >>> not the same as putting in an actual address (which i am getting rid of= >> as it is >>> invalid MOST of the time... >> >>Understood. That difference isn't key to my responses, so I've just=20 >>referred to it as an address, but didn't mean to confuse that issue. >> >>> >>Moving the source address in that case didn't make it go away, so th= >>at's >>> >>just shuffling the deck chairs. If you wanted more space for IP, it'= >>s >>> >>just as logical to leave the current IP header alone and place the e= >>xtra=20 >>> >>forwarding info in the TCP header - if you're violating layers for I= >>CMP, =3D >>>=20 >>> this is either a semantic quibble or confusing. >>>=20 >>> 1. i havnt changed the IP header ast aal - i 've changed the meaning of= >> a field - >>> thishas some very nice legacy interworking properties (as noted in my n= >>ote) >> >>Changing the meaning of a field changes the header. I.e., you can't pass = >> >>that packet through a legacy router usefully - it could generate ICMPs=20 >>to the wrong place, and won't interpret the source address field as an=20 >>extension of the destination address. >> >>My view is that: >> change IP src address to mean destination realm >> add source identifier to TCP header (e.g., as an option) >>is just as usefully accomplished as: >> leave IP as-is >> add destination realm to the TCP header (as an option) >> >>(the only remaining difference is that your source identifier isn't the=20 >>same as IP's source address; I could just as easily put the source ID in = >> >>the TCP header too if you prefer). >> >>Further, your paper and emails have not addressed the fact that TCP=20 >>headers don't exactly have lots of space - especially the SYN packet,=20 >>which is where the source identifier for a connection would need to be=20 >>established. >> >>=2E.. >>> >>why not for forwarding? >>> >>> since most of these ICMP response are meant as a response to a tr= >>anspo=3D >>> >>rt entity, >>> >>> this is semantically reasoanble. >>> >> >>> >>Your system posits transports might not ever need source addresses. >>> >>Those transports no longer benefit from ICMP information from the ne= >>twork=3D >>> >>> indeed since there is no information theoretic or control theoertic rea= >>son they >>> should want fedback from the net if thewy didnt want it from the end. -= >> i am just=20 >>> bringing some consistency to a design error of the internet. >> >>I agree that unidirectional packets don't necessarily need network=20 >>feedback. That implies: >> >>1. that your entire supposition that the IP packet doesn't need a source = >> >>address because the transport layer is unacknowledged may be true, but=20 >>actually implies that all transport layers should be bidirectional=20 >>(rather than implying that you don't need a source address). >> >>2. bidirectional packets need network address info in the network=20 >>header, because the network needs to respond to that information. if I=20 >>leave this to the transport layer, then every time I deploy a new=20 >>transport protocol (SCTP, DCCP, etc.), I need to recode all my routers=20 >>to know where to peek to get information for ICMP to respond to. >> >>Again, as noted, many ICMP messages originate from the network, not the=20 >>end host. The need for source addresses in the header in the Internet is = >> >>to enable network-based error indicators. It's not clear at all why that = >> >>is something we can/should want to get rid of entirely. >> >>Joe >> >> >> >>> >> >>> >>> In missive <48776F2A.8030405 at isi.edu>, Joe Touch typed: >>> >>>=3D20 >>> >>> >>This is an OpenPGP/MIME signed message (RFC 2440 and 3156) >>> >>> >>--------------enigFDD94A1CA6B765ED0E2F3126 >>> >>> >>Content-Type: text/plain; charset=3D3Dwindows-1252; format=3D3D= >>flowed >>> >>> >>Content-Transfer-Encoding: quoted-printable >>> >>> >> >>> >>> >>Jon, >>> >>> >> >>> >>> >>You asked why the Internet had source addresses. I provided an = >>answe=3D >>> >>r,=3D20 >>> >>> >>based on my understanding of the historical context for the dec= >>ision=3D >>> >>=3D2E I=3D20 >>> >>> >>apologize for being too terse for that to be clear, or for bein= >>g too=3D >>> >>=3D20 >>> >>> >>glib to belie a thoughful consideration of the contents of your= >> pape=3D >>> >>r. >>> >>> >> >>> >>> >>That, however, does not mean that I did not read your paper. >>> >>> >> >>> >>> >>My response of your (IMO, historical) question has nothing to d= >>o wit=3D >>> >>h=3D20 >>> >>> >>your proposal for removing them, as is discussed below. >>> >>> >> >>> >>> >>Jon Crowcroft wrote: >>> >>> >> > a perfect example of people responding to email that they ha= >>ven't=3D >>> >> >>> >>> >> > actually read properly >>> >>> >> >>> >>> >>I urge posters to read the mail they *write* as well as those o= >>thers=3D >>> >>=3D20 >>> >>> >>post. ;-) Please read my more detailed note below before concl= >>uding=3D >>> >> how=3D20 >>> >>> >>properly I've read your work. >>> >>> =3D20 >>> >>> >> >>> >>> >>-- >>> >>> >> >>> >>> >>You assert that: >>> >>> >> >>> >>> >>> Remember this (RFC 791)? Let=3D3D92s think about the line mar= >>ked >>> >>> >>> by Xs. So why is there a source address there? The naive answ= >>er >>> >>> >>> is that some receivers might want to reply. >>> >>> >> >>> >>> >>That is a historically consistent answer. >>> >>> >> >>> >>> >>> It;s a Datagram, >>> >>> >>> Stupid. Not all higher layers want to send something back! Th= >>e >>> >>> >>> end-to-end argument says that we do not put a function in a l= >>ower >>> >>> >>> layer, unless it is required by the majority of upper layer u= >>sers >>> >>> >> >>> >>> >>E2E argument allows designers to "put things in a layer that TH= >>AT la=3D >>> >>yer >>> >>> >>actually needs". >>> >>> >> >>> >>> >>Later, your doc says that: >>> >>> >> >>> >>> >>> a better place to send advisory >>> >>> >>> information in the future Internet is onwards to the receiver= >>, not=3D >>> >> >>> >>> >>> backwards to the sender. Obviously the unreachable cases need= >> >>> >>> >>> to be considered more carefully, although if an end system is= >> not >>> >>> >>> reachable, a SNA-RK might be still reachable. >>> >>> >> >>> >>> >>Host and net unreachables can't be fixed at all, as you note la= >>ter. =3D >>> >> >>> >>> >>Other messages require the receiver know the source, which - if= >> this=3D >>> >> is=3D20 >>> >>> >>one of those higher layers that doesn't want to send something = >>back =3D >>> >>-=3D20 >>> >>> >>won't happen either. >>> >>> >> >>> >>> >>The fact that further discussion asserts that error notificatio= >>ns we=3D >>> >>re=3D20 >>> >>> >>always a bad idea I find naive as well. And MTU discovery will = >>NEVER=3D >>> >>=3D20 >>> >>> >>happen if the receiver has no notion of who the sender is. >>> >>> >> >>> >>> >>--- >>> >>> >> >>> >>> >>> In missive <48768425.4000801 at isi.edu>, Joe Touch typed: >>> >>> >>>=3D20 >>> >>> >>> >>This is an OpenPGP/MIME signed message (RFC 2440 and 3156)= >> >>> >>> >>> >>--------------enig163A833E39F238C5F60A48CF >>> >>> >>> >>Content-Type: text/plain; charset=3D3D3DISO-8859-1; format= >>=3D3D3Dfl=3D >>> >>owed >>> >>> >>> >>Content-Transfer-Encoding: quoted-printable >>> >>> >>> >> >>> >>> >>> >> >>> >>> >>> >> >>> >>> >>> >>Jon Crowcroft wrote: >>> >>> >>> >>> speaking of sacred cows, >>> >>> >>> >>> why are their source addresses in IP Packets? >>> >>> >>> >>> http://www.cl.cam.ac.uk/~jac22/out/sna.pdf >>> >>> >>> >> >>> >>> >>> >>The same reason letters have return addresses; for errors = >>(e.g.=3D >>> >>, ICM=3D3D >>> >>> >>Ps). =3D3D3D >>> >>> >>> >> >>> >>> >>> >> Not all errors signal the transport layer; some signal t= >>he ne=3D >>> >>twork=3D3D >>> >>> >>=3D3D3D20 >>> >>> >>> >>layer (e.g., too-big, redirect, etc.) >>> >>> >>> >> >>> >>> >>> >>PS - burying them in the TCP header eats option space from= >> TCP,=3D >>> >> whic=3D3D >>> >>> >>h=3D3D3D20 >>> >>> >>> >>isn't exactly in abundance either ;-) >>> >>> >>> >> >>> >>> >>> >>Joe >>> >>> >>> >> >>> >>> >>> >> >>> >>> >>> >>--------------enig163A833E39F238C5F60A48CF >>> >>> >>> >>Content-Type: application/pgp-signature; name=3D3D3D"signa= >>ture.as=3D >>> >>c" >>> >>> >>> >>Content-Description: OpenPGP digital signature >>> >>> >>> >>Content-Disposition: attachment; filename=3D3D3D"signature= >>=2Easc" >>> >>> >>> >> >>> >>> >>> >>-----BEGIN PGP SIGNATURE----- >>> >>> >>> >>Version: GnuPG v1.4.7 (MingW32) >>> >>> >>> >>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev= >>=2Eorg >>> >>> >>> >> >>> >>> >>> >>iD8DBQFIdoQmE5f5cImnZrsRAnC9AKDrvpZ2kzV9rzrT8NN1NWkTEsWdYQ= >>CdF9O=3D >>> >>k >>> >>> >>> >>W8nN+CrIaW3+dENfI/qDyaw=3D3D3D >>> >>> >>> >>=3D3D3Do5Lq >>> >>> >>> >>-----END PGP SIGNATURE----- >>> >>> >>> >> >>> >>> >>> >>--------------enig163A833E39F238C5F60A48CF-- >>> >>> >>>=3D20 >>> >>> >>> cheers >>> >> >>> >> >>> >>--------------enig841B4237908E688C7D411F39 >>> >>Content-Type: application/pgp-signature; name=3D"signature.asc" >>> >>Content-Description: OpenPGP digital signature >>> >>Content-Disposition: attachment; filename=3D"signature.asc" >>> >> >>> >>-----BEGIN PGP SIGNATURE----- >>> >>Version: GnuPG v1.4.7 (MingW32) >>> >>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org >>> >> >>> >>iD8DBQFId3KxE5f5cImnZrsRAl1GAJ4m5yLUosDO/kb7TwPLTa3Wi8GOWQCfbX8Y >>> >>mhEpJZ+jr+qMgMXMe3xEFtQ=3D >>> >>=3DxV8K >>> >>-----END PGP SIGNATURE----- >>> >> >>> >>--------------enig841B4237908E688C7D411F39-- >>>=20 >>> cheers >>>=20 >>> jon >> >> >>--------------enigD0DFC0254F721440EFF890E4 >>Content-Type: application/pgp-signature; name="signature.asc" >>Content-Description: OpenPGP digital signature >>Content-Disposition: attachment; filename="signature.asc" >> >>-----BEGIN PGP SIGNATURE----- >>Version: GnuPG v1.4.7 (MingW32) >>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org >> >>iD8DBQFId3fRE5f5cImnZrsRAqZIAKC5AISvnZl/XvTpQQo8MQmorJbYcACcDnHE >>J6vm6gE7ZeA+AeVBsDHv/t8= >>=SAYu >>-----END PGP SIGNATURE----- >> >>--------------enigD0DFC0254F721440EFF890E4-- cheers jon From touch at ISI.EDU Fri Jul 11 08:45:20 2008 From: touch at ISI.EDU (Joe Touch) Date: Fri, 11 Jul 2008 08:45:20 -0700 Subject: [e2e] end2end-interest Digest, s/Vol 53, Issue 10 / sacred cows, sacre bleu/ In-Reply-To: References: <51183BA6-4D6C-4814-BF58-CD1D24A42CB8@uwaterloo.ca> <4876220D.5040302@reed.com> <48768425.4000801@isi.edu> <48776F2A.8030405@isi.edu> <487772B1.8090302@isi.edu> <487777D1.6090001@isi.edu> Message-ID: <48778010.102@isi.edu> Jon Crowcroft wrote: > you say i should put the realm info as a tcp option and then say there isnt > much space for tcp options. You do put something as a TCP option - the source ID. I'm saying that it is just as useful (or problematic) to put the realm there, and that TCP lacks space in general for either. > i say sna does it in a way that is more flexible, doesnt need a lot of routers to > change just yet, All routers on a path need to change to find the SNA ID to send return ICMP errors. > and provides a lot of what people have done in mobile ipv6 (with > route optimisation) without the pain of turning on full internet wide v6 routing. > admittedly there's a little tweaking of some icmp code - this is not performance > critical and one could easily (as per shim6) do the transport/icmp interworking > cleanly across all transports If this is done as a shim on IP, then it's just an IP option (implemented a different way), in which case you haven't removed the source address so much as shifted it. If this is done as a common transport option, you're pinning transport protocols into a structure in order to support a network layer capability, which violates layering. > hosts already peak into ICMP errors to see for what Transport they might be useful; That's not peeking; that's receiving an ICMP message and parsing it as indicated. > i dont see why ICMP looking in transport to figure out > whether its useful to send something at all and to whome is any different > in terms of religions like "layer violation" and its a whole lot more efficient It's not a religious issue; I'm noting that source IDs/addresses aren't only transport-layer info, and that's why ICMP needs access to them. Overall: - your proposal doesn't get rid of the source addr, it just moves it e.g., because packets without source addrs can be silently dropped without signaling the source, as you note, and apps sending packets without sources should expect this - moving the source address doesn't accomplish anything you want extra space for realms; that's fine, but taking that space from IP and putting the info in TCP isn't a win; it complicates ICMP design at routers. it's just as useful to put realms in the TCP header, or to put it in an IP option; there may be utility in that, but this has nothing to do with getting rid of a source address Joe > In missive <487777D1.6090001 at isi.edu>, Joe Touch typed: > > >>This is an OpenPGP/MIME signed message (RFC 2440 and 3156) > >>--------------enigD0DFC0254F721440EFF890E4 > >>Content-Type: text/plain; charset=ISO-8859-1; format=flowed > >>Content-Transfer-Encoding: quoted-printable > >> > >>Jon (et al.), > >> > >>Jon Crowcroft wrote: > >>> In missive <487772B1.8090302 at isi.edu>, Joe Touch typed: > >>>=20 > >>> >>Consider a packet whose transport lacks a destination address > >>> >>altogether, as you note should be possible. Receivers of those packe= > >>ts > >>> >>have no way to turn them around. > >>> =20 > >>> >>> icmp errors can be sent, but icmp in routers would have to parse t= > >>he TCP sna option > >>>=20 > >>> >>So basically the need for the *network* layer to signal the source i= > >>s > >>> >>accommodated in packets using the TCP sna option by layer violation.= > >> > >>>=20 > >>> ICMP is layered on top of ip as is tcp - icmp talking to tcp is not a l= > >>ayer > >>> violation. > >> > >>If you call ICMP a transport layer (fair enough), you haven't explained=20 > >>why one transport should peek into the headers of another. ICMP can talk = > >> > >>to TCP, but having ICMP parse TCP headers would be layer violation IMO. > >> > >>> by the way, i dont put an _address_ in the transport - i put an identif= > >>ier - this > >>> is then used receivers to lookup an address to the originator. i _might= > >>_ put a > >>> routing hint (e.g. a care of adddress) in the transport too - this is = > >> > >>> not the same as putting in an actual address (which i am getting rid of= > >> as it is > >>> invalid MOST of the time... > >> > >>Understood. That difference isn't key to my responses, so I've just=20 > >>referred to it as an address, but didn't mean to confuse that issue. > >> > >>> >>Moving the source address in that case didn't make it go away, so th= > >>at's > >>> >>just shuffling the deck chairs. If you wanted more space for IP, it'= > >>s > >>> >>just as logical to leave the current IP header alone and place the e= > >>xtra=20 > >>> >>forwarding info in the TCP header - if you're violating layers for I= > >>CMP, =3D > >>>=20 > >>> this is either a semantic quibble or confusing. > >>>=20 > >>> 1. i havnt changed the IP header ast aal - i 've changed the meaning of= > >> a field - > >>> thishas some very nice legacy interworking properties (as noted in my n= > >>ote) > >> > >>Changing the meaning of a field changes the header. I.e., you can't pass = > >> > >>that packet through a legacy router usefully - it could generate ICMPs=20 > >>to the wrong place, and won't interpret the source address field as an=20 > >>extension of the destination address. > >> > >>My view is that: > >> change IP src address to mean destination realm > >> add source identifier to TCP header (e.g., as an option) > >>is just as usefully accomplished as: > >> leave IP as-is > >> add destination realm to the TCP header (as an option) > >> > >>(the only remaining difference is that your source identifier isn't the=20 > >>same as IP's source address; I could just as easily put the source ID in = > >> > >>the TCP header too if you prefer). > >> > >>Further, your paper and emails have not addressed the fact that TCP=20 > >>headers don't exactly have lots of space - especially the SYN packet,=20 > >>which is where the source identifier for a connection would need to be=20 > >>established. > >> > >>=2E.. > >>> >>why not for forwarding? > >>> >>> since most of these ICMP response are meant as a response to a tr= > >>anspo=3D > >>> >>rt entity, > >>> >>> this is semantically reasoanble. > >>> >> > >>> >>Your system posits transports might not ever need source addresses. > >>> >>Those transports no longer benefit from ICMP information from the ne= > >>twork=3D > >>> > >>> indeed since there is no information theoretic or control theoertic rea= > >>son they > >>> should want fedback from the net if thewy didnt want it from the end. -= > >> i am just=20 > >>> bringing some consistency to a design error of the internet. > >> > >>I agree that unidirectional packets don't necessarily need network=20 > >>feedback. That implies: > >> > >>1. that your entire supposition that the IP packet doesn't need a source = > >> > >>address because the transport layer is unacknowledged may be true, but=20 > >>actually implies that all transport layers should be bidirectional=20 > >>(rather than implying that you don't need a source address). > >> > >>2. bidirectional packets need network address info in the network=20 > >>header, because the network needs to respond to that information. if I=20 > >>leave this to the transport layer, then every time I deploy a new=20 > >>transport protocol (SCTP, DCCP, etc.), I need to recode all my routers=20 > >>to know where to peek to get information for ICMP to respond to. > >> > >>Again, as noted, many ICMP messages originate from the network, not the=20 > >>end host. The need for source addresses in the header in the Internet is = > >> > >>to enable network-based error indicators. It's not clear at all why that = > >> > >>is something we can/should want to get rid of entirely. > >> > >>Joe > >> > >> > >> > >>> >> > >>> >>> In missive <48776F2A.8030405 at isi.edu>, Joe Touch typed: > >>> >>>=3D20 > >>> >>> >>This is an OpenPGP/MIME signed message (RFC 2440 and 3156) > >>> >>> >>--------------enigFDD94A1CA6B765ED0E2F3126 > >>> >>> >>Content-Type: text/plain; charset=3D3Dwindows-1252; format=3D3D= > >>flowed > >>> >>> >>Content-Transfer-Encoding: quoted-printable > >>> >>> >> > >>> >>> >>Jon, > >>> >>> >> > >>> >>> >>You asked why the Internet had source addresses. I provided an = > >>answe=3D > >>> >>r,=3D20 > >>> >>> >>based on my understanding of the historical context for the dec= > >>ision=3D > >>> >>=3D2E I=3D20 > >>> >>> >>apologize for being too terse for that to be clear, or for bein= > >>g too=3D > >>> >>=3D20 > >>> >>> >>glib to belie a thoughful consideration of the contents of your= > >> pape=3D > >>> >>r. > >>> >>> >> > >>> >>> >>That, however, does not mean that I did not read your paper. > >>> >>> >> > >>> >>> >>My response of your (IMO, historical) question has nothing to d= > >>o wit=3D > >>> >>h=3D20 > >>> >>> >>your proposal for removing them, as is discussed below. > >>> >>> >> > >>> >>> >>Jon Crowcroft wrote: > >>> >>> >> > a perfect example of people responding to email that they ha= > >>ven't=3D > >>> >> > >>> >>> >> > actually read properly > >>> >>> >> > >>> >>> >>I urge posters to read the mail they *write* as well as those o= > >>thers=3D > >>> >>=3D20 > >>> >>> >>post. ;-) Please read my more detailed note below before concl= > >>uding=3D > >>> >> how=3D20 > >>> >>> >>properly I've read your work. > >>> >>> =3D20 > >>> >>> >> > >>> >>> >>-- > >>> >>> >> > >>> >>> >>You assert that: > >>> >>> >> > >>> >>> >>> Remember this (RFC 791)? Let=3D3D92s think about the line mar= > >>ked > >>> >>> >>> by Xs. So why is there a source address there? The naive answ= > >>er > >>> >>> >>> is that some receivers might want to reply. > >>> >>> >> > >>> >>> >>That is a historically consistent answer. > >>> >>> >> > >>> >>> >>> It;s a Datagram, > >>> >>> >>> Stupid. Not all higher layers want to send something back! Th= > >>e > >>> >>> >>> end-to-end argument says that we do not put a function in a l= > >>ower > >>> >>> >>> layer, unless it is required by the majority of upper layer u= > >>sers > >>> >>> >> > >>> >>> >>E2E argument allows designers to "put things in a layer that TH= > >>AT la=3D > >>> >>yer > >>> >>> >>actually needs". > >>> >>> >> > >>> >>> >>Later, your doc says that: > >>> >>> >> > >>> >>> >>> a better place to send advisory > >>> >>> >>> information in the future Internet is onwards to the receiver= > >>, not=3D > >>> >> > >>> >>> >>> backwards to the sender. Obviously the unreachable cases need= > >> > >>> >>> >>> to be considered more carefully, although if an end system is= > >> not > >>> >>> >>> reachable, a SNA-RK might be still reachable. > >>> >>> >> > >>> >>> >>Host and net unreachables can't be fixed at all, as you note la= > >>ter. =3D > >>> >> > >>> >>> >>Other messages require the receiver know the source, which - if= > >> this=3D > >>> >> is=3D20 > >>> >>> >>one of those higher layers that doesn't want to send something = > >>back =3D > >>> >>-=3D20 > >>> >>> >>won't happen either. > >>> >>> >> > >>> >>> >>The fact that further discussion asserts that error notificatio= > >>ns we=3D > >>> >>re=3D20 > >>> >>> >>always a bad idea I find naive as well. And MTU discovery will = > >>NEVER=3D > >>> >>=3D20 > >>> >>> >>happen if the receiver has no notion of who the sender is. > >>> >>> >> > >>> >>> >>--- > >>> >>> >> > >>> >>> >>> In missive <48768425.4000801 at isi.edu>, Joe Touch typed: > >>> >>> >>>=3D20 > >>> >>> >>> >>This is an OpenPGP/MIME signed message (RFC 2440 and 3156)= > >> > >>> >>> >>> >>--------------enig163A833E39F238C5F60A48CF > >>> >>> >>> >>Content-Type: text/plain; charset=3D3D3DISO-8859-1; format= > >>=3D3D3Dfl=3D > >>> >>owed > >>> >>> >>> >>Content-Transfer-Encoding: quoted-printable > >>> >>> >>> >> > >>> >>> >>> >> > >>> >>> >>> >> > >>> >>> >>> >>Jon Crowcroft wrote: > >>> >>> >>> >>> speaking of sacred cows, > >>> >>> >>> >>> why are their source addresses in IP Packets? > >>> >>> >>> >>> http://www.cl.cam.ac.uk/~jac22/out/sna.pdf > >>> >>> >>> >> > >>> >>> >>> >>The same reason letters have return addresses; for errors = > >>(e.g.=3D > >>> >>, ICM=3D3D > >>> >>> >>Ps). =3D3D3D > >>> >>> >>> >> > >>> >>> >>> >> Not all errors signal the transport layer; some signal t= > >>he ne=3D > >>> >>twork=3D3D > >>> >>> >>=3D3D3D20 > >>> >>> >>> >>layer (e.g., too-big, redirect, etc.) > >>> >>> >>> >> > >>> >>> >>> >>PS - burying them in the TCP header eats option space from= > >> TCP,=3D > >>> >> whic=3D3D > >>> >>> >>h=3D3D3D20 > >>> >>> >>> >>isn't exactly in abundance either ;-) > >>> >>> >>> >> > >>> >>> >>> >>Joe > >>> >>> >>> >> > >>> >>> >>> >> > >>> >>> >>> >>--------------enig163A833E39F238C5F60A48CF > >>> >>> >>> >>Content-Type: application/pgp-signature; name=3D3D3D"signa= > >>ture.as=3D > >>> >>c" > >>> >>> >>> >>Content-Description: OpenPGP digital signature > >>> >>> >>> >>Content-Disposition: attachment; filename=3D3D3D"signature= > >>=2Easc" > >>> >>> >>> >> > >>> >>> >>> >>-----BEGIN PGP SIGNATURE----- > >>> >>> >>> >>Version: GnuPG v1.4.7 (MingW32) > >>> >>> >>> >>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev= > >>=2Eorg > >>> >>> >>> >> > >>> >>> >>> >>iD8DBQFIdoQmE5f5cImnZrsRAnC9AKDrvpZ2kzV9rzrT8NN1NWkTEsWdYQ= > >>CdF9O=3D > >>> >>k > >>> >>> >>> >>W8nN+CrIaW3+dENfI/qDyaw=3D3D3D > >>> >>> >>> >>=3D3D3Do5Lq > >>> >>> >>> >>-----END PGP SIGNATURE----- > >>> >>> >>> >> > >>> >>> >>> >>--------------enig163A833E39F238C5F60A48CF-- > >>> >>> >>>=3D20 > >>> >>> >>> cheers > >>> >> > >>> >> > >>> >>--------------enig841B4237908E688C7D411F39 > >>> >>Content-Type: application/pgp-signature; name=3D"signature.asc" > >>> >>Content-Description: OpenPGP digital signature > >>> >>Content-Disposition: attachment; filename=3D"signature.asc" > >>> >> > >>> >>-----BEGIN PGP SIGNATURE----- > >>> >>Version: GnuPG v1.4.7 (MingW32) > >>> >>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > >>> >> > >>> >>iD8DBQFId3KxE5f5cImnZrsRAl1GAJ4m5yLUosDO/kb7TwPLTa3Wi8GOWQCfbX8Y > >>> >>mhEpJZ+jr+qMgMXMe3xEFtQ=3D > >>> >>=3DxV8K > >>> >>-----END PGP SIGNATURE----- > >>> >> > >>> >>--------------enig841B4237908E688C7D411F39-- > >>>=20 > >>> cheers > >>>=20 > >>> jon > >> > >> > >>--------------enigD0DFC0254F721440EFF890E4 > >>Content-Type: application/pgp-signature; name="signature.asc" > >>Content-Description: OpenPGP digital signature > >>Content-Disposition: attachment; filename="signature.asc" > >> > >>-----BEGIN PGP SIGNATURE----- > >>Version: GnuPG v1.4.7 (MingW32) > >>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > >> > >>iD8DBQFId3fRE5f5cImnZrsRAqZIAKC5AISvnZl/XvTpQQo8MQmorJbYcACcDnHE > >>J6vm6gE7ZeA+AeVBsDHv/t8= > >>=SAYu > >>-----END PGP SIGNATURE----- > >> > >>--------------enigD0DFC0254F721440EFF890E4-- > > cheers > > jon -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20080711/f3740e6f/signature.bin From huitema at windows.microsoft.com Fri Jul 11 08:54:21 2008 From: huitema at windows.microsoft.com (Christian Huitema) Date: Fri, 11 Jul 2008 08:54:21 -0700 Subject: [e2e] Why do we need TCP flow control (rwnd)? In-Reply-To: <20080711140515.5BDAD28E155@aland.bbn.com> References: Your message of "Wed, 02 Jul 2008 19:16:41 BST." <4E44F683-8AAB-451F-BC39-0ECA9A6F688F@surrey.ac.uk> <20080711140515.5BDAD28E155@aland.bbn.com> Message-ID: <8EFB68EAE061884A8517F2A755E8B60A0AA17C580A@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> > The reason folks thought that data networks would be Poisson was that > > 1. Phone networks were demonstrably Poisson > > 2. They had nothing else in the arsenal (that is, if you were going > to do anything non-trivial, you lacked an analytic alternative) Craig, The point about nothing else is certainly valid. If you have to perform your computation using log tables and an actual spreadsheet, then tackling anything besides Poisson will be very challenging. However, it has been known for some time that Poisson was at best a first degree approximation, even for phone traffic. Consider two widely documented cases, time variations in traffic and flash crowd, both of which have been part of traffic engineering for a long time. The average traffic load is known to vary as a function of the time of day, day of the week, month of the year, not to mention Mother's day. There is no way you can model that as a single "independent arrival" process. Flash crowds happen when many people decide to pick up their phone at the same time, e.g. to call in a TV show, or to report about a particular incident. Again, there is no way to model flash crowds as independent arrivals. Even the duration of phone calls was probably not well modeled by time independent departure processes, e.g. if you take into account the behavior of teenagers in the 70's. I suspect that any process that results from human behavior is very likely to exhibit much more variability than predicted by a Poisson model. That's certainly true for phone traffic as well. -- Christian Huitema From Jon.Crowcroft at cl.cam.ac.uk Fri Jul 11 09:02:21 2008 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Fri, 11 Jul 2008 17:02:21 +0100 Subject: [e2e] end2end-interest Digest, s/Vol 53, Issue 10 / sacred cows, sacre bleu/ In-Reply-To: <48778010.102@isi.edu> References: <51183BA6-4D6C-4814-BF58-CD1D24A42CB8@uwaterloo.ca> <4876220D.5040302@reed.com> <48768425.4000801@isi.edu> <48776F2A.8030405@isi.edu> <487772B1.8090302@isi.edu> <487777D1.6090001@isi.edu> <48778010.102@isi.edu> Message-ID: as I said, I put an identifier in transport (optionally) and free up the space in IP for more flexible use of locator+identifers there. this achieves _exactly_ what mobilei pv6 with route optimisation does (and more since I can also do multipath and multihomed tcp properly now) I simplify the design of ip to get these properties properly, at the cost of complex icmp but icmp is slow path/control plane so that tradeoff is to MY benefit. putting information for forwarding (as opposed to for end system) into the TCP header would require ip forwarding to look there - on the fast path which is clearly a Bad Idea not just in relegious sense, but also in an engienering sense. ICMP communicates largely information for transport (i.e. its a middle box function) so as i have said several times, it is completely within scope to consider making this communication more fit for purpose (indeed, more in keeping with the end to end argument) end of argument In missive <48778010.102 at isi.edu>, Joe Touch typed: >>This is an OpenPGP/MIME signed message (RFC 2440 and 3156) >>--------------enigF1C37DEE2E67C3C7E2C863DF >>Content-Type: text/plain; charset=ISO-8859-1; format=flowed >>Content-Transfer-Encoding: quoted-printable >> >> >> >>Jon Crowcroft wrote: >>> you say i should put the realm info as a tcp option and then say there= >> isnt >>> much space for tcp options. >> >>You do put something as a TCP option - the source ID. I'm saying that it = >> >>is just as useful (or problematic) to put the realm there, and that TCP=20 >>lacks space in general for either. >> >>> i say sna does it in a way that is more flexible, doesnt need a lot of = >>routers to >>> change just yet,=20 >> >>All routers on a path need to change to find the SNA ID to send return=20 >>ICMP errors. >> >> > and provides a lot of what people have done in mobile ipv6 (with >>> route optimisation) without the pain of turning on full internet wide v= >>6 routing. >>> admittedly there's a little tweaking of some icmp code - this is not pe= >>rformance >>> critical and one could easily (as per shim6) do the transport/icmp inte= >>rworking >>> cleanly across all transports >> >>If this is done as a shim on IP, then it's just an IP option=20 >>(implemented a different way), in which case you haven't removed the=20 >>source address so much as shifted it. >> >>If this is done as a common transport option, you're pinning transport=20 >>protocols into a structure in order to support a network layer=20 >>capability, which violates layering. >> >>> hosts already peak into ICMP errors to see for what Transport they migh= >>t be useful;=20 >> >>That's not peeking; that's receiving an ICMP message and parsing it as=20 >>indicated. >> >>> i dont see why ICMP looking in transport to figure out=20 >>> whether its useful to send something at all and to whome is any differe= >>nt=20 >>> in terms of religions like "layer violation" and its a whole lot more e= >>fficient >> >>It's not a religious issue; I'm noting that source IDs/addresses aren't >>only transport-layer info, and that's why ICMP needs access to them. >> >>Overall: >> >>- your proposal doesn't get rid of the source addr, it just moves it >> e.g., because packets without source addrs can be silently >> dropped without signaling the source, as you note, >> and apps sending packets without sources should expect this >> >>- moving the source address doesn't accomplish anything >> you want extra space for realms; that's fine, but taking >> that space from IP and putting the info in TCP isn't >> a win; it complicates ICMP design at routers. it's >> just as useful to put realms in the TCP header, >> or to put it in an IP option; there may be utility >> in that, but this has nothing to do with getting rid >> of a source address >> >>Joe >> >> >>> In missive <487777D1.6090001 at isi.edu>, Joe Touch typed: >>>=20 >>> >>This is an OpenPGP/MIME signed message (RFC 2440 and 3156) >>> >>--------------enigD0DFC0254F721440EFF890E4 >>> >>Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed >>> >>Content-Transfer-Encoding: quoted-printable >>> >> >>> >>Jon (et al.), >>> >> >>> >>Jon Crowcroft wrote: >>> >>> In missive <487772B1.8090302 at isi.edu>, Joe Touch typed: >>> >>>=3D20 >>> >>> >>Consider a packet whose transport lacks a destination address >>> >>> >>altogether, as you note should be possible. Receivers of those = >>packe=3D >>> >>ts >>> >>> >>have no way to turn them around. >>> >>> =3D20 >>> >>> >>> icmp errors can be sent, but icmp in routers would have to pa= >>rse t=3D >>> >>he TCP sna option >>> >>>=3D20 >>> >>> >>So basically the need for the *network* layer to signal the sou= >>rce i=3D >>> >>s >>> >>> >>accommodated in packets using the TCP sna option by layer viola= >>tion.=3D >>> >> >>> >>>=3D20 >>> >>> ICMP is layered on top of ip as is tcp - icmp talking to tcp is no= >>t a l=3D >>> >>ayer >>> >>> violation. >>> >> >>> >>If you call ICMP a transport layer (fair enough), you haven't explai= >>ned=3D20 >>> >>why one transport should peek into the headers of another. ICMP can = >>talk =3D >>> >> >>> >>to TCP, but having ICMP parse TCP headers would be layer violation I= >>MO. >>> >> >>> >>> by the way, i dont put an _address_ in the transport - i put an id= >>entif=3D >>> >>ier - this >>> >>> is then used receivers to lookup an address to the originator. i _= >>might=3D >>> >>_ put a >>> >>> routing hint (e.g. a care of adddress) in the transport too - this= >> is =3D >>> >> >>> >>> not the same as putting in an actual address (which i am getting r= >>id of=3D >>> >> as it is >>> >>> invalid MOST of the time... >>> >> >>> >>Understood. That difference isn't key to my responses, so I've just=3D= >>20 >>> >>referred to it as an address, but didn't mean to confuse that issue.= >> >>> >> >>> >>> >>Moving the source address in that case didn't make it go away, = >>so th=3D >>> >>at's >>> >>> >>just shuffling the deck chairs. If you wanted more space for IP= >>, it'=3D >>> >>s >>> >>> >>just as logical to leave the current IP header alone and place = >>the e=3D >>> >>xtra=3D20 >>> >>> >>forwarding info in the TCP header - if you're violating layers = >>for I=3D >>> >>CMP, =3D3D >>> >>>=3D20 >>> >>> this is either a semantic quibble or confusing. >>> >>>=3D20 >>> >>> 1. i havnt changed the IP header ast aal - i 've changed the meani= >>ng of=3D >>> >> a field - >>> >>> thishas some very nice legacy interworking properties (as noted in= >> my n=3D >>> >>ote) >>> >> >>> >>Changing the meaning of a field changes the header. I.e., you can't = >>pass =3D >>> >> >>> >>that packet through a legacy router usefully - it could generate ICM= >>Ps=3D20 >>> >>to the wrong place, and won't interpret the source address field as = >>an=3D20 >>> >>extension of the destination address. >>> >> >>> >>My view is that: >>> >> change IP src address to mean destination realm >>> >> add source identifier to TCP header (e.g., as an option) >>> >>is just as usefully accomplished as: >>> >> leave IP as-is >>> >> add destination realm to the TCP header (as an option) >>> >> >>> >>(the only remaining difference is that your source identifier isn't = >>the=3D20 >>> >>same as IP's source address; I could just as easily put the source I= >>D in =3D >>> >> >>> >>the TCP header too if you prefer). >>> >> >>> >>Further, your paper and emails have not addressed the fact that TCP=3D= >>20 >>> >>headers don't exactly have lots of space - especially the SYN packet= >>,=3D20 >>> >>which is where the source identifier for a connection would need to = >>be=3D20 >>> >>established. >>> >> >>> >>=3D2E.. >>> >>> >>why not for forwarding? >>> >>> >>> since most of these ICMP response are meant as a response to= >> a tr=3D >>> >>anspo=3D3D >>> >>> >>rt entity, >>> >>> >>> this is semantically reasoanble. >>> >>> >> >>> >>> >>Your system posits transports might not ever need source addres= >>ses. >>> >>> >>Those transports no longer benefit from ICMP information from t= >>he ne=3D >>> >>twork=3D3D >>> >>> >>> >>> indeed since there is no information theoretic or control theoerti= >>c rea=3D >>> >>son they >>> >>> should want fedback from the net if thewy didnt want it from the e= >>nd. -=3D >>> >> i am just=3D20 >>> >>> bringing some consistency to a design error of the internet. >>> >> >>> >>I agree that unidirectional packets don't necessarily need network=3D= >>20 >>> >>feedback. That implies: >>> >> >>> >>1. that your entire supposition that the IP packet doesn't need a so= >>urce =3D >>> >> >>> >>address because the transport layer is unacknowledged may be true, b= >>ut=3D20 >>> >>actually implies that all transport layers should be bidirectional=3D= >>20 >>> >>(rather than implying that you don't need a source address). >>> >> >>> >>2. bidirectional packets need network address info in the network=3D= >>20 >>> >>header, because the network needs to respond to that information. if= >> I=3D20 >>> >>leave this to the transport layer, then every time I deploy a new=3D= >>20 >>> >>transport protocol (SCTP, DCCP, etc.), I need to recode all my route= >>rs=3D20 >>> >>to know where to peek to get information for ICMP to respond to. >>> >> >>> >>Again, as noted, many ICMP messages originate from the network, not = >>the=3D20 >>> >>end host. The need for source addresses in the header in the Interne= >>t is =3D >>> >> >>> >>to enable network-based error indicators. It's not clear at all why = >>that =3D >>> >> >>> >>is something we can/should want to get rid of entirely. >>> >> >>> >>Joe >>> >> >>> >> >>> >> >>> >>> >> >>> >>> >>> In missive <48776F2A.8030405 at isi.edu>, Joe Touch typed: >>> >>> >>>=3D3D20 >>> >>> >>> >>This is an OpenPGP/MIME signed message (RFC 2440 and 3156)= >> >>> >>> >>> >>--------------enigFDD94A1CA6B765ED0E2F3126 >>> >>> >>> >>Content-Type: text/plain; charset=3D3D3Dwindows-1252; form= >>at=3D3D3D=3D >>> >>flowed >>> >>> >>> >>Content-Transfer-Encoding: quoted-printable >>> >>> >>> >> >>> >>> >>> >>Jon, >>> >>> >>> >> >>> >>> >>> >>You asked why the Internet had source addresses. I provide= >>d an =3D >>> >>answe=3D3D >>> >>> >>r,=3D3D20 >>> >>> >>> >>based on my understanding of the historical context for th= >>e dec=3D >>> >>ision=3D3D >>> >>> >>=3D3D2E I=3D3D20 >>> >>> >>> >>apologize for being too terse for that to be clear, or for= >> bein=3D >>> >>g too=3D3D >>> >>> >>=3D3D20 >>> >>> >>> >>glib to belie a thoughful consideration of the contents of= >> your=3D >>> >> pape=3D3D >>> >>> >>r. >>> >>> >>> >> >>> >>> >>> >>That, however, does not mean that I did not read your pape= >>r. >>> >>> >>> >> >>> >>> >>> >>My response of your (IMO, historical) question has nothing= >> to d=3D >>> >>o wit=3D3D >>> >>> >>h=3D3D20 >>> >>> >>> >>your proposal for removing them, as is discussed below. >>> >>> >>> >> >>> >>> >>> >>Jon Crowcroft wrote: >>> >>> >>> >> > a perfect example of people responding to email that th= >>ey ha=3D >>> >>ven't=3D3D >>> >>> >> >>> >>> >>> >> > actually read properly >>> >>> >>> >> >>> >>> >>> >>I urge posters to read the mail they *write* as well as th= >>ose o=3D >>> >>thers=3D3D >>> >>> >>=3D3D20 >>> >>> >>> >>post. ;-) Please read my more detailed note below before = >>concl=3D >>> >>uding=3D3D >>> >>> >> how=3D3D20 >>> >>> >>> >>properly I've read your work. >>> >>> >>> =3D3D20 >>> >>> >>> >> >>> >>> >>> >>-- >>> >>> >>> >> >>> >>> >>> >>You assert that: >>> >>> >>> >> >>> >>> >>> >>> Remember this (RFC 791)? Let=3D3D3D92s think about the l= >>ine mar=3D >>> >>ked >>> >>> >>> >>> by Xs. So why is there a source address there? The naive= >> answ=3D >>> >>er >>> >>> >>> >>> is that some receivers might want to reply. >>> >>> >>> >> >>> >>> >>> >>That is a historically consistent answer. >>> >>> >>> >> >>> >>> >>> >>> It;s a Datagram, >>> >>> >>> >>> Stupid. Not all higher layers want to send something bac= >>k! Th=3D >>> >>e >>> >>> >>> >>> end-to-end argument says that we do not put a function i= >>n a l=3D >>> >>ower >>> >>> >>> >>> layer, unless it is required by the majority of upper la= >>yer u=3D >>> >>sers >>> >>> >>> >> >>> >>> >>> >>E2E argument allows designers to "put things in a layer th= >>at TH=3D >>> >>AT la=3D3D >>> >>> >>yer >>> >>> >>> >>actually needs". >>> >>> >>> >> >>> >>> >>> >>Later, your doc says that: >>> >>> >>> >> >>> >>> >>> >>> a better place to send advisory >>> >>> >>> >>> information in the future Internet is onwards to the rec= >>eiver=3D >>> >>, not=3D3D >>> >>> >> >>> >>> >>> >>> backwards to the sender. Obviously the unreachable cases= >> need=3D >>> >> >>> >>> >>> >>> to be considered more carefully, although if an end syst= >>em is=3D >>> >> not >>> >>> >>> >>> reachable, a SNA-RK might be still reachable. >>> >>> >>> >> >>> >>> >>> >>Host and net unreachables can't be fixed at all, as you no= >>te la=3D >>> >>ter. =3D3D >>> >>> >> >>> >>> >>> >>Other messages require the receiver know the source, which= >> - if=3D >>> >> this=3D3D >>> >>> >> is=3D3D20 >>> >>> >>> >>one of those higher layers that doesn't want to send somet= >>hing =3D >>> >>back =3D3D >>> >>> >>-=3D3D20 >>> >>> >>> >>won't happen either. >>> >>> >>> >> >>> >>> >>> >>The fact that further discussion asserts that error notifi= >>catio=3D >>> >>ns we=3D3D >>> >>> >>re=3D3D20 >>> >>> >>> >>always a bad idea I find naive as well. And MTU discovery = >>will =3D >>> >>NEVER=3D3D >>> >>> >>=3D3D20 >>> >>> >>> >>happen if the receiver has no notion of who the sender is.= >> >>> >>> >>> >> >>> >>> >>> >>--- >>> >>> >>> >> >>> >>> >>> >>> In missive <48768425.4000801 at isi.edu>, Joe Touch typed: >>> >>> >>> >>>=3D3D20 >>> >>> >>> >>> >>This is an OpenPGP/MIME signed message (RFC 2440 and = >>3156)=3D >>> >> >>> >>> >>> >>> >>--------------enig163A833E39F238C5F60A48CF >>> >>> >>> >>> >>Content-Type: text/plain; charset=3D3D3D3DISO-8859-1;= >> format=3D >>> >>=3D3D3D3Dfl=3D3D >>> >>> >>owed >>> >>> >>> >>> >>Content-Transfer-Encoding: quoted-printable >>> >>> >>> >>> >> >>> >>> >>> >>> >> >>> >>> >>> >>> >> >>> >>> >>> >>> >>Jon Crowcroft wrote: >>> >>> >>> >>> >>> speaking of sacred cows, >>> >>> >>> >>> >>> why are their source addresses in IP Packets? >>> >>> >>> >>> >>> http://www.cl.cam.ac.uk/~jac22/out/sna.pdf >>> >>> >>> >>> >> >>> >>> >>> >>> >>The same reason letters have return addresses; for er= >>rors =3D >>> >>(e.g.=3D3D >>> >>> >>, ICM=3D3D3D >>> >>> >>> >>Ps). =3D3D3D3D >>> >>> >>> >>> >> >>> >>> >>> >>> >> Not all errors signal the transport layer; some sig= >>nal t=3D >>> >>he ne=3D3D >>> >>> >>twork=3D3D3D >>> >>> >>> >>=3D3D3D3D20 >>> >>> >>> >>> >>layer (e.g., too-big, redirect, etc.) >>> >>> >>> >>> >> >>> >>> >>> >>> >>PS - burying them in the TCP header eats option space= >> from=3D >>> >> TCP,=3D3D >>> >>> >> whic=3D3D3D >>> >>> >>> >>h=3D3D3D3D20 >>> >>> >>> >>> >>isn't exactly in abundance either ;-) >>> >>> >>> >>> >> >>> >>> >>> >>> >>Joe >>> >>> >>> >>> >> >>> >>> >>> >>> >> >>> >>> >>> >>> >>--------------enig163A833E39F238C5F60A48CF >>> >>> >>> >>> >>Content-Type: application/pgp-signature; name=3D3D3D3= >>D"signa=3D >>> >>ture.as=3D3D >>> >>> >>c" >>> >>> >>> >>> >>Content-Description: OpenPGP digital signature >>> >>> >>> >>> >>Content-Disposition: attachment; filename=3D3D3D3D"si= >>gnature=3D >>> >>=3D2Easc" >>> >>> >>> >>> >> >>> >>> >>> >>> >>-----BEGIN PGP SIGNATURE----- >>> >>> >>> >>> >>Version: GnuPG v1.4.7 (MingW32) >>> >>> >>> >>> >>Comment: Using GnuPG with Mozilla - http://enigmail.m= >>ozdev=3D >>> >>=3D2Eorg >>> >>> >>> >>> >> >>> >>> >>> >>> >>iD8DBQFIdoQmE5f5cImnZrsRAnC9AKDrvpZ2kzV9rzrT8NN1NWkTE= >>sWdYQ=3D >>> >>CdF9O=3D3D >>> >>> >>k >>> >>> >>> >>> >>W8nN+CrIaW3+dENfI/qDyaw=3D3D3D3D >>> >>> >>> >>> >>=3D3D3D3Do5Lq >>> >>> >>> >>> >>-----END PGP SIGNATURE----- >>> >>> >>> >>> >> >>> >>> >>> >>> >>--------------enig163A833E39F238C5F60A48CF-- >>> >>> >>> >>>=3D3D20 >>> >>> >>> >>> cheers >>> >>> >> >>> >>> >> >>> >>> >>--------------enig841B4237908E688C7D411F39 >>> >>> >>Content-Type: application/pgp-signature; name=3D3D"signature.as= >>c" >>> >>> >>Content-Description: OpenPGP digital signature >>> >>> >>Content-Disposition: attachment; filename=3D3D"signature.asc" >>> >>> >> >>> >>> >>-----BEGIN PGP SIGNATURE----- >>> >>> >>Version: GnuPG v1.4.7 (MingW32) >>> >>> >>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org >>> >>> >> >>> >>> >>iD8DBQFId3KxE5f5cImnZrsRAl1GAJ4m5yLUosDO/kb7TwPLTa3Wi8GOWQCfbX8= >>Y >>> >>> >>mhEpJZ+jr+qMgMXMe3xEFtQ=3D3D >>> >>> >>=3D3DxV8K >>> >>> >>-----END PGP SIGNATURE----- >>> >>> >> >>> >>> >>--------------enig841B4237908E688C7D411F39-- >>> >>>=3D20 >>> >>> cheers >>> >>>=3D20 >>> >>> jon >>> >> >>> >> >>> >>--------------enigD0DFC0254F721440EFF890E4 >>> >>Content-Type: application/pgp-signature; name=3D"signature.asc" >>> >>Content-Description: OpenPGP digital signature >>> >>Content-Disposition: attachment; filename=3D"signature.asc" >>> >> >>> >>-----BEGIN PGP SIGNATURE----- >>> >>Version: GnuPG v1.4.7 (MingW32) >>> >>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org >>> >> >>> >>iD8DBQFId3fRE5f5cImnZrsRAqZIAKC5AISvnZl/XvTpQQo8MQmorJbYcACcDnHE >>> >>J6vm6gE7ZeA+AeVBsDHv/t8=3D >>> >>=3DSAYu >>> >>-----END PGP SIGNATURE----- >>> >> >>> >>--------------enigD0DFC0254F721440EFF890E4-- >>>=20 >>> cheers >>>=20 >>> jon >> >> >>--------------enigF1C37DEE2E67C3C7E2C863DF >>Content-Type: application/pgp-signature; name="signature.asc" >>Content-Description: OpenPGP digital signature >>Content-Disposition: attachment; filename="signature.asc" >> >>-----BEGIN PGP SIGNATURE----- >>Version: GnuPG v1.4.7 (MingW32) >>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org >> >>iD8DBQFId4AQE5f5cImnZrsRAiVYAJ9gkJxsv7y+UqJlnkhe2xEQGB06OgCeMWQ0 >>/q2ZOYRu0DHrMLUzzZC1Q9s= >>=YQ+E >>-----END PGP SIGNATURE----- >> >>--------------enigF1C37DEE2E67C3C7E2C863DF-- cheers jon From touch at ISI.EDU Fri Jul 11 09:10:16 2008 From: touch at ISI.EDU (Joe Touch) Date: Fri, 11 Jul 2008 09:10:16 -0700 Subject: [e2e] end2end-interest Digest, s/Vol 53, Issue 10 / sacred cows, sacre bleu/ In-Reply-To: References: <51183BA6-4D6C-4814-BF58-CD1D24A42CB8@uwaterloo.ca> <4876220D.5040302@reed.com> <48768425.4000801@isi.edu> <48776F2A.8030405@isi.edu> <487772B1.8090302@isi.edu> <487777D1.6090001@isi.edu> <48778010.102@isi.edu> Message-ID: <487785E8.3030202@isi.edu> Jon, Jon Crowcroft wrote: ... > I simplify the design of ip to get these properties > properly, at the cost of complex icmp but > icmp is slow path/control plane so that tradeoff is to MY benefit. > > putting information for forwarding (as opposed to for end system) > into the TCP header would require ip forwarding to look there - > on the fast path which is clearly a Bad Idea not just in relegious > sense, but also in an engienering sense. I agree that shifting things around to make forwarding faster would be beneficial. However, I disagree that putting things in the transport header is a reasonable solution - whether ICMP is slow path or not, you're requiring routers to parse transport header, which is also a bad engineering idea. > ICMP communicates largely information for transport > (i.e. its a middle box function) so as i have said several times, it is > completely within scope to consider making this communication more > fit for purpose (indeed, more in keeping with the end to end argument) ICMP is useful for network (e.g., routing) as well as transport. Even when considering just their transport use, however, they are generated as network signals to the source transport. Again, I appreciate the desire for more space for realms, etc., but there is no case here for using space in the transport header for the source ID or any other network layer information. > end of argument I agree; we have each come to our conclusions. Joe > In missive <48778010.102 at isi.edu>, Joe Touch typed: > > >>This is an OpenPGP/MIME signed message (RFC 2440 and 3156) > >>--------------enigF1C37DEE2E67C3C7E2C863DF > >>Content-Type: text/plain; charset=ISO-8859-1; format=flowed > >>Content-Transfer-Encoding: quoted-printable > >> > >> > >> > >>Jon Crowcroft wrote: > >>> you say i should put the realm info as a tcp option and then say there= > >> isnt > >>> much space for tcp options. > >> > >>You do put something as a TCP option - the source ID. I'm saying that it = > >> > >>is just as useful (or problematic) to put the realm there, and that TCP=20 > >>lacks space in general for either. > >> > >>> i say sna does it in a way that is more flexible, doesnt need a lot of = > >>routers to > >>> change just yet,=20 > >> > >>All routers on a path need to change to find the SNA ID to send return=20 > >>ICMP errors. > >> > >> > and provides a lot of what people have done in mobile ipv6 (with > >>> route optimisation) without the pain of turning on full internet wide v= > >>6 routing. > >>> admittedly there's a little tweaking of some icmp code - this is not pe= > >>rformance > >>> critical and one could easily (as per shim6) do the transport/icmp inte= > >>rworking > >>> cleanly across all transports > >> > >>If this is done as a shim on IP, then it's just an IP option=20 > >>(implemented a different way), in which case you haven't removed the=20 > >>source address so much as shifted it. > >> > >>If this is done as a common transport option, you're pinning transport=20 > >>protocols into a structure in order to support a network layer=20 > >>capability, which violates layering. > >> > >>> hosts already peak into ICMP errors to see for what Transport they migh= > >>t be useful;=20 > >> > >>That's not peeking; that's receiving an ICMP message and parsing it as=20 > >>indicated. > >> > >>> i dont see why ICMP looking in transport to figure out=20 > >>> whether its useful to send something at all and to whome is any differe= > >>nt=20 > >>> in terms of religions like "layer violation" and its a whole lot more e= > >>fficient > >> > >>It's not a religious issue; I'm noting that source IDs/addresses aren't > >>only transport-layer info, and that's why ICMP needs access to them. > >> > >>Overall: > >> > >>- your proposal doesn't get rid of the source addr, it just moves it > >> e.g., because packets without source addrs can be silently > >> dropped without signaling the source, as you note, > >> and apps sending packets without sources should expect this > >> > >>- moving the source address doesn't accomplish anything > >> you want extra space for realms; that's fine, but taking > >> that space from IP and putting the info in TCP isn't > >> a win; it complicates ICMP design at routers. it's > >> just as useful to put realms in the TCP header, > >> or to put it in an IP option; there may be utility > >> in that, but this has nothing to do with getting rid > >> of a source address > >> > >>Joe > >> > >> > >>> In missive <487777D1.6090001 at isi.edu>, Joe Touch typed: > >>>=20 > >>> >>This is an OpenPGP/MIME signed message (RFC 2440 and 3156) > >>> >>--------------enigD0DFC0254F721440EFF890E4 > >>> >>Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed > >>> >>Content-Transfer-Encoding: quoted-printable > >>> >> > >>> >>Jon (et al.), > >>> >> > >>> >>Jon Crowcroft wrote: > >>> >>> In missive <487772B1.8090302 at isi.edu>, Joe Touch typed: > >>> >>>=3D20 > >>> >>> >>Consider a packet whose transport lacks a destination address > >>> >>> >>altogether, as you note should be possible. Receivers of those = > >>packe=3D > >>> >>ts > >>> >>> >>have no way to turn them around. > >>> >>> =3D20 > >>> >>> >>> icmp errors can be sent, but icmp in routers would have to pa= > >>rse t=3D > >>> >>he TCP sna option > >>> >>>=3D20 > >>> >>> >>So basically the need for the *network* layer to signal the sou= > >>rce i=3D > >>> >>s > >>> >>> >>accommodated in packets using the TCP sna option by layer viola= > >>tion.=3D > >>> >> > >>> >>>=3D20 > >>> >>> ICMP is layered on top of ip as is tcp - icmp talking to tcp is no= > >>t a l=3D > >>> >>ayer > >>> >>> violation. > >>> >> > >>> >>If you call ICMP a transport layer (fair enough), you haven't explai= > >>ned=3D20 > >>> >>why one transport should peek into the headers of another. ICMP can = > >>talk =3D > >>> >> > >>> >>to TCP, but having ICMP parse TCP headers would be layer violation I= > >>MO. > >>> >> > >>> >>> by the way, i dont put an _address_ in the transport - i put an id= > >>entif=3D > >>> >>ier - this > >>> >>> is then used receivers to lookup an address to the originator. i _= > >>might=3D > >>> >>_ put a > >>> >>> routing hint (e.g. a care of adddress) in the transport too - this= > >> is =3D > >>> >> > >>> >>> not the same as putting in an actual address (which i am getting r= > >>id of=3D > >>> >> as it is > >>> >>> invalid MOST of the time... > >>> >> > >>> >>Understood. That difference isn't key to my responses, so I've just=3D= > >>20 > >>> >>referred to it as an address, but didn't mean to confuse that issue.= > >> > >>> >> > >>> >>> >>Moving the source address in that case didn't make it go away, = > >>so th=3D > >>> >>at's > >>> >>> >>just shuffling the deck chairs. If you wanted more space for IP= > >>, it'=3D > >>> >>s > >>> >>> >>just as logical to leave the current IP header alone and place = > >>the e=3D > >>> >>xtra=3D20 > >>> >>> >>forwarding info in the TCP header - if you're violating layers = > >>for I=3D > >>> >>CMP, =3D3D > >>> >>>=3D20 > >>> >>> this is either a semantic quibble or confusing. > >>> >>>=3D20 > >>> >>> 1. i havnt changed the IP header ast aal - i 've changed the meani= > >>ng of=3D > >>> >> a field - > >>> >>> thishas some very nice legacy interworking properties (as noted in= > >> my n=3D > >>> >>ote) > >>> >> > >>> >>Changing the meaning of a field changes the header. I.e., you can't = > >>pass =3D > >>> >> > >>> >>that packet through a legacy router usefully - it could generate ICM= > >>Ps=3D20 > >>> >>to the wrong place, and won't interpret the source address field as = > >>an=3D20 > >>> >>extension of the destination address. > >>> >> > >>> >>My view is that: > >>> >> change IP src address to mean destination realm > >>> >> add source identifier to TCP header (e.g., as an option) > >>> >>is just as usefully accomplished as: > >>> >> leave IP as-is > >>> >> add destination realm to the TCP header (as an option) > >>> >> > >>> >>(the only remaining difference is that your source identifier isn't = > >>the=3D20 > >>> >>same as IP's source address; I could just as easily put the source I= > >>D in =3D > >>> >> > >>> >>the TCP header too if you prefer). > >>> >> > >>> >>Further, your paper and emails have not addressed the fact that TCP=3D= > >>20 > >>> >>headers don't exactly have lots of space - especially the SYN packet= > >>,=3D20 > >>> >>which is where the source identifier for a connection would need to = > >>be=3D20 > >>> >>established. > >>> >> > >>> >>=3D2E.. > >>> >>> >>why not for forwarding? > >>> >>> >>> since most of these ICMP response are meant as a response to= > >> a tr=3D > >>> >>anspo=3D3D > >>> >>> >>rt entity, > >>> >>> >>> this is semantically reasoanble. > >>> >>> >> > >>> >>> >>Your system posits transports might not ever need source addres= > >>ses. > >>> >>> >>Those transports no longer benefit from ICMP information from t= > >>he ne=3D > >>> >>twork=3D3D > >>> >>> > >>> >>> indeed since there is no information theoretic or control theoerti= > >>c rea=3D > >>> >>son they > >>> >>> should want fedback from the net if thewy didnt want it from the e= > >>nd. -=3D > >>> >> i am just=3D20 > >>> >>> bringing some consistency to a design error of the internet. > >>> >> > >>> >>I agree that unidirectional packets don't necessarily need network=3D= > >>20 > >>> >>feedback. That implies: > >>> >> > >>> >>1. that your entire supposition that the IP packet doesn't need a so= > >>urce =3D > >>> >> > >>> >>address because the transport layer is unacknowledged may be true, b= > >>ut=3D20 > >>> >>actually implies that all transport layers should be bidirectional=3D= > >>20 > >>> >>(rather than implying that you don't need a source address). > >>> >> > >>> >>2. bidirectional packets need network address info in the network=3D= > >>20 > >>> >>header, because the network needs to respond to that information. if= > >> I=3D20 > >>> >>leave this to the transport layer, then every time I deploy a new=3D= > >>20 > >>> >>transport protocol (SCTP, DCCP, etc.), I need to recode all my route= > >>rs=3D20 > >>> >>to know where to peek to get information for ICMP to respond to. > >>> >> > >>> >>Again, as noted, many ICMP messages originate from the network, not = > >>the=3D20 > >>> >>end host. The need for source addresses in the header in the Interne= > >>t is =3D > >>> >> > >>> >>to enable network-based error indicators. It's not clear at all why = > >>that =3D > >>> >> > >>> >>is something we can/should want to get rid of entirely. > >>> >> > >>> >>Joe > >>> >> > >>> >> > >>> >> > >>> >>> >> > >>> >>> >>> In missive <48776F2A.8030405 at isi.edu>, Joe Touch typed: > >>> >>> >>>=3D3D20 > >>> >>> >>> >>This is an OpenPGP/MIME signed message (RFC 2440 and 3156)= > >> > >>> >>> >>> >>--------------enigFDD94A1CA6B765ED0E2F3126 > >>> >>> >>> >>Content-Type: text/plain; charset=3D3D3Dwindows-1252; form= > >>at=3D3D3D=3D > >>> >>flowed > >>> >>> >>> >>Content-Transfer-Encoding: quoted-printable > >>> >>> >>> >> > >>> >>> >>> >>Jon, > >>> >>> >>> >> > >>> >>> >>> >>You asked why the Internet had source addresses. I provide= > >>d an =3D > >>> >>answe=3D3D > >>> >>> >>r,=3D3D20 > >>> >>> >>> >>based on my understanding of the historical context for th= > >>e dec=3D > >>> >>ision=3D3D > >>> >>> >>=3D3D2E I=3D3D20 > >>> >>> >>> >>apologize for being too terse for that to be clear, or for= > >> bein=3D > >>> >>g too=3D3D > >>> >>> >>=3D3D20 > >>> >>> >>> >>glib to belie a thoughful consideration of the contents of= > >> your=3D > >>> >> pape=3D3D > >>> >>> >>r. > >>> >>> >>> >> > >>> >>> >>> >>That, however, does not mean that I did not read your pape= > >>r. > >>> >>> >>> >> > >>> >>> >>> >>My response of your (IMO, historical) question has nothing= > >> to d=3D > >>> >>o wit=3D3D > >>> >>> >>h=3D3D20 > >>> >>> >>> >>your proposal for removing them, as is discussed below. > >>> >>> >>> >> > >>> >>> >>> >>Jon Crowcroft wrote: > >>> >>> >>> >> > a perfect example of people responding to email that th= > >>ey ha=3D > >>> >>ven't=3D3D > >>> >>> >> > >>> >>> >>> >> > actually read properly > >>> >>> >>> >> > >>> >>> >>> >>I urge posters to read the mail they *write* as well as th= > >>ose o=3D > >>> >>thers=3D3D > >>> >>> >>=3D3D20 > >>> >>> >>> >>post. ;-) Please read my more detailed note below before = > >>concl=3D > >>> >>uding=3D3D > >>> >>> >> how=3D3D20 > >>> >>> >>> >>properly I've read your work. > >>> >>> >>> =3D3D20 > >>> >>> >>> >> > >>> >>> >>> >>-- > >>> >>> >>> >> > >>> >>> >>> >>You assert that: > >>> >>> >>> >> > >>> >>> >>> >>> Remember this (RFC 791)? Let=3D3D3D92s think about the l= > >>ine mar=3D > >>> >>ked > >>> >>> >>> >>> by Xs. So why is there a source address there? The naive= > >> answ=3D > >>> >>er > >>> >>> >>> >>> is that some receivers might want to reply. > >>> >>> >>> >> > >>> >>> >>> >>That is a historically consistent answer. > >>> >>> >>> >> > >>> >>> >>> >>> It;s a Datagram, > >>> >>> >>> >>> Stupid. Not all higher layers want to send something bac= > >>k! Th=3D > >>> >>e > >>> >>> >>> >>> end-to-end argument says that we do not put a function i= > >>n a l=3D > >>> >>ower > >>> >>> >>> >>> layer, unless it is required by the majority of upper la= > >>yer u=3D > >>> >>sers > >>> >>> >>> >> > >>> >>> >>> >>E2E argument allows designers to "put things in a layer th= > >>at TH=3D > >>> >>AT la=3D3D > >>> >>> >>yer > >>> >>> >>> >>actually needs". > >>> >>> >>> >> > >>> >>> >>> >>Later, your doc says that: > >>> >>> >>> >> > >>> >>> >>> >>> a better place to send advisory > >>> >>> >>> >>> information in the future Internet is onwards to the rec= > >>eiver=3D > >>> >>, not=3D3D > >>> >>> >> > >>> >>> >>> >>> backwards to the sender. Obviously the unreachable cases= > >> need=3D > >>> >> > >>> >>> >>> >>> to be considered more carefully, although if an end syst= > >>em is=3D > >>> >> not > >>> >>> >>> >>> reachable, a SNA-RK might be still reachable. > >>> >>> >>> >> > >>> >>> >>> >>Host and net unreachables can't be fixed at all, as you no= > >>te la=3D > >>> >>ter. =3D3D > >>> >>> >> > >>> >>> >>> >>Other messages require the receiver know the source, which= > >> - if=3D > >>> >> this=3D3D > >>> >>> >> is=3D3D20 > >>> >>> >>> >>one of those higher layers that doesn't want to send somet= > >>hing =3D > >>> >>back =3D3D > >>> >>> >>-=3D3D20 > >>> >>> >>> >>won't happen either. > >>> >>> >>> >> > >>> >>> >>> >>The fact that further discussion asserts that error notifi= > >>catio=3D > >>> >>ns we=3D3D > >>> >>> >>re=3D3D20 > >>> >>> >>> >>always a bad idea I find naive as well. And MTU discovery = > >>will =3D > >>> >>NEVER=3D3D > >>> >>> >>=3D3D20 > >>> >>> >>> >>happen if the receiver has no notion of who the sender is.= > >> > >>> >>> >>> >> > >>> >>> >>> >>--- > >>> >>> >>> >> > >>> >>> >>> >>> In missive <48768425.4000801 at isi.edu>, Joe Touch typed: > >>> >>> >>> >>>=3D3D20 > >>> >>> >>> >>> >>This is an OpenPGP/MIME signed message (RFC 2440 and = > >>3156)=3D > >>> >> > >>> >>> >>> >>> >>--------------enig163A833E39F238C5F60A48CF > >>> >>> >>> >>> >>Content-Type: text/plain; charset=3D3D3D3DISO-8859-1;= > >> format=3D > >>> >>=3D3D3D3Dfl=3D3D > >>> >>> >>owed > >>> >>> >>> >>> >>Content-Transfer-Encoding: quoted-printable > >>> >>> >>> >>> >> > >>> >>> >>> >>> >> > >>> >>> >>> >>> >> > >>> >>> >>> >>> >>Jon Crowcroft wrote: > >>> >>> >>> >>> >>> speaking of sacred cows, > >>> >>> >>> >>> >>> why are their source addresses in IP Packets? > >>> >>> >>> >>> >>> http://www.cl.cam.ac.uk/~jac22/out/sna.pdf > >>> >>> >>> >>> >> > >>> >>> >>> >>> >>The same reason letters have return addresses; for er= > >>rors =3D > >>> >>(e.g.=3D3D > >>> >>> >>, ICM=3D3D3D > >>> >>> >>> >>Ps). =3D3D3D3D > >>> >>> >>> >>> >> > >>> >>> >>> >>> >> Not all errors signal the transport layer; some sig= > >>nal t=3D > >>> >>he ne=3D3D > >>> >>> >>twork=3D3D3D > >>> >>> >>> >>=3D3D3D3D20 > >>> >>> >>> >>> >>layer (e.g., too-big, redirect, etc.) > >>> >>> >>> >>> >> > >>> >>> >>> >>> >>PS - burying them in the TCP header eats option space= > >> from=3D > >>> >> TCP,=3D3D > >>> >>> >> whic=3D3D3D > >>> >>> >>> >>h=3D3D3D3D20 > >>> >>> >>> >>> >>isn't exactly in abundance either ;-) > >>> >>> >>> >>> >> > >>> >>> >>> >>> >>Joe > >>> >>> >>> >>> >> > >>> >>> >>> >>> >> > >>> >>> >>> >>> >>--------------enig163A833E39F238C5F60A48CF > >>> >>> >>> >>> >>Content-Type: application/pgp-signature; name=3D3D3D3= > >>D"signa=3D > >>> >>ture.as=3D3D > >>> >>> >>c" > >>> >>> >>> >>> >>Content-Description: OpenPGP digital signature > >>> >>> >>> >>> >>Content-Disposition: attachment; filename=3D3D3D3D"si= > >>gnature=3D > >>> >>=3D2Easc" > >>> >>> >>> >>> >> > >>> >>> >>> >>> >>-----BEGIN PGP SIGNATURE----- > >>> >>> >>> >>> >>Version: GnuPG v1.4.7 (MingW32) > >>> >>> >>> >>> >>Comment: Using GnuPG with Mozilla - http://enigmail.m= > >>ozdev=3D > >>> >>=3D2Eorg > >>> >>> >>> >>> >> > >>> >>> >>> >>> >>iD8DBQFIdoQmE5f5cImnZrsRAnC9AKDrvpZ2kzV9rzrT8NN1NWkTE= > >>sWdYQ=3D > >>> >>CdF9O=3D3D > >>> >>> >>k > >>> >>> >>> >>> >>W8nN+CrIaW3+dENfI/qDyaw=3D3D3D3D > >>> >>> >>> >>> >>=3D3D3D3Do5Lq > >>> >>> >>> >>> >>-----END PGP SIGNATURE----- > >>> >>> >>> >>> >> > >>> >>> >>> >>> >>--------------enig163A833E39F238C5F60A48CF-- > >>> >>> >>> >>>=3D3D20 > >>> >>> >>> >>> cheers > >>> >>> >> > >>> >>> >> > >>> >>> >>--------------enig841B4237908E688C7D411F39 > >>> >>> >>Content-Type: application/pgp-signature; name=3D3D"signature.as= > >>c" > >>> >>> >>Content-Description: OpenPGP digital signature > >>> >>> >>Content-Disposition: attachment; filename=3D3D"signature.asc" > >>> >>> >> > >>> >>> >>-----BEGIN PGP SIGNATURE----- > >>> >>> >>Version: GnuPG v1.4.7 (MingW32) > >>> >>> >>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > >>> >>> >> > >>> >>> >>iD8DBQFId3KxE5f5cImnZrsRAl1GAJ4m5yLUosDO/kb7TwPLTa3Wi8GOWQCfbX8= > >>Y > >>> >>> >>mhEpJZ+jr+qMgMXMe3xEFtQ=3D3D > >>> >>> >>=3D3DxV8K > >>> >>> >>-----END PGP SIGNATURE----- > >>> >>> >> > >>> >>> >>--------------enig841B4237908E688C7D411F39-- > >>> >>>=3D20 > >>> >>> cheers > >>> >>>=3D20 > >>> >>> jon > >>> >> > >>> >> > >>> >>--------------enigD0DFC0254F721440EFF890E4 > >>> >>Content-Type: application/pgp-signature; name=3D"signature.asc" > >>> >>Content-Description: OpenPGP digital signature > >>> >>Content-Disposition: attachment; filename=3D"signature.asc" > >>> >> > >>> >>-----BEGIN PGP SIGNATURE----- > >>> >>Version: GnuPG v1.4.7 (MingW32) > >>> >>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > >>> >> > >>> >>iD8DBQFId3fRE5f5cImnZrsRAqZIAKC5AISvnZl/XvTpQQo8MQmorJbYcACcDnHE > >>> >>J6vm6gE7ZeA+AeVBsDHv/t8=3D > >>> >>=3DSAYu > >>> >>-----END PGP SIGNATURE----- > >>> >> > >>> >>--------------enigD0DFC0254F721440EFF890E4-- > >>>=20 > >>> cheers > >>>=20 > >>> jon > >> > >> > >>--------------enigF1C37DEE2E67C3C7E2C863DF > >>Content-Type: application/pgp-signature; name="signature.asc" > >>Content-Description: OpenPGP digital signature > >>Content-Disposition: attachment; filename="signature.asc" > >> > >>-----BEGIN PGP SIGNATURE----- > >>Version: GnuPG v1.4.7 (MingW32) > >>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > >> > >>iD8DBQFId4AQE5f5cImnZrsRAiVYAJ9gkJxsv7y+UqJlnkhe2xEQGB06OgCeMWQ0 > >>/q2ZOYRu0DHrMLUzzZC1Q9s= > >>=YQ+E > >>-----END PGP SIGNATURE----- > >> > >>--------------enigF1C37DEE2E67C3C7E2C863DF-- > > cheers > > jon -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20080711/b5b08a2f/signature.bin From craig at aland.bbn.com Fri Jul 11 10:29:21 2008 From: craig at aland.bbn.com (Craig Partridge) Date: Fri, 11 Jul 2008 13:29:21 -0400 Subject: [e2e] Why do we need TCP flow control (rwnd)? In-Reply-To: Your message of "Thu, 03 Jul 2008 00:38:52 +0200." <486C037C.4060300@web.de> Message-ID: <20080711172921.9996A28E155@aland.bbn.com> You achieve research by looking at the points more carefully. * Analysis is useful when employed correctly. For instance, for all that Poisson is terrible, if you can prove a negative result with Poisson arrivals (e.g. service model Zed is a disaster even if arrivals are Poisson) that's a very strong result (as we know Poisson is nicer than real traffic -- per Christian's note). * Simulators validated by real world experiments are very valuable testing environments (I have access to such a simulator for testing wireless systems -- worth its weight in gold). * Observations are extremely valuable when carefully documented such that the reader can determine if the observations show a general truth or a specific situation. Remember, we learned a lot during the various congestion collapses of the late 1980s [and there was more than one], by observing each one and comparing what we learned. Different collapses had different morphologies -- one I still remember is when the Atlantic satellite link got so overloaded that each connection's fair share of the capacity was less than one TCP segment... Or, to make this short -- we make progress by being (a) careful and (b) smart (in that order). Craig In message <486C037C.4060300 at web.de>, Detlef Bosau writes: >Good rant. > >And I coudln't agree more. > >Only one problem remains.... And that's a very honest question: >If we agree upon some facts: >- Poisson processes and Markov prossesses are of little use in >networking research, >- Analysis is not really helpful (and frankly spoken, I hardly believe >those analytical TCP models, which are around), >- Simulation can prove anything and nothing, >- Observation is not reproducible and not systematic, >so, if we agree upon the fact, that research on networking is basically >impossible, _how_ can we accomplish research on networking then? > >It's of course allowed - and it's always scientifically correct to do so >- to put in question anything we have. >But if we only see blind alleys, how do we find a way out? > > > >-- >Detlef Bosau Mail: detlef.bosau at web.de >Galileistrasse 30 Web: http://www.detlef-bosau.de >70565 Stuttgart Skype: detlef.bosau >Mobile: +49 172 681 9937 From dpreed at reed.com Fri Jul 11 10:41:44 2008 From: dpreed at reed.com (David P. Reed) Date: Fri, 11 Jul 2008 13:41:44 -0400 Subject: [e2e] Why do we need TCP flow control (rwnd)? In-Reply-To: <20080711140515.5BDAD28E155@aland.bbn.com> References: <20080711140515.5BDAD28E155@aland.bbn.com> Message-ID: <48779B58.3010007@reed.com> Ahem: phone networks are NOT demonstrably Poisson. There is no such statement that is true, Craig. At best, one can say that sometimes a Poisson arrival process has some statistics that match actual data. That's called "fitting a curve to data". The evidence that a system *is* Poisson requires understanding of the structure of the system - one cannot prove by simple statistics that a *process* is Poisson, but instead must start by saying that a process is either Poisson or some other process, chosen over the entire space of non-Poisson processes, and do a reproducible scientific hypothesis test to discriminate between them. And the most trivial observations of the humans that place phone calls will disprove that phone calls are generated by a Poisson process. To think otherwise is to wear blinders. All the modelers do is say, what if we *assume* a Poisson process that has been parameterized by statistics gathered from experiments. They *hope* that this will characterize processes that are non-Poisson with similar statistics. So all we know from the telephone network is that it has some statistics that we've measured about probability of a call arriving into the system. Besides the epistemological issue above: We know, in fact, that a call arrival cannot occur for at least a few seconds on the same line after such a call. That makes it non-Poisson at the line level, right there. We also know that when a call is in progress on a line, a new call cannot be originated on that line, so there is inter-line correlation between probabilities of arrival. This suggests that the telephone system is very strongly non-Poisson, even if you assume humans are random actors, and they are not, because they walk to and from phones, they have physical needs, they plan their calls based on assumptions about the callees, etc. So one should be very careful to distinguish an assumption from a fact. Craig Partridge wrote: > In message <4E44F683-8AAB-451F-BC39-0ECA9A6F688F at surrey.ac.uk>, Lloyd Wood writ > es: > > >> On 2 Jul 2008, at 00:56, Fred Baker wrote: >> >>> The thing that I find a little hard to grasp is why folks might have >>> thought the network was Poisson in the first place. >>> >> I doubt they did; it was chosen because it made the arithmetic >> tractable. >> >> "First, assume a spherical cow..." >> > > I think this is unfair to the legions of statisticians that got > us to making Poisson models work in the first place. > > The reason folks thought that data networks would be Poisson was that > > 1. Phone networks were demonstrably Poisson > > 2. They had nothing else in the arsenal (that is, if you were going > to do anything non-trivial, you lacked an analytic alternative) > > I had long discussions with folks who did statistical modeling in the late > 1980s, as it was increasingly clear Poisson was a mistake. Up to that > point, network traffic was in small enough networks that one could, and > many did, imagine that as the Internet matured, it would start to behave > like the existing big network -- the telephone network. But the Internet > growth took off and the disparities between what Poisson predicted and > measurements showed became too large to shrug off. Statistical folks > were deeply puzzled and frustrated. > > Craig > > From craig at aland.bbn.com Fri Jul 11 10:49:39 2008 From: craig at aland.bbn.com (Craig Partridge) Date: Fri, 11 Jul 2008 13:49:39 -0400 Subject: [e2e] Why do we need TCP flow control (rwnd)? In-Reply-To: Your message of "Fri, 11 Jul 2008 13:41:44 EDT." <48779B58.3010007@reed.com> Message-ID: <20080711174939.175E728E155@aland.bbn.com> Hi Dave: My understanding of the literature (and I don't claim to be an expert) is that between the late 1950s and the mid 1970s, the telephony system fit Poisson very well (for arrivals and departures of phone calls and the like) and that this was an essential driver to the introduction of statistical muxing in the telephone system. As modems, faxes, changes in charging models, etc. came along, that changed but that it was true (a sort of golden moment for the statisticians) and drove advances. But I wasn't there.... Craig In message <48779B58.3010007 at reed.com>, "David P. Reed" writes: >Ahem: phone networks are NOT demonstrably Poisson. There is no such >statement that is true, Craig. At best, one can say that sometimes a >Poisson arrival process has some statistics that match actual data. >That's called "fitting a curve to data". > >The evidence that a system *is* Poisson requires understanding of the >structure of the system - one cannot prove by simple statistics that a >*process* is Poisson, but instead must start by saying that a process is >either Poisson or some other process, chosen over the entire space of >non-Poisson processes, and do a reproducible scientific hypothesis test >to discriminate between them. And the most trivial observations of the >humans that place phone calls will disprove that phone calls are >generated by a Poisson process. To think otherwise is to wear blinders. > >All the modelers do is say, what if we *assume* a Poisson process that >has been parameterized by statistics gathered from experiments. They >*hope* that this will characterize processes that are non-Poisson with >similar statistics. > >So all we know from the telephone network is that it has some statistics >that we've measured about probability of a call arriving into the system. > >Besides the epistemological issue above: We know, in fact, that a call >arrival cannot occur for at least a few seconds on the same line after >such a call. That makes it non-Poisson at the line level, right there. >We also know that when a call is in progress on a line, a new call >cannot be originated on that line, so there is inter-line correlation >between probabilities of arrival. > >This suggests that the telephone system is very strongly non-Poisson, >even if you assume humans are random actors, and they are not, because >they walk to and from phones, they have physical needs, they plan their >calls based on assumptions about the callees, etc. > >So one should be very careful to distinguish an assumption from a fact. > >Craig Partridge wrote: >> In message <4E44F683-8AAB-451F-BC39-0ECA9A6F688F at surrey.ac.uk>, Lloyd Wood w >rit >> es: >> >> >>> On 2 Jul 2008, at 00:56, Fred Baker wrote: >>> >>>> The thing that I find a little hard to grasp is why folks might have >>>> thought the network was Poisson in the first place. >>>> >>> I doubt they did; it was chosen because it made the arithmetic >>> tractable. >>> >>> "First, assume a spherical cow..." >>> >> >> I think this is unfair to the legions of statisticians that got >> us to making Poisson models work in the first place. >> >> The reason folks thought that data networks would be Poisson was that >> >> 1. Phone networks were demonstrably Poisson >> >> 2. They had nothing else in the arsenal (that is, if you were going >> to do anything non-trivial, you lacked an analytic alternative) >> >> I had long discussions with folks who did statistical modeling in the late >> 1980s, as it was increasingly clear Poisson was a mistake. Up to that >> point, network traffic was in small enough networks that one could, and >> many did, imagine that as the Internet matured, it would start to behave >> like the existing big network -- the telephone network. But the Internet >> growth took off and the disparities between what Poisson predicted and >> measurements showed became too large to shrug off. Statistical folks >> were deeply puzzled and frustrated. >> >> Craig >> >> From day at std.com Fri Jul 11 10:49:48 2008 From: day at std.com (John Day) Date: Fri, 11 Jul 2008 13:49:48 -0400 Subject: [e2e] Why do we need TCP flow control (rwnd)? In-Reply-To: <8EFB68EAE061884A8517F2A755E8B60A0AA17C580A@NA-EXMSG-W601.wingroup.windepl oy.ntdev.microsoft.com> References: Your message of "Wed, 02 Jul 2008 19:16:41 BST." <4E44F683-8AAB-451F-BC39-0ECA9A6F688F@surrey.ac.uk> <20080711140515.5BDAD28E155@aland.bbn.com> <8EFB68EAE061884A8517F2A755E8B60A0AA17C580A@NA-EXMSG-W601.wingroup.windepl oy.ntdev.microsoft.com> Message-ID: I agree with Christian that your second point has more validity. While there may have been members of the old guard who believed that eventually data networks would look like phone networks, it was far from a common idea among those thinking about the problem. A primary difference in the argument for data networks at the time was that they were phone networks weren't. As I said some weeks ago, I remember being aware that Poisson wasn't a good approximation in the mid-70s and initiating a literature search to find alternatives approaches. I remember turning up things like diffusion approximation method, but never had a chance to pursue it. I am afraid that this one more thing we have to chalk up to "grade inflation" as the field expanded. It is just too bad that it spills over into textbooks. At 8:54 -0700 2008/07/11, Christian Huitema wrote: > > The reason folks thought that data networks would be Poisson was that >> >> 1. Phone networks were demonstrably Poisson >> >> 2. They had nothing else in the arsenal (that is, if you were going >> to do anything non-trivial, you lacked an analytic alternative) > >Craig, > >The point about nothing else is certainly valid. If you have to >perform your computation using log tables and an actual spreadsheet, >then tackling anything besides Poisson will be very challenging. >However, it has been known for some time that Poisson was at best a >first degree approximation, even for phone traffic. > >Consider two widely documented cases, time variations in traffic and >flash crowd, both of which have been part of traffic engineering for >a long time. The average traffic load is known to vary as a function >of the time of day, day of the week, month of the year, not to >mention Mother's day. There is no way you can model that as a single >"independent arrival" process. Flash crowds happen when many people >decide to pick up their phone at the same time, e.g. to call in a TV >show, or to report about a particular incident. Again, there is no >way to model flash crowds as independent arrivals. Even the duration >of phone calls was probably not well modeled by time independent >departure processes, e.g. if you take into account the behavior of >teenagers in the 70's. > >I suspect that any process that results from human behavior is very >likely to exhibit much more variability than predicted by a Poisson >model. That's certainly true for phone traffic as well. > >-- Christian Huitema From v13 at v13.gr Fri Jul 11 11:03:56 2008 From: v13 at v13.gr (Stefanos Harhalakis) Date: Fri, 11 Jul 2008 21:03:56 +0300 Subject: [e2e] Why do we need TCP flow control (rwnd)? In-Reply-To: <8EFB68EAE061884A8517F2A755E8B60A0AA17C580A@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> References: <4E44F683-8AAB-451F-BC39-0ECA9A6F688F@surrey.ac.uk> <20080711140515.5BDAD28E155@aland.bbn.com> <8EFB68EAE061884A8517F2A755E8B60A0AA17C580A@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> Message-ID: <200807112103.57460.v13@v13.gr> On Friday 11 July 2008, Christian Huitema wrote: > I suspect that any process that results from human behavior is very likely > to exhibit much more variability than predicted by a Poisson model. That's > certainly true for phone traffic as well. While I'm not related to statistics I believe that it is almost impossible to (statistically) model a group A that is affected by groups B and C without first modeling B and C. As you said, Internet traffic is affected by many external sources like human behaviour, random facts etc, which are by themselves extremely complex. Since we've not modeled (yet?) those external sources (regarding their Internet behaviour influence) we most probably won't be able to accurately model Internet traffic. The only exception that I can think of is that we could be extremely lucky and the whole thing would just follow a common model. From dpreed at reed.com Fri Jul 11 11:27:39 2008 From: dpreed at reed.com (David P. Reed) Date: Fri, 11 Jul 2008 14:27:39 -0400 Subject: [e2e] Why do we need TCP flow control (rwnd)? In-Reply-To: <20080711174939.175E728E155@aland.bbn.com> References: <20080711174939.175E728E155@aland.bbn.com> Message-ID: <4877A61B.7070609@reed.com> My guess is that Poisson models based on measured statistics were used in queuing models, and the statistics of the simulation outputs reasonably matched the statistics of measured dependent variables. That's far from confirmation of Poisson-ness. That merely said that the simple model predicted the observed statistics. I wouldn't get so concerned, but I live every day with the presumption that radio noise is Gaussian and White because of some Law of Physics. It's bullshit, but it's taught to undergrad EEs as if it was "discovered" by Shannon, by Ph.D. holding professors. Shannon would turn in his grave if accused of discovering a law of physics. Craig Partridge wrote: > Hi Dave: > > My understanding of the literature (and I don't claim to be an expert) > is that between the late 1950s and the mid 1970s, the telephony system > fit Poisson very well (for arrivals and departures of phone calls and > the like) and that this was an essential driver to the introduction > of statistical muxing in the telephone system. As modems, faxes, changes in > charging models, etc. came along, that changed but that it was true > (a sort of golden moment for the statisticians) and drove advances. > > But I wasn't there.... > > Craig > > In message <48779B58.3010007 at reed.com>, "David P. Reed" writes: > > >> Ahem: phone networks are NOT demonstrably Poisson. There is no such >> statement that is true, Craig. At best, one can say that sometimes a >> Poisson arrival process has some statistics that match actual data. >> That's called "fitting a curve to data". >> >> The evidence that a system *is* Poisson requires understanding of the >> structure of the system - one cannot prove by simple statistics that a >> *process* is Poisson, but instead must start by saying that a process is >> either Poisson or some other process, chosen over the entire space of >> non-Poisson processes, and do a reproducible scientific hypothesis test >> to discriminate between them. And the most trivial observations of the >> humans that place phone calls will disprove that phone calls are >> generated by a Poisson process. To think otherwise is to wear blinders. >> >> All the modelers do is say, what if we *assume* a Poisson process that >> has been parameterized by statistics gathered from experiments. They >> *hope* that this will characterize processes that are non-Poisson with >> similar statistics. >> >> So all we know from the telephone network is that it has some statistics >> that we've measured about probability of a call arriving into the system. >> >> Besides the epistemological issue above: We know, in fact, that a call >> arrival cannot occur for at least a few seconds on the same line after >> such a call. That makes it non-Poisson at the line level, right there. >> We also know that when a call is in progress on a line, a new call >> cannot be originated on that line, so there is inter-line correlation >> between probabilities of arrival. >> >> This suggests that the telephone system is very strongly non-Poisson, >> even if you assume humans are random actors, and they are not, because >> they walk to and from phones, they have physical needs, they plan their >> calls based on assumptions about the callees, etc. >> >> So one should be very careful to distinguish an assumption from a fact. >> >> Craig Partridge wrote: >> >>> In message <4E44F683-8AAB-451F-BC39-0ECA9A6F688F at surrey.ac.uk>, Lloyd Wood w >>> > >rit > >>> es: >>> >>> >>> >>>> On 2 Jul 2008, at 00:56, Fred Baker wrote: >>>> >>>> >>>>> The thing that I find a little hard to grasp is why folks might have >>>>> thought the network was Poisson in the first place. >>>>> >>>>> >>>> I doubt they did; it was chosen because it made the arithmetic >>>> tractable. >>>> >>>> "First, assume a spherical cow..." >>>> >>>> >>> I think this is unfair to the legions of statisticians that got >>> us to making Poisson models work in the first place. >>> >>> The reason folks thought that data networks would be Poisson was that >>> >>> 1. Phone networks were demonstrably Poisson >>> >>> 2. They had nothing else in the arsenal (that is, if you were going >>> to do anything non-trivial, you lacked an analytic alternative) >>> >>> I had long discussions with folks who did statistical modeling in the late >>> 1980s, as it was increasingly clear Poisson was a mistake. Up to that >>> point, network traffic was in small enough networks that one could, and >>> many did, imagine that as the Internet matured, it would start to behave >>> like the existing big network -- the telephone network. But the Internet >>> growth took off and the disparities between what Poisson predicted and >>> measurements showed became too large to shrug off. Statistical folks >>> were deeply puzzled and frustrated. >>> >>> Craig >>> >>> >>> > > From swb at employees.org Fri Jul 11 11:55:03 2008 From: swb at employees.org (Scott Brim) Date: Fri, 11 Jul 2008 14:55:03 -0400 Subject: [e2e] end2end-interest Digest, s/Vol 53, Issue 10 / sacred cows, sacre bleu/ In-Reply-To: References: <51183BA6-4D6C-4814-BF58-CD1D24A42CB8@uwaterloo.ca> <4876220D.5040302@reed.com> <48768425.4000801@isi.edu> <48776F2A.8030405@isi.edu> <487772B1.8090302@isi.edu> Message-ID: <4877AC87.5060104@employees.org> On 7/11/08 10:55 AM, Jon Crowcroft allegedly wrote: > by the way, i dont put an _address_ in the transport - i put an identifier - this > is then used receivers to lookup an address to the originator. i _might_ put a > routing hint (e.g. a care of adddress) in the transport too - this is > not the same as putting in an actual address (which i am getting rid of as it is > invalid MOST of the time... That's what I thought and what I've been wondering about. The recipient of the identifier needs to look it up somewhere. 99% of the endpoints out there today don't have global names. Where will the identifiers be looked up? Either every endpoint gets registered in something like DNS (and it's updated dynamically) or you depend on application-level intermediaries. Either way you're depending on intermediaries and you've lost e2e transparency? Scott From faber at ISI.EDU Fri Jul 11 13:33:46 2008 From: faber at ISI.EDU (Ted Faber) Date: Fri, 11 Jul 2008 13:33:46 -0700 Subject: [e2e] Why do we need TCP flow control (rwnd)? In-Reply-To: <20080711174939.175E728E155@aland.bbn.com> References: <48779B58.3010007@reed.com> <20080711174939.175E728E155@aland.bbn.com> Message-ID: <20080711203346.GE57069@zod.isi.edu> On Fri, Jul 11, 2008 at 01:49:39PM -0400, Craig Partridge wrote: > > Hi Dave: > > My understanding of the literature (and I don't claim to be an expert) > is that between the late 1950s and the mid 1970s, the telephony system > fit Poisson very well (for arrivals and departures of phone calls and > the like) and that this was an essential driver to the introduction > of statistical muxing in the telephone system. As modems, faxes, changes in > charging models, etc. came along, that changed but that it was true > (a sort of golden moment for the statisticians) and drove advances. > > But I wasn't there.... I think David is drawing the distinction between a Poisson process, which is defined pretty precisely and something that produces events with a Poisson distribution. True Poisson processes are rare; the only one I can think of off the top of my head is radioactive decay. Series of events that are Poisson distributed are markedly easier to find. The pseudorandom number generator on my machine (which is certainly not a Poisson process) can be massaged to create a sequence of events that are Poisson distributed. I believe that the statements that the telephone interrarrivals were Poisson distributed and that they were not generated by a Poisson process are both true. This is like the fact that my students aren't Normal, but I still grade on a bell curve. :-) (Yes, yes, I know, I don't need to hear about the various laws of large numbers; that sentence was a joke...) -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20080711/bafb64b0/attachment.bin From faber at ISI.EDU Fri Jul 11 15:20:30 2008 From: faber at ISI.EDU (Ted Faber) Date: Fri, 11 Jul 2008 15:20:30 -0700 Subject: [e2e] Why do we need TCP flow control (rwnd)? In-Reply-To: References: <48779B58.3010007@reed.com> <20080711174939.175E728E155@aland.bbn.com> <20080711203346.GE57069@zod.isi.edu> Message-ID: <20080711222029.GC97842@zod.isi.edu> On Fri, Jul 11, 2008 at 02:59:13PM -0700, Lachlan Andrew wrote: > Greetings Ted, > > 2008/7/11 Ted Faber : > > > > True Poisson processes are rare; the only one I can think of off the top > > of my head is radioactive decay. > > Just to be picky, that isn't Poisson either, although it is well > approximated as Poisson on "short" time-scales (relative to the > half-life). No observations on my students' Normality? :-) You're correct, of course. I do believe that the radioactive decay of a pound of U-238 over a month is a Poisson process, but on timescales close to the half-life it is not. Smaller samples or isotopes with shorter half-lives would not be. That's what I get for underspecification. :-) -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20080711/c159f4ad/attachment.bin From jnc at mercury.lcs.mit.edu Fri Jul 11 15:54:19 2008 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Fri, 11 Jul 2008 18:54:19 -0400 (EDT) Subject: [e2e] end2end-interest Digest, s/Vol 53, Issue 10 / sacred cows, sacre bleu/ Message-ID: <20080711225419.D0DCD6BE5AE@mercury.lcs.mit.edu> > From: Joe Touch >> ICMP is layered on top of ip as is tcp - icmp talking to tcp is not a >> layer violation. > If you call ICMP a transport layer (fair enough) This is a bit of a side point, but... I would not call ICMP a transport layer. It's part of the internetwork layer. Where I think the confusion comes from is that the ICMP _protocol_ is carried on top of the IP _protocol_. But protocol != layer. (Standard rant about how any layer model is a poor match to reality in the network, because the sub-system dependency graph is actually a tree, not anything linear, elided...) Noel From dpreed at reed.com Fri Jul 11 23:42:18 2008 From: dpreed at reed.com (David P. Reed) Date: Sat, 12 Jul 2008 02:42:18 -0400 Subject: [e2e] Why do we need TCP flow control (rwnd)? In-Reply-To: <20080711203346.GE57069@zod.isi.edu> References: <48779B58.3010007@reed.com> <20080711174939.175E728E155@aland.bbn.com> <20080711203346.GE57069@zod.isi.edu> Message-ID: <4878524A.9040202@reed.com> Actually, Ted, constructing a sequence of events that are Poisson distributed in time *requires* a Poisson process. Unless you mean the trivial statement that any sequence of events in time is Poisson, because a Poisson process can produce any sequence of events whatsoever. The reason is that a sequence has NO PROBABILITY DISTRIBUTION WHATSOEVER. It has a conditional probability of 1, given that it is the sequence under consideration. If you have a set of 5 such chosen sequences, they still have a conditional probability of one in your sample set. If you observe 5 such sequences in the world, you still cannot tell if they are Poisson distributed without a *prior* that says they are (say) either Poisson or Bernoulli distributed. Then you can evaluate the conditional probability of them being generated, and this gives you some evidence. But absent the prior that limits you to Poisson or Bernoulli, you are unable to say anything of the sort. And as I said, we have a prior. We know that telephone calls are generated by people, who have constraints that *cannot* match the Poisson process. So it would be arrogant and blind at the same time to claim that "telephone calls are Poisson". All one can say is that if we make the false assumption that telephone calls are Poisson, then our simplified simulations and narrow modeling fit the observed behavior of the system reasonably well, This is a useful result. But it goes nowhere toward either - proving that the process is Poisson, - proving the distributions are Poisson, or -proving that the assumption of Poisson behavior will always work in new models that may amplify aspects of human behavior that are definitely not Poisson. This is not subtle. Teaching EE kids that behavior *is* Poisson distributed is teaching them how NOT to think. Professors should be ashamed. Ted Faber wrote: > On Fri, Jul 11, 2008 at 01:49:39PM -0400, Craig Partridge wrote: > >> Hi Dave: >> >> My understanding of the literature (and I don't claim to be an expert) >> is that between the late 1950s and the mid 1970s, the telephony system >> fit Poisson very well (for arrivals and departures of phone calls and >> the like) and that this was an essential driver to the introduction >> of statistical muxing in the telephone system. As modems, faxes, changes in >> charging models, etc. came along, that changed but that it was true >> (a sort of golden moment for the statisticians) and drove advances. >> >> But I wasn't there.... >> > > I think David is drawing the distinction between a Poisson process, > which is defined pretty precisely and something that produces events > with a Poisson distribution. > > True Poisson processes are rare; the only one I can think of off the top > of my head is radioactive decay. Series of events that are Poisson > distributed are markedly easier to find. The pseudorandom number > generator on my machine (which is certainly not a Poisson process) can > be massaged to create a sequence of events that are Poisson distributed. > > I believe that the statements that the telephone interrarrivals were > Poisson distributed and that they were not generated by a Poisson > process are both true. > > This is like the fact that my students aren't Normal, but I still grade > on a bell curve. :-) (Yes, yes, I know, I don't need to hear about the > various laws of large numbers; that sentence was a joke...) > > From dpreed at reed.com Fri Jul 11 23:59:58 2008 From: dpreed at reed.com (David P. Reed) Date: Sat, 12 Jul 2008 02:59:58 -0400 Subject: [e2e] Why do we need TCP flow control (rwnd)? In-Reply-To: <20080711222029.GC97842@zod.isi.edu> References: <48779B58.3010007@reed.com> <20080711174939.175E728E155@aland.bbn.com> <20080711203346.GE57069@zod.isi.edu> <20080711222029.GC97842@zod.isi.edu> Message-ID: <4878566E.5040806@reed.com> Not to be picky, but a pound lump of U-238 by itself is probably not a Poisson emitter, either. Neutrons, etc. do interact with the other elements of the generating process, perhaps triggering additional events. And an atom of U-238 generates a single event. Probably also not a Poisson process. Perhaps U-238 in a very, very low-density empty region of space? I prefer to think of Poisson processes as entirely in the domain of mathematics - a calculation tool - given the difficulty of proving anything is a Poisson process. How do we know that the apparent indeterminacy (randomness) of physics is essential in reality or merely a determinacy inaccessible to us, below the planck limit? My philosophy of science suggests that it does not matter, but yours may differ. Ted Faber wrote: > On Fri, Jul 11, 2008 at 02:59:13PM -0700, Lachlan Andrew wrote: > >> Greetings Ted, >> >> 2008/7/11 Ted Faber : >> >>> True Poisson processes are rare; the only one I can think of off the top >>> of my head is radioactive decay. >>> >> Just to be picky, that isn't Poisson either, although it is well >> approximated as Poisson on "short" time-scales (relative to the >> half-life). >> > > No observations on my students' Normality? :-) > > You're correct, of course. I do believe that the radioactive decay of a > pound of U-238 over a month is a Poisson process, but on timescales > close to the half-life it is not. Smaller samples or isotopes with > shorter half-lives would not be. That's what I get for > underspecification. :-) > > From Jon.Crowcroft at cl.cam.ac.uk Sat Jul 12 01:03:09 2008 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Sat, 12 Jul 2008 09:03:09 +0100 Subject: [e2e] end2end-interest Digest, s/Vol 53, Issue 10 / sacred cows, sacre bleu/ In-Reply-To: <4877AC87.5060104@employees.org> References: <51183BA6-4D6C-4814-BF58-CD1D24A42CB8@uwaterloo.ca> <4876220D.5040302@reed.com> <48768425.4000801@isi.edu> <48776F2A.8030405@isi.edu> <487772B1.8090302@isi.edu> <4877AC87.5060104@employees.org> Message-ID: yes, sometimes you need some mapping and indirection - that isn't terribly surprising since the purpose of this proposal is to do parsimonious ipv4 support for mobility, multihoming and multipath - these typically all need some extra information somewhere (even when you add route optimisation in mobile ipv6) - the cellular guys have this all sorted but ip folks dont seem to be willing to bite the bullet on the necessary actually it turns out in some cases (actually quite a lot) we dont need an explicit indirection service - it can be implicit in how packets are routed (ie. the snark has a nat like function in some cases) thanks to everyone for all the input = i will now try and clarify al the points made in an update to the paper in the same place In missive <4877AC87.5060104 at employees.org>, Scott Brim typed: >>On 7/11/08 10:55 AM, Jon Crowcroft allegedly wrote: >>> by the way, i dont put an _address_ in the transport - i put an identifier - this >>> is then used receivers to lookup an address to the originator. i _might_ put a >>> routing hint (e.g. a care of adddress) in the transport too - this is >>> not the same as putting in an actual address (which i am getting rid of as it is >>> invalid MOST of the time... >> >>That's what I thought and what I've been wondering about. The recipient >>of the identifier needs to look it up somewhere. 99% of the endpoints >>out there today don't have global names. Where will the identifiers be >>looked up? Either every endpoint gets registered in something like DNS >>(and it's updated dynamically) or you depend on application-level >>intermediaries. Either way you're depending on intermediaries and >>you've lost e2e transparency? >> >>Scott >> cheers jon From L.Wood at surrey.ac.uk Sat Jul 12 07:51:02 2008 From: L.Wood at surrey.ac.uk (L.Wood@surrey.ac.uk) Date: Sat, 12 Jul 2008 15:51:02 +0100 Subject: [e2e] end2end-interest Digest, s/Vol 53, Issue 10 / sacred cows, sacre bleu/ References: <51183BA6-4D6C-4814-BF58-CD1D24A42CB8@uwaterloo.ca> <4876220D.5040302@reed.com> <48768425.4000801@isi.edu> <48776F2A.8030405@isi.edu> <487772B1.8090302@isi.edu><4877AC87.5060104@employees.org> Message-ID: <4835AFD53A246A40A3B8DA85D658C4BE4473D9@EVS-EC1-NODE4.surrey.ac.uk> > thanks to everyone for all the input = i will now try and clarify al the points > made in an update to the paper in the same place Can't you just submit to peer review in a conference or something? Anonymous reviews come with no source address and can't be responded to directly, which seems ENTIRELY appropriate given the topic of your paper. L. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20080712/d3124383/attachment.html From lachlan.andrew at gmail.com Fri Jul 11 10:08:14 2008 From: lachlan.andrew at gmail.com (Lachlan Andrew) Date: Fri, 11 Jul 2008 10:08:14 -0700 Subject: [e2e] Why do we need TCP flow control (rwnd)? In-Reply-To: <8EFB68EAE061884A8517F2A755E8B60A0AA17C580A@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> References: <4E44F683-8AAB-451F-BC39-0ECA9A6F688F@surrey.ac.uk> <20080711140515.5BDAD28E155@aland.bbn.com> <8EFB68EAE061884A8517F2A755E8B60A0AA17C580A@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> Message-ID: 2008/7/11 Christian Huitema : > > The point about nothing else is certainly valid. If you have to perform your computation using log tables and an actual spreadsheet, then tackling anything besides Poisson will be very challenging. However, it has been known for some time that Poisson was at best a first degree approximation, even for phone traffic. I disagree. A time-invariant Poisson model (a la M/G/1) may be very inaccurate, but useful statistical analysis can be done with time varying Poisson models, which capture diurnal variation and flash crowds. (No, that is not the same as saying "any two points can be fitted by an exponential", as was previously said.) As Mark Crovella correctly pointed out, *session* arrivals (analogous to phone calls) seem to be well modelled by a Poisson process, even though individual connections are not, and packets certainly aren't. We shouldn't throw out all models which use the word "Poisson", because *some* Poisson models are inaccurate. Isn't that like throwing out all measurement studies on the grounds of being "anecdotal evidence"? > Even the duration of phone calls was probably not well modeled by time independent departure processes Of course. It has long been known that call holding times are far from exponential. However, for an M/G/K/K queue (the one used for telephony) behaves exactly the same as M/M/K/K by several important measures such as blocking probability, and so there was little to be gained by studying the more complicated model. Cheers, Lachlan -- Lachlan Andrew Dept of Computer Science, Caltech 1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125, USA Ph: +1 (626) 395-8820 Fax: +1 (626) 568-3603 http://netlab.caltech.edu/lachlan From lachlan.andrew at gmail.com Fri Jul 11 12:36:05 2008 From: lachlan.andrew at gmail.com (Lachlan Andrew) Date: Fri, 11 Jul 2008 12:36:05 -0700 Subject: [e2e] Why do we need TCP flow control (rwnd)? In-Reply-To: <20080711172921.9996A28E155@aland.bbn.com> References: <486C037C.4060300@web.de> <20080711172921.9996A28E155@aland.bbn.com> Message-ID: 2008/7/11 Craig Partridge : > > You achieve research by looking at the points more carefully. > > * Analysis is useful when employed correctly. Exactly. > For instance, for all > that Poisson is terrible, if you can prove a negative result with > Poisson arrivals (e.g. service model Zed is a disaster even if > arrivals are Poisson) that's a very strong result (as we know > Poisson is nicer than real traffic -- per Christian's note). Rules of thumb like "Poisson is nicer" also have to be treated with caution. As David Reed pointed out, simple Poisson models don't model the fact that users back off during congestion. In that sense, Poisson is less nice than real traffic. There's no substitute for checking how the specific approximations of a model affect the specific conclusions you are drawing. > Or, to make this short -- we make progress by being (a) careful and (b) > smart (in that order). As long as "careful" comes before "publish, standardise or deploy", I don't think it always needs to come before "smart". It is good not to be too constrained when trying to make progress. The inventors of turbo codes admit they wouldn't have thought of their ideas if they had been careful about the information theory behind them. Cheers, Lachlan -- Lachlan Andrew Dept of Computer Science, Caltech 1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125, USA Ph: +1 (626) 395-8820 Fax: +1 (626) 568-3603 http://netlab.caltech.edu/lachlan From lachlan.andrew at gmail.com Fri Jul 11 14:59:13 2008 From: lachlan.andrew at gmail.com (Lachlan Andrew) Date: Fri, 11 Jul 2008 14:59:13 -0700 Subject: [e2e] Why do we need TCP flow control (rwnd)? In-Reply-To: <20080711203346.GE57069@zod.isi.edu> References: <48779B58.3010007@reed.com> <20080711174939.175E728E155@aland.bbn.com> <20080711203346.GE57069@zod.isi.edu> Message-ID: Greetings Ted, 2008/7/11 Ted Faber : > > True Poisson processes are rare; the only one I can think of off the top > of my head is radioactive decay. Just to be picky, that isn't Poisson either, although it is well approximated as Poisson on "short" time-scales (relative to the half-life). In a Poisson process, events on disjoint intervals are independent. In radioactive decay, if there are a lot of decays in an early interval, there are fewer particles left to decay on later intervals, causing negative correlation. (Note that, unlike diurnal variations of traffic, that effect can't be described as being a time-varying Poisson process, because time-varying Poisson processes still have to have that independence.) Cheers, Lachlan -- Lachlan Andrew Dept of Computer Science, Caltech 1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125, USA Ph: +1 (626) 395-8820 Fax: +1 (626) 568-3603 http://netlab.caltech.edu/lachlan From day at std.com Sun Jul 13 19:32:01 2008 From: day at std.com (John Day) Date: Sun, 13 Jul 2008 22:32:01 -0400 Subject: [e2e] end2end-interest Digest, s/Vol 53, Issue 10 / sacred cows, sacre bleu/ In-Reply-To: <487785E8.3030202@isi.edu> References: <51183BA6-4D6C-4814-BF58-CD1D24A42CB8@uwaterloo.ca> <4876220D.5040302@reed.com> <48768425.4000801@isi.edu> <48776F2A.8030405@isi.edu> <487772B1.8090302@isi.edu> <487777D1.6090001@isi.edu> <48778010.102@isi.edu> <487785E8.3030202@isi.edu> Message-ID: Remember ICMP is a kludge. Work through how it should be done and you will have a cleaner solution. I am being dense. How do you find TCBs with no source address? The TCP connection-identifier is only unique within the scope of the (source-address, destination-address) pair. Once you do something dumb like overload the connection-id to identify applications, i.e. well-known ports, so that half the connection-id is the same for a large number of connections and take away the source address, you are left with (source-port-id, destination-address) needing to be unique, which is pretty unlikely. What did I miss? Take care, John At 9:10 -0700 2008/07/11, Joe Touch wrote: >Jon, > >Jon Crowcroft wrote: >... >>I simplify the design of ip to get these properties >>properly, at the cost of complex icmp but icmp is slow path/control >>plane so that tradeoff is to MY benefit. >> >>putting information for forwarding (as opposed to for end system) >>into the TCP header would require ip forwarding to look there - on >>the fast path which is clearly a Bad Idea not just in relegious >>sense, but also in an engienering sense. > >I agree that shifting things around to make forwarding faster would >be beneficial. However, I disagree that putting things in the >transport header is a reasonable solution - whether ICMP is slow >path or not, you're requiring routers to parse transport header, >which is also a bad engineering idea. > >>ICMP communicates largely information for transport >>(i.e. its a middle box function) so as i have said several times, it is >>completely within scope to consider making this communication more >>fit for purpose (indeed, more in keeping with the end to end >>argument) > >ICMP is useful for network (e.g., routing) as well as transport. >Even when considering just their transport use, however, they are >generated as network signals to the source transport. > >Again, I appreciate the desire for more space for realms, etc., but >there is no case here for using space in the transport header for >the source ID or any other network layer information. > >>end of argument > >I agree; we have each come to our conclusions. > >Joe > >>In missive <48778010.102 at isi.edu>, Joe Touch typed: >> >> >>This is an OpenPGP/MIME signed message (RFC 2440 and 3156) >> >>--------------enigF1C37DEE2E67C3C7E2C863DF >> >>Content-Type: text/plain; charset=ISO-8859-1; format=flowed >> >>Content-Transfer-Encoding: quoted-printable >> >> >> >> >> >> >> >>Jon Crowcroft wrote: >> >>> you say i should put the realm info as a tcp option and then say there= >> >> isnt >> >>> much space for tcp options. >> >> >> >>You do put something as a TCP option - the source ID. I'm saying that it = >> >> >> >>is just as useful (or problematic) to put the realm there, and that TCP=20 >> >>lacks space in general for either. >> >> >> >>> i say sna does it in a way that is more flexible, doesnt need a lot of = >> >>routers to >> >>> change just yet,=20 >> >> >> >>All routers on a path need to change to find the SNA ID to send return=20 >> >>ICMP errors. >> >> >> >> > and provides a lot of what people have done in mobile ipv6 (with >> >>> route optimisation) without the pain of turning on full internet wide v= >> >>6 routing. >> >>> admittedly there's a little tweaking of some icmp code - this is not pe= >> >>rformance >> >>> critical and one could easily (as per shim6) do the transport/icmp inte= >> >>rworking >> >>> cleanly across all transports >> >> >> >>If this is done as a shim on IP, then it's just an IP option=20 >> >>(implemented a different way), in which case you haven't removed the=20 >> >>source address so much as shifted it. >> >> >> >>If this is done as a common transport option, you're pinning transport=20 >> >>protocols into a structure in order to support a network layer=20 >> >>capability, which violates layering. >> >> >> >>> hosts already peak into ICMP errors to see for what Transport they migh= >> >>t be useful;=20 >> >> >> >>That's not peeking; that's receiving an ICMP message and parsing it as=20 >> >>indicated. >> >> >> >>> i dont see why ICMP looking in transport to figure out=20 >> >>> whether its useful to send something at all and to whome is any differe= >> >>nt=20 >> >>> in terms of religions like "layer violation" and its a whole lot more e= >> >>fficient >> >> >> >>It's not a religious issue; I'm noting that source IDs/addresses aren't >> >>only transport-layer info, and that's why ICMP needs access to them. >> >> >> >>Overall: >> >> >> >>- your proposal doesn't get rid of the source addr, it just moves it >> >> e.g., because packets without source addrs can be silently >> >> dropped without signaling the source, as you note, >> >> and apps sending packets without sources should expect this >> >> >> >>- moving the source address doesn't accomplish anything >> >> you want extra space for realms; that's fine, but taking >> >> that space from IP and putting the info in TCP isn't >> >> a win; it complicates ICMP design at routers. it's >> >> just as useful to put realms in the TCP header, >> >> or to put it in an IP option; there may be utility >> >> in that, but this has nothing to do with getting rid >> >> of a source address >> >> >> >>Joe >> >> >> >> >> >>> In missive <487777D1.6090001 at isi.edu>, Joe Touch typed: >> >>>=20 >> >>> >>This is an OpenPGP/MIME signed message (RFC 2440 and 3156) >> >>> >>--------------enigD0DFC0254F721440EFF890E4 >> >>> >>Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed >> >>> >>Content-Transfer-Encoding: quoted-printable >> >>> >> >> >>> >>Jon (et al.), >> >>> >> >> >>> >>Jon Crowcroft wrote: >> >>> >>> In missive <487772B1.8090302 at isi.edu>, Joe Touch typed: >> >>> >>>=3D20 >> >>> >>> >>Consider a packet whose transport lacks a destination address >> >>> >>> >>altogether, as you note should be possible. Receivers of those = >> >>packe=3D >> >>> >>ts >> >>> >>> >>have no way to turn them around. >> >>> >>> =3D20 >> >>> >>> >>> icmp errors can be sent, but icmp in routers would have to pa= >> >>rse t=3D >> >>> >>he TCP sna option >> >>> >>>=3D20 >> >>> >>> >>So basically the need for the *network* layer to signal the sou= >> >>rce i=3D >> >>> >>s >> >>> >>> >>accommodated in packets using the TCP sna option by layer viola= >> >>tion.=3D >> >>> >> >> >>> >>>=3D20 >> >>> >>> ICMP is layered on top of ip as is tcp - icmp talking to tcp is no= >> >>t a l=3D >> >>> >>ayer >> >>> >>> violation. >> >>> >> >> >>> >>If you call ICMP a transport layer (fair enough), you haven't explai= >> >>ned=3D20 >> >>> >>why one transport should peek into the headers of another. ICMP can = >> >>talk =3D >> >>> >> >> >>> >>to TCP, but having ICMP parse TCP headers would be layer violation I= >> >>MO. >> >>> >> >> >>> >>> by the way, i dont put an _address_ in the transport - i put an id= >> >>entif=3D >> >>> >>ier - this >> >>> >>> is then used receivers to lookup an address to the originator. i _= >> >>might=3D >> >>> >>_ put a >> >>> >>> routing hint (e.g. a care of adddress) in the transport too - this= >> >> is =3D >> >>> >> >> >>> >>> not the same as putting in an actual address (which i am getting r= >> >>id of=3D >> >>> >> as it is >> >>> >>> invalid MOST of the time... >> >>> >> >> >>> >>Understood. That difference isn't key to my responses, so >>I've just=3D= >> >>20 >> >>> >>referred to it as an address, but didn't mean to confuse that issue.= >> >> >> >>> >> >> >>> >>> >>Moving the source address in that case didn't make it go away, = >> >>so th=3D >> >>> >>at's >> >>> >>> >>just shuffling the deck chairs. If you wanted more space for IP= >> >>, it'=3D >> >>> >>s >> >>> >>> >>just as logical to leave the current IP header alone and place = >> >>the e=3D >> >>> >>xtra=3D20 >> >>> >>> >>forwarding info in the TCP header - if you're violating layers = >> >>for I=3D >> >>> >>CMP, =3D3D >> >>> >>>=3D20 >> >>> >>> this is either a semantic quibble or confusing. >> >>> >>>=3D20 >> >>> >>> 1. i havnt changed the IP header ast aal - i 've changed the meani= >> >>ng of=3D >> >>> >> a field - >> >>> >>> thishas some very nice legacy interworking properties (as noted in= >> >> my n=3D >> >>> >>ote) >> >>> >> >> >>> >>Changing the meaning of a field changes the header. I.e., you can't = >> >>pass =3D >> >>> >> >> >>> >>that packet through a legacy router usefully - it could generate ICM= >> >>Ps=3D20 >> >>> >>to the wrong place, and won't interpret the source address field as = >> >>an=3D20 >> >>> >>extension of the destination address. >> >>> >> >> >>> >>My view is that: >> >>> >> change IP src address to mean destination realm >> >>> >> add source identifier to TCP header (e.g., as an option) >> >>> >>is just as usefully accomplished as: >> >>> >> leave IP as-is >> >>> >> add destination realm to the TCP header (as an option) >> >>> >> >> >>> >>(the only remaining difference is that your source identifier isn't = >> >>the=3D20 >> >>> >>same as IP's source address; I could just as easily put the source I= >> >>D in =3D >> >>> >> >> >>> >>the TCP header too if you prefer). >> >>> >> >> >>> >>Further, your paper and emails have not addressed the fact >>that TCP=3D= >> >>20 >> >>> >>headers don't exactly have lots of space - especially the SYN packet= >> >>,=3D20 >> >>> >>which is where the source identifier for a connection would need to = >> >>be=3D20 >> >>> >>established. >> >>> >> >> >>> >>=3D2E.. >> >>> >>> >>why not for forwarding? >> >>> >>> >>> since most of these ICMP response are meant as a response to= >> >> a tr=3D >> >>> >>anspo=3D3D >> >>> >>> >>rt entity, >> >>> >>> >>> this is semantically reasoanble. >> >>> >>> >> >> >>> >>> >>Your system posits transports might not ever need source addres= >> >>ses. >> >>> >>> >>Those transports no longer benefit from ICMP information from t= >> >>he ne=3D >> >>> >>twork=3D3D >> >>> >>> >> >>> >>> indeed since there is no information theoretic or control theoerti= >> >>c rea=3D >> >>> >>son they >> >>> >>> should want fedback from the net if thewy didnt want it from the e= >> >>nd. -=3D >> >>> >> i am just=3D20 >> >>> >>> bringing some consistency to a design error of the internet. >> >>> >> >> >>> >>I agree that unidirectional packets don't necessarily need >>network=3D= >> >>20 >> >>> >>feedback. That implies: >> >>> >> >> >>> >>1. that your entire supposition that the IP packet doesn't need a so= >> >>urce =3D >> >>> >> >> >>> >>address because the transport layer is unacknowledged may be true, b= >> >>ut=3D20 >> >>> >>actually implies that all transport layers should be >>bidirectional=3D= >> >>20 >> >>> >>(rather than implying that you don't need a source address). >> >>> >> >> >>> >>2. bidirectional packets need network address info in the network=3D= >> >>20 >> >>> >>header, because the network needs to respond to that information. if= >> >> I=3D20 >> >>> >>leave this to the transport layer, then every time I deploy a new=3D= >> >>20 >> >>> >>transport protocol (SCTP, DCCP, etc.), I need to recode all my route= >> >>rs=3D20 >> >>> >>to know where to peek to get information for ICMP to respond to. >> >>> >> >> >>> >>Again, as noted, many ICMP messages originate from the network, not = >> >>the=3D20 >> >>> >>end host. The need for source addresses in the header in the Interne= >> >>t is =3D >> >>> >> >> >>> >>to enable network-based error indicators. It's not clear at all why = >> >>that =3D >> >>> >> >> >>> >>is something we can/should want to get rid of entirely. >> >>> >> >> >>> >>Joe >> >>> >> >> >>> >> >> >>> >> >> >>> >>> >> >> >>> >>> >>> In missive <48776F2A.8030405 at isi.edu>, Joe Touch typed: >> >>> >>> >>>=3D3D20 >> >>> >>> >>> >>This is an OpenPGP/MIME signed message (RFC 2440 and 3156)= >> >> >> >>> >>> >>> >>--------------enigFDD94A1CA6B765ED0E2F3126 >> >>> >>> >>> >>Content-Type: text/plain; charset=3D3D3Dwindows-1252; form= >> >>at=3D3D3D=3D >> >>> >>flowed >> >>> >>> >>> >>Content-Transfer-Encoding: quoted-printable >> >>> >>> >>> >> >> >>> >>> >>> >>Jon, >> >>> >>> >>> >> >> >>> >>> >>> >>You asked why the Internet had source addresses. I provide= >> >>d an =3D >> >>> >>answe=3D3D >> >>> >>> >>r,=3D3D20 >> >>> >>> >>> >>based on my understanding of the historical context for th= >> >>e dec=3D >> >>> >>ision=3D3D >> >>> >>> >>=3D3D2E I=3D3D20 >> >>> >>> >>> >>apologize for being too terse for that to be clear, or for= >> >> bein=3D >> >>> >>g too=3D3D >> >>> >>> >>=3D3D20 >> >>> >>> >>> >>glib to belie a thoughful consideration of the contents of= >> >> your=3D >> >>> >> pape=3D3D >> >>> >>> >>r. >> >>> >>> >>> >> >> >>> >>> >>> >>That, however, does not mean that I did not read your pape= >> >>r. >> >>> >>> >>> >> >> >>> >>> >>> >>My response of your (IMO, historical) question has nothing= >> >> to d=3D >> >>> >>o wit=3D3D >> >>> >>> >>h=3D3D20 >> >>> >>> >>> >>your proposal for removing them, as is discussed below. >> >>> >>> >>> >> >> >>> >>> >>> >>Jon Crowcroft wrote: >> >>> >>> >>> >> > a perfect example of people responding to email that th= >> >>ey ha=3D >> >>> >>ven't=3D3D >> >>> >>> >> >> >>> >>> >>> >> > actually read properly >> >>> >>> >>> >> >> >>> >>> >>> >>I urge posters to read the mail they *write* as well as th= >> >>ose o=3D >> >>> >>thers=3D3D >> >>> >>> >>=3D3D20 >> >>> >>> >>> >>post. ;-) Please read my more detailed note below before = >> >>concl=3D >> >>> >>uding=3D3D >> >>> >>> >> how=3D3D20 >> >>> >>> >>> >>properly I've read your work. >> >>> >>> >>> =3D3D20 >> >>> >>> >>> >> >> >>> >>> >>> >>-- >> >>> >>> >>> >> >> >>> >>> >>> >>You assert that: >> >>> >>> >>> >> >> >>> >>> >>> >>> Remember this (RFC 791)? Let=3D3D3D92s think about the l= >> >>ine mar=3D >> >>> >>ked >> >>> >>> >>> >>> by Xs. So why is there a source address there? The naive= >> >> answ=3D >> >>> >>er >> >>> >>> >>> >>> is that some receivers might want to reply. >> >>> >>> >>> >> >> >>> >>> >>> >>That is a historically consistent answer. >> >>> >>> >>> >> >> >>> >>> >>> >>> It;s a Datagram, >> >>> >>> >>> >>> Stupid. Not all higher layers want to send something bac= >> >>k! Th=3D >> >>> >>e >> >>> >>> >>> >>> end-to-end argument says that we do not put a function i= >> >>n a l=3D >> >>> >>ower >> >>> >>> >>> >>> layer, unless it is required by the majority of upper la= >> >>yer u=3D >> >>> >>sers >> >>> >>> >>> >> >> >>> >>> >>> >>E2E argument allows designers to "put things in a layer th= >> >>at TH=3D >> >>> >>AT la=3D3D >> >>> >>> >>yer >> >>> >>> >>> >>actually needs". >> >>> >>> >>> >> >> >>> >>> >>> >>Later, your doc says that: >> >>> >>> >>> >> >> >>> >>> >>> >>> a better place to send advisory >> >>> >>> >>> >>> information in the future Internet is onwards to the rec= >> >>eiver=3D >> >>> >>, not=3D3D >> >>> >>> >> >> >>> >>> >>> >>> backwards to the sender. Obviously the unreachable cases= >> >> need=3D >> >>> >> >> >>> >>> >>> >>> to be considered more carefully, although if an end syst= >> >>em is=3D >> >>> >> not >> >>> >>> >>> >>> reachable, a SNA-RK might be still reachable. >> >>> >>> >>> >> >> >>> >>> >>> >>Host and net unreachables can't be fixed at all, as you no= >> >>te la=3D >> >>> >>ter. =3D3D >> >>> >>> >> >> >>> >>> >>> >>Other messages require the receiver know the source, which= >> >> - if=3D >> >>> >> this=3D3D >> >>> >>> >> is=3D3D20 >> >>> >>> >>> >>one of those higher layers that doesn't want to send somet= >> >>hing =3D >> >>> >>back =3D3D >> >>> >>> >>-=3D3D20 >> >>> >>> >>> >>won't happen either. >> >>> >>> >>> >> >> >>> >>> >>> >>The fact that further discussion asserts that error notifi= >> >>catio=3D >> >>> >>ns we=3D3D >> >>> >>> >>re=3D3D20 >> >>> >>> >>> >>always a bad idea I find naive as well. And MTU discovery = >> >>will =3D >> >>> >>NEVER=3D3D >> >>> >>> >>=3D3D20 >> >>> >>> >>> >>happen if the receiver has no notion of who the sender is.= >> >> >> >>> >>> >>> >> >> >>> >>> >>> >>--- >> >>> >>> >>> >> >> >>> >>> >>> >>> In missive <48768425.4000801 at isi.edu>, Joe Touch typed: >> >>> >>> >>> >>>=3D3D20 >> >>> >>> >>> >>> >>This is an OpenPGP/MIME signed message (RFC 2440 and = >> >>3156)=3D >> >>> >> >> >>> >>> >>> >>> >>--------------enig163A833E39F238C5F60A48CF >> >>> >>> >>> >>> >>Content-Type: text/plain; charset=3D3D3D3DISO-8859-1;= >> >> format=3D >> >>> >>=3D3D3D3Dfl=3D3D >> >>> >>> >>owed >> >>> >>> >>> >>> >>Content-Transfer-Encoding: quoted-printable >> >>> >>> >>> >>> >> >> >>> >>> >>> >>> >> >> >>> >>> >>> >>> >> >> >>> >>> >>> >>> >>Jon Crowcroft wrote: >> >>> >>> >>> >>> >>> speaking of sacred cows, >> >>> >>> >>> >>> >>> why are their source addresses in IP Packets? >> >>> >>> >>> >>> >>> http://www.cl.cam.ac.uk/~jac22/out/sna.pdf >> >>> >>> >>> >>> >> >> >>> >>> >>> >>> >>The same reason letters have return addresses; for er= >> >>rors =3D >> >>> >>(e.g.=3D3D >> >>> >>> >>, ICM=3D3D3D >> >>> >>> >>> >>Ps). =3D3D3D3D >> >>> >>> >>> >>> >> >> >>> >>> >>> >>> >> Not all errors signal the transport layer; some sig= >> >>nal t=3D >> >>> >>he ne=3D3D >> >>> >>> >>twork=3D3D3D >> >>> >>> >>> >>=3D3D3D3D20 >> >>> >>> >>> >>> >>layer (e.g., too-big, redirect, etc.) >> >>> >>> >>> >>> >> >> >>> >>> >>> >>> >>PS - burying them in the TCP header eats option space= >> >> from=3D >> >>> >> TCP,=3D3D >> >>> >>> >> whic=3D3D3D >> >>> >>> >>> >>h=3D3D3D3D20 >> >>> >>> >>> >>> >>isn't exactly in abundance either ;-) >> >>> >>> >>> >>> >> >> >>> >>> >>> >>> >>Joe >> >>> >>> >>> >>> >> >> >>> >>> >>> >>> >> >> >>> >>> >>> >>> >>--------------enig163A833E39F238C5F60A48CF >> >>> >>> >>> >>> >>Content-Type: application/pgp-signature; name=3D3D3D3= >> >>D"signa=3D >> >>> >>ture.as=3D3D >> >>> >>> >>c" >> >>> >>> >>> >>> >>Content-Description: OpenPGP digital signature >> >>> >>> >>> >>> >>Content-Disposition: attachment; filename=3D3D3D3D"si= >> >>gnature=3D >> >>> >>=3D2Easc" >> >>> >>> >>> >>> >> >> >>> >>> >>> >>> >>-----BEGIN PGP SIGNATURE----- >> >>> >>> >>> >>> >>Version: GnuPG v1.4.7 (MingW32) >> >>> >>> >>> >>> >>Comment: Using GnuPG with Mozilla - http://enigmail.m= >> >>ozdev=3D >> >>> >>=3D2Eorg >> >>> >>> >>> >>> >> >> >>> >>> >>> >>> >>iD8DBQFIdoQmE5f5cImnZrsRAnC9AKDrvpZ2kzV9rzrT8NN1NWkTE= >> >>sWdYQ=3D >> >>> >>CdF9O=3D3D >> >>> >>> >>k >> >>> >>> >>> >>> >>W8nN+CrIaW3+dENfI/qDyaw=3D3D3D3D >> >>> >>> >>> >>> >>=3D3D3D3Do5Lq >> >>> >>> >>> >>> >>-----END PGP SIGNATURE----- >> >>> >>> >>> >>> >> >> >>> >>> >>> >>> >>--------------enig163A833E39F238C5F60A48CF-- >> >>> >>> >>> >>>=3D3D20 >> >>> >>> >>> >>> cheers >> >>> >>> >> >> >>> >>> >> >> >>> >>> >>--------------enig841B4237908E688C7D411F39 >> >>> >>> >>Content-Type: application/pgp-signature; name=3D3D"signature.as= >> >>c" >> >>> >>> >>Content-Description: OpenPGP digital signature >> >>> >>> >>Content-Disposition: attachment; filename=3D3D"signature.asc" >> >>> >>> >> >> >>> >>> >>-----BEGIN PGP SIGNATURE----- >> >>> >>> >>Version: GnuPG v1.4.7 (MingW32) >> >>> >>> >>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org >> >>> >>> >> >> >>> >>> >>iD8DBQFId3KxE5f5cImnZrsRAl1GAJ4m5yLUosDO/kb7TwPLTa3Wi8GOWQCfbX8= >> >>Y >> >>> >>> >>mhEpJZ+jr+qMgMXMe3xEFtQ=3D3D >> >>> >>> >>=3D3DxV8K >> >>> >>> >>-----END PGP SIGNATURE----- >> >>> >>> >> >> >>> >>> >>--------------enig841B4237908E688C7D411F39-- >> >>> >>>=3D20 >> >>> >>> cheers >> >>> >>>=3D20 >> >>> >>> jon >> >>> >> >> >>> >> >> >>> >>--------------enigD0DFC0254F721440EFF890E4 >> >>> >>Content-Type: application/pgp-signature; name=3D"signature.asc" >> >>> >>Content-Description: OpenPGP digital signature >> >>> >>Content-Disposition: attachment; filename=3D"signature.asc" >> >>> >> >> >>> >>-----BEGIN PGP SIGNATURE----- >> >>> >>Version: GnuPG v1.4.7 (MingW32) >> >>> >>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org >> >>> >> >> >>> >>iD8DBQFId3fRE5f5cImnZrsRAqZIAKC5AISvnZl/XvTpQQo8MQmorJbYcACcDnHE >> >>> >>J6vm6gE7ZeA+AeVBsDHv/t8=3D >> >>> >>=3DSAYu >> >>> >>-----END PGP SIGNATURE----- >> >>> >> >> >>> >>--------------enigD0DFC0254F721440EFF890E4-- >> >>>=20 >> >>> cheers >> >>>=20 >> >>> jon >> >> >> >> >> >>--------------enigF1C37DEE2E67C3C7E2C863DF >> >>Content-Type: application/pgp-signature; name="signature.asc" >> >>Content-Description: OpenPGP digital signature >> >>Content-Disposition: attachment; filename="signature.asc" >> >> >> >>-----BEGIN PGP SIGNATURE----- >> >>Version: GnuPG v1.4.7 (MingW32) >> >>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org >> >> >> >>iD8DBQFId4AQE5f5cImnZrsRAiVYAJ9gkJxsv7y+UqJlnkhe2xEQGB06OgCeMWQ0 >> >>/q2ZOYRu0DHrMLUzzZC1Q9s= >> >>=YQ+E >> >>-----END PGP SIGNATURE----- >> >> >> >>--------------enigF1C37DEE2E67C3C7E2C863DF-- >> >> cheers >> >> jon > > > >Content-Type: application/pgp-signature; name="signature.asc" >Content-Description: OpenPGP digital signature >Content-Disposition: attachment; filename="signature.asc" > >Attachment converted: Macintosh HD:signature 16.asc ( / ) (00396180) From touch at ISI.EDU Sun Jul 13 21:42:47 2008 From: touch at ISI.EDU (Joe Touch) Date: Sun, 13 Jul 2008 21:42:47 -0700 Subject: [e2e] Why do we need TCP flow control (rwnd)? In-Reply-To: References: <48779B58.3010007@reed.com> <20080711174939.175E728E155@aland.bbn.com> <20080711203346.GE57069@zod.isi.edu> Message-ID: <487AD947.4080401@isi.edu> Lachlan Andrew wrote: > Greetings Ted, > > 2008/7/11 Ted Faber : >> True Poisson processes are rare; the only one I can think of off the top >> of my head is radioactive decay. > > Just to be picky, that isn't Poisson either, although it is well > approximated as Poisson on "short" time-scales (relative to the > half-life). > > In a Poisson process, events on disjoint intervals are independent. > In radioactive decay, if there are a lot of decays in an early > interval, there are fewer particles left to decay on later intervals, > causing negative correlation. There are two different effects to consider: 1. just saying "radioactive decay" isn't sufficient; as you note, decay within any finite amount has negative correlations with the future (over all timescales, not just far-term) 2. radioactive decay can cause cascades - so there is a positive correlation with near-term decay (over the span of decay products) It's not at all clear which of these dominates, or whether they balance. Both appear to be irrelevant for Geiger-counter mechanisms, though. For U235, with a half-life of 700M years, you lose only 0.01% of a sample in a period of 100,000 years (longer than we think our species has existed); you lose 0.000001% over 10 years (longer than most simulations I know would care about such random number generators). When you have enough atoms for that to be statistically significant (i.e., that you don't get quantization impacts, as you would, e.g., with 100 atoms), you're done. Even a miniscule amount, however, has more than enough atoms to suffice (e.g., 2.6 billion atoms in even 1 millionth of a gram). #2 comes into play in significant ways only when specifically engineered; decay product neutrons are too fast to initiate a cascade naturally. They need to be slowed down, or other elements need to be present. In a small sample, it would be unlikely they'd even hit other nucleii. I.e., a radioactive device would probably be sufficiently accurate to emulate a Possion process. Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20080713/8dde896e/signature.bin From faber at ISI.EDU Mon Jul 14 13:31:28 2008 From: faber at ISI.EDU (Ted Faber) Date: Mon, 14 Jul 2008 13:31:28 -0700 Subject: [e2e] Why do we need TCP flow control (rwnd)? In-Reply-To: <4878524A.9040202@reed.com> References: <48779B58.3010007@reed.com> <20080711174939.175E728E155@aland.bbn.com> <20080711203346.GE57069@zod.isi.edu> <4878524A.9040202@reed.com> Message-ID: <20080714203128.GD37803@zod.isi.edu> On Sat, Jul 12, 2008 at 02:42:18AM -0400, David P. Reed wrote: > Actually, Ted, constructing a sequence of events that are Poisson > distributed in time *requires* a Poisson process. Given a random variable X that's uniformly distributed on (0,1), Y= -a ln(1-X), for a > 0, is exponentially distributed with parameter a. Events with interarrivaltimes given by Y are Poisson distributed with parameter a. Poisson distributed events from a uniform random variable. This isn't esoteric; it's an example right out of my graduate probability text. I'm old enough that it's not online but if your library has Kishor Trivedi's _Probability & Statistics With Reliability, Queueing, And Computer Science Applications_, you can find the proof in the section on computing distributions of funtions of a random variable. In my 1982 edition, the proof is on page 140. -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20080714/18ff084e/attachment.bin From dpreed at reed.com Mon Jul 14 18:09:07 2008 From: dpreed at reed.com (David P. Reed) Date: Mon, 14 Jul 2008 21:09:07 -0400 Subject: [e2e] Why do we need TCP flow control (rwnd)? In-Reply-To: <20080714203128.GD37803@zod.isi.edu> References: <48779B58.3010007@reed.com> <20080711174939.175E728E155@aland.bbn.com> <20080711203346.GE57069@zod.isi.edu> <4878524A.9040202@reed.com> <20080714203128.GD37803@zod.isi.edu> Message-ID: <487BF8B3.1080908@reed.com> Ted - you must not be reading my email very carefully. The description you give below *is* [subject to very poor writing style] a Poisson process. The construction that is implied by "events with interarrival times given by Y" is expressed via really lousy mathematical exposition - where was the editor? But since I can guess what the author(s?) intended to say, I'd forgive them for not specifying that they are suggesting an algorithm that takes as input an ordered sequence of samples taken from repeated experiments based on different instantiations of the variable Y (computed from different instantiations of a random variable X), and then converting the ordered sequence into a particular event sequence that they call Poisson. A careful mathematical exposition would describe this in terms of random sequences Xbar (selected independently from a uniform distribution), and Ybar, and the resulting sequence Zbar, which is the summation of prefixes of Ybar. Neither X nor Y are Poisson random variables, but the sequence thus derived is an instance of a Poisson process. A Poisson process is defined as an event-generating process that assigns a specific probability to a particular count of events that occur in each interval of the real line. - Peace Ted Faber wrote: > On Sat, Jul 12, 2008 at 02:42:18AM -0400, David P. Reed wrote: > >> Actually, Ted, constructing a sequence of events that are Poisson >> distributed in time *requires* a Poisson process. >> > > Given a random variable X that's uniformly distributed on (0,1), Y= -a > ln(1-X), for a > 0, is exponentially distributed with parameter a. > Events with interarrivaltimes given by Y are Poisson distributed with > parameter a. > > Poisson distributed events from a uniform random variable. > > This isn't esoteric; it's an example right out of my graduate > probability text. I'm old enough that it's not online but if your > library has Kishor Trivedi's _Probability & Statistics With Reliability, > Queueing, And Computer Science Applications_, you can find the proof in > the section on computing distributions of funtions of a random variable. > In my 1982 edition, the proof is on page 140. > > From faber at ISI.EDU Mon Jul 14 18:40:56 2008 From: faber at ISI.EDU (Ted Faber) Date: Mon, 14 Jul 2008 18:40:56 -0700 Subject: [e2e] Why do we need TCP flow control (rwnd)? In-Reply-To: <487BF8B3.1080908@reed.com> References: <48779B58.3010007@reed.com> <20080711174939.175E728E155@aland.bbn.com> <20080711203346.GE57069@zod.isi.edu> <4878524A.9040202@reed.com> <20080714203128.GD37803@zod.isi.edu> <487BF8B3.1080908@reed.com> Message-ID: <20080715014056.GA38967@zod.isi.edu> On Mon, Jul 14, 2008 at 09:09:07PM -0400, David P. Reed wrote: > Ted - you must not be reading my email very carefully. The description > you give below *is* [subject to very poor writing style] a Poisson process. Your kindness is misplaced. As you know that wasn't a clarity issue, but a technical error. I appreciate it anyway. -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20080714/cd772ca4/attachment.bin