Wireless and Mobility Architectures Expectations and Requirements for GENI

1. Wireless and Mobility Architectures Expectations and Requirements for GENI Sanjoy Paul(Moderator) Wireless Information Network Laboratory (WINLAB), Rutgers University

2. Question (1): New Architectural Issues • Q.1: What architectural features would you like to see supported in GENI in order to facilitate your wireless/mobility research and experiments? Specifically, if GENI were built to support networking research in wired network with wireless as the first (last) hop access technology, would that be sufficient for you to conduct your wireless/mobility research? Why or why not? • [CP] Software radios with multiple antennas capable of MIMO as well as concurrent transmission/reception on multiple frequencies, with enough DSP and FPGA horsepower to really play with radio capabilities. • [RK] A rapidly-forming mobile wireless transit AS for GENI that will repair a catastrophic (Katrina/Tsunami scale) damage to GENI infrastructure.  The transit AS should go operational in a matter of hours and bridge GENI partitions.  GENI wired infrastructure should support emulation of such a partitioning. • [RK] On-demand network capacity enhancement using mobile nodes: An operator must be able to schedule the mobility of nodes to required location to have a network deployed including attaching to infrastructure points, become operational and torn down after the requirement is over.  Say, I want to provide better communications capability during a major event but do not want to build permanent infrastructure. • [RK] The architecture should support both mobility (keep your endpointidentifier as you move a la Mobile IP) and nomadicity (readdress whenyou move a la DHCP) efficiently. 

3. Question (1) – New Architectural Issues • [BF] Communication across a flexible combination of wired and wireless technologies, where some of the _middle_ hops may be wireless too: • Emergency communication: the hurricane rolls in or the big earthquake hits, cutting power and wired communication infrastructure at multiple points at once, leaving the wired infrastructure partitioned...  Fortunately it's harder for a natural disaster to partition the airwaves: we'd best make sure our protocols can take advantage of that fact when necessary. • Developing nations: it may well be feasible to wire up small, remote villages internally but infeasible to run long-distance cables between them: suddenly we need small wired islands in a large-scale wireless network... • [MD,KF] Mobile networks (e.g. where clusters of nodes move together -- such as airplanes, etc), and where such networks can act as transit nodes (consider a collection of airplanes or air balloons, etc). • [MD,KF] Researchers should be able to have full control over the data flow, ideally all the way down to the physical / modulation layer. For example, some research may want to explore circuit-like services, rather than a packet service. More important and generally, it is essential to have control over routing, e.g. supporting source routing at a minimum, but more fundamentally to explore routing algorithms and be able to control where all data goes. It would also be useful to have persistent storage at all nodes, and to have rich error-generating and error-monitoring capabilities. • [MD,KF] Ad-hoc assemblages of networks, whether mobile/wireless or not. Such scenarios involve cases where little infrastructure may be available, and will bring up challenges involving issues like addressing, security, auto configuration, etc. • [TB]Wireless as last hop won't support the most interesting MANETs.

4. Question (2): Unique Requirements • Q.2: What unique requirements (not necessarily architectural) are imposed by wireless/mobile networking research on GENI? Specifically, if GENI were built to support networking research in wired network with wireless as the first (last) hop access technology, would that be sufficient for you to conduct your wireless/mobility research? Why or why not? • [CP] Enough unlicensed spectrum in enough bands that we can really play.   • [RK] Nodes should be able to move seamlessly between wireless networks connected to GENI. Imagine a group of nodes (bikers?) who start from CMU's mesh network, go to the UIUC mesh network, and travel to WINLAB. • [RK] A rich set of wireless technologies must be supported, 802.11?, WiMAX,Bluetooth, Zigbee, ... • [MD,KF] Explore the use of satellites, especially LEOs. Such satellites offer a radically different form of physical connectivity than fixed, engineered wireless links. They also behave differently than geostationary satellites, which are also interesting due to the relatively long propagation delay, but lack some of the dynamics of LEOs. • [MD,KF] Performance of wireless links in developing countries/areas. There is considerable current interest in • Regardless of advancements in the network and media access protocols, the links still may not work reliably due to power problems. It is therefore useful to be able to explore cases where these wireless nodes can be power cycled or degraded (e.g. to simulate weather-based degradation). Mobility is also important.

