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). = > >> > >>