From detlef.bosau at web.de Fri Apr 6 17:34:42 2007 From: detlef.bosau at web.de (Detlef Bosau) Date: Sat, 07 Apr 2007 02:34:42 +0200 Subject: [e2e] Once again PF scheduling and TCP Message-ID: <4616E722.3070402@web.de> Hi. To my understanding, there exist basically two possible approaches for proportional fair scheduling in wireless networks which differ in the update of the EWMA filter which estimates the average throughput for a flow. The one approch updates the average based on the service rate a user is _offered_, the second approach updates the average based on the service rate a user acutaly _uses_, i.e. if the user does not get a time slot the average is updated by 0. As far as I see, the second approach is widely used. Does someone happen to know the reason for this? In addition, the the constant alpha used in the EWMA filter R(i+1) = (1-alpha) * R(i) + alpha * R(i) is set to 1/1000 in all the papers I read so far. I?m not quite sure, whether this is due to some divine inspiration or whether 1/1000 is some magic number ;-) However, when alpha is set to 1, the average rate would be close to the actual rate and therefore PF scheduling would have no effect. On the other hand, when alpha is chosen extremely small, sudden changes in the channel quality can lead to large delay spikes for a user. In some simulations, I made during the last days, I only considered two terminals attached to the same base station and I used a constant BLER. I started TCP flows synchronously for both terminals in one simulation and with a temporal offset in another. When I started both flows with a large temporal gap, which may perfectly occur in reality, and when I chose alpha vera small (1/10000), the considered TCP flows did not achieve the same throughput in the long run, but converged at the same _cumulative_ _goodput_. The flow that started earlier suffered from large delay spikes when the second flow started and even in recovery phase the flows suffered larger delay spikes than with first come first serve scheduling. I indentedly leave out all the simulation details here, because I?m primarily interested in two questions: 1.: Why is the second of the two update variants typically used? (Or am I wrong there?) 2.: What?s the rational for the constant alpha = 1/1000, which is obviously chosen without any consideration of bandwidth, round trip time, buffer capacity etc.? It?s interesting that, assumed I don?t have a mistake in my simulations, in an environment where two users suffer from a constant _and_ _identical_ (!) error rate proportional fair and first come first serve scheduling lead to dramaticly different results. Ideally, both scheduling algorithms should behave identically under these circumstances. Particularly, the notion of fairness appears to be different: FCFS leads to rate fairness, PF leads to a fair cumulative goodput. Detlef From almeroth at cs.ucsb.edu Mon Apr 9 17:08:58 2007 From: almeroth at cs.ucsb.edu (Kevin C Almeroth) Date: Mon, 9 Apr 2007 17:08:58 -0700 (PDT) Subject: [e2e] CFP for the ACM/Usenix IMC Workshop on Wireless Measurement Message-ID: *************** CALL FOR PAPERS *************** The IMC Workshop on Internet Measurement for Wireless Networks (IM4WiN 2007) October 23, 2007 San Diego, California http://im4win.cs.ucsb.edu/ The International Workshop on Internet Measurement for Wireless Networks (IM4WiN) is the first workshop to be associated with the Internet Measurement Conference (IMC).In the tradition of IMC, the focus is on Internet measurement and analysis with the goal that papers contribute to the current understanding of how to collect or analyze Internet measurements,or give insight into how the Internet behaves. IM4WiN narrows this focus and goal to apply specifically to wireless networks. The focus of IM4WiN is on measurement and analysis of wireless networks that are already part of the Internet or are planned to be eventually connected. Within this scope, IM4WiN is interested in papers whose primary focus is measurement and/or analysis of data with the goal that this activity leads to meaningful understanding of important network properties and/or new protocols, systems, technology, and/or best practices. Papers that fall outside of this scope will not be accepted. Examples of good topics with the IM4WiN scope include: * Challenges in heterogeneous wireless networks (3G, WiFi, Wimax) * Benchmarks for wireless algorithms, protocols and applications * Operational experience concerning wireless network performance * Prediction and inference of user access, demand and mobility * Challenges with wireless measurements * Experimental (in)validation of wireless network assumptions * Metrics for wireless network performance evaluation * Wireless network troubleshooting techniques and recommendations * Experience with building/designing/expanding wireless networks * Description of tools for building and/or managing test beds * Techniques for improving experiment repeatability * Techniques for validating wireless test bed results * Measurement-based guidelines for network design * Wireless security * Wireless vehicular networks * Wireless networking as infrastructure in developing regions * Energy efficient protocols and design IM4WiN is seeking up to 6 two-column pages, formatted exactly to the requirements specified on the IMC/IM4WiN web page, and submitted according to the instructions contained therein. Important dates for IM4WiN are: * Registration: July 20, 2007 (11:59 EDT) * Submission: July 27, 2007 (11:59 EDT) * Notification: September 3, 2007 * Camera Ready: September 21, 2007 (11:59 EDT) For more information see http://im4win.cs.ucsb.edu/cfp.html, or contact the Workshop Chairs: * Dina Papagiannaki (Intel Research) * Kevin Almeroth (UC-Santa Barbara) From msaqibilyas74 at yahoo.co.uk Wed Apr 11 00:32:37 2007 From: msaqibilyas74 at yahoo.co.uk (Saqib Ilyas) Date: Wed, 11 Apr 2007 08:32:37 +0100 (BST) Subject: [e2e] iBGP session break In-Reply-To: <4616E722.3070402@web.de> Message-ID: <347200.48426.qm@web25408.mail.ukl.yahoo.com> Greetings everyone My question is: Is it possible for an iBGP session to break even when the underlying IP topology is not partitioned? We would expect that IGP maintains connectivity at the IP layer, and even in case of a failure in the network that doesnt partition the topology, the IGP should be able to quickly converge to a new configuration for paths between every possible pair of nodes. This should result in, perhaps, a few dropped TCP packets for the iBGP session, but not a session break. Would it, then still be possible for an iBGP session to break and blackholes to consequently result? Regards Muhammad Saqib Ilyas Assistant Professor Department of Computer and Information Systems Engineering NED University of Engineering and Technology, Karachi, Pakistan http://www.saqibilyas.info Graduate Student, LUMS Country Leader, INETA Pakistan Microsoft Most Valuable Professional - C++ --------------------------------- Yahoo! Answers - Got a question? Someone out there knows the answer. Tryit now. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20070411/b51f4cea/attachment.html From anoop at brocade.com Wed Apr 11 11:21:44 2007 From: anoop at brocade.com (Anoop Ghanwani) Date: Wed, 11 Apr 2007 11:21:44 -0700 Subject: [e2e] iBGP session break In-Reply-To: <347200.48426.qm@web25408.mail.ukl.yahoo.com> Message-ID: <39BA3BC178B4394DB184389E88A97F8C0212FE63@hq-exch-1.corp.brocade.com> ________________________________ From: end2end-interest-bounces at postel.org [mailto:end2end-interest-bounces at postel.org] On Behalf Of Saqib Ilyas Sent: Wednesday, April 11, 2007 12:33 AM To: end2end-interest at postel.org Subject: [e2e] iBGP session break Greetings everyone My question is: Is it possible for an iBGP session to break even when the underlying IP topology is not partitioned? We would expect that IGP maintains connectivity at the IP layer, and even in case of a failure in the network that doesnt partition the topology, the IGP should be able to quickly converge to a new configuration for paths between every possible pair of nodes. This should result in, perhaps, a few dropped TCP packets for the iBGP session, but not a session break. Would it, then still be possible for an iBGP session to break and blackholes to consequently result? It is certainly possible depending on the configuration. BGP uses hold and keep-alive timers. If a session has its hold timer expire because of not receiving a keepalive, then the session will be terminated, even though TCP would not normally have torn down the connection on its own. In the typical case (hold timer 180 sec, keep alive timer 60 sec), you probably wouln't lose the peering while the IGP is reconverging. But if these timers are set very low, then you might. Anoop -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20070411/af882843/attachment.html From dpsmiles at MIT.EDU Fri Apr 13 20:10:23 2007 From: dpsmiles at MIT.EDU (Durga Prasad Pandey) Date: Fri, 13 Apr 2007 23:10:23 -0400 Subject: [e2e] Simulator for wireless network In-Reply-To: <39BA3BC178B4394DB184389E88A97F8C0212FE63@hq-exch-1.corp.brocade.com> References: <39BA3BC178B4394DB184389E88A97F8C0212FE63@hq-exch-1.corp.brocade.com> Message-ID: What would be considered the best network simulator(s) for wireless networks, particularly for TCP experiments? Durga From jeroen at unfix.org Sat Apr 14 06:17:34 2007 From: jeroen at unfix.org (Jeroen Massar) Date: Sat, 14 Apr 2007 14:17:34 +0100 Subject: [e2e] Simulator for wireless network In-Reply-To: References: <39BA3BC178B4394DB184389E88A97F8C0212FE63@hq-exch-1.corp.brocade.com> Message-ID: <4620D46E.5080509@spaghetti.zurich.ibm.com> Durga Prasad Pandey wrote: > What would be considered the best network simulator(s) for wireless > networks, particularly for TCP experiments? A large amount (>40) old laptops spread around a site. Don't simulate, use real live setups. You can of course use NS-2 or play around with Dummynet/netem and so on but the results are just how you configure the software, not what it actually will be. More importantly it of course all depends on exactly what you want to measure. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 311 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20070414/e668be3d/signature.bin From detlef.bosau at web.de Sat Apr 14 14:03:07 2007 From: detlef.bosau at web.de (Detlef Bosau) Date: Sat, 14 Apr 2007 23:03:07 +0200 Subject: [e2e] Simulator for wireless network In-Reply-To: <4620D46E.5080509@spaghetti.zurich.ibm.com> References: <39BA3BC178B4394DB184389E88A97F8C0212FE63@hq-exch-1.corp.brocade.com> <4620D46E.5080509@spaghetti.zurich.ibm.com> Message-ID: <4621418B.2090009@web.de> Jeroen Massar wrote: > Durga Prasad Pandey wrote: > >> What would be considered the best network simulator(s) for wireless >> networks, particularly for TCP experiments? >> > > A large amount (>40) old laptops spread around a site. > > Don't simulate, use real live setups. Unfortunately, that?s not always possible. In addition, there are always two ways to produce wrong results. The first is: Simulate. As you never know, what you?re simulating, your results will be wrong for sure. The second is: Conduct real experiments. As you never know, what you?re really doing, your results will be wrong for sure. So, the best way is, and somewhere I heard this were an old jiddish saying: If you have only two impossible choices, choose the third. So, in my opinion, you should have a very precise idea what you want to find out, either by real experiments or by simulation. Some questions are: - are you interested in 802.11 networks? - are you interested in cellular networks? - is mobility (beyond pedestrian) allowed in your network? - which design questions are not yet fully discussed? I?m writing an RLP agent for the NS2 myself at the moment and I have much more questions than answers here. And I?m often quite upset, when I read "papers" which refer to "well known simulators" and present some funny tables and columns of numbers, called "results" and it?s in fact not even clear, which question is actually answered. One basic lessen, I?ve always learned from dealing with mobile networks / wireless networks and the like: Even the best answer is at least as bad as the question. Why I choose the NS2: It?s quite easy. I?m quite familiar with the NS2 and it?s widely accepted. And because I?m quite familiar with the NS2, it?s quite easy for me to add new classes and protocols there and I?m well aware of a huge number of pitfalls which are around nearly each corner. E.g. the first time, you get a null pointer exception or segmentation violation or something like that will cause you a nightmare of debugging the code day and night in the debugger - o.k., this afternoon I consumed a "one way event" with delete instead of free, but after some hours, I remembered I did something simular some years ago and looked at my own old source code - which solved the problem. (As you can imagine, I got some funny error messages before ;-)) If you?re completely new to simulation and have the time, you will perhaps start with the NS 3. I don?t know. But first of all: You should make perfectly clear, what you want to simulate and what?s your precise question. Because good questions are often more than half the answer. Detlef -- Detlef Bosau Galileistrasse 30 70565 Stuttgart Mail: detlef.bosau at web.de Web: http://www.detlef-bosau.de Mobile: +49 172 681 9937 From uma.shanker at kcl.ac.uk Sat Apr 14 15:40:39 2007 From: uma.shanker at kcl.ac.uk (U.Shanker) Date: Sat, 14 Apr 2007 23:40:39 +0100 Subject: [e2e] Simulator for wireless network In-Reply-To: <4621418B.2090009@web.de> References: <39BA3BC178B4394DB184389E88A97F8C0212FE63@hq-exch-1.corp.brocade.com> <4620D46E.5080509@spaghetti.zurich.ibm.com> <4621418B.2090009@web.de> Message-ID: <46215867.9040406@kcl.ac.uk> Detlef Bosau wrote: > Jeroen Massar wrote: >> Durga Prasad Pandey wrote: >> >>> What would be considered the best network simulator(s) for wireless >>> networks, particularly for TCP experiments? >>> >> >> A large amount (>40) old laptops spread around a site. >> >> Don't simulate, use real live setups. > > Unfortunately, that?s not always possible. Agreed > > In addition, there are always two ways to produce wrong results. > > The first is: Simulate. As you never know, what you?re simulating, > your results will be wrong for sure. Interesting. But probably I just want effect of one or other parameters on the whole system. In that case, simulation is the best. > The second is: Conduct real experiments. As you never know, what > you?re really doing, your results will be wrong for sure. > > So, the best way is, and somewhere I heard this were an old jiddish > saying: If you have only two impossible choices, choose the third. What about taking some real network data and using simulations based on that. We use this using Opnet modeler etc. I think this is one of the best approach. > > So, in my opinion, you should have a very precise idea what you want > to find out, either by real experiments or by simulation. > Some questions are: > > - are you interested in 802.11 networks? > - are you interested in cellular networks? > - is mobility (beyond pedestrian) allowed in your network? > - which design questions are not yet fully discussed? > > I?m writing an RLP agent for the NS2 myself at the moment and I have > much more questions than answers here. > And I?m often quite upset, when I read "papers" which refer to "well > known simulators" and present some funny tables and columns of > numbers, called "results" and it?s in fact not even clear, which > question is actually answered. > > One basic lessen, I?ve always learned from dealing with mobile > networks / wireless networks and the like: > Even the best answer is at least as bad as the question. > > Why I choose the NS2: It?s quite easy. I?m quite familiar with the NS2 > and it?s widely accepted. And because I?m quite familiar with the NS2, > it?s quite easy for me to add new classes and protocols there and I?m > well aware of a huge number of pitfalls which are around nearly each > corner. E.g. the first time, you get a null pointer exception or > segmentation violation or something like that will cause you a > nightmare of debugging the code day and night in the debugger - o.k., > this afternoon I consumed a "one way event" with delete instead of > free, but after some hours, I remembered I did something simular some > years ago and looked at my own old source code - which solved the > problem. > (As you can imagine, I got some funny error messages before ;-)) I think, here you made very good point. I tried ns2 and spend most of the time between understand the whole NS2 system and debugging between C++ and otcl code. Finally I moved to the OPNET (free for the universities !). It really solved most of the my problems and I was just able to concentrate on simulation only. But if somebody can master a tool like NS2, then better to use that. I know there a big ns2 community and forums is quite useful. > > If you?re completely new to simulation and have the time, you will > perhaps start with the NS 3. I don?t know. > > But first of all: You should make perfectly clear, what you want to > simulate and what?s your precise question. > Because good questions are often more than half the answer. > > Detlef > Finally, as Detlaf said, it will really depend what exactly you want to do. Want to see effects of some standard parameters within the complex WLAN/UMTS/WIMAX environment, then OPNET could be very fast in providing results. If want to do changed in the standard TCP implementations together with WLAN etc, then may be NS2 will be faster. Looking for the complex environment and some changes in the TCP, then you have to take the time and probably use the OPNET. I was really very fast with NS2 and TCP and WLAN simulation. But when it comes to the UMTS and WiMAX etc together with TCP/WLAN then it appeared that, I have to move back from ns2 2.29 to 2.27, as UMTS implementation was based on the older NS2 version and so on. If you plan to spend next few years with this kind of simulations work then probably its worth start using NS2/NS3. -- regards, Uma Shanker, PhD Student, Center for Telecommunications Research King's College London, Strand, London WC2R 2LS, UK. Tel: +44-20-7848-2889 Email: uma.shanker(at)kcl.ac.uk From giuseppe.bianchi at uniroma2.it Sat Apr 14 17:15:36 2007 From: giuseppe.bianchi at uniroma2.it (Giuseppe Bianchi) Date: Sun, 15 Apr 2007 02:15:36 +0200 Subject: [e2e] Simulator for wireless network In-Reply-To: <46215867.9040406@kcl.ac.uk> References: <39BA3BC178B4394DB184389E88A97F8C0212FE63@hq-exch-1.corp.brocade.com> <4620D46E.5080509@spaghetti.zurich.ibm.com> <4621418B.2090009@web.de> <46215867.9040406@kcl.ac.uk> Message-ID: <46216B6000000265@relay-pt1.poste.it> (added by postmaster@poste.it) At 00.40 15/04/2007, U.Shanker wrote: >Detlef Bosau wrote: >>Jeroen Massar wrote: >>>Durga Prasad Pandey wrote: >>> >>>>What would be considered the best network simulator(s) for wireless >>>>networks, particularly for TCP experiments? >>>> >>> >>>A large amount (>40) old laptops spread around a site. >>> >>>Don't simulate, use real live setups. >> >>Unfortunately, that?s not always possible. >Agreed And don't neglect the fact that, at least for 802.11 networks (the area which I'm experimentally more confident), there is a strong dependence on the network cards / Drivers / OSs employed. For at least two reasons (at least = limiting to what I'm personally aware of): 1. it is not granted that ALL cards will exactly behave as specified by the 802.11 standard (e.g. some use different CWmin, different EIFS, in some cases odd behavior do emerge e.g. because of possible implementation issues) 2. they may also employ proprietary algorithms, either expected (such as rate adaptation) or, and this is the case that may really play havoc with your experiments, unexpected (e.g. one ongoing finding is that some cards seem to use undocumented proprietary power control solutions which you would not nearly expect from a wire-powered device!). This implies that, in order to have a reasonable confidence that the experimental trial is meaningful (at least from a qualitative point of view, e.g., to assess e.g. dependence from a set of system parameters), you have to use homogeneous systems, and it is quite costly to deploy more than a few identical boards/PCs, with identical card model and driver version... Another possibility is to repeat the experiment with different HW/SW and HOPE that results are the same. Not only this doubles the cost and labor, but in many cases this is not even technically possible (e.g. when your solution uses some driver-level mechanism or requires driver modification). In any case, some care (and, most important, the understanding if the hardware/software you are using shows some odd behavior) is needed before taking conclusions, especially in stressful conditions (e.g. many terminals, outdoor links). Giuseppe. From craig at aland.bbn.com Sat Apr 14 18:08:57 2007 From: craig at aland.bbn.com (Craig Partridge) Date: Sat, 14 Apr 2007 21:08:57 -0400 Subject: [e2e] Simulator for wireless network In-Reply-To: Your message of "Fri, 13 Apr 2007 23:10:23 EDT." Message-ID: <20070415010857.DD2FC123842@aland.bbn.com> >What would be considered the best network simulator(s) for wireless >networks, particularly for TCP experiments? You've asked a tough question. Here's my sense of the current world: * reviewers of papers generally don't trust any publicly available simulator to give accurate predictions of wireless results, except in very carefully crafted scenarios (and often not then -- I've had papers rejected due to simulation concerns even when I could show that the simulation issues had been addressed -- there's that much concern). * there exist simulators that can be trusted -- they've been verified to have results that match what is seen in the wild -- but they are proprietary. The simulator I know of has two useful features: it runs the same code in simulation as it does on the actual radios and it emulates the wireless communications environment (e.g. signal propagation). * if you want repeatable experiments that have some grounding in reality you'd do best to use an environment like Emulab's 802.11 testbed. Hope that's useful! Craig From hgs at cs.columbia.edu Sat Apr 14 20:03:20 2007 From: hgs at cs.columbia.edu (Henning Schulzrinne) Date: Sat, 14 Apr 2007 23:03:20 -0400 Subject: [e2e] Simulator for wireless network In-Reply-To: <20070415010857.DD2FC123842@aland.bbn.com> References: <20070415010857.DD2FC123842@aland.bbn.com> Message-ID: <377EF052-ECA9-438F-85DA-4421B6311CE0@cs.columbia.edu> For 802.11, we'll have a paper in Infocom 2007 that compares simulation results and real-world (ORBIT testbed) measurements. There are indeed numerous small differences that are either not modeled correctly in common simulators or just not specified, even beyond RF issues. On Apr 14, 2007, at 9:08 PM, Craig Partridge wrote: > >> What would be considered the best network simulator(s) for wireless >> networks, particularly for TCP experiments? > > You've asked a tough question. Here's my sense of the current world: > > * reviewers of papers generally don't trust any publicly available > simulator to give accurate predictions of wireless results, > except > in very carefully crafted scenarios (and often not then -- I've > had papers rejected due to simulation concerns even when I could > show that the simulation issues had been addressed -- there's > that > much concern). > > * there exist simulators that can be trusted -- they've been > verified > to have results that match what is seen in the wild -- but > they are > proprietary. The simulator I know of has two useful > features: it > runs the same code in simulation as it does on the actual > radios and > it emulates the wireless communications environment (e.g. signal > propagation). > > * if you want repeatable experiments that have some grounding > in reality > you'd do best to use an environment like Emulab's 802.11 > testbed. > > Hope that's useful! > > Craig From awo at ieee.org Sun Apr 15 02:57:58 2007 From: awo at ieee.org (Adam Wolisz) Date: Sun, 15 Apr 2007 11:57:58 +0200 Subject: [e2e] Simulator for wireless network In-Reply-To: <4621F23C.2060404@ieee.org> References: <39BA3BC178B4394DB184389E88A97F8C0212FE63@hq-exch-1.corp.brocade.com> <4620D46E.5080509@spaghetti.zurich.ibm.com> <4621418B.2090009@web.de> <46215867.9040406@kcl.ac.uk> <46216B6000000265@relay-pt1.poste.it> (added by postmaster@poste.it) <4621F23C.2060404@ieee.org> Message-ID: <4621F726.3020307@ieee.org> > ALl, > Giuseppe has addressed a very important point. > > In fact the following question is a basic one: what is to be > investigated - an ideal behavior of the envisioned, > precisely defined solution - or THE behavior of really deployed products? > > In the WINTECH 2006 workshop The First ACM International Workshop on > Wireless Network Testbeds, Experimental evaluation and > CHaracterization - one of the MOBICOM 2006 workshops - > a very interesting paper presents > "An Empirical ANalysis of Heterogeneity in IEEE 802.11 MAC protocol > implementations and it implications" > > Surprisingly enough, besides of a long list of differences which are > to be expected _ e.g. rate adaptation > algorithms are NOT defined by the standard, propreitary solutions have > to be used! - also > very clear violations of the standard have been observed within > products of major manufactureres. > > In particular the list of observed differences (and violations of the > standard!) has been given, > along with a demonstration, that due to this differences unfairness in > bandwidth sharing exists among terminals > using products of different manufactures. And the differences ARE > SIGNIFICANT! > > So the question: throughput of an 802.11 is in fact unspecified - > sorry.... > > On the other hand : throughput of an 802.11 implementation by Company > XXX model YYYY from August 200z > is probably not what one is necessarily looking at.... > or perhaps exactly what one is looking at! > > Best > adam wolisz > > > > Giuseppe Bianchi wrote: > >> At 00.40 15/04/2007, U.Shanker wrote: >> >>> Detlef Bosau wrote: >>> >>>> Jeroen Massar wrote: >>>> >>>>> Durga Prasad Pandey wrote: >>>>> >>>>>> What would be considered the best network simulator(s) for wireless >>>>>> networks, particularly for TCP experiments? >>>>>> >>>>> >>>>> A large amount (>40) old laptops spread around a site. >>>>> >>>>> Don't simulate, use real live setups. >>>> >>>> >>>> Unfortunately, that?s not always possible. >>> >>> Agreed >> >> >> And don't neglect the fact that, at least for 802.11 networks (the >> area which I'm experimentally more confident), there is a strong >> dependence on the network cards / Drivers / OSs employed. For at >> least two reasons (at least = limiting to what I'm personally aware >> of): >> >> 1. it is not granted that ALL cards will exactly behave as specified >> by the 802.11 standard (e.g. some use different CWmin, different >> EIFS, in some cases odd behavior do emerge e.g. because of possible >> implementation issues) >> >> 2. they may also employ proprietary algorithms, either expected (such >> as rate adaptation) or, and this is the case that may really play >> havoc with your experiments, unexpected (e.g. one ongoing finding is >> that some cards seem to use undocumented proprietary power control >> solutions which you would not nearly expect from a wire-powered >> device!). >> >> This implies that, in order to have a reasonable confidence that the >> experimental trial is meaningful (at least from a qualitative point >> of view, e.g., to assess e.g. dependence from a set of system >> parameters), you have to use homogeneous systems, and it is quite >> costly to deploy more than a few identical boards/PCs, with identical >> card model and driver version... Another possibility is to repeat the >> experiment with different HW/SW and HOPE that results are the same. >> Not only this doubles the cost and labor, but in many cases this is >> not even technically possible (e.g. when your solution uses some >> driver-level mechanism or requires driver modification). In any case, >> some care (and, most important, the understanding if the >> hardware/software you are using shows some odd behavior) is needed >> before taking conclusions, especially in stressful conditions (e.g. >> many terminals, outdoor links). >> >> Giuseppe. >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20070415/ba608b2c/attachment-0001.html From keshav at uwaterloo.ca Sun Apr 15 07:18:13 2007 From: keshav at uwaterloo.ca (S. Keshav) Date: Sun, 15 Apr 2007 10:18:13 -0400 Subject: [e2e] Simulator for wireless network In-Reply-To: References: Message-ID: <4AB0C12D-B135-4A9F-8452-7A979F51C4F4@uwaterloo.ca> Durga, The discussions on this topic should convince you, I hope, that before using simulations, their role has to be clearly understood. For physical systems, such as planes, cars, and sailboats, the primary operational parameters are the laws of physics, which can be modeled to as great a degree of accuracy as desired. In other words, I can overlay a 2D or 3D grid on the underlying system and apply the laws of physics at each grid point. This is why it's possible to accurately design physical systems from computer simulations. For computer systems, where a single line of code can completely change the behavior of the system, one has to confront the fact that no simulation is ever going to be accurate. As has been pointed out already, the issue is not just of radio propagation modeling, which is hard enough, but the problem is that there are many layers of software that intervene from the receipt of a radio signal and a user- perceptible effect. A slight change in any of these can materially affect the result. For instance, a slight change in the card firmware can change the way in which packets are handed to the driver, which can change the timing at which packets are received by an application, which may result in user-perceptible audio effects for VOIP over WLAN. It is practically impossible to model these with any accuracy, and even if you do, a patch to the firmware, driver, OS, or application will invalidate your results. This is the reason why 'proof by simulation', for computer systems, at least, is farcical. Not only are simulators known to be buggy, but they are also simulating a system that is too loosely coupled to be adequately modeled. So, does this mean that simulation is useless? Not really. Simulations are useful in helping to form intuitions about the underlying system. They can also help explore the parameter space systematically. But, one has to realize that it is a coarse tool, and necessarily so. As long as you go in with your eyes open, simulations are a reasonable first step (but only the first step). keshav From detlef.bosau at web.de Sun Apr 15 12:15:14 2007 From: detlef.bosau at web.de (Detlef Bosau) Date: Sun, 15 Apr 2007 21:15:14 +0200 Subject: [e2e] Simulator for wireless network In-Reply-To: <4621F726.3020307@ieee.org> References: <39BA3BC178B4394DB184389E88A97F8C0212FE63@hq-exch-1.corp.brocade.com> <4620D46E.5080509@spaghetti.zurich.ibm.com> <4621418B.2090009@web.de> <46215867.9040406@kcl.ac.uk> <46216B6000000265@relay-pt1.poste.it> (added by postmaster@poste.it) <4621F23C.2060404@ieee.org> <4621F726.3020307@ieee.org> Message-ID: <462279C2.3090203@web.de> Adam Wolisz wrote: > >> ALl, >> Giuseppe has addressed a very important point. >> >> In fact the following question is a basic one: what is to be >> investigated - an ideal behavior of the envisioned, >> precisely defined solution - or THE behavior of really deployed >> products? Exactly. And that?s why it?s so important to have the question well put. And when we investigate the behaviour of a deployed product, we practically investigate the behaviour of _exactly_ _that_ deployed product - which may well be subject to change without notice (as it is written in nearly each manual of any appliance you can buy). Standard violation included, as you wrote later in your post. >> >> In the WINTECH 2006 workshop The First ACM International Workshop on >> Wireless Network Testbeds, Experimental evaluation and >> CHaracterization - one of the MOBICOM 2006 workshops - >> a very interesting paper presents >> "An Empirical ANalysis of Heterogeneity in IEEE 802.11 MAC protocol >> implementations and it implications" >> >> Surprisingly enough, besides of a long list of differences which are >> to be expected _ e.g. rate adaptation >> algorithms are NOT defined by the standard, propreitary solutions >> have to be used! - also >> very clear violations of the standard have been observed within >> products of major manufactureres. >> >> In particular the list of observed differences (and violations of the >> standard!) has been given, >> along with a demonstration, that due to this differences unfairness >> in bandwidth sharing exists among terminals >> using products of different manufactures. And the differences ARE >> SIGNIFICANT! >> One important question is always the objective of a simulation: - Are we interested in whether a proposed mechanism / standard works fine? Then we should so state and then the question is a structural one and not a technological one. To my understanding, this is basically the research perspective. - Are we interested in whether a certain appliance / device / implementation complies to a standard, or whether a proposed standard is beyond actual technological limitations, then the question is a technological one. That?s bascially the development perspective. Technological limitations can well influence the standards, IIRC a prominent example is the inter frame gap in Ethernet which was due to the fact that early Ethernat adapters could not switch faster from the transmission mode to the receiver mode. Detlef -- Detlef Bosau Galileistrasse 30 70565 Stuttgart Mail: detlef.bosau at web.de Web: http://www.detlef-bosau.de Mobile: +49 172 681 9937 From detlef.bosau at web.de Sun Apr 15 12:26:08 2007 From: detlef.bosau at web.de (Detlef Bosau) Date: Sun, 15 Apr 2007 21:26:08 +0200 Subject: [e2e] Simulator for wireless network In-Reply-To: <4AB0C12D-B135-4A9F-8452-7A979F51C4F4@uwaterloo.ca> References: <4AB0C12D-B135-4A9F-8452-7A979F51C4F4@uwaterloo.ca> Message-ID: <46227C50.9000700@web.de> S. Keshav wrote: > > > This is the reason why 'proof by simulation', for computer systems, at > least, is farcical. Not only are simulators known to be buggy, but > they are also simulating a system that is too loosely coupled to be > adequately modeled. Is a "proof by implementation" is better? I don?t think so. Implementations are known to be buggy. Implementations are known to not behave as expected. ... However, this could lead to a somewhat useless debate on the topic: "What is a proof?" In my opinion, the first step to be done is to exactly define the question. Then we can discuss how we can find the answer. And the question "which simulator is the best one for wireless networks" is that extremely vague that I doubt that there is a sound answer to this one. Detlef -- Detlef Bosau Galileistrasse 30 70565 Stuttgart Mail: detlef.bosau at web.de Web: http://www.detlef-bosau.de Mobile: +49 172 681 9937 From detlef.bosau at web.de Sun Apr 15 15:57:18 2007 From: detlef.bosau at web.de (Detlef Bosau) Date: Mon, 16 Apr 2007 00:57:18 +0200 Subject: [e2e] Simulator for wireless network In-Reply-To: <46215867.9040406@kcl.ac.uk> References: <39BA3BC178B4394DB184389E88A97F8C0212FE63@hq-exch-1.corp.brocade.com> <4620D46E.5080509@spaghetti.zurich.ibm.com> <4621418B.2090009@web.de> <46215867.9040406@kcl.ac.uk> Message-ID: <4622ADCE.3000205@web.de> U.Shanker wrote: >>> >>> Don't simulate, use real live setups. >> >> Unfortunately, that?s not always possible. > Agreed >> >> In addition, there are always two ways to produce wrong results. >> >> The first is: Simulate. As you never know, what you?re simulating, >> your results will be wrong for sure. > Interesting. But probably I just want effect of one or other > parameters on the whole system. In that case, simulation is the best. O.k., I see I should add simleys if appropriate. What I wanted to say is that there is no such thing as an ideal way and that either simulation or a real test bed is the only way to go in any case. >> The second is: Conduct real experiments. As you never know, what >> you?re really doing, your results will be wrong for sure. >> >> So, the best way is, and somewhere I heard this were an old jiddish >> saying: If you have only two impossible choices, choose the third. > What about taking some real network data and using simulations based > on that. We use this using Opnet modeler etc. I think this is one of > the best approach. I never worked with the Opnet modeler. However, I would not believe that this is perfectly bug free. As the NS 2 is not perfectly bug free. As a driver for some Lucent WaveLAN card provided for M$ Wista or Vindows or how it?s actually called could be expected to be perfectly bug free. I even don?t know whether the source code for the Opnet modeler is available. The NS2 code is, and so I can see what I?m doing. And BTW: I?m absolutely not convinced of actually availalbe RLP / mobile network simulators for the NS2, perhaps I don?t know all of them. Of course, this is due to the questions I?m actually trying to find an answer to. So, I have to write my own simulator classes. Of course, it?s always a concern that no one will believe my results produced with this classes, this matches Craig?s experiences. The only thing I can do is to make the classes available to the public and to request comments on this code. > I think, here you made very good point. I tried ns2 and spend most of > the time between understand the whole NS2 system and debugging between > C++ and otcl code. And this is a necessary experience. Of course, there are other simulators. I had a look at the Omnet simulator and the BSD based classes for the Omnet provided by the TH Karlsruhe. Of course, this is interesting. However, it appears not be quite widespread and editing the BSD kernel code for own agents is at least somewhat cumbersome. So, I still use the NS2, because it?s simply easier for me. However, in each case you have to understand what you?re doing. I often was asked: "What are you simulating there?" And that is a valid question. You must always know which parts of a network, which mechanisms and algorithms you are simulating, otherwise you won?t be able to understand the differences between a simulator and reality. So, a simulator never can be used as a black box but you must know it?s internal architecture and limitations. I know, often PhD students want to achieve their PhD in a short period of time and think it is sufficient to plan two years for understanding simulation itself, the NS2 in particular and do some research with it. It is a matter of fact, that some papers were generated that way. However, these papers _are_ that way. Admittedly, I?m anything but a talented programmer. So, it took me at least about two years to reasonably understand what I?m doing with the NS2, particularly as there was no one I could learn from whom. The so called "NS2 expertise" of many people, even PhD students, it not even superficial - it simply doesn?t exist. And it?s not only sufficient to understand how a simulator works. Some weeks ago I had a first glance at a PhD thesis on emulation which numbered several phenomena which must be simulated in the emulator. Wonderful. I remembered an older post by David Reed then, who told us that the typical number of phenomena - transport - routing - serialziation - perhaps somewhat MAC is quite funny to look at - but it doesn?t reflect the situation in a real network. It?s at best some naive understanding on what is happening there. So, that?s the reason why I emphasize the importance of proper questioning. You _MUST_ reduce complexity and focus yourself to a certain aspect of networking you want to study, otherwise you will get lost in all the details. And there is a very important and interesting experience, I?m actually making myself. At the moment, I?m trying to understand some aspects of RLP and proportional fair scheduling. Now, when I try to write an RLP simulator myself, I recognize all the gaps in my own understanding of RLP and I see all the degrees of freedom in such an implementation and the design alternatives you have. I would never see that when I would rely upon a "ready tool". > Finally I moved to the OPNET (free for the universities !). It really > solved most of the my problems and I was just able to concentrate on ^^^^^^^^^^^^^^^^^^^^^ I?m not with an university, so I have to use tools which are freely available. However, from what I?ve seen so far about OPNET, the source code is not completely available - and that?s not acceptable for me. For some reasons, I needed to write an event dispatcher for a certain agent because I needed some coroutine model in my simulator. Wonderful. Events in the NS2 are not polymorphic per se. It?s trivial to make them polymorphic. Simply add a sophisticed method: ... virtual void make_it_polymorphic(){}; ... and anything is fine. However: How will I do that in a simulator, I have some object code of which and can plumb the one or the other class into the whole thing myself? In the NS2, I simply added the line above - and now I can write MyWonderfulMostIntelligentAgent::handler(Event *){ if (dynamic_cast (e) {selfmsghandler(e); return}; if (dynamic_cast (e) {linknotification(e); return}; .... Agent::handle(e); return; } (I think, in the Omnet it?s done that way.) > simulation only. But if somebody can master a tool like NS2, Who if not yourself shall master your simulator? You will have to master your simulation scripts, your scenarios, your system model, your implmentations, perhaps some day your thesis. So, it?s a good point to start with: Master your simulator ;-) > Finally, as Detlaf said, it will really depend what exactly you want > to do. Want to see effects of some standard parameters within the > complex WLAN/UMTS/WIMAX environment, then OPNET could be very fast in > providing results. At least it provides columns with numbers. My room is full of papers like that and I did not yet manage to carry them all to the waste basket. I?m somwehat tired to read all these papers where people tuned some parameters which they don?t understand and take those funny numbers produced by the simulator as "results". Let me take a concrete example. For my RLP simulator (I?m sorry, but I?m somewhat restricted to this topic these days ;-)) I have to decide whether the ARQ is done stop?n wait or sliding window. Now, there are some useful guidelines to that in Gorry Fairhursts RFC. And in Rami Mukhtars PhD thesis, it?s stop?n wait, IIRC. (Please don?t kill me, if I?m wrong ;-)) So, it?s about a few weeks now, where I simply consider whether ARQ should be done stop?n wait or sliding window. Now, I?m implementing my simulator myself. So I must _make_ this decision. And if I ever get a paper published on this matter, I must _defend_ this decision. I have no such excuse like "the OPNET did it that way" or "the Bell Labs did it that way". I made my decsion myself (in fact, I made one!) and I think I can defend it. And basically, there would be the alternative to study both ways and compare the results. So, what I?m using from the NS2 is the event driven simulator framework and the routing mechanisms. The "intelligence" for a simulation is put in the agents. And these will be my own ones. Of course, the TCP agents are taken from the NS 2 package. But I think, these are sufficiently accepted and well proven. > If want to do changed in the standard TCP implementations together > with WLAN etc, then may be NS2 will be faster. Looking for the complex > environment and some changes in the TCP, then you have to take the > time and probably use the OPNET. > > I was really very fast with NS2 and TCP and WLAN simulation. But when > it comes to the UMTS and WiMAX etc together with TCP/WLAN then it > appeared that, I have to move back from ns2 2.29 to 2.27, as UMTS > implementation was based on the older NS2 version and so on. Why did you rely upon old, perhaps unmanaged code? Those "contributions" which are written by some PhD student, and when he got his degree he forgets about his code and hopefully no one will ever detect the errors? I know, what I?m writing here sounds extremely harsh and bitter. But it reflects my own life experience and my own programming experience. When I have to _rely_ on some simulation code, I have to know what I?m doing. And there are some extremely helpful tools to achieve this. Your brain, your hands, the vi and the gcc. > If you plan to spend next few years with this kind of simulations work > then probably its worth start using NS2/NS3. > I agree. And if there were no "sentimental reasons" and I hade the time to start with something completley new, it would be probably worthwile to join the NS3 project. However, the main issue is to make perfectly clear what you?re asking for. And when the question is clear, as I said: a good question is nearly half the answer, you can choose the way to answer it, be it analysis or simulation and in case of simulation you will be able to write the appropriate code. (Existing code will hardly be sufficient because if there would be existing code for your question, your question might not be an open one.) As I said. This whole thing sounds somewhat harsh and bitter. But I only share my own experience here. I don?t want to discourage anyone. However, simulation is no simple task which can be done quickly and easily. Doing good simulations require good standing and years of concentrated and extremely focussed work. Detlef -- Detlef Bosau Galileistrasse 30 70565 Stuttgart Mail: detlef.bosau at web.de Web: http://www.detlef-bosau.de Mobile: +49 172 681 9937 From bohacek at udel.edu Mon Apr 16 04:17:33 2007 From: bohacek at udel.edu (Stephan Bohacek) Date: Mon, 16 Apr 2007 04:17:33 -0700 Subject: [e2e] Simulator for wireless network In-Reply-To: References: <39BA3BC178B4394DB184389E88A97F8C0212FE63@hq-exch-1.corp.brocade.com> Message-ID: <010001c78018$d4934460$2b840480@eecis4akb8pasu> Durga, As pointed out by several of the earlier responses, RF propagation is important for wireless simulation. We have developed a propagation simulator that is available for download (http://udelmodels.eecis.udel.edu). The web site also includes trace files and other data (e.g., city maps and propagation matrices). You did not state if your interest is in mobile wireless networks or fixed wireless networks. If your interest is in mobile wireless networks, we have also developed an urban mobility simulator based on a large number of surveys (no random waypoint here). Without a doubt, our simulator is not accurate. Our goal is to give an idea of the performance of protocols in realistic urban settings, not to exactly predict which packets are lost. There are many aspects of propagation that have yet to be included in our model. Currently, we are making measurements for propagation models to be included in our next version. Propagation modeling (and simulation in general) is a bottomless pit; one can always make better simulators that give more confidence in conclusions draw from simulation. The current version of our simulator is only the beginning; we intend to be falling down this pit for a while. I hope this helps, Stephan -----Original Message----- From: end2end-interest-bounces at postel.org [mailto:end2end-interest-bounces at postel.org] On Behalf Of Durga Prasad Pandey Sent: Friday, April 13, 2007 8:10 PM To: end2end-interest at postel.org Subject: [e2e] Simulator for wireless network What would be considered the best network simulator(s) for wireless networks, particularly for TCP experiments? Durga From uma.shanker at kcl.ac.uk Mon Apr 16 02:14:09 2007 From: uma.shanker at kcl.ac.uk (U.Shanker) Date: Mon, 16 Apr 2007 10:14:09 +0100 Subject: [e2e] Simulator for wireless network In-Reply-To: <4622ADCE.3000205@web.de> References: <39BA3BC178B4394DB184389E88A97F8C0212FE63@hq-exch-1.corp.brocade.com> <4620D46E.5080509@spaghetti.zurich.ibm.com> <4621418B.2090009@web.de> <46215867.9040406@kcl.ac.uk> <4622ADCE.3000205@web.de> Message-ID: <46233E61.608@kcl.ac.uk> Detlef Bosau wrote: > > I even don?t know whether the source code for the Opnet modeler is > available. The NS2 code is, and so I can see what I?m doing. > But you can not expect to have source code of every-thing we use. I think, some kind of black-box(es) in the whole environment is better to have. This is to hide the complexity. Generally not every had a skill and knowledge to understand the whole system. In telecommunication from physical layer to application layer, it really hard to find people with all the skills(of all the layers). So, if I am just a Transport layer person, then its better to have a good (well recognized) black-box with standard APIs for other layers, then just the source code of the physical layer. So, as even if the source code is available for physical layer, for me its useless. Just to make it short, most of the problems in this world are solved by abstracting(the other parts) and not by going in details to the whole system. > And BTW: I?m absolutely not convinced of actually availalbe RLP / > mobile network simulators for the NS2, perhaps I don?t know all of them. > Of course, this is due to the questions I?m actually trying to find an > answer to. So, I have to write my own simulator classes. Of course, > it?s always a concern that no one will believe my results produced > with this classes, this matches Craig?s experiences. The only thing I > can do is to make the classes available to the public and to request > comments on this code. I think, this is also a kind of abstraction for your RLP work. -- regards, Uma Shanker, PhD Student, Center for Telecommunications Research King's College London, Strand, London WC2R 2LS, UK. Tel: +44-20-7848-2889 Email: uma.shanker at kcl.ac.uk From giuseppe.bianchi at uniroma2.it Mon Apr 16 02:53:39 2007 From: giuseppe.bianchi at uniroma2.it (Giuseppe Bianchi) Date: Mon, 16 Apr 2007 11:53:39 +0200 Subject: [e2e] Simulator for wireless network In-Reply-To: <4621F23C.2060404@ieee.org> References: <39BA3BC178B4394DB184389E88A97F8C0212FE63@hq-exch-1.corp.brocade.com> <4620D46E.5080509@spaghetti.zurich.ibm.com> <4621418B.2090009@web.de> <46215867.9040406@kcl.ac.uk> <46216B6000000265@relay-pt1.poste.it> <4621F23C.2060404@ieee.org> Message-ID: <4622AF0B0002121A@relay-pt2.poste.it> (added by postmaster@poste.it) For those interested in tech details and in understanding which differences between ideal (standard) and real (implementation) world we are here talking about, in addition to the paper pointed out by Adam, here is a pointer to a cached version of our incoming infocom 2007 paper which seems complementary: http://www.tti.unipa.it/~ilenia/pub/info07.pdf "Experimental assessment of the backoff behavior of commercial IEEE 802.11b network cards" - specifically deals with MAC/backoff differences - power control oddities not yet included in this work Giuseppe. At 11.37 15/04/2007, Adam Wolisz wrote: >In the WINTECH 2006 workshop The First ACM International Workshop on >Wireless Network Testbeds, Experimental evaluation and >CHaracterization - one of the MOBICOM 2006 workshops - >a very interesting paper presents >"An Empirical ANalysis of Heterogeneity in IEEE 802.11 MAC protocol >implementations and it implications" > >Surprisingly enough, besides of a long list of differences which are >to be expected _ e.g. rate adaptation >algorithms are NOT defined by the standard, propreitary solutions >have to be used! - also >very clear violations of the standard have been observed within >products of major manufactureres. >Giuseppe Bianchi wrote: >>1. it is not granted that ALL cards will exactly behave as >>specified by the 802.11 standard (e.g. some use different >>CWmin, different EIFS, in some cases odd behavior do emerge e.g. >>because of possible implementation issues) From zartash at lums.edu.pk Mon Apr 16 03:09:36 2007 From: zartash at lums.edu.pk (Zartash Afzal Uzmi) Date: Mon, 16 Apr 2007 15:09:36 +0500 Subject: [e2e] iBGP session break In-Reply-To: <39BA3BC178B4394DB184389E88A97F8C0212FE63@hq-exch-1.corp.brocade.com> Message-ID: <200704161008.l3GA83bB020765@cyrus.lums.edu.pk> >>Greetings everyone >>My question is: Is it possible for an iBGP session to break even when the underlying IP topology is not partitioned?? >>We would expect that IGP maintains connectivity at the IP layer, and even in case of a failure in the network that doesnt partition the topology, the >>IGP should be able to quickly converge to a new configuration for paths between every?possible pair of nodes. This should result in, perhaps, a few >>dropped TCP packets for the iBGP session, but not a session break. Would it, then still be possible for an iBGP session to break and blackholes to >>consequently result?? ? >It is certainly possible depending on the configuration.? BGP uses hold?and keep-alive >timers.? If a?session?has its?hold timer expire because of not receiving a keepalive, then >the?session will be?terminated, even though TCP would not normally have torn down >the connection on its own.? >? >In the typical case (hold timer 180 sec, keep alive timer 60 sec), you probably >wouln't lose the peering while the IGP is reconverging.? But if these timers >are set very low, then you might. >? >Anoop? I wonder of there exist scenarios (in real world configurations, maybe!) when BGP timers are set at such low values that BGP session breaks while IGP is still re-converging? If setting BGP timers to such low values is not very common, is it safe to assume that a break in BGP session is also not very common? Are there other reasons (other than IGP convergence taking longer than BGP timers) which may cause BGP sessions to break? Thanks, Zartash From detlef.bosau at web.de Mon Apr 16 03:36:57 2007 From: detlef.bosau at web.de (Detlef Bosau) Date: Mon, 16 Apr 2007 12:36:57 +0200 Subject: [e2e] Simulator for wireless network In-Reply-To: <46233E61.608@kcl.ac.uk> References: <39BA3BC178B4394DB184389E88A97F8C0212FE63@hq-exch-1.corp.brocade.com> <4620D46E.5080509@spaghetti.zurich.ibm.com> <4621418B.2090009@web.de> <46215867.9040406@kcl.ac.uk> <4622ADCE.3000205@web.de> <46233E61.608@kcl.ac.uk> Message-ID: <462351C9.3070204@web.de> U.Shanker wrote: > Detlef Bosau wrote: >> >> I even don?t know whether the source code for the Opnet modeler is >> available. The NS2 code is, and so I can see what I?m doing. >> > But you can not expect to have source code of every-thing we use. Of course I can! I remember a remark by a professor for software engineering, Hans-Jochen Ludewig, who once told us that the most important part in a program, if not the ony important one, is the specification! In case of a disaster, fire, earthquake all backups lost etc., the only important part which must be kept by all circumstances is the specification! Anything else may get lost. So, when you analyze wireless networks, it?s exactly the same story: The only important thing is the specification! Anything else is a crude mixture of bugs and beginner?s first steps to programming - and to hide the mess from the public, it is claimed to be "company confidential". Whether we use open and well known specifications and implement them in a manner that anyone can check whether the implementation matches the specification or not makes the very difference whether we are doing science or whether we are just kidding. It?s not the purpose of science / universities to promote mediocre products from the industry. There is a new buzzword each and every day. And lots of people are eager to keep track with all the new "developments". But this is not my attitude to thoroughful, proper science. If you have a simulator with a code you do not know or do not understand, you will _NEVER_ be able to defend your "results" gained by this product - it?s simply useless. It is inevitable to use a simulator which is carefuly specified and implemented - or the outcome of your simulation is poor luck. Artifacts caused by bugs, useless stuff. It?s waste of time to loose a word on it. > I think, some kind of black-box(es) in the whole environment is better > to have. This is to hide the complexity. If you want to hide complexity, you don?t use _black_ boxes but you use _specified_ boxes. You use boxes with a specified behaviour. When the behaviour is properly specified and there is evidence (not only by one test run but _evidence_) that a certain component behaves in the specified manner, you may well use it. That?s were scientists should stand upon each others shoulders. And not on their toes. (Refer to the well known quote by Hamming, IIRC, you will find it in Wesleys signature :-)) > Generally not every had a skill and knowledge to understand the whole > system. Generally not everyone is a computer scientist, and not everyone is pursuing a PhD and not everyone is professor and not everyone does research. If I were to review a paper with simulation results where it becomes clear that the authors don?t have a perfect and reliable understanding of what they are doing - I would reject it without further consideration. We?ve seen enough cold fursions and successful clone experiments by this famous professor in South Korea, the name of whom I just forgot. Not only that this is no science, the problem is even worse: All these "happenings" have absolutely destructive consequences for the reputation of a discipline and science in general. Do it - or leave it. But plese do nothing in betewen. > In telecommunication from physical layer to application layer, it > really hard to find people with all the skills(of all the layers). So, > if I am I know. And if you listen to the German government, it?s extremely hard to find those people. (If the German government were not as stupid as it is, it would have a look at the job market. We have 4 millions of unemployed people here. Perhaps not everybody is as skilled as we request in this discussion. But I think, the 40 to 50 adequately skilled persons which are really needed can be found here without any problems.) Many of the participants in this list, I expect it is the vast majority, hold a PhD in computer science, electrical engineering or communication engineering. If we assume, that this is not earned by luck or as a gift but it is _deserved_, these people _are_ adequately skilled. Otherewise we would have to put academic degrees in question. > just a Transport layer person, then its better to have a good (well > recognized) black-box with standard APIs for other layers, then just > the source code of the physical layer. So, as even if the source code > is available for physical layer, for me its useless. You may well use a component written by someone else. But there must be evidence that this component behaves as requested. (And by all means - I did not say that science is a nine-to-five job.) > > Just to make it short, most of the problems in this world are solved > by abstracting(the other parts) and not by going in details to the > whole system. Yes. There is a quick, and wrong, answer to nearly any question in the world. > >> And BTW: I?m absolutely not convinced of actually availalbe RLP / >> mobile network simulators for the NS2, perhaps I don?t know all of them. >> Of course, this is due to the questions I?m actually trying to find >> an answer to. So, I have to write my own simulator classes. Of >> course, it?s always a concern that no one will believe my results >> produced with this classes, this matches Craig?s experiences. The >> only thing I can do is to make the classes available to the public >> and to request comments on this code. > I think, this is also a kind of abstraction for your RLP work. At least, I did not find one - during the last seven years. It may be my fault - or my claims are too high, I don?t know. Just in the beginning of this year, I was about to start with a paper - when a colleague told me after a first glance, he would not believe my "artifacts". O.k. Where do artifacts end? Where do results begin? So I learned a basic lesson in wireless networking: Do not believe in _any_ abstraction which you do not completely understand. And if this takes to attend some lessons in physics, it _takes_ to attend these. And if you have to reproduce a proof of lentgh 20 pages in a textbook of communiation engineering, you simply have to do it. Perhaps, that way a PhD study is not finished within two years. Perhaps, you will receive criticism because you were not ambitioned because you do not write enough papers. What is your attitude? Proper science? Or a well known reputation? There are extremely few persons who receive both. And the people who _deserve_ both, in the whole history of science, may be easily counted with one hand. -- Detlef Bosau Galileistrasse 30 70565 Stuttgart Mail: detlef.bosau at web.de Web: http://www.detlef-bosau.de Mobile: +49 172 681 9937 From johnh at ISI.EDU Mon Apr 16 09:59:07 2007 From: johnh at ISI.EDU (John Heidemann) Date: Mon, 16 Apr 2007 09:59:07 -0700 Subject: [e2e] Simulator for wireless network In-Reply-To: <462279C2.3090203@web.de> Message-ID: <200704161659.l3GGx7Gv005413@dash.isi.edu> On Sun, 15 Apr 2007 21:15:14 +0200, Detlef Bosau wrote: >Adam Wolisz wrote: >> >>> ALl, >>> Giuseppe has addressed a very important point. >>> >>> In fact the following question is a basic one: what is to be >>> investigated - an ideal behavior of the envisioned, >>> precisely defined solution - or THE behavior of really deployed >>> products? > >Exactly. And that?s why it?s so important to have the question well put. > >And when we investigate the behaviour of a deployed product, we >practically investigate the behaviour of _exactly_ _that_ deployed >product - which may well be subject to change without notice (as it is >written in nearly each manual of any appliance you can buy). Standard >violation included, as you wrote later in your post. I believe this is a key observation, and one that's often node made explicit in a rush to "more realism" in simulations. One can only answer "what's the best simulator" (or more generally, what's the best evaluation tool) in the context of a specific research question. If you're trying to do quantitative predictions about a particular product you'll deploy in a specific place next week, then the best possible fidelity is essential. But relax any of those constraints and, in many cases, inaccuracy in one aspect of the simulation overwhelm accuracy in the others. For example, running real code in your simulator can be great, but if you turn around and use an artificial traffic or mobility model, the results can easilyi be dominated completely by that choice and not whether you're using mbufs or skbufs, or which bugs you emulate. This observation motivated the fairly abstract TCP models in ns-2. Because they're simplified, it is easy to explore variants and understand the "envelope" of valid TCP implementations, both current, old, and not-yet-in-wide-deployment. IMHO, the biggest benefit of simulators that share code with real implementations is not realism in simulation, but the ability to iterate between simulation and actual experimentation. Although a bit dated, some of these issues were discussed in Expanding Confidence in Network Simulation. IEEE Network Magazine, 15 (5), pp. 58-63, Sept./Oct., 2001, with a copy at . -John Heidemann (Disclaimer: I was heavily involved in ns development in the past.) From touch at ISI.EDU Mon Apr 16 10:57:50 2007 From: touch at ISI.EDU (Joe Touch) Date: Mon, 16 Apr 2007 10:57:50 -0700 Subject: [e2e] Simulator for wireless network In-Reply-To: <46227C50.9000700@web.de> References: <4AB0C12D-B135-4A9F-8452-7A979F51C4F4@uwaterloo.ca> <46227C50.9000700@web.de> Message-ID: <4623B91E.9050200@isi.edu> Detlef Bosau wrote: > S. Keshav wrote: >> >> >> This is the reason why 'proof by simulation', for computer systems, at >> least, is farcical. Not only are simulators known to be buggy, but >> they are also simulating a system that is too loosely coupled to be >> adequately modeled. > > Is a "proof by implementation" is better? > > I don?t think so. Implementations are known to be buggy. Implementations > are known to not behave as expected. > ... The difference is that if I actually transfer data over an implementation, I have measured something real. If real measurements of a real system measure the desired property - i.e., TCP throughput over actually lossy links - then the result is what satellite people call "ground truth". As you note, such proof is an existence proof - you can't disprove all alternatives, you can't prove that someone can't go faster or slower. What you can prove is that something happened. Which is not possible with simulation alone. 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/20070416/aea64faa/signature.bin From jg at laptop.org Mon Apr 16 15:19:05 2007 From: jg at laptop.org (Jim Gettys) Date: Mon, 16 Apr 2007 19:19:05 -0300 Subject: [e2e] Simulator for wireless network In-Reply-To: <4623B91E.9050200@isi.edu> References: <4AB0C12D-B135-4A9F-8452-7A979F51C4F4@uwaterloo.ca> <46227C50.9000700@web.de> <4623B91E.9050200@isi.edu> Message-ID: <1176761945.4908.30.camel@localhost> On Mon, 2007-04-16 at 10:57 -0700, Joe Touch wrote: > > Detlef Bosau wrote: > > S. Keshav wrote: > >> > >> > >> This is the reason why 'proof by simulation', for computer systems, at > >> least, is farcical. Not only are simulators known to be buggy, but > >> they are also simulating a system that is too loosely coupled to be > >> adequately modeled. > > > > Is a "proof by implementation" is better? > > > > I don?t think so. Implementations are known to be buggy. Implementations > > are known to not behave as expected. Yes, operating systems are known to be buggy: and you get them fixed if you want to get real results. Oh, you say you can't get the bugs fixed? Then choose a different operating system..... Responsible vendors get their bugs fixed when you bring them to their attention, or the code is available for you to fix. And the insight gained when the implementation not behaving as you expect you learn that your programs are broken. That is also of great value. Would that many/most HTTP implementations understood the underlying TCP protocol; unfortunately, most implementers do not. No one said that experimental science was easy.... (says one who worried about how HTTP would run across the actual internet, rather than a simulator; Craig, thanks again for shepherding us crazies through the process...). Having said the above, I note that some particular tools, such as those that can inject delay in network paths, or losses in those paths, in combination with measurements across real networks can give additional insight into the likely behavior of real systems in different circumstances that you may not easily be able to test directly. Those tools have good value. But there is no substitute for real measurement. - Jim -- Jim Gettys One Laptop Per Child From Eric.Anderson at Colorado.EDU Mon Apr 16 16:07:17 2007 From: Eric.Anderson at Colorado.EDU (Eric W Anderson) Date: Mon, 16 Apr 2007 17:07:17 -0600 Subject: [e2e] Simulator for wireless network In-Reply-To: References: <39BA3BC178B4394DB184389E88A97F8C0212FE63@hq-exch-1.corp.brocade.com> Message-ID: <20070416230716.GA10486@colorado.edu> At the risk of flogging a dead horse, here are a few observations. Right now, my group is working on studying the physical- and MAC-layer impact of using steerable antennas in 802.11-ish networks. We've used ns2 and Opnet a fair bit, and right now we're measuring actual deployments. With that said here are my thoughts: (1) RF propagation is extremely sensitive to the details of a physical environment. If you do your research using the "40 laptops" approach, it's important to consider an appropriate range of physical environments. If you use a simulator, you need to consider what sort of physical world you're specifying -- or implicitly assuming. (2) Both Opnet and ns2 make significant simplifying assumptions about the RF environment and the sender and receiver hardware. Whether these assumptions are OK or not depends very much on what you're studying. (3) Opnet's main strengths -- to me -- are its extensive library of equipment models and its built-in statistics gathering. Both are handiest if you're a network administrator and want to quickly evaluate a proposed deployment of stock systems and protocols. If you're interested in re-designing things significantly, they're probably less useful. In my experience, the built-in statistics tracking proved inappropriate for the fine granularity data I needed to gather. (4) Parts of Opnet are modifiable models which come with the source code, and other parts are opaque and immutable. The parts I most wanted to change or instrument were often in the latter category. In the end, we've settled on actually implementing things as our preferred approach. I'll probably use ns2 in the future when an actual deployment is impractical. I probably won't be using Opnet again. That's my two cents' worth, Eric Thus spake Durga Prasad Pandey (dpsmiles at MIT.EDU): > What would be considered the best network simulator(s) for wireless > networks, particularly for TCP experiments? > > Durga -- Eric W. Anderson University of Colorado eric.anderson at colorado.edu Dept. of Computer Science phone: +1-720-984-8864 Systems Lab - ECCS 112 PGP key fingerprints: personal: 1BD4 CFCE 8B59 8D6E EA3E EBD5 4DC9 3E61 656C 462B academic: D3C5 D6FF EDED 9F1F C36D 53A3 74B7 53A6 3C74 5F12 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20070416/fd198998/attachment.bin From detlef.bosau at web.de Thu Apr 19 07:49:23 2007 From: detlef.bosau at web.de (Detlef Bosau) Date: Thu, 19 Apr 2007 16:49:23 +0200 Subject: [e2e] How do we simulate mobile networks? Was: Simulator for wireless network In-Reply-To: <200704161659.l3GGx7Gv005413@dash.isi.edu> References: <200704161659.l3GGx7Gv005413@dash.isi.edu> Message-ID: <46278173.5050702@web.de> John Heidemann wrote: > > I believe this is a key observation, and one that's often node made > explicit in a rush to "more realism" in simulations. One can only > answer "what's the best simulator" (or more generally, what's the best > evaluation tool) in the context of a specific research question. > Perhaps, the original question turns into: "How do we simulate particular functions in wireless networks?" Or even better: "What must we simulate when we simulate wireless networks?" Those discussions which tool were simply the best are typically quite aggravating. To be concrete. Let?s assume my favourite szenario: FH--------BS ..... MH Fixed Host, Base Station, Mobile Host were the mobile host is attached to BS via some mobile network technology. Which components / functions must be simulated / modeled then? E.g., I often bothered this mailing list with the question whether there are interactions between TCP and MAC scheduling. Now, let?s imagine we were interested in an answer to this question. Not only for GPRS or HSDPA or UMTS, but technology independent. Perhaps, I don?t know, the answer is not even the same for all of the networks listed above. I sometimes met particular simulator components for the one or the other technology for the NS2, but to my knowledge we do not yet have some generic 3G and beyond simulator architecture in the NS2. Is this correct? And does somebody know the situation with NS3? Unfortenately, I did not yet take the time to get aquainted with the NS3 architecture. Particularly, I do not know whether a it makes sense to "port" simulation approaches viable with the NS2 into the NS3. However, assumed the NS3 is still a discrete event simulator, some key elements will be similar to all other d.e.s. as NS2 or omnet. So, hopefully this post is not made completely obsolete by the NS3... Back to the question. Let?s start with the basic processing chain from the base station to the mobile terminal and vice versa. An IP datagram (let?s assume IP here for simplicity) is a) first split up into a number of RLP blocks which are b) block coded and added a checksum, c) perhaps interleaved by an outer interleaver, d) channel coded, typically by a convolutional coder, e) perhaps interleaved by an inner interleaver, f) queued for media access in case of common channels, g) granted media access and added an upstream state flag in some networks and eventually h) sent to the wireless channel. Let?s ignore the details of physical modulation, transfer and demodulation here. (Question: Is f) correct that way? To my understanding, an USF can be added not earlier than wenn the media access is granted, particularly an USF would be added in symbols instead of bits then?) At the receiver side, the frame is i) taken to the inner deinterleaver to reconstruct the physically coded RLP frames, j) taken to the decoder, e.g. Viterbi decoder, to decode the original information word, i.e. the RLP frame with checksum, k) taken to the outer interleaver, l) taken to the block decoder m) finally: forwarded to the ARQ receiver or, in case of a corrupted frame, discarded. n) the ARQ receiver reassembles the original IP packet or requests retransmissions if necessary. A note to interleaving: "Perhaps" means that interleaving does necessarily apply to each technology. Now, the processing chain from b) to m) takes a constant time plus some variable MAC delay in f). To my understanding, this processing chain forms a pipeline with surely more than one RLP frame capacity. So, I don?t think that a stop?n wait approach will be always sufficient here. At the moment, I plan to simulate the processing chain from b) to m) as a sliding window chain. This can be done by use of queue/delay pairs as it is accomplisehd typically in the NS2. The _delay_ reflects the processing delay from b) to m), not only the physical propagation delay. I plan to use individual links, i.e. queue/delay pairs, for each mobile terminals in the NS2, which are controlled by a common MAC component which grants "media access" by allowing an individual delay component to serve its queue based upon the chosen MAC algorithm. Hence, although I have individual links, I can make them behave exactly like a common channel in reality. Up to know, whe have - the processing chain from the ARQ sender to the ARQ receiver, which is modeled by a queue/delay component which abstract the whole pipeline into a simple "proecessing delay" which reflects the pipeline?s capacity (Little?s theorem: average workload = average processing time * arbitrary arrival rate, we use the arrival rate to reflect the physical bandwidth and use the average processing time to model the capacity then) and - a MAC controller which can obey arbitrary MAC disciplines, particularly opportunistic ones which in turn need - filters for throughput estimation. I plan to simulate RLP frames of a constant physcial length, although they may have different _payload_ length to simulate different coding schemes. (Typically, the coded rlp frame has always the same lenght because the convolutional code is not changed but the payload length may differ due to different puncuturing.) For the ARQ sender / receiver, I plan to use a simple selective retransmission scheme as can be found e.g. in RLP version 3 (IIRC) in the 3GPP. I do not yet consider HARQ, and I?m still not quite sure whether HARQ does not restrict us to a stop?n wait protocol. So, the basic degrees of freedom are: - the pipeline?s capacity (1 frame in case of stop?n wait), - the MAC scheme, if applicable, - the coding scheme overhead, which is fixed in case of non adaptive FEC, - the throughput estimation filter, which is basically an EWMA filter in actual PF-schedulers, although other filters may be considered, e.g. TSW. As a consequence of a retransmission scheme, we have - new (first attempt) transmissions, - retransmissions, - control frames (e.g. NAK) which compete for the wireless media. Following RLP v3, I serve them priorized: control frames are given the highest priority, followed by retransmissions and new transmissions are given the lowest priority. To my understanding, this is reasonable for flow control reasons: A reciever should be delivered from not yet completed packets as soon as possible in order to free buffer space. So, requests for retransmissions and retransmissions themselves are given higher priority than first transmissions. From that, we have some more degrees of freedom: - Can packets be dropped at the queue in f)? - Will the different queues share common memory or will they be assigned individual memory? NB: We did not yet talk about a retransmission buffer at the sender?s side. Finally, because we want to simulate wireless networks, we need an error model. In fact, this is easily implemented as a block error process at the delay component. However, the most interesting question is: How should errors be modeled? In fact, this is perhaps an easy part in the implentation, but a wrong choice in this place can render the whole effort completeley useless. I think, this error model is the right place to add "reality" to the system. O.k. This post was some kind of brain storming, which I?m currently doing in cooperation with Emmanual Lochin, who particularly studies the effect on different estimators used for PF scheduling. However, any comment is greatly appreciated, particularly concerning the block error model. As soon as we some results and some useful simulator components, we would be glad to share this with others. And if this is all old stuff, already available in existing products but only not documented, then I think it?s at least helpful to have an open source version (o.k., if ever someone is willing to use my source code ;-)) and perhaps some lines of documentation. At the moment, I?m working with ns2, 2.30. Regards Detlef -- Detlef Bosau Galileistrasse 30 70565 Stuttgart Mail: detlef.bosau at web.de Web: http://www.detlef-bosau.de Mobile: +49 172 681 9937 From glennj+ at cs.cmu.edu Fri Apr 20 09:59:12 2007 From: glennj+ at cs.cmu.edu (Glenn Judd) Date: Fri, 20 Apr 2007 12:59:12 -0400 Subject: [e2e] Simulator for wireless network References: Message-ID: <9C0D1A9F38D23E4290347EE31C22B0AF010169F2@e2k3.srv.cs.cmu.edu> We have been developing an approach that compliments the previously discussed options of simulation and experimentation: physical layer wireless emulation. This approach uses real devices/radios/apps; thus everything on the device is real from the APP<->PHY layers. We emulate the one thing that makes actual experimentation difficult: signal propagation. This eliminates the key problems of experimentation such as the lack of repeatability due to lack of control of the physical environment, and the cumbersome task of controlling (possibly mobile) devices distributed in physical space. A high-level description of this project can be found at: http://www.cs.cmu.edu/~prs/emulator/ We are in the process of making this platform available for use by researchers. Anyone interested please contact me, and I can give details of current functionality and availability. Glenn glennj at cs.cmu.edu From detlef.bosau at web.de Fri Apr 20 16:34:24 2007 From: detlef.bosau at web.de (Detlef Bosau) Date: Sat, 21 Apr 2007 01:34:24 +0200 Subject: [e2e] Simulator for wireless network In-Reply-To: <010001c78018$d4934460$2b840480@eecis4akb8pasu> References: <39BA3BC178B4394DB184389E88A97F8C0212FE63@hq-exch-1.corp.brocade.com> <010001c78018$d4934460$2b840480@eecis4akb8pasu> Message-ID: <46294E00.9060308@web.de> I apologize, if some answers are given on your website. However, my firefox (Linux) does not survive it. This is presumably not due to your site but to my firefox version....... Perhaps, it should start up playing this famous Beatles song: "When I get older, loosing my hear..." unfortunately not that many year from now.... %-) Stephan Bohacek wrote: > Durga, > > As pointed out by several of the earlier responses, RF propagation is > important for wireless simulation. We have developed a propagation simulator > that is available for download (http://udelmodels.eecis.udel.edu). The web > site also includes trace files and other data (e.g., city maps and > propagation matrices). > What exactly will I find in this trace files? I would appreciate Block Erasure Rates (BLER) :-) If SNR or C/I is available as well as some mapping, which a computer scientist can work with, this would be nice too. Because I?m still interested in PF scheduling, it would be particularly interesting to have traces - for fast moving users and - for a number of users sharing the same base station / RNC, wherever the MAC scheduling is done in case of common channels. > You did not state if your interest is in mobile wireless networks or fixed > wireless networks. If your interest is in mobile wireless networks, we have > also developed an urban mobility simulator based on a large number of > surveys (no random waypoint here). > > I?m not that much interested in random waypoint modells. During the last few years, I got used to look for particular scenarios. These might sometimes be a bit artificial. However, I think it?s more interesting to study particular cases which can lead to problems than to look at the average case, which does not mean of course, that this would be not interesting. But I?m more attracted by concrete scenarious which can lead to structural problems. > Without a doubt, our simulator is not accurate. Our goal is to give an idea > of the performance of protocols in realistic urban settings, not to exactly > predict which packets are lost. There are many aspects of propagation that > have yet to be included in our model. Currently, we are making measurements > for propagation models to be included in our next version. Propagation > modeling (and simulation in general) is a bottomless pit; one can always > ...however it?s an extremely important one.... > make better simulators that give more confidence in conclusions draw from > simulation. The current version of our simulator is only the beginning; we > intend to be falling down this pit for a while. > > I think, this could be extremely interesting. Detlef -- Detlef Bosau Galileistrasse 30 70565 Stuttgart Mail: detlef.bosau at web.de Web: http://www.detlef-bosau.de Mobile: +49 172 681 9937 From detlef.bosau at web.de Sat Apr 21 11:12:10 2007 From: detlef.bosau at web.de (Detlef Bosau) Date: Sat, 21 Apr 2007 20:12:10 +0200 Subject: [e2e] Simulator for wireless network In-Reply-To: <9C0D1A9F38D23E4290347EE31C22B0AF010169F2@e2k3.srv.cs.cmu.edu> References: <9C0D1A9F38D23E4290347EE31C22B0AF010169F2@e2k3.srv.cs.cmu.edu> Message-ID: <462A53FA.6090805@web.de> Glenn Judd wrote: > We have been developing an approach that compliments the previously > discussed options of simulation and experimentation: physical layer > wireless emulation. > If I understand this correctly, you are ready to emulate the behaviour of a physical channel. Is this correct? To my understanding, this is the by far most important part of the whole wireless network business. Many of the work in this area is, frankly spoken and I?m ready to take contradiction here, at least questionable because the assumptions about the lowest layers used in the system model, be it IP latencies or whatever, seem to be quite arbitrary and the question arises naturally whether they are chosen to "improve the results". Think of the whole work about spurious timeouts and the like. Some of this work even used a "Hiccup" module in the NS2, where arbitrary delay spikes were introduced in a flow. That way, I can prove anything or nothing. In this sense, an approach like this is, I know I?m harsh here, worthless. Of course, these results are artifacts. And of course, when I do simulation my own, the results are artifacts. The one researcher is lucky and gets it published, the other one gets it rejected. Neither way is sufficient. The more I think about the whole wireless network business, the more I become convinced that it is absolutely inevitable to have good models and / or simulations and / or emulations of the wireless channel. All the rest is basically Garbage In Garbage Out. Unfortunately, I?m not a communications engineer, so I?m absolutely not skilled enough to do this work on my own. Otherwise, the criticism: "You miss a model of the wireless channel? So, start and build one!" would be perfectly legitimate. Even more, I?m unemployed, so I don?t have the opportunity to make perhaps necessary physical experiments here. I once was advised, I should try something with my mobile phone. Not only, this is by far too expensive, but when you make measurements on IP latencies, you have that many of unkown influences there, that it?s hard to get something useful from this. I think, physical experiments should be done on an extremely low layer, e.g. with well known signal sources and mobiles which read these sources and measure the SNR or C/I and give you an insight of what?s happening on the "symbol layer". Upward from that, you can map this to block erasure rates or whatever you prefer. For your emulator, you perhaps won?t even map this because you emulate the physical channel itself. However, I think, what?s inevitable here is to have appropriate channel models, either analytical ones or replays from practical traces. Question: What is the state of the art here? Are good channel models available? I think, this is the key question in this whole area. Detlef -- Detlef Bosau Galileistrasse 30 70565 Stuttgart Mail: detlef.bosau at web.de Web: http://www.detlef-bosau.de Mobile: +49 172 681 9937 From detlef.bosau at web.de Fri Apr 27 17:04:01 2007 From: detlef.bosau at web.de (Detlef Bosau) Date: Sat, 28 Apr 2007 02:04:01 +0200 Subject: [e2e] Timeouts in ARQ / RLP Message-ID: <46328F71.2010506@web.de> I?m curious whether we need timeouts in ARQ. I?m not quite sure about RLPv3, I have to re-read the details. But IIRC, RLPv3 needs timeouts to detect lost NAKs / retransmits. In a pure stop?n wait scenario, using timeouts may be appropriate, because the round trip time for a sending attempt and the appropriate ACK is pretty well known und subject only to little changes. In sliding window scenarios with extensive queueing, the situation is more complicated. In addition, it is pretty well accepted, that loss detection using timeouts should be avoided if ever possible. So, does anybody happen to know the state of the art in RLP / ARQ? Thanks a lot! Detlef From dlfisher at nsf.gov Sun Apr 29 11:35:55 2007 From: dlfisher at nsf.gov (Fisher, Darleen L.) Date: Sun, 29 Apr 2007 14:35:55 -0400 Subject: [e2e] Collaboration on Future Internet Architectures Message-ID: <21070EF5B3AE194385A8CCC4841D1BF749D05F@NSF-BE-02.ad.nsf.gov> Call for Research Collaboration on Future Internet Architectures in Partnership with the US NSF FIND Program Background The Internet's unquestionable success at embodying a single global architecture has also led over the decades of its operation to unquestionable difficulties with regard to support for sound operation and some types of functionality as well as raising issues about security and robustness. Recently the international network research community has focused on developing fresh perspectives on how to design and test new architectures for coherent, global data networks that overcome these difficulties and enable a healthy robust Future Internet. As a reflection of this growing community interest, there has been international interest in rethinking the Internet to meet the needs of the 21st century. In the United States, the National Science Foundation (NSF) has announced a focus area for networking research called FIND, or Future Internet Design. The agenda of this focus area is to invite the research community to take a long-range perspective, and to consider what we want our global network of 10 or 15 years to be, and how to build networks that meet the future requirements. (For further information on the FIND program, see NSF solicitation 07-507.) The research funded by FIND aims to contribute to the emergence of one or more integrated visions of a future network. (See www.nets-find.net for information about the funded research projects.) A vital part of this effort concerns fostering collaboration and consensus-building among researchers working on future global network architectures. To this end, NSF has created a FIND Planning Committee that works with NSF to organize a series of meetings among FIND grant recipients structured around activities to identify and refine overarching concepts for networks of the future. As part of the research we leave open the question of whether there will be one Internet or several virtualized Internets. A broader community Because there is a broad set of efforts with similar goals supported by other agencies, industry, and nations, NSF sees significant value in researchers in the FIND program participating in collaboration and consensus-building with other researchers, in academia and industry in the US and particularly internationally, who share like-minded visions. We believe that such visions of future global networks would greatly benefit from global participation and that testing and deploying these networks require global participation. NSF would like to do its share in helping to create a global research community centered on working toward future global network architectures by inviting researchers interested in such collaboration to participate in FIND activities. We hope that other national and international groups will invite FIND participants to work with their researchers as well. The FIND meetings are organized for the benefit of those already actively working in this area, or for those who have specific intellectual contributions they are prepared to make in support of this kind of research. These meetings are not informational meetings for people interested in learning about the problem, or for those preparing to submit proposals to NSF. Invitee Selection Since the efficacy of FIND meetings is in part a function of their size and coherence, we are asking researchers or individuals engaged in activities in support of research to submit short white papers describing themselves and how their work or intellectual contribution is relevant to future global internet architectures. Based on the FIND planning committee's evaluation of the described work or contribution would contribute to a vision of the future, researchers will be invited to join the FIND meetings and other events, as overall meeting sizes and logistics permit. The white papers should not focus on implementing large-scale infrastructure projects. The evaluation of the white papers will focus on certain criteria that are listed below, along with expectations regarding what external participation entails. Naturally, interested parties should take these considerations into account as they write their white papers, and include information in their papers sufficient to allow the FIND planning committee to evaluate the aptness of their participation. Please try to limit your white paper to 2 pages. * In a few sentences, please describe your relevant work, and its intended impact. When possible, include as an attachment (or a URL) a longer description of your work, which if you wish can be something prepared for another purpose (e.g. an original funding proposal or a publication). It will help to limit the supporting material to 15 pages or fewer. * Please summarize in the white paper the ways you see your contributions as being compatible with the objectives of FIND (the URL for the FIND solicitation is included above). Contributions that accord with the FIND program will generally be based on a long-term vision of future networking, rather than addressing specific near-term problems, and framed in terms of how it might contribute to an overall architecture for a future network. * Since the FIND meetings have been organized for the benefit of researchers who have already been funded and are actively pursuing their research, research described in white papers should already be supported. Please describe the means you have available to cover your FIND-related activities: the source of funds, their duration, and (roughly) the supported level of effort. Unfortunately, NSF lacks additional funds to financially support your participation in the meetings, so you must be prepared to cover those costs as well. * If you have submitted a FIND research proposal to the current NeTS solicitation, you should not submit a white paper here based on that research. You should provisionally hold June 27-28, 2007 of the next meeting because if selected for funding, you will be invited to attend the June meeting. The selection will be made in early June. * As one of the goals of FIND is to develop an active community of researchers who work increasingly together over time towards coherent, overall architectural visions, we aim for external participants to likewise become significantly engaged. To this end, you should anticipate (and have resources for) participating in FIND project meetings (three per year) in an active, sustained fashion. * Invitations are for individuals, not organizations, so individuals, not organizations should submit white papers. * We view the research as pre-competitive, so your research must not be encumbered by intellectual property restrictions that prevent you from fully discussing your work and its results with the other participants. Your white paper (and the supporting description of current research or other relevant contributions) will be read by members of the research community, so do not submit anything that you would not reveal to your peers. (White papers are not viewed as formal submissions to NSF.) Timing and submission You may submit a white paper at any time during the FIND program. The papers we receive will be reviewed before each scheduled FIND PI meeting. Meetings are anticipated to occur approximately three times a year, in March, June/July and October/November. The next FIND meeting is scheduled for June 27-28, 2007 in the Washington D.C area. Priority in consideration for that meeting will be given to white papers that are received by Friday, May 14th, 2007. Send your white paper to Darleen Fisher and Allison Mankin for coordination. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20070429/7bc3a923/attachment.html