5. Question (3): Virtualization • Q.3: Would you argue for or against the statement "Wireless networks are much more difficult than wired networks to "slice" via "virtualization" and hence the number of experiments/services that can be conducted concurrently on a GENI wireless network is limited leading to lower ROI for tax dollars". If you agree with the above statement, why do you think so? If you don't, what are your arguments? • [CP] Number of experiments per unit dollar is a pretty poor way to measure like return -- one brilliant wireless experiment could prove more valuable than 100 wireline experiments (or vice-versa).  So I don't buy the statement. • [CP] Ignoring ROI, I'm not sure if wireless is easier or harder to slice.After all, there's plenty of spectrum, and one radio can presumablyparticipate in multiple groups, on different frequencies, at the sametime given enough horsepower and antennae.   • [RK] Yes wireless is hard to slice if the best radio you have for your research is 802.11! Wireless networking community should build a spectrally agile multi-channel radio that is inexpensive and can really exploit recent advances in communications and networking. • [RK] To go with this radio we will need an electromagnetically shielded testfacility where you can radiate anywhere in the radio spectrum with apermanent experimental license from FCC. • [RK] GENI should get better radios than WiFi/WiMax/Zigbee/Bluetooth.

6. Question (3) – Virtualization • [BF] I buy the argument that virtualizing wireless devices into "slices" may be _somewhat_ more challenging than for wired devices, I don't think it should be _that_ much more difficult, certainly not enough to justify a severe limitation of slicing/virtualization functionality.  Lots of the smart cell phones already run Linux anyway, and there are many ways to address resource limitation issues: e.g., make researchers work in less space, implement some coarse-grained gang-scheduling functionality to slice devices over time as well as internally, ... • [MD,KF] No fundamental reason why a wireless network should be "harder to slice" than a wired one. It is probably true that this slicing requires more engineering given current technologies, but it seems questionable whether there are really fundamental challenges we could not hope to meet. • [MD,KF] As to the ROI for tax dollars, the question implies that the ROI is based primarily on the number of concurrent experiments, a premise that we disagree with. In particular, the highest ROI may come in exploring a research space that we know very little about today, regardless of how many experiments in aggregate can be run. • [TB]Yes.  This is due to the broadcast and interference-limited nature of wireless.  Time division requires good synchronization, and due to the non-zero propagation delay, some timing slack (which either makes the slicing very bursty or very high overhead).

7. Question (4): Admission Control & Resource Reservation • Q.4: Admission Control (AC) and Resource Reservation (RR) are key requirements that MUST be supported in GENI to facilitate a wide range of wireless networking research. Do you agree with the above statement? If so, why? If not, why not? In other words, is it essential to support AC and RR in GENI or can we get by without these features and still do useful wireless/mobile networking research? • [CP] I don't think Admission Control matters. Resource Reservation in the sense of reserving a slice matters.  The more general problem, no. • [RK] I would say enough capacity and a protocol for sharing the (virtualized) resources may be sufficient.  Rigorous AC and RR may not be necessary.If the amount of configuration the researcher has to do to get his workdone is high, then they will likely roll their own testbed.  Even if necessary, admission control or resource reservation must be painless to configure and be transparent enough to not get in the way of experiments. • [BF] At least "soft" AC and RR would be highly desirable, but I'm not sure if they're really essential. • [MD,KF] This question presents a false dichotomy. AC and RR are necessary for some set of experiments, both wired and wireless, but in both cases, useful experiments can be done without AC or RR. • [TB] AC/RR is a nice feature that enhances controllability and repeatabilityabove the internet.

