From detlef.bosau at web.de Tue Dec 11 05:20:03 2012 From: detlef.bosau at web.de (Detlef Bosau) Date: Tue, 11 Dec 2012 14:20:03 +0100 Subject: [e2e] Are there any persons interested in TCP over mobile wireless networks in Germany? Message-ID: <50C73303.8090800@web.de> I have to apologize for this question, however, I would greatly appreciate to get in touch with academic persons who are interested in this area. -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de ------------------------------------------------------------------ From lars at netapp.com Tue Dec 11 05:48:09 2012 From: lars at netapp.com (Eggert, Lars) Date: Tue, 11 Dec 2012 13:48:09 +0000 Subject: [e2e] Are there any persons interested in TCP over mobile wireless networks in Germany? In-Reply-To: <50C73303.8090800@web.de> References: <50C73303.8090800@web.de> Message-ID: On Dec 11, 2012, at 14:20, Detlef Bosau wrote: > I have to apologize for this question, however, I would greatly appreciate to get in touch with academic persons who are interested in this area. http://lmgtfy.com/?q=TCP+over+mobile+wireless+networks+site%3Ade Lars From detlef.bosau at web.de Tue Dec 11 06:04:31 2012 From: detlef.bosau at web.de (Detlef Bosau) Date: Tue, 11 Dec 2012 15:04:31 +0100 Subject: [e2e] Are there any persons interested in TCP over mobile wireless networks in Germany? In-Reply-To: References: <50C73303.8090800@web.de> Message-ID: <50C73D6F.8030309@web.de> Am 11.12.2012 14:48, schrieb Eggert, Lars: > On Dec 11, 2012, at 14:20, Detlef Bosau wrote: >> I have to apologize for this question, however, I would greatly appreciate to get in touch with academic persons who are interested in this area. > http://lmgtfy.com/?q=TCP+over+mobile+wireless+networks+site%3Ade > > Lars Although I don't see my original post yet, however, this was definitely not the answer I hoped to see. And please let me note: Google is never an answer. Particularly, Google cannot be an answer to a descent question. -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de ------------------------------------------------------------------ From detlef.bosau at web.de Wed Dec 12 07:38:39 2012 From: detlef.bosau at web.de (Detlef Bosau) Date: Wed, 12 Dec 2012 16:38:39 +0100 Subject: [e2e] Delivery times in mobile networs? Re: Are there any persons interested in TCP over mobile wireless networks in Germany? In-Reply-To: <50C73303.8090800@web.de> References: <50C73303.8090800@web.de> Message-ID: <50C8A4FF.6020209@web.de> Am 11.12.2012 14:20, schrieb Detlef Bosau: > I have to apologize for this question, however, I would greatly > appreciate to get in touch with academic persons who are interested in > this area. > My central question at the moment is: Do we have stationary packet delivery times on mobile wireless links? I was pointed to some papers, where those delivery times are estimated with EWMA filters. May I be honest? I absolutely hate academic lying. When a delivery time is not stationary, I cannot estimate it using an EWMA filter. (For EWMA filter fans: If you simply use "15" as the result for your EWMA filter, you have much less work and the result is as wrong as the original ;-)) To my understanding, it simply is not reasonable to expect stationary delivery times here. But I'm trying to get a sound answer for this question for about a year now, and I don't find sound literature nor do I find someone to answer my question. Perhaps, this list is not the right place for my question, I would appreciate hints. However, I would like to find an answer to my question. Detlef -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de ------------------------------------------------------------------ From lachlan.andrew at gmail.com Wed Dec 12 14:36:21 2012 From: lachlan.andrew at gmail.com (Lachlan Andrew) Date: Thu, 13 Dec 2012 09:36:21 +1100 Subject: [e2e] Delivery times in mobile networs? Re: Are there any persons interested in TCP over mobile wireless networks in Germany? In-Reply-To: <50C8A4FF.6020209@web.de> References: <50C73303.8090800@web.de> <50C8A4FF.6020209@web.de> Message-ID: Greetings Detlef, Of course you can use an EWMA filter to estimate a non-stationary process. Why do you think you couldn't? In a non-stationary process, such as fading, there is usually considerable temporal correlation. If the time constant of the filter is short compared with the "body" of the autocorrelation of the delivery times, then the non-stationarity makes essentially no difference. If you want to be taken seriously (as I know you do) then it would be wise to tone down your criticism of other people's work. Although it is common for "standard practice" to be wrong, it is even more common for it to be sensible. Cheers, Lachlan On 13 December 2012 02:38, Detlef Bosau wrote: > Am 11.12.2012 14:20, schrieb Detlef Bosau: >> >> I have to apologize for this question, however, I would greatly appreciate >> to get in touch with academic persons who are interested in this area. >> > My central question at the moment is: Do we have stationary packet delivery > times on mobile wireless links? > > I was pointed to some papers, where those delivery times are estimated with > EWMA filters. > May I be honest? I absolutely hate academic lying. When a delivery time is > not stationary, I cannot estimate it using an EWMA filter. > (For EWMA filter fans: If you simply use "15" as the result for your EWMA > filter, you have much less work and the result is as wrong as the original > ;-)) > > To my understanding, it simply is not reasonable to expect stationary > delivery times here. But I'm trying to get a sound answer for this question > for about a year now, and I don't find sound literature nor do I find > someone to answer my question. > > Perhaps, this list is not the right place for my question, I would > appreciate hints. However, I would like to find an answer to my question. > > Detlef > > -- > ------------------------------------------------------------------ > Detlef Bosau > Galileistra?e 30 > 70565 Stuttgart Tel.: +49 711 5208031 > mobile: +49 172 6819937 > skype: detlef.bosau > ICQ: 566129673 > detlef.bosau at web.de http://www.detlef-bosau.de > ------------------------------------------------------------------ > -- Lachlan Andrew Centre for Advanced Internet Architectures (CAIA) Swinburne University of Technology, Melbourne, Australia Ph +61 3 9214 4837 From detlef.bosau at web.de Thu Dec 13 00:58:30 2012 From: detlef.bosau at web.de (Detlef Bosau) Date: Thu, 13 Dec 2012 09:58:30 +0100 Subject: [e2e] Delivery times in mobile networs? Re: Are there any persons interested in TCP over mobile wireless networks in Germany? In-Reply-To: References: <50C73303.8090800@web.de> <50C8A4FF.6020209@web.de> Message-ID: <50C998B6.1030306@web.de> Am 12.12.2012 23:36, schrieb Lachlan Andrew: > Greetings Detlef, > > Of course you can use an EWMA filter to estimate a non-stationary > process. Why do you think you couldn't? You should use 15. It's just simpler to implement. (For the rest, I recommend looking it up in a textbook on mathematical statistics. You cannot estimate parameters, which simply don't exist. Unfortunately, a C-compiler does only syntax checking on programs, hence it cannot prevent semantic nonsense.) > > In a non-stationary process, such as fading, there is usually > considerable temporal correlation. EWMA filters are estimators for a random variable's expectation. And, like other ARMA filters as well, this makes sense in a series of i.i.d. random variables. > If the time constant of the filter > is short compared with the "body" of the autocorrelation of the > delivery times, then the non-stationarity makes essentially no > difference. In that case, we may talk aboult "nearly stationary" processes. > If you want to be taken seriously (as I know you do) then it would be > wise to tone down your criticism of other people's work. Although it Lachlan, it's not a matter of tone. If you think about TCP's RTO, this is a confidence interval estimated from observations of successful deliveries. Simply think of some mobile access network with a sudden link outage. What does an RTO mean in that case? What I point to, is written in Edge's original paper from 1983 or 1984. So, I wonder why you are that surprised when I repeat something, which is accepted in CS for nearly 30 years now. I don't see "criticism" when I point to accepted knowledge and point to errors. And EWMA filters, like other ARMA estimators, simply cannot applied to time series when the necessary assumptions and conditions are not met. When someone tells me 5+5 were 11, this is not a matter of tone, this is simply wrong. -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de ------------------------------------------------------------------ From detlef.bosau at web.de Thu Dec 13 01:04:56 2012 From: detlef.bosau at web.de (Detlef Bosau) Date: Thu, 13 Dec 2012 10:04:56 +0100 Subject: [e2e] Delivery times in mobile networs? Re: Are there any persons interested in TCP over mobile wireless networks in Germany? In-Reply-To: <50C998B6.1030306@web.de> References: <50C73303.8090800@web.de> <50C8A4FF.6020209@web.de> <50C998B6.1030306@web.de> Message-ID: <50C99A38.6000608@web.de> Just as an illustration: EWMA filters are used for the analysis of time series. And I think all of us are very well aware of typical artefacts in the analysis of time series, the most prominent of which are certainly aliasing phenomena. ("Backward spinning wheels in movies.") -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de ------------------------------------------------------------------ From detlef.bosau at web.de Thu Dec 13 02:40:37 2012 From: detlef.bosau at web.de (Detlef Bosau) Date: Thu, 13 Dec 2012 11:40:37 +0100 Subject: [e2e] Delivery times in mobile networs? Re: Are there any persons interested in TCP over mobile wireless networks in Germany? In-Reply-To: <50C99A38.6000608@web.de> References: <50C73303.8090800@web.de> <50C8A4FF.6020209@web.de> <50C998B6.1030306@web.de> <50C99A38.6000608@web.de> Message-ID: <50C9B0A5.7010104@web.de> And particularly to networks: In HSDPA, we often see channel coding changes between one transmission block and the following one. Compared to, say, Ethernet, this would be analogous to swapping interfaces from Ethernet (10 Mbit/s), FE, GE or even 10GE. Not only between one packet and the following one but even faster, because in mobile networks IP packets may well be split up into several transmission blocks. When we think of wired networks, many of us will hardly see an "internal relationship" between observed RTT, when the interfaces are changed. And estimating an expectation for the observed RTT from observations with different hardware would surely be rejected because we compare peaches and oranges in a case like this. Actually, in TCP there are two ways to handle this situation: Either, the RTT drops. Then, after some time, the RTT estimation in a TCP socket drops as well. And will (hopefully) settles after some time. (That's, what is covered by "weakly stationary" or "quasi stationary" by Edge.) Or the RTT exhibits a drastic increase. In that case, we are likely to see a timeout - and the situation is salvaged by the timer backoff proposed, IIRC, by Karn & Partridge. So, we simply drop the existing RTO because it is no longer useful as a confidence interval for RTT. We drop the existing RTO, we typically drop the estimations for RTT and RTTVAR as well and do timer backoff, until we observe successfull packet transmissions, re-initialize RTT and RTTVAR and return to normal operation. Am 13.12.2012 10:04, schrieb Detlef Bosau: > Just as an illustration: EWMA filters are used for the analysis of > time series. > > And I think all of us are very well aware of typical artefacts in the > analysis of time series, the most prominent of which are certainly > aliasing phenomena. > ("Backward spinning wheels in movies.") > > > > -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de ------------------------------------------------------------------ From lars at netapp.com Thu Dec 13 03:15:01 2012 From: lars at netapp.com (Eggert, Lars) Date: Thu, 13 Dec 2012 11:15:01 +0000 Subject: [e2e] Delivery times in mobile networs? Re: Are there any persons interested in TCP over mobile wireless networks in Germany? In-Reply-To: <50C8A4FF.6020209@web.de> References: <50C73303.8090800@web.de> <50C8A4FF.6020209@web.de> Message-ID: On Dec 12, 2012, at 16:38, Detlef Bosau wrote: > My central question at the moment is: Do we have stationary packet delivery times on mobile wireless links? Figures 12 and 13 in Binoy's thesis at http://eggert.org/students/chemmagate-thesis.pdf have some related data. (Note that these plot TCP SYN/SYNACK RTTs and mobile networks are known to use TCP proxies that can introduce additional delays.) Lars From detlef.bosau at web.de Thu Dec 13 07:21:48 2012 From: detlef.bosau at web.de (Detlef Bosau) Date: Thu, 13 Dec 2012 16:21:48 +0100 Subject: [e2e] Delivery times in mobile networs? Re: Are there any persons interested in TCP over mobile wireless networks in Germany? In-Reply-To: References: <50C73303.8090800@web.de> <50C8A4FF.6020209@web.de> Message-ID: <50C9F28C.90707@web.de> Am 13.12.2012 15:57, schrieb Jim Gettys: > > > > On Thu, Dec 13, 2012 at 6:15 AM, Eggert, Lars > wrote: > > On Dec 12, 2012, at 16:38, Detlef Bosau > wrote: > > My central question at the moment is: Do we have stationary > packet delivery times on mobile wireless links? > > Not sure what you mean by "stationary". > > This crossed my radar screen: > > http://conferences.sigcomm.org/sigcomm/2012/paper/cellnet/p1.pdf Thanks for the hint. This is not exactly what I had in mind, however it is extremely closely related. I.e. at a very first glance, non stationary delivery times can result in a buffer bloat phenomenon. To bring it to a simple point (Lachlan, please don't hurt me..... ;-)): The typically "serialization delay" which is typically used in network simulators is simply wrong for mobile networks. It is SIMPLY WRONG to use "constant rates" for mobile networks, - first because in mobile networks net data rates may change (sometimes several times within the transport of one single IP packet), for adaptation reasons, - second because mobile networks often employ opportunistic scheduling algorithms which may cause a channel getting no service for some period of time, - third because mobile networks typically employ some kind of recovery layer with automatic retransmission. So the simple "serialization and delivery" of a packet of, say, 1024 bytes length in GPRS may last from 7 seconds to 375 seconds according to the relevant ETSI standards. There may be other delays than the mentioned ones and the issue is perhaps much more complex than I said, however one must not, as in wired networks, take a net data rate of, e.g., 10 MBit/s and 1024 byte and expect a "serialization delay" and think the "serialization delay" were 891,2 microseconds. Actually, even the values taken from the standard are 0,95 quantiles. So the "serialization" delay may last much longer, it is even possible that the packet is not delivered at all and hence stays in the queue forever. -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de ------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20121213/d9e819b6/attachment.html From b_a_denny at yahoo.com Thu Dec 13 10:33:58 2012 From: b_a_denny at yahoo.com (Barbara Denny) Date: Thu, 13 Dec 2012 10:33:58 -0800 (PST) Subject: [e2e] Delivery times in mobile networs? Re: Are there any persons interested in TCP over mobile wireless networks in Germany? In-Reply-To: Message-ID: <1355423638.13214.YahooMailClassic@web141402.mail.bf1.yahoo.com> Just to clarify, are you interested in the single hop or multi-hop case, or both? The subject line says mobile wireless networks but your question uses the term links. barbara --- On Thu, 12/13/12, Eggert, Lars wrote: > From: Eggert, Lars > Subject: Re: [e2e] Delivery times in mobile networs? Re: Are there any persons interested in TCP over mobile wireless networks in Germany? > To: "Detlef Bosau" > Cc: "" > Date: Thursday, December 13, 2012, 3:15 AM > On Dec 12, 2012, at 16:38, Detlef > Bosau > wrote: > > My central question at the moment is: Do we have > stationary packet delivery times on mobile wireless links? > > Figures 12 and 13 in Binoy's thesis at http://eggert.org/students/chemmagate-thesis.pdf have > some related data. > > (Note that these plot TCP SYN/SYNACK RTTs and mobile > networks are known to use TCP proxies that can introduce > additional delays.) > > Lars > From detlef.bosau at web.de Thu Dec 13 11:02:22 2012 From: detlef.bosau at web.de (Detlef Bosau) Date: Thu, 13 Dec 2012 20:02:22 +0100 Subject: [e2e] Delivery times in mobile networs? Re: Are there any persons interested in TCP over mobile wireless networks in Germany? In-Reply-To: <1355423638.13214.YahooMailClassic@web141402.mail.bf1.yahoo.com> References: <1355423638.13214.YahooMailClassic@web141402.mail.bf1.yahoo.com> Message-ID: <50CA263E.3010000@web.de> Am 13.12.2012 19:33, schrieb Barbara Denny: > Just to clarify, are you interested in the single hop or multi-hop case, or both? The subject line says mobile wireless networks but your question uses the term links. For the moment, I'm primarily interested in the single hop. Detlef -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de ------------------------------------------------------------------ From detlef.bosau at web.de Fri Dec 14 08:13:12 2012 From: detlef.bosau at web.de (Detlef Bosau) Date: Fri, 14 Dec 2012 17:13:12 +0100 Subject: [e2e] Delivery times in mobile networs? Re: Are there any persons interested in TCP over mobile wireless networks in Germany? In-Reply-To: References: <50C73303.8090800@web.de> <50C8A4FF.6020209@web.de> Message-ID: <50CB5018.4050806@web.de> Am 13.12.2012 15:57, schrieb Jim Gettys: > > > > On Thu, Dec 13, 2012 at 6:15 AM, Eggert, Lars > wrote: > > On Dec 12, 2012, at 16:38, Detlef Bosau > wrote: > > My central question at the moment is: Do we have stationary > packet delivery times on mobile wireless links? > > Not sure what you mean by "stationary". > > This crossed my radar screen: > > http://conferences.sigcomm.org/sigcomm/2012/paper/cellnet/p1.pdf > And there you find > Simply speaking, the static value could be too > small in large BDP (Bandwidth-Delay Product) links but too large > in small BDP links. And if you compare this to the "BDP Definition" as used e.g. in > @article{ meyer, > author ="Michael Meyer and Joachim Sachs and Markus Holzke", > title ="{Performance Evaluation of A TCP Proxy in WCSMA Networks}", > journal ="IEEE Wireless Communications", > year = "2003", > month = "October" > } you see, what I'm talking about. Particularly, as the quoted paper uses the GPRS link's gross data rate for the calculation of the "Bandwidth-Delay Product", a term which is, decently spoken, complete nonsense in the context of mobile wireless networks. I have to apologize for being upset, if you knew me a bit closer, you would surely understand my attitude. If you have a look hat Little's paper (I think it's commonly known that the "Bandwidth-Delay Product" is the CS "conception" of Little's Theorem, of course used with the "CS conception" of the term "bandwidth", which was a subject of discussion in this list some weeks ago, you'll find that this is an equation between several expectations. The average (i.e. expected) number of jobs in a queueing system equals the product of the average (i.e. expected) arrival rate times the avarage (i.e. expected) sojourn time. As TCP employs a self clocking mechanism for clocking out sent packets and the delivery times in mobile links are non stationary (I did not ask for papers, because this were an open question, that mobile link's delivery times are not stationary is obvious, however the people I talk to don't believe me, this is a cause for my anger) neither the arrival rate nor the sojourn time have an expectation, hence Little's theorem simply does not apply here. More simply: When you offer lots of load to a wireless interface (be it window- or rate-controlled, this doesn't make a difference) and the delivery time suffers from a sudden increase (I well know the lots of paper with Gilbert-Markov-Models and "link outages" - what is a "link outage" in mobile wireless networks? We work with mobile wireless networks for 20 years now and many guys still think in the black and white manner of a link being up or down! Although a simple look into the standards will tell you that e.g. for a GPRS link the .95 quantile for the delivery of 1024 byte packet varies (depending on the chosen QoS class and the link's properties) from 7 seconds to 375 seconds. And please note the meaning of 0.95 quantile. When the mentioned 6 minutes are over, it may well be that your packet is lost and no one told you about that. So, when the delivery time suffers from a sudden increase - why do we wonder about buffer bloats then? And when delivery times of, say, a HSDPA interfaces vary on a time range from some few milliseconds, why do we wonder, that TCP sending sockets seeing a RTT of, say, 50 ms, do not timely adapt? I first discussed this issue with academics in Germany 6 years ago, they did not believe me. I noted that the term BDP is completely inappropriate for mobile networks, no one believed me. For some reasons which don't belong here, I cannot afford papers at visible conferences and when I submit papers on that issue to conferences or papers, no one believes me. I'm frequently taken for an idiot and rejected and offended - and when I claim, rain would consist of water, no one believes me. On the one hand, I'm glad to see this paper. On the other hand, I'm extremely upset and I hardly can describe my anger and bitterness here, although this must not be part of this list. But I'm only a human being, so I cannot ignore my emotions. Detlef -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de ------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20121214/839a45b7/attachment.html From braden at isi.edu Tue Dec 18 12:41:31 2012 From: braden at isi.edu (Bob Braden) Date: Tue, 18 Dec 2012 12:41:31 -0800 Subject: [e2e] Just testing... Message-ID: <50D0D4FB.8070801@isi.edu> Thanks, Joe. Bob Braden From detlef.bosau at web.de Mon Dec 24 15:57:27 2012 From: detlef.bosau at web.de (Detlef Bosau) Date: Tue, 25 Dec 2012 00:57:27 +0100 Subject: [e2e] Bandwidth, was: Re: Free Internet & IPv6 In-Reply-To: <1348085253.52094.YahooMailClassic@web163003.mail.bf1.yahoo.com> References: <1348085253.52094.YahooMailClassic@web163003.mail.bf1.yahoo.com> Message-ID: <50D8EBE7.1090300@web.de> Am 19.09.2012 22:07, schrieb Daniel Havey: > I wonder why the bandwidth is unused in the first place? Is it being wasted because it is of little value? What bandwidth are we talking about? I guess that bandwidth as a commodity would have a time and place. Bandwidth on what router and when? Please allow me to refer to this old discussion. Particularly as I have seen the following paper: "Modeling Computer Networks for Emulation" by Herrscher, Leonhardi, Rothermel, PDPTA'02. Which is a bit older too. Let my quote some sentences from this paper. > The simplest dynamic model is the table model. > Instead of a static value, a table is provided that > consists of tuples with triggers and actions. Each > action can be a parameter change or another > dynamic model. Tables are especially suited to > replay parameters gathered from measurements. > For example, the changing bandwidth of a mobile > 802.11b node can be easily modeled that way (see > fig. 3). The triggers can be either time values or > packet counts. In most cases, a time triggered > table will be appropriate. Some of you know from private converstions, that I've struggled with mobile networks for quite some years now. The by far most important lesson is, that the term "bandwidth" is frequently used in a questionable manner by CS guys (as I'm myself). With sometimes more than questionable results. It took me some time to say the following, because some colleagues strongly advised me not to do so, because no one would take me seriously. Be it that way or not, I would like to return to that topic. Particularly when wireless networks are concerned, CS guys cooperate closely with CE and EE guys and so, to my understanding, it is inevitable to use well defined terms that way as they _ARE_ defined and to avoid "redefinitions" by all means. (During my education, I got in touch with civil engineers. And for those, the first of all were the definitions of terms, the second were the standards, particularly the DIN in germany, and in the third place came the ten commandments, the rest was of minor importance.) So, to my understanding (and I find this, e.g., in Shannon-Hartley's Theorem) the term bandwidth denotes the frequency range of a signal or a channel. No more, no less. Consequence: The sentences quoted above don't really make sense: A wireless signal's "bandwidth" in 802.11 networks does not change when a station moves around. When it comes to a mobile station in 802.11b, the signal may be influenced e.g. by - multipath interference - shading - free space loss - noise The text above refers to fee space loss, which is not necessarily the most important influence. Particularly when mobility is considered, multipath interference is extremely important, which makes a replay from logged values highly questionable. (From signal theory we now, that it's not a trivial task to replay a formerly logged motion scenario. Please keep in mind that minimum and maximum points of multipath interference can be quite closely, e.g. in the magnitude of several centimetres in GSM or WLAN.) In addition, up to know we only talked about the SNR or C/I ratio. We did not consider scheduling issues. I will not attempt to model a wireless interface in this post. (To the best of my knowledge, this is a tough issue and although I'm looking for convincing models for years now, I did not really find some. At least none which can be used for the purpose of simulation or emulation. There are models which can be used for these purposes and there are models which refer to reality. Unfortunately, I've never seen a model which matched both criteria.) Back to 802.11: When I consider the situation in my appartment, I can well ignore this whole SNR stuff. What bothers me most are collisions. At the very moment, I "see" 6 (in words: six) 802.11 nets which I could join, if I had the appropriate key. Hence, these networks inevitably overlap. And so, collisions cannot be avoided. So, when I would move from the living room to the kitchen, this would hardly influence the throughput from my WLAN base station to my notebook. It would have certainly have more influence, when some of my neighbours would turn off their computers and I would see less collisions than now ;-) Please note: The "bandwidth" does not change - neither when I move my computer nor when neighbours turn off their computers. There are changes - to the SNR as seen by the signal's receiver (mobile station or base station) and to - the number of collisions, in other words: to the network load. Both will results in changes of the wireless channel's throughput as perceived by upper layers and - finally - by the application and the user. However, I think the term "bandwidth" must not be used here. We should make a proper distinction between bandwidth and throughput. With particular respect to packet switching, I even would be careful with "throughput", because the some observations indicate that packet delivery times in wireless networks are not stationary in some scenarios. In that cases, we should focus on delivery times - the term "bandwidth" surely does not make sense here. With particular respect to Daniel's question in the quoted post, I think it's always a good idea to properly identify the resource of interest. Typically the shared/common resource. Be it "bandwidth" (in FDM), be it "sending time" (in TDM), be it "power" (in CDMA). Personally, I'm a bit frustrated by a certain confusion of terms here. This is hardly a problem when reading articles. In most cases, I can well understand what authors want to say. However, when it comes to a technical conversation, I often met a Babylonian confusion - which made it hardly possible to communicate. And which is particularly annoying when it comes to modelling. As it can bee seen from the quoted text fragment. In quite some typical 802.11 implementations, applications, scenarios "free space loss" is simply a non issue. And so it hardly makes sense to waste much programming effort to model free space loss, while collisions (where the shared resource is "sending time") are the much more important issue, of course amongst others. Of course, this always depends on the scenario. But from my first hand experience, I see quite some 802.11 networks in offices or apartments or hot spot scenarios. I rarely get in touch with battlefield scenarios or some isolated WLAN cells somewhere in the desert ;-) So, basically, I'm not quite sure whether we should develop a certain awareness for the correct terminology. Do you agree here? Detlef -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de ------------------------------------------------------------------ From detlef.bosau at web.de Tue Dec 25 05:40:49 2012 From: detlef.bosau at web.de (Detlef Bosau) Date: Tue, 25 Dec 2012 14:40:49 +0100 Subject: [e2e] Bandwidth, was: Re: Free Internet & IPv6 In-Reply-To: <1356405568.01746958@apps.rackspace.com> References: <1348085253.52094.YahooMailClassic@web163003.mail.bf1.yahoo.com> <50D8EBE7.1090300@web.de> <1356405568.01746958@apps.rackspace.com> Message-ID: <50D9ACE1.4070803@web.de> Am 25.12.2012 04:19, schrieb dpreed at reed.com: > > Good luck getting people to use the term "bitrate" instead of the > entirely erroneous term "bandwidth" that has developed since the > 1990's or so. > David, I very well see the "custom" side of the problem. In the sense, that using "bandwidth" here, is a custom. H > Indeed, bandwidth is now meaningless as a term, just as "broadband" > is. Once upon a time, both referred to bounds on the frequency > components of the physical layer signal, both in wires (twisted pair, > coax, etc) and in RF. The RF bandwidth of 802.11b DSSS modulation > was about 10 MHz, whereas the bitrate achieved was about 2 Mb/sec. > Now we use OFDM modulation in 802.11n, with bandwidths of 40 MHz more > or less, but bitrates of >> 40 Mb/sec. (yes, that is mostly because > of 64-QAM, which encodes 6 bits on each subcarrier within an OFDM > "symbol"). > You're talking about two different things which should be taken apart. The one thing are the physical limitations of technologies. And I agree: We now have broad frequency ranges even for wireless channels so that we can - in principle - achieve huge throughputs there. "In principle". It's not that long ago that I encountered a classroom scenario where the students should establish MANETs - and although the "bandwidth" was quite attractive, the achieved "throughput" wasn't. This was no university scenario. And now the teachers try to explain..... > What causes the 802.11n MAC protocol to achieve whatever bitrate it > achieves is incredibly complex. > I absolutely agree. However, I don't agree to quite a lot of simulations and emulations which simply ignore that complexity and replace it by simply wrong models. > Interestingly, in many cases the problem is really bad due to > "bufferbloat" in the 802.11n device designs and drivers, which causes > extreme buildup of latency, which then causes the TCP control loops to > be very slow in adapting to new flows sharing the path. > Interestingly ;-) Could it be, that we (at least to a certain degree) encounter a "home made problem" here? Particularly when you refer to nonsense like that one: @article{ meyer, author ="Michael Meyer and Joachim Sachs and Markus Holzke", title ="{Performance Evaluation of A TCP Proxy in WCSMA Networks}", journal ="IEEE Wireless Communications", year = "2003", month = "October" } Where the path capacity of a GPRS link is given by the "latency bandwidth product" and the "bandwidth" is 384 kBit/s (which is the gross data rate of GPRS) - and then users are recommended to use large initial window sizes for TCP to fully exploit this "capacity"? Which simply ignores, and I had lots of arguments here even with EE and CE guys, that the path capacity is not used for initial transmissions but because of retransmissions, some packets are placed on "the channel" dozens of times? Could it be, that using a simple stop 'n wait algorithm for mobile links (which is generally a good idea because in terrestric mobile networks the "radio link" quite frequently doesn't keep the amount of data which is necessary for one IP address, so there's no need to use sliding window here) and sending a packet to the link when another packet has left the link (which is the recommendation by Jacobson and Karels for more then twenty years now ;-) would alleviate the problem? Actually, the GPRS standard accepts delivery times up to five minutes. So, assuming a "bandwidth" of 384 kBit/s, I sometimes consider making my notebook talking to itself using GPRS as some kind of memory extension.... (However, I'm still looking for a fast random access algorithm, the serial access is sometimes a bit annoying.) (It could be a nice product brand: "WAX". "Wireless Address eXtension." ) No kidding: When we send huge amounts of data to an interface with the strong expectation that this data is conveyed to somewhere - although the interface does not get any service for some reason, this is as reasonable as lending money to Greece and strongly expecting to get the money paid back - with interest. (I herewith apologize to greek readers here. You might tell me, that not we Germans suffer from Greece - but it's the other way round, Greece suffers from Germany. However, hope is on the way: The next elections in Germany are in fall 2013.) So, it's not surprising that we have buffer bloats there (like the debit of Greece to Germany). (To the non european readers: Germany sometimes talked Greece in buying useless things in Germany, like e.g. submarines. Particularly Germany vouched for Greece's credit worthiness - and now, Greece has useless submarines and no money but an incredible debit, German submarine builders are unemployed - and German taxis payers are made to believe that Greece were the cause of the problem.) The analogy is not new: In some text books, sliding window systems as they are used in TCP, are called "credit based schemes". And we can find quite some analogies between data transportation systems and networks on the one hand and economic systems on the other. So, the often mentioned "buffer bloat" problem in networking is similar to the "balance bloat" problem, which is often talked about in economics. And the reasons are not that different: In both cases, we have a strong mismatch between expectation and reality. > This latter problem is due to the fact that neither the radio > engineers (who design the modulators) nor the CS people (who write the > code in the device drivers and application programs) actually > understand queueing theory or control theory very well. > The more important problem is, at least in Germany, that they do not understand each other. And the very reason for this is, at least in Germany, that they do not listen to each other. David, when I talk to colleagues and claim that throughput may be different from a gross bit rate, I'm blamed as a know it all - and frankly spoken, I'm more than offended by this after having experienced this for quite a couple of years. And with particular respect to radio engineers: At least in Germany, these are mostly electrical engineers by education. And a typical electrical engineer is supposed to have more forgotten knowledge and understanding of control theory than a CS guy is supposed to ever have heard of. Let me take the Meyer/Holzke/Sachs paper for example. It took me weeks to understand how these guys forged their results. It took me YEARS to get an understandig of mobile networks to see, that these "results" are wrong, however, they are submitted, accepted, published, so anyone is convinced: "This is correct, it's published by scientists, at least one of them holds a PhD, so the paper must be correct." It is neither correct nor science, it is bullshit. However, the public believes in this "story" and other guys than the authors are blamed when systems do not work as promissed by this paper. > For example, both seem to think that adding buffering "increases > throughput" > I do not know who is "both". I'm neither of them. When people say, increasing buffers means increasing throughput, I first of all would discriminate workload from buffers and when we talk about workload and buffers, it's always a good idea to have a look at textbooks like "Queuing systems" by Len Kleinrock. Throughput is achieved, as the word says, by "putting through" and not by "putting at". The pyramids would not be there if the slaves only putted the stones somewhere on stock near the building place - and no one would have moved the stones to their final place. > > - whereas typically it causes catastrophic failure of the control > loops involved in adaptation. > And that is much too simple. One say, buffers increase throughput. You say: buffers cause catastrophic failure. Could we agree upon: "It depends."? And that it is worthwhile to carefully look at the system of interest, if buffers can be beneficial and should be added - or if buffers are malicious and should be left out? Otherwise we would end up in having "the answer". No matter, what's the question. When you say we should stay away from thoughtless buffering, I couldn't be more with you. (And in much private conversations I pointed to the Takoma bridge disaster, where a "buffer bloat" (sic! State variables in dynamic systems can be seen as buffers for energy!) caused structural damage. And it's the very core of the congavoid paper to ensure stability (and in the very core, stability does not mean anything else as avoiding buffer bloat) by fixing a system's workload to a reasonable size. (The, not easy, question is: What is "reasonable"?) The congavoid paper does not make too much words on this issue. However: Beware of the footnote on page 2. The note on the Ljapunov equation. Stated in the terms of TCP that does mean, amongst others: By limiting the workload on the path, we limit the workload which can gather in a local buffer. There are other, more complex, implications. And that's why I posted my question to this list. One implication is: It might be beneficial to have some MBytes of workload in a TCP flow, when the path includes a geostationary satellite link from Hamburg to New York. The same workload is completely malicious when the path consists only of a GPRS link. So, may I speak frankly? God in heaven, which devil made us use one and only one congestion window for the whole path end to end? And when I recently proposed to change this in a research proposal, I got the question: "Which problem do you want to solve?" Saying this, I strongly emphasise: For the model used by JK, the congavoid paper is a stroke of genius. And for those, who see shortcomings in the congavoid paper, I say: The shortcomings don't lie in the congavoid paper but in your reading. If we carefully read the work by Jacobson and Karels and the work by Raj Jain and others from the same period of time, many of our problems would not appear new. The authors anticipated much of our problems. If we only spent the time for careful reading. "The badness lies in the brain of the reader." > > Or worse, many times the hardware and firmware on an 802.11n link will > be set so that it will retransmit the current frame over and over > (either until delivery or perhaps 255 times) before dropping the packet. > That's exactly what happens on all wireless networks to my knowledge (not only on 802.11 but in others as well, and again: Retransmission itself isn't bad. But thoughtless retransmission is evil.) And that's what's simply ignored in the paper I referred to yesterday (Herrscher, Leonhardi, Rothermel) and the paper I referred to above (Meier, Sachs, Holzke) and what's simply ignored in countless private conversations. However: You run into the same pitfall yourself! Please look at the alternative you mention: Either you retransmit the packet over and over - or you drop it. We know the saying: If you have only two alternatives, both of which are impossible, choose the third. In some cases it may be possible to adapt your system, so that further transmissions may become successful. In some cases it may be possible to change your route. I don't know - and again: It depends. However, I doubt that "retransmit the packet over and over" and "(silently) drop" the packet are the only possibilities in each and every case. So the problem is sometimes not the lack of opportunities. It's the lack of willingness to choose them. Sometimes, there is no third way. As often stated: TANSTAAFL. And again to my criticism for using only one CWND. Exactly using one CWND for a whole path (of say 70 hops ore more) means to use ONE answer fo MANY questions. And ONE solution to ANY problem. (My apologies go to IBM guys ;-)) > Such very long delays mean that the channel is heavily blocked by > traffic that slows down all the other stations whose traffic would > actually get through without retransmission. > Absolutely. We should not make the whole world suffer from our local problem. (It was part of my research proposal.) > Yet CS people and EE's are prone to say that the problem is due to > "interference", and try to arrange for "more power". > More power? Sometimes interference can be alleviated by less power! > > More power then causes other nearby networks to be slowed down (as > they have to listen for "silence" before transmitting). > I stated so, when I discussed the Herrscher, Leonhardi, Rothermel Paper yesterday. However, you don't make a difference between external noise (which may interfere with your wireless cell) or multipath interference, where your signal is split up in rays which interfere with themselves. These are different scenarios which should be treated differently. (E.g. the first one by power regulation, the second one by MIMO systems or rake receivers. Sometimes, different problems require different solutions.) In some cases, power regulation will not work. Why do not act in the other way round then? Make the cells use the same frequency range and couple the adjacent bands from, say, two "fife band" ranges to one "ten band" range and increase sending power. And then change your line coding and channel coding to a higher net data rate - and hence shorter (in a temporal sense) packets. So, you couple your cells to increase the joined capacity - and doing so you lower your network load. Could this be a way to go? Alleviate interference by increasing sending power. Sounds strange, however may work sometimes. (And it's an example for the aforementioned "third alternative".) > Thus, Detlef, we do need an improvement in terminology, but even more > in understanding. > David, is that really a contradiction? Or isn't a careful terminology helpful to improve better understanding? > The nonsense that passes for knowledge around wireless networking, > even taught by "professors of networking" is appalling. It's the > blind leading the blind. > May I put this in my signature? This is the by far the most wise sentence, I've ever read on this subject. > > I don't think graduate students in computer networking will ever be > required to learn about Poynting vectors, control theory, and wavelet > decompositions, and the ones in EE will not learn dynamic queueing > theory, distributed congestion control, and so forth. And the > information theory students will probably never use a vector signal > analyzer. > And this is perhaps even not necessary. But it is highly useful to listen to each other and be willing to get things explained by each other. We can walk around like a blinds leading blinds - or we can try to walk around adding our views. > > So the terminology and understanding issues will persist. > But it should lead to a better understanding instead of more confusion. -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de ------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20121225/800b0e77/attachment-0001.html From detlef.bosau at web.de Wed Dec 26 14:48:55 2012 From: detlef.bosau at web.de (Detlef Bosau) Date: Wed, 26 Dec 2012 23:48:55 +0100 Subject: [e2e] Delivery Times .... was Re: Bandwidth, was: Re: Free Internet & IPv6 In-Reply-To: <1356405568.01746958@apps.rackspace.com> References: <1348085253.52094.YahooMailClassic@web163003.mail.bf1.yahoo.com> <50D8EBE7.1090300@web.de> <1356405568.01746958@apps.rackspace.com> Message-ID: <50DB7ED7.5090008@web.de> Am 25.12.2012 04:19, schrieb dpreed at reed.com: > > Indeed, bandwidth is now meaningless as a term, just as "broadband" > is. Once upon a time, both referred to bounds on the frequency > components of the physical layer signal, both in wires (twisted pair, > coax, etc) and in RF. The RF bandwidth of 802.11b DSSS modulation > was about 10 MHz, whereas the bitrate achieved was about 2 Mb/sec. > Now we use OFDM modulation in 802.11n, with bandwidths of 40 MHz more > or less, but bitrates of >> 40 Mb/sec. (yes, that is mostly because > of 64-QAM, which encodes 6 bits on each subcarrier within an OFDM > "symbol"). > > What causes the 802.11n MAC protocol to achieve whatever bitrate it > achieves is incredibly complex. Interestingly, in many cases the > problem is really bad due to "bufferbloat" in the 802.11n device > designs and drivers, which causes extreme buildup of latency, which > then causes the TCP control loops to be very slow in adapting to new > flows sharing the path. > > And this refers directly to my original question. May I put it in very simple words. In mobile networks (let's include wifi there) a packet is either reliably delivered - in unpredictable time. Or it is unreliably delivered - that is possible in predictable time. Can we agree upon that? I still want to write my research proposal. However, I'm tired to get it rejected after exactly these two lines. Detlef -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de ------------------------------------------------------------------ The nonsense that passes for knowledge around wireless networking, even taught by "professors of networking" is appalling. It's the blind leading the blind. (D.P. Reed, 2012/12/25) ------------------------------------------------------------------ From detlef.bosau at web.de Thu Dec 27 01:05:36 2012 From: detlef.bosau at web.de (Detlef Bosau) Date: Thu, 27 Dec 2012 10:05:36 +0100 Subject: [e2e] Delivery Times .... was Re: Bandwidth, was: Re: Free Internet & IPv6 In-Reply-To: <1356562906.75320908@apps.rackspace.com> References: <1348085253.52094.YahooMailClassic@web163003.mail.bf1.yahoo.com> <50D8EBE7.1090300@web.de> <1356405568.01746958@apps.rackspace.com> <50DB7ED7.5090008@web.de> <1356562906.75320908@apps.rackspace.com> Message-ID: <50DC0F60.9020803@web.de> Am 27.12.2012 00:01, schrieb dpreed at reed.com: > > In mobile networks (let's include wifi there) a packet is either > reliably delivered - in unpredictable time. > Or it is unreliably delivered - that is possible in predictable time. > > That is also true of wired networks. > Absolutely. However, in wired networks packet corruption is (hopefully) that rare, that the "unreliably delivered" packets are delivered "unreliably" with p_succ= 0.9999 or something similar. (Simply spoken: Corruption loss is typically ignored.) > > It is the fundamental constraint of packet networking. At any level, > one can decide to choose either case. Rather than "unpredictable", > one should say "unbounded stochastic". > E.g. in GPRS, the standard defines certain quantiles. E.g. for 1024 bytes, we have certain delay classes: mean 0.95 quantil 1.: < 2s < 7 2.: < 15s < 75s 3.: < 75s < 375s I don't now whether "mean" refers to "average value" or "median". Each class refers to some different sdu corruption probability. (I don't have the values in mind, may be 10^-3, 10^-5, 10^-9, however 10^-9 will ever be implemented.... ;-)) If you have a look at typical simulation systems, e.g. the NS-2, wireless interfaces are assigned a certain "rate". Which implicitly assumes a more or less stationary delay. Does that make sense? Particularly, as the extremely high latency 375 s most likely refers to some "countless" repetition of packets (100 times, 1000 times....), which may indicate a situation where we should rather choose a different interface or a different route if possible. -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de ------------------------------------------------------------------ The nonsense that passes for knowledge around wireless networking, even taught by "professors of networking" is appalling. It's the blind leading the blind. (D.P. Reed, 2012/12/25) ------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20121227/d9c2c814/attachment.html From detlef.bosau at web.de Thu Dec 27 07:48:14 2012 From: detlef.bosau at web.de (Detlef Bosau) Date: Thu, 27 Dec 2012 16:48:14 +0100 Subject: [e2e] Delivery Times .... was Re: Bandwidth, was: Re: Free Internet & IPv6 In-Reply-To: <50DC0F60.9020803@web.de> References: <1348085253.52094.YahooMailClassic@web163003.mail.bf1.yahoo.com> <50D8EBE7.1090300@web.de> <1356405568.01746958@apps.rackspace.com> <50DB7ED7.5090008@web.de> <1356562906.75320908@apps.rackspace.com> <50DC0F60.9020803@web.de> Message-ID: <50DC6DBE.5050603@web.de> Am 27.12.2012 10:05, schrieb Detlef Bosau: > E.g. in GPRS, the standard defines certain quantiles. E.g. for 1024 > bytes, we have certain delay classes: > > mean 0.95 quantil > 1.: < 2s < 7 > 2.: < 15s < 75s > 3.: < 75s < 375s > > I don't now whether "mean" refers to "average value" or "median". Of course, there are reaons for these high latencies: As David noted, these may result from a huge number of retransmissions. And the difference between "mean" and the 0.95 quantil indicate a high variance, thus an application which will exploit the available "throughput", i.e. the "mean" latency, may require huge buffers - and thus see huge round trip times. Hence, the question is whether TCP as is and mobile networks are really compatible. Obviously, it's a matter of fact that there is that TCP over mobile networks is requested from the market. So the issue is to find a good match, at least compromise, between expectation and reality here. From scott.brim at gmail.com Thu Dec 27 10:53:28 2012 From: scott.brim at gmail.com (Scott Brim) Date: Thu, 27 Dec 2012 13:53:28 -0500 Subject: [e2e] Delivery Times .... was Re: Bandwidth, was: Re: Free Internet & IPv6 In-Reply-To: <50DB7ED7.5090008@web.de> References: <1348085253.52094.YahooMailClassic@web163003.mail.bf1.yahoo.com> <50D8EBE7.1090300@web.de> <1356405568.01746958@apps.rackspace.com> <50DB7ED7.5090008@web.de> Message-ID: Also allow for "partially reliable" delivery as in SCTP. On Dec 26, 2012 6:03 PM, "Detlef Bosau" wrote: > Am 25.12.2012 04:19, schrieb dpreed at reed.com: > >> >> Indeed, bandwidth is now meaningless as a term, just as "broadband" is. >> Once upon a time, both referred to bounds on the frequency components of >> the physical layer signal, both in wires (twisted pair, coax, etc) and in >> RF. The RF bandwidth of 802.11b DSSS modulation was about 10 MHz, whereas >> the bitrate achieved was about 2 Mb/sec. Now we use OFDM modulation in >> 802.11n, with bandwidths of 40 MHz more or less, but bitrates of >> 40 >> Mb/sec. (yes, that is mostly because of 64-QAM, which encodes 6 bits on >> each subcarrier within an OFDM "symbol"). >> >> What causes the 802.11n MAC protocol to achieve whatever bitrate it >> achieves is incredibly complex. Interestingly, in many cases the problem >> is really bad due to "bufferbloat" in the 802.11n device designs and >> drivers, which causes extreme buildup of latency, which then causes the TCP >> control loops to be very slow in adapting to new flows sharing the path. >> >> >> > And this refers directly to my original question. > > May I put it in very simple words. > > In mobile networks (let's include wifi there) a packet is either reliably > delivered - in unpredictable time. > Or it is unreliably delivered - that is possible in predictable time. > > Can we agree upon that? > > I still want to write my research proposal. However, I'm tired to get it > rejected after exactly these two lines. > > Detlef > > -- > ------------------------------**------------------------------**------ > Detlef Bosau > Galileistra?e 30 > 70565 Stuttgart Tel.: +49 711 5208031 > mobile: +49 172 6819937 > skype: detlef.bosau > ICQ: 566129673 > detlef.bosau at web.de http://www.detlef-bosau.de > ------------------------------**------------------------------**------ > The nonsense that passes for knowledge around wireless networking, > even taught by "professors of networking" is appalling. It's the > blind leading the blind. (D.P. Reed, 2012/12/25) > ------------------------------**------------------------------**------ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20121227/d3cfef76/attachment.html From detlef.bosau at web.de Fri Dec 28 04:11:14 2012 From: detlef.bosau at web.de (Detlef Bosau) Date: Fri, 28 Dec 2012 13:11:14 +0100 Subject: [e2e] Delivery Times .... was Re: Bandwidth, was: Re: Free Internet & IPv6 In-Reply-To: <1356644915.637229905@apps.rackspace.com> References: <1348085253.52094.YahooMailClassic@web163003.mail.bf1.yahoo.com> <50D8EBE7.1090300@web.de> <1356405568.01746958@apps.rackspace.com> <50DB7ED7.5090008@web.de> <1356562906.75320908@apps.rackspace.com> <50DC0F60.9020803@web.de> <50DC6DBE.5050603@web.de> <1356644915.637229905@apps.rackspace.com> Message-ID: <50DD8C62.1060400@web.de> Am 27.12.2012 22:48, schrieb dpreed at reed.com: > > Some LTE technical architecture folks have said to me, informally, > that LTE (unlike GPRS) was designed from the ground up for TCP/IP, > whereas GPRS was not really intended for TCP/IP. > Hm. As you said, this not quite precise. What are the differences between LTE and GPRS? And does LTE really avoid large delays? -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de ------------------------------------------------------------------ The nonsense that passes for knowledge around wireless networking, even taught by "professors of networking" is appalling. It's the blind leading the blind. (D.P. Reed, 2012/12/25) ------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20121228/ebe78af0/attachment.html From detlef.bosau at web.de Fri Dec 28 04:35:55 2012 From: detlef.bosau at web.de (Detlef Bosau) Date: Fri, 28 Dec 2012 13:35:55 +0100 Subject: [e2e] Delivery Times .... was Re: Bandwidth, was: Re: Free Internet & IPv6 In-Reply-To: <1356644915.637229905@apps.rackspace.com> References: <1348085253.52094.YahooMailClassic@web163003.mail.bf1.yahoo.com> <50D8EBE7.1090300@web.de> <1356405568.01746958@apps.rackspace.com> <50DB7ED7.5090008@web.de> <1356562906.75320908@apps.rackspace.com> <50DC0F60.9020803@web.de> <50DC6DBE.5050603@web.de> <1356644915.637229905@apps.rackspace.com> Message-ID: <50DD922B.1020808@web.de> Am 27.12.2012 22:48, schrieb dpreed at reed.com: > > Some LTE technical architecture folks have said to me, informally, > that LTE (unlike GPRS) was designed from the ground up for TCP/IP, > whereas GPRS was not really intended for TCP/IP. > > I don't know what that means, but perhaps one ought to ignore GPRS's > delay classes. > > O.k., in LTE, we don't talk about delay classes any longer ;-) We now call it "terminal classes" ;-) What I've read so far, LTE is often used as a DSL replacement, i.e. for STATIONARY users!!!! When it comes to mobility, LTE inevitably inherits essential properties of UMTS and the like. E.g. Rayleigh-fading. And therefore consequently some kind of opportunistic scheduling, which is necessary to make wireless networks affordable for the users. It may be possible that the problems are not that prominent as LTE is still yet to achieve huge numbers of customers. However, when LTE has fully reached the market, the problems are likely to be the same as in other mobile networks. (Not that political correctly spoken: Whoever said that LTE is designed for TCP, I don't buy this. The contrary is the case. The broader the range of latencies will be, the less stationary delivery times will become. As one particular problem.) -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de ------------------------------------------------------------------ The nonsense that passes for knowledge around wireless networking, even taught by "professors of networking" is appalling. It's the blind leading the blind. (D.P. Reed, 2012/12/25) ------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20121228/56ed7ef5/attachment.html From detlef.bosau at web.de Fri Dec 28 05:01:51 2012 From: detlef.bosau at web.de (Detlef Bosau) Date: Fri, 28 Dec 2012 14:01:51 +0100 Subject: [e2e] Delivery Times .... was Re: Bandwidth, was: Re: Free Internet & IPv6 In-Reply-To: <1356644915.637229905@apps.rackspace.com> References: <1348085253.52094.YahooMailClassic@web163003.mail.bf1.yahoo.com> <50D8EBE7.1090300@web.de> <1356405568.01746958@apps.rackspace.com> <50DB7ED7.5090008@web.de> <1356562906.75320908@apps.rackspace.com> <50DC0F60.9020803@web.de> <50DC6DBE.5050603@web.de> <1356644915.637229905@apps.rackspace.com> Message-ID: <50DD983F.5070004@web.de> I've just read a little bit on LTE. Certainly, the bandwidth is increased: Depending on the spectrum in use, it may not be 5 MHz (as in UMTS) but 20 MHz. As we all know Shannon-Hartley's theorem, data rate is only linearly increased by the bandwidth decrease, however, the is a logarithmic dependency on the noise. Hence, the more drastic increase of the net data rate will not be achieved by a bandwidth increase but by more aggressive line coding, e.g. 64 QAM (or even 256 QAM in the future?) instead of 16 QAM or QPSK as it is used today. In addition. MIMO techniqures are used. The good news is: Using LTE, "good" channels can be better utilized than now. The bad news is: The system dynamics will become more complex than now and TCP's congestion control, which does not work well with GPRS, will likely work even worse. May I ask a somewhat provoking question? Could it be that many of the buffer bloat problems, we frequently talk about, are not "buffer bloat" - but unhandled (or wrongly handled) congestion collapses? (And we can well say: "Corruption collaps", because both, congestion loss and corruption loss will require packets to be retransmitted and hence may cause network instability, when wrongly handled.) Detlef -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de ------------------------------------------------------------------ The nonsense that passes for knowledge around wireless networking, even taught by "professors of networking" is appalling. It's the blind leading the blind. (D.P. Reed, 2012/12/25) ------------------------------------------------------------------ From detlef.bosau at web.de Fri Dec 28 08:36:17 2012 From: detlef.bosau at web.de (Detlef Bosau) Date: Fri, 28 Dec 2012 17:36:17 +0100 Subject: [e2e] Delivery Times .... was Re: Bandwidth, was: Re: Free Internet & IPv6 In-Reply-To: <1356704890.01121623@apps.rackspace.com> References: <1348085253.52094.YahooMailClassic@web163003.mail.bf1.yahoo.com> <50D8EBE7.1090300@web.de> <1356405568.01746958@apps.rackspace.com> <50DB7ED7.5090008@web.de> <1356562906.75320908@apps.rackspace.com> <50DC0F60.9020803@web.de> <50DC6DBE.5050603@web.de> <1356644915.637229905@apps.rackspace.com> <50DD983F.5070004@web.de> <1356704890.01121623@apps.rackspace.com> Message-ID: <50DDCA81.2000302@web.de> Am 28.12.2012 15:28, schrieb dpreed at reed.com: > > Bufferbloat arises because of the lower layers' lack of congestion > signals (dropped packets) while the lower layers attempt (using large > amounts of buffering) to avoid loss (lost packets). > O.k., however this is not a contradiction to what I said! If, e.g. for increasing noise, the delivery time for packets over wireless interfaces increases, buffers may not be freed and the "path capacity" (quotes intended) drops. So, this can be one reason for buffer bloat, do you agree here? > In other words, by focusing on keeping packets alive at any cost, the > Internet loses all of its basic congestion detection. > Absolutely agreed! > For the Internet, it *really does not help* to use buffering to hide > natural channel problems - either delay or transmission errors. > Agreed. However, it may help to use buffering to compensate varying service rates. The emphasis lies on "varying". In addition: For doing so, it is *absolutely crucial* to care fore stability. > > That's because the consistent rule in the Internet is to build the > end-to-end required functionality *at the endpoints* and not in the > network. That applies to wireless as well as wired. > David, you might have guessed this: I would like to put this rule in question. I think we should care for congestion control not only at the endpoints but at certain places (which are to be defined) in the network as well. > The solution to congestion in the network is *not to allow the network > to stay congested* - which means aggressively dumping queued packets > whenever the queue builds up at any link to more than 1 packet. > Doing so might waste a lot of performance. However, in some cases, this may be necessary. Perhaps, we have to agree upon "it depends". > Paradoxical it may seem. But it's the same rule as with "garbage > collection" in large Java systems: whatever you do, don't wait until > the memory is completely full to garbage collect! That is the worst > case operating point of the system in terms of jitter and gives you > worse throughput as well. Garbage collection when the memory is about > 1/2 garbage and 1/2 good stuff is much, much better for throughput, > and garbage collecting even earlier works better for worst-case > latency and jitter. This is how one sets the "control loop" for > garbage collection wisely. > David, what is the control loop of congestion control controlling? (I sometimes think, we should have not only a second look at the congavoid paper but it is worthwile to give it even a ninth and a tenth look. I think, there is a huge confusion about what we are controlling at all!) > The same thing for network buffers - *never* let an internal queue > build up to more than 1 packet on a sustained basis. > Not on a sustained basis. However: On a controlled basis AND WITH CAREFUL KNOWLEDGE OF WHAT WE ARE DOING! Please don't mind my emphasis. I think, we agree upon the pitfalls. However, I don't want to totally stay away from them, but when we run into a pitfall, we must take great care to not only get into it but to find a way out as well. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20121228/4a63ec89/attachment.html From detlef.bosau at web.de Sat Dec 29 17:10:11 2012 From: detlef.bosau at web.de (Detlef Bosau) Date: Sun, 30 Dec 2012 02:10:11 +0100 Subject: [e2e] Delivery Times .... was Re: Bandwidth, was: Re: Free Internet & IPv6 In-Reply-To: <1356714754.081314280@apps.rackspace.com> References: <1348085253.52094.YahooMailClassic@web163003.mail.bf1.yahoo.com> <50D8EBE7.1090300@web.de> <1356405568.01746958@apps.rackspace.com> <50DB7ED7.5090008@web.de> <1356562906.75320908@apps.rackspace.com> <50DC0F60.9020803@web.de> <50DC6DBE.5050603@web.de> <1356644915.637229905@apps.rackspace.com> <50DD983F.5070004@web.de> <1356704890.01121623@apps.rackspace.com> <50DDCA81.2000302@web.de> <1356714754.081314280@apps.rackspace.com> Message-ID: <50DF9473.3010004@web.de> Perhaps, I try an answer to the public :-) Am 28.12.2012 18:12, schrieb dpreed at reed.com: > > As far as questioning the rule by controlling congestion within the > network, how would you propose to do that without also signalling to > the sources that they must back off? Somewhere a queue will fill. > To my understanding, and I appreciate correction here, we must carefully discriminate congestion/instability and performance issues here. A certain problem particularly in TCP is, that VJCC (and we're talking about VJCC, although their are numerous flavours of it, Reno, Vegas, Veno, Laminar TCP etc. etc. etc., the whole Yosemite park turned into PhD theses, no one will ever read only to protect the heads of PhD students from the cold, because the workd suffers from global warming) does a bold combination of congestion control, performance control and resource sharing. Once, a TCP flow has reached equilibrium, congestion control is quite simply achieved: We must obey the conservation principle. (So, first of all: turn off all rate controlled TCP flavours, the conservation principle is the clue to stability as the congavoid paper correctly, not to say: loud and clearly, states in the footnote on page 2. There is a terrible tong twister, this "Ljapunov"-word, however, that's, to my understanding, the crucial point in the whole thing.) Perhaps, we have to discriminate two stories now. First, and I'm not going to talkt about that now, but it is important: Of couse we can see a problem, when the system fails to reach equilibrium or the equilibrium state is lost somehow and we mast return to equilibrium state. In wireless networks, this may be e.g. a consequence of a sudden path change. The other story is that we have to find the optimum workload for equilibrium. The congavoid paper is extremely dense here and I'm still to understand many details. (I'm understanding the congavoid paper step by step for more than 10 years now and each time, I return to this paper, I understand something new. It is surely one of the densest texts I ever read.) Now, the performance of a queuing system is determined by the workload. (Not by the buffers. Although we determine the workload indirectly by buffers, limits and discarding packets.) And so the first problem is that ONE workload determines TWO criteria, i.e. a system's throughput and a system's sojourn time (wrt. TCP: RTT) as well. So perhaps, we must determine which is the criteria of interest. A performance p := throughput/RTT may be a reasonable tradeoff - however in some cases we might want not to use it. In VJCC, we assume a stationary system's capacity as well for the heuristics to determine the workload and to share the workload between competing flows. (AIMD, CWND determination, Little's theorem.) So, the first problem we will certainly encounter in mobile systems is: In mobile systems, the system's capacity is certainly anything. But stationary. So, it would be no surprise if the "determined" workload varies from one inadequate size to the other one. (And as we know from queuing systems, an inadequate workload may cause the performance to decrease dramatically. Particularly, as David stated more than once, it may cause unacceptable sojourn times.) So, I'm not fully convinced that we have a matter of back off here. But my first approach (which I consider for my research proposal) is path segmentation in order to - break up the work load in portions we can handle and in segments we can handle and MOST IMPORTANT - use adequate algorithms for workload determination. My very strong conjecture is that the workload determination scheme in VJCC will definitely not hold in paths which contain one or more mobile segments because of a non stationary capacity. - another problem is the combination of workload determination and resource sharing, particularly when we combine traffic and cross traffic with perhaps completely different round trip times - and therefore completely different time scales to react upon load and path changes. - and there are lots of other aspects here, the well known "mice and elephants" issue, the issue of non greedy sources, however I strongly think, that all these issues will finally convince us that we must break up the problem into pieces. With the particular goal to - first find local solutions for local problems (Jerry Salzer's paper), - keep local problems local (same paper). The more I think about it the more I'm convinced that it is simply nonsense to find one and only CWND for a whole TCP path consisting of perhaps 50 or 60 links. With a RTT of 600 ms because of an overloaded geostationary satellite link - and when there is a local capacity problem because of some cross traffic on link 34, we start (depending on personal preference) the whole AIMD or BIC or CUBIC scheme to lessen a 60 MByte CWND for about 500 bytes. (Next time, we want to catch a flea, we could even call the national guard.) In many cases we would not even notice the "local load issue" - in other cases there is a congestion drop and the whole (completely oversized) system starts to work, with devastating consequences. And please note: The capacity issue on link 34 is not a congestion issue - it is a capacity issue because it's a matter of resource sharing to adjust the LOCAL (!!!!) part of a flow's CWND here. A back off strategy will perhaps not work, particularly it will not react upon a local problem timely and with appropriate dynamics. Breaking up the flow into segments (and particularly breaking up the workload into segments!!!!) would offer the possibility to locally fix the problem - with adequate actions and system dynamics which are certainly much easier to handle. When we have a system with dozens of screws to turn - it's perhaps a helpful idea not to use only one (and perhaps much too big) screwdriver which in addition does not turn one screw a time - but all screws at once. From the system theory's perspective, it will perhaps become very complex to have the system parts decoupled. And we know from the past that we can encounter huge challenges by long term dependencies, sometimes people talked about "chaotic behaviour". So please, these are just my 2 cent. In no case an attempt to present a "solution" or even a part of it. In a sense, this reminds me on the discussion of routing and bridging. "We could" connect many computers in the world to one "billions of terabyte per second" Ethernet, if this existed. Perhaps without a single router. I think, we all agree that there extremely compelling reasons for not doing so. Detlef -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de ------------------------------------------------------------------ The nonsense that passes for knowledge around wireless networking, even taught by "professors of networking" is appalling. It's the blind leading the blind. (D.P. Reed, 2012/12/25) ------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20121230/6262ab4d/attachment.html From detlef.bosau at web.de Sun Dec 30 06:45:28 2012 From: detlef.bosau at web.de (Detlef Bosau) Date: Sun, 30 Dec 2012 15:45:28 +0100 Subject: [e2e] Delivery Times .... was Re: Bandwidth, was: Re: Free Internet & IPv6 In-Reply-To: <1356714754.081314280@apps.rackspace.com> References: <1348085253.52094.YahooMailClassic@web163003.mail.bf1.yahoo.com> <50D8EBE7.1090300@web.de> <1356405568.01746958@apps.rackspace.com> <50DB7ED7.5090008@web.de> <1356562906.75320908@apps.rackspace.com> <50DC0F60.9020803@web.de> <50DC6DBE.5050603@web.de> <1356644915.637229905@apps.rackspace.com> <50DD983F.5070004@web.de> <1356704890.01121623@apps.rackspace.com> <50DDCA81.2000302@web.de> <1356714754.081314280@apps.rackspace.com> Message-ID: <50E05388.7080608@web.de> Am 28.12.2012 18:12, schrieb dpreed at reed.com: > > As far as questioning the rule by controlling congestion within the > network, how would you propose to do that without also signalling to > the sources that they must back off? Somewhere a queue will fill. > > In general, we have not achieved nearly universal congestion > signalling in the routers and switches. This is what Jim Gettys, Vint > Cerf, and Van Jacobson are trying (against resistance) to do - to > stave off bufferbloat's effects. > > Bufferbloat has such a huge effect (easily measured, as I did in the > ATT cellular network a few years ago in nearly every city in the US > that I visited, when I discovered up to 4 seconds of latency with > *zero* packet loss end-to-end, which means complete service > unavailability for all data services, especially web pages). > With particular respect to that observation: As you remember, I asked for the reasons of latencies dozens of times, at least on this mailing list. And I well remember, that some years ago Dominik Kaspar presented some extreme latencies and there was a big astonishment and a long discussion how this could be. So: What's the reason for 4 seconds of latency? One reason COULD be: A mobile interface simply gets no service for 4 seconds due to opportunistic scheduling, and a simple stop n' wait TCP has a 4 seconds coffee break. Not to be misunderstood: I well see your question. However, when we talk about latencies, the first and most important task is to properly identify the reason for this latency. I deal with wireless latencies and the question for the reason for about 13 years now. And instead of concrete answers for the reason, the by far most often answer I got was pure finger pointing and hand waving. This includes statements like: "GPRS is badly implemented" or "anything will be better using LTE" or "no buffer no bloat" or similar nonsense. Perhaps, I'm bit childish in this respect, but I strongly believe what I wrote some hours ago, that we have to break the problem into pieces we can handle. With all due respect to the existing work in this area, it might be not the wisest decision to tackle a huge and incredible complex problem (and I don't know, whether system theorists are reading here in the news group, however I think the often hopeless naive manner how we CS guys tackle control theoretic problems makes them cry and giggle at the same time) with an extremely restricted number of means and tools. As I stated last night: VJCC (and derivatives) tackle three tasks: - stability, - performance, - ressource sharing. Each of these is extremely complex by itself - and we tackle it by ONE means: The one and only end 2 end congestion window. (And when I'm provoking people here: As we see, that our tool is perhaps too simple for the problem, we introduce e.g. active queue management and those things, so that our system becomes even more complex. So, when we cannot solve simple problems, let's start with complex ones, this might be easier.) When we talk about an end 2 end latency of 4 seconds without packet loss, this phenomenon may result from about a dozen reasons or so. So the first question is: What is the reason? And the next question is: How can we help it? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20121230/f6d17d18/attachment.html From detlef.bosau at web.de Sun Dec 30 14:13:03 2012 From: detlef.bosau at web.de (Detlef Bosau) Date: Sun, 30 Dec 2012 23:13:03 +0100 Subject: [e2e] Delivery Times .... was Re: Bandwidth, was: Re: Free Internet & IPv6 In-Reply-To: <1356899459.767631954@apps.rackspace.com> References: <1348085253.52094.YahooMailClassic@web163003.mail.bf1.yahoo.com> <50D8EBE7.1090300@web.de> <1356405568.01746958@apps.rackspace.com> <50DB7ED7.5090008@web.de> <1356562906.75320908@apps.rackspace.com> <50DC0F60.9020803@web.de> <50DC6DBE.5050603@web.de> <1356644915.637229905@apps.rackspace.com> <50DD983F.5070004@web.de> <1356704890.01121623@apps.rackspace.com> <50DDCA81.2000302@web.de> <1356714754.081314280@apps.rackspace.com> <50E05388.7080608@web.de> <1356899459.767631954@apps.rackspace.com> Message-ID: <50E0BC6F.9050300@web.de> Am 30.12.2012 21:30, schrieb dpreed at reed.com: > > One other point... you all probably don't know this, but shortly after > I posted my first results, Joe Touch decided that I should be "banned" > for arguing with the well-known troll, Richard Bennett, on this list. > Apperently, disagreement with a troll is not OK. I am still moderated > (are you), and my every post scrutinzed for disagreement with Joe > Touch's views, apparently. > With respect to your implicit question: To the best of my knowledge, I'm not moderated. I don't yet notice Richard Bennett, however I don't know, whether you implicitly would like to call me a troll here. If so, I couldn't help it. However, this shouldn't be the way, we treat each other. What your disagreements with Joe Touch is concerned: I think, you should discuss this with Joe Touch. > > I did not report any of my further experimental results on this list > for that reason. I discussed them in other fora - ones where Richard > Bennett could not disrupt conversations with his brand of > disparagement, mostly with people who could do something about the > issue (like Jim Gettys and folks in the DOCSIS world). > I never put in question your experimental results. Why should I? When I ask questions to your results, it is my intention to understand them. > That could be why you have not seen further mention, very likely. > On the one hand, you well have my personal mail address, on the other hand, the situation you describe is a bit embarrassing. And I'm a bit unsure about how to react. (And I have to ask for some degree of tolerance here because English is not my first language and so I may well have missed quite some allusion or connotation "between the lines". If so, I have to apologize, I do not want to offend anybody.) > The results of the vast Netalyzr measurements in their dataset > confirmed my observations about multiple seconds of uplink buffering > being common,, as did others' measurements. The bufferbloat reduction > effort is now going forward based on Gettys, Jacobson, and Nichols > work, with Vint Cerf's assistance. > It is surely not my intention to criticize this work. At least, as I can partly understand your frustration. In an earlier research project of mine, I pointed to the latencies in GPRS and no one believed my, anything was whitewashed and I was ridiculed at. To a certain degree, this still happens today. This is particularly difficult when talking in foreign languages. (Not only in German an English. I'm born in lower saxony. And moved to Stuttgart some years ago. For lower saxons and swabians it well holds true what an austrian comedian once said about germans and swabians: What seperates the lower saxons from the swabians is the common language.)(At least for people from Hannover and Stuttgart, there are similarities. When you put together people from rural areas, you need an interpreter.) > It's very possible that Joe will not allow this message through. > However, it is possible that he might. If so, that's great. My posts > are still moderated, however, perhaps because Richard Bennett still is > viewed as an authority beyond his knowledge and experience. > I did not read your arguments with Richard Bennett and I don't think it will help anybody if I woule make comments on this issue. Detlef -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de ------------------------------------------------------------------ The nonsense that passes for knowledge around wireless networking, even taught by "professors of networking" is appalling. It's the blind leading the blind. (D.P. Reed, 2012/12/25) ------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20121230/1eddc7a5/attachment.html From detlef.bosau at web.de Sun Dec 30 14:53:04 2012 From: detlef.bosau at web.de (Detlef Bosau) Date: Sun, 30 Dec 2012 23:53:04 +0100 Subject: [e2e] Delivery Times .... was Re: Bandwidth, was: Re: Free Internet & IPv6 In-Reply-To: <1356894324.11712120@apps.rackspace.com> References: <1348085253.52094.YahooMailClassic@web163003.mail.bf1.yahoo.com> <50D8EBE7.1090300@web.de> <1356405568.01746958@apps.rackspace.com> <50DB7ED7.5090008@web.de> <1356562906.75320908@apps.rackspace.com> <50DC0F60.9020803@web.de> <50DC6DBE.5050603@web.de> <1356644915.637229905@apps.rackspace.com> <50DD983F.5070004@web.de> <1356704890.01121623@apps.rackspace.com> <50DDCA81.2000302@web.de> <1356714754.081314280@apps.rackspace.com> <50E05388.7080608@web.de> <1356894324.11712120@apps.rackspace.com> Message-ID: <50E0C5D0.2060901@web.de> Am 30.12.2012 20:05, schrieb dpreed at reed.com: > > I would have loved to disclose what was causing the ATT 4 second > latency in detail. However, proprietary embarassment at having > deployed a system that was behaving like crap throughout the world > made it impossible. I would have been embarassed to be chief of > network operations or chief of contracting for ATT, and ATT preferred > not to tell me anything other than that "they had confirmed my > observations" after a period where they believed I was somehow not > measuring the right thing. > I do not doubt this observation. Why should I? However, it would be helpful to have more details here. If we don't have them, we can't help it, we have to come along with this situation. And perhaps, there is a way for doing so. -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de ------------------------------------------------------------------ The nonsense that passes for knowledge around wireless networking, even taught by "professors of networking" is appalling. It's the blind leading the blind. (D.P. Reed, 2012/12/25) ------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20121230/8e9dfb22/attachment.html