8. Question (5-a): End-user Opt-in • Q.5 (a): Should GENI allow end-user devices, such as, mobile phones and personal laptops, to become part of GENI experiments on an "opt-in" basis? If yes, what value would it bring? If not, why not? •  [CP] Why not?  Why exclude? •  [RK] Yes, absolutely.  It would be good to plan for them from the start and keep them real.  What fraction of the real world mobile wireless networking consists of embedded PCs running Linux with 802.11 interfaces?  I hope there will be a research community focusing on mobile security -- these real world devices will be a key part of understanding and addressing real threats and vulnerabilities. • [BF] Yes, absolutely: this capability could prove crucial to enabling new technologies developed and tested on GENI to "bridge the gap" from the research world into practical use.  I expect GENI could often prove instrumental in providing the "critical mass" in a cloud of cooperating devices required to get a new distributed technology going and in real use. • [MD,KF] Absolutely. Doing so brings human mobility, real users, and real traffic into the experiments, which are highly valuable to many kinds of experiments. • [TB] Opt-in devices will probably only be periodic members of GENI, will add management complexity (net and human), and are less controllable.

9. Question (5-b): Network Opt-in • Q.5 (b) What about allowing a Sensor Network testbed from a university or a WiFi Mesh Network testbed from a town/city as opposed to an end-user device (like a mobile phone in part (a)) to become part of GENI on an "opt-in" basis? Is there more complexity than value in supporting this feature? Or this is a key architectural aspect that must be supported by GENI? • [CP] I think having sensor network participation is good but I think sensors as a distinct topic is fading -- but GENI may help us puzzle that out. • [RK] It seems like there is an experimental part of GENI and a live network part that resembles NSFnet or Internet2.  It will be nice to allow community networks to participate in the live network part. • [BF] Again, yes, absolutely - but with the proviso thatthe rules be designed such that any substantial administrative burden caused by the integration of the third-party network testbed or mesh into GENI end up being primarily borne by that third party and not by GENI.This may for example mean requiring the third-party not only to take on any obvious, direct administration costs involved in this integration, but also to propose, develop, and submit to a suitable peer review process, any improvements to the GENI architecture and/or software infrastructure that may be needed to support the third-party add-on.  In other words,it is important that GENI be open to such add-ons but be careful not to let itself get bogged down in supporting them. • [MD,KF] If we're really talking about a platform to evaluate the future Internet, then all of these (and maybe more) should be represented or at least supportable. If it's a question of cost, then we would need to prioritize -- given a choice between urban mesh networks and sensor networks, we'd advocate mesh networks because there is more evidence of wide-scale usage.

10. Question (6): Mobile Nodes • Q.6: How important is it for GENI to support "mobile nodes" (such as, cars/buses etc.) for wireless/mobility networking research/experiments? Can one argue that it is enough to "emulate" mobility for conducting, say, vehicular networking research and not invest in expensive mobile nodes as part of GENI? What kind of research can and cannot be conducted in GENI without explicit support of "physically" Mobile Nodes? • [CP] Emulation is never the same as reality and in a world where no one trusts emulation results (I've got paper rejections to prove it), we can't buy into emulation. • [RK] Vehicular networking is of great interest to the community. Robotic networking (where agents are network-aware and adjust mobility when possible to get better communications while meeting mission objectives) would be nice to have too.Suppose a drive-by past a hotspot is 10 seconds, after discovery and other protocol exchanges, how much useful information can I actually exchange on one encounter?  Is the opportunity really only 5 seconds? When I am at highway speeds can I actually associate with an AP or should I use the ad hoc mode?  How does one change DHCP to work in such settings?  Can it be done?  How do I test how good my vehicular networking protocol will work in practice?At BBN we are emulating the contact with a mobile node by using nodes on elevators.  We also have a virtual testbed where the mobility can be emulated but the elevator nodes inject a lot more realism and challenges. While these surrogates are good for initial testing, I do not think we will be able to go to demo without actually doing somedriving around with the nodes.  Emulation is not sufficient!

11. Question (6) – Mobile Nodes • [BF] I think that GENI should aggressively explore avenues for operating real "mobile nodes" in relatively cost-effective ways: e.g., don't try to purchase and deploy a GENI-specific mobile fleet of some kind, but perhaps at least DO try to find and make deals with taxi and bus companies, companies with delivery fleets, etc., to place inexpensive and self-contained GENI nodes on vehicles that move around a lot anyway. • [MD,KF]For our research, this would be very important. We want to explore mobile platforms as well as mobile networks (e.g. ships or planes with small networks on the vessels that move together), and ways in which this mobility can be leveraged for transit connectivity. For example, a router could know that a ship is bound for a remote location and queue data to be physically transferred to the destination, or a router that is aware of airplane or satellite flight patterns could relay signals through the appropriate entity. • The problem with emulation is that there aren't currently good models for many of the effects of mobility on communication we are interested in. At a minimum, a GENI infrastructure needs to help develop the models that might be used in the rest of the system for mobility research. In addition, the use of emulation models reinforces our earlier point, that is critical to be able to have full control over the data flow and have good monitoring and analysis support.

12. Question (6) – Mobile Nodes • [TB] Real mobility is expensive.  It seems like emulations of mobility from real mobility connectivity traces would be a step in the right direction.  This also lends more repeatability to experiments. Part-time real mobility would be great.One approach would be to attach mobile agents to a scheduled service like buses as in Diesel net. In a large city, the number of nodes could be many and the patterns would be similar (though not repeatable) from day to day.

13. Back Up • Back up

14. Question (1) – contd. • Q.1: What architectural features would you like to see supported in GENI in order to facilitate your wireless/mobility research and experiments? Specifically, if GENI were built to support networking research in wired network with wireless as the first (last) hop access technology, would that be sufficient for you to conduct your wireless/mobility research? Why or why not? •  [RK] If the wireless network is a stub to GENI, what is new?  Don't wealready have wireless networks that work fine as stubs to the Internet?Sure, it is nice to have access wireless networks offering traffic, butis that all?A more challenging problem for GENI to  go after would be arapidly-forming mobile wireless transit AS for GENI that will repair(albeit at a degraded capacity) a catastrophic (Katrina/Tsunami scale)damage to GENI infrastructure.  The transit AS should go operational ina matter of hours and bridge GENI partitions.  GENI wired infrastructureshould support emulation of such a partitioning.Dreaming on a bit further, logistics should be more closely tied to thenetwork. An operator must be able to schedule the mobility of nodes torequired location to have a network deployed including attaching toinfrastructure points, become operational and torn down after therequirement is over.  Say, I want to provide better communicationscapability during a major event but do not want to build permanentinfrastructure.  Given the DARPA AGVs, all we should require is a creditcard and a website where we can order mobile comms on demand. :)The architecture should support both mobility (keep your endpointidentifier as you move a la Mobile IP) and nomadicity (readdress whenyou move a la DHCP) efficiently. 

15. Question (1) – contd. • Q.1: What architectural features would you like to see supported in GENI in order to facilitate your wireless/mobility research and experiments? Specifically, if GENI were built to support networking research in wired network with wireless as the first (last) hop access technology, would that be sufficient for you to conduct your wireless/mobility research? Why or why not? • [MD,KF]In short, placing wireless only at the 'edges' is not particularly attractive to us. One of our areas of interest is mobile networks (e.g. where clusters of nodes move together -- such as airplanes, etc), and where such networks can act as transit nodes (consider a collection of airplanes or air balloons, etc). • In terms of high-level architectural features, whether wireless or wired, we believe researchers should be able to have full control over the data flow, ideally all the way down to the physical / modulation layer. For example, some research may want to explore circuit-like services, rather than a packet service. More important and generally, it is essential to have control over routing, e.g. supporting source routing at a minimum, but more fundamentally to explore routing algorithms and be able to control where all data goes. It would also be useful to have persistent storage at all nodes, and to have rich error-generating and error-monitoring capabilities. • As to the second part of the question more specifically, we're interested in ad-hoc assemblages of networks, whether mobile or not, and whether wireless or not. Such scenarios involve cases where little infrastructure may be available, and will bring up challenges involving issues like addressing, security, auto configuration, etc. Therefore supporting wireless only at the edge is not really appropriate for these types of scenarios.

16. Question (2) – contd. • Q.2: What unique requirements (not necessarily architectural) are imposed by wireless/mobile networking research on GENI? Specifically, if GENI were built to support networking research in wired network with wireless as the first (last) hop access technology, would that be sufficient for you to conduct your wireless/mobility research? Why or why not? • [MD,KF] Turning to our specific (unusual?) desires, we'd like to explore the use of network infrastructure including satellites, especially LEOs. Such satellites offer a radically different form of physical connectivity than fixed, engineered wireless links. They also behave differently than geostationary satellites, which are also interesting due to the relatively long propagation delay, but lack some of the dynamics of LEOs. • We are also interested in the performance of wireless links in developing countries/areas. There is considerable current interest in adapting low-cost wireless (WiFi) for long distance use. Regardless of advancements in the network and media access protocols, the links still may not work reliably due to power problems. It is therefore useful to be able to explore cases where these wireless nodes can be power cycled or degraded (e.g. to simulate weather-based degradation). Mobility is also important, as discussed more below.

17. Question (3) – contd. • Q.3: Would you argue for or against the statement "Wireless networks are much more difficult than wired networks to "slice" via "virtualization" and hence the number of experiments/services that can be conducted concurrently on a GENI wireless network is limited leading to lower ROI for tax dollars". If you agree with the above statement, why do you think so? If you don't, what are your arguments? • [RK] Yes wireless is hard to slice if the best radio you have for yourresearch is 802.11!DARPA WNaN (WANN) can solve this problem if DARPA can make these radios publicly available. If not, the wireless networking community should build a spectrally agile multi-channel radio that is inexpensive and can really exploit recent advances in communications and networking.To go with this radio we will need an electromagnetically shielded testfacility where you can radiate anywhere in the radio spectrum with apermanent experimental license from FCC.GENI should get better radios than WiFi/WiMax/Zigbee/Bluetooth.

18. Question (3) – contd. • Q.3: Would you argue for or against the statement "Wireless networks are much more difficult than wired networks to "slice" via "virtualization" and hence the number of experiments/services that can be conducted concurrently on a GENI wireless network is limited leading to lower ROI for tax dollars". If you agree with the above statement, why do you think so? If you don't, what are your arguments? • [MD,KF] We see no fundamental reason why a wireless network should be "harder to slice" than a wired one. It is probably true that this slicing requires more engineering given current technologies, but it seems questionable whether there are really fundamental challenges we could not hope to meet. • As to the ROI for tax dollars, the question implies that the ROI is based primarily on the number of concurrent experiments, a premise that we disagree with. In particular, the highest ROI may come in exploring a research space that we know very little about today, regardless of how many experiments in aggregate can be run.

19. Question (4) – contd. •  Q.4: Admission Control (AC) and Resource Reservation (RR) are key requirements that MUST be supported in GENI to facilitate a wide range of wireless networking research. Do you agree with the above statement? If so, why? If not, why not? In other words, is it essential to support AC and RR in GENI or can we get by without these features and still do useful wireless/mobile networking research? • [BF] At least "soft" AC and RR would be highly desirable, but I'm not sure if they're really essential. • [MD,KF] This question presents a false dichotomy. AC and RR are necessary for some set of experiments, both wired and wireless, but in both cases, useful experiments can be done without AC or RR.

20. Question (5-a) – contd. • Q.5 (a): Should GENI allow end-user devices, such as, mobile phones and personal laptops, to become part of GENI experiments on an "opt-in" basis? If yes, what value would it bring? If not, why not? • [BF] Yes, absolutely: this capability could prove crucial to enabling new technologies developed and tested on GENI to "bridge the gap" from the research world into practical use.  I expect GENI could often prove instrumental in providing the "critical mass" in a cloud of cooperating devices required to get a new distributed technology going and in real use. • [MD,KF] Absolutely. Doing so brings human mobility, real users, and real traffic into the experiments, which are highly valuable to many kinds of experiments.

21. Question (5-b) – contd. • Q.5 (b) What about allowing a Sensor Network testbed from a university or a WiFi Mesh Network testbed from a town/city as opposed to an end-user device (like a mobile phone in part (a)) to become part of GENI on an "opt-in" basis? Is there more complexity than value in supporting this feature? Or this is a key architectural aspect that must be supported by GENI? • [BF] Again, yes, absolutely - but with the proviso that the rules be designed such that any substantial administrative burden caused by the integration of the third-party network testbed or mesh into GENI end up being primarily borne by that third party and not by GENI.  This may for example mean requiring the third-party not only to take on any obvious, direct administration costs involved in this integration, but also to propose, develop, and submit to a suitable peer review process, any improvements to the GENI architecture and/or software infrastructure that may be needed to support the third-party add-on.  In other words, it is important that GENI be open to such add-ons but be careful not to let itself get bogged down in supporting them.

22. Question (5-b) – contd. • Q.5 (b) What about allowing a Sensor Network testbed from a university or a WiFi Mesh Network testbed from a town/city as opposed to an end-user device (like a mobile phone in part (a)) to become part of GENI on an "opt-in" basis? Is there more complexity than value in supporting this feature? Or this is a key architectural aspect that must be supported by GENI? • [MD,KF] If we're really talking about a platform to evaluate the future Internet, then all of these (and maybe more) should be represented or at least supportable. If it's a question of cost, then we would need to prioritize -- given a choice between urban mesh networks and sensor networks, we'd advocate mesh networks because there is more evidence of wide-scale usage.

23. Question (6) – contd. • Q.6: How important is it for GENI to support "mobile nodes" (such as, cars/buses etc.) for wireless/mobility networking research/experiments? Can one argue that it is enough to "emulate" mobility for conducting, say, vehicular networking research and not invest in expensive mobile nodes as part of GENI? What kind of research can and cannot be conducted in GENI without explicit support of "physically" Mobile Nodes? • [RK]Judging by the literature in MobiCom/MobiHoc and its satellite workshops, vehicular networking is of great interest to the community. Robotic networking (where agents are network-aware and adjust mobility when possible to get better communications while meeting mission objectives) would be nice to have too.Suppose a drive-by past a hotspot is 10 seconds, after discovery and other protocol exchanges, how much useful information can I actually exchange on one encounter?  Is the opportunity really only 5 seconds? When I am at highway speeds can I actually associate with an AP or should I use the ad hoc mode?  How does one change DHCP to work in such settings?  Can it be done?  How do I test how good my vehicular networking protocol will work in practice?At BBN we are emulating the contact with a mobile node by using nodes on elevators.  We also have a virtual testbed where the mobility can be emulated but the elevator nodes inject a lot more realism and challenges. While these surrogates are good for initial testing, I do not think we will be able to go to demo without actually doing somedriving around with the nodes.  Emulation is not sufficient!

24. Question (6) – contd. • Q.6: How important is it for GENI to support "mobile nodes" (such as, cars/buses etc.) for wireless/mobility networking research/experiments? Can one argue that it is enough to "emulate" mobility for conducting, say, vehicular networking research and not invest in expensive mobile nodes as part of GENI? What kind of research can and cannot be conducted in GENI without explicit support of "physically" Mobile Nodes? • [MD,KF] For our research, this would be very important. We want to explore mobile platforms as well as mobile networks (e.g. ships or planes with small networks on the vessels that move together), and ways in which this mobility can be leveraged for transit connectivity. For example, a router could know that a ship is bound for a remote location and queue data to be physically transferred to the destination, or a router that is aware of airplane or satellite flight patterns could relay signals through the appropriate entity. • The problem with emulation is that there aren't currently good models for many of the effects of mobility on communication we are interested in. At a minimum, a GENI infrastructure needs to help develop the models that might be used in the rest of the system for mobility research. In addition, the use of emulation models reinforces our earlier point, that is is critical to be able to have full control over the data flow and have good monitoring and analysis support.