Transcript Title

Wireless and Mobility Architectures
Expectations and Requirements for GENI
Sanjoy Paul (Moderator)
Wireless Information Network Laboratory (WINLAB), Rutgers University
1
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 endpoint
identifier as you move a la Mobile IP) and nomadicity (readdress when
you move a la DHCP) efficiently.
2
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 errormonitoring 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.
3
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.
4
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 presumably
participate in multiple groups, on different frequencies, at the same
time 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 multichannel 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 test
facility where you can radiate anywhere in the radio spectrum with a
permanent experimental license from FCC.
[RK] GENI should get better radios than WiFi/WiMax/Zigbee/Bluetooth.
5
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 gangscheduling 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).
6
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 work
done 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 repeatability
above the internet.
7
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.
8
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 that the rules be designed such
that any substantial administrative burden caused by the integration of the thirdparty 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.
9
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
10
actually doing somedriving around with the nodes. Emulation is not sufficient!
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.
11
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.
12
Back Up

Back up
13
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 we
already have wireless networks that work fine as stubs to the Internet?
Sure, it is nice to have access wireless networks offering traffic, but
is that all?
A more challenging problem for GENI to go after would be a
rapidly-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 in
a matter of hours and bridge GENI partitions. GENI wired infrastructure
should support emulation of such a partitioning.
Dreaming on a bit further, logistics should be more closely tied to the
network. 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. Given the DARPA AGVs, all we should require is a credit
card and a website where we can order mobile comms on demand. :)
The architecture should support both mobility (keep your endpoint
identifier as you move a la Mobile IP) and nomadicity (readdress when
you move a la DHCP) efficiently.
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?
 [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.

15
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.


16
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 your
research 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 test
facility where you can radiate anywhere in the radio spectrum with a
permanent experimental license from FCC.
GENI should get better radios than WiFi/WiMax/Zigbee/Bluetooth.
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?
[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.
18
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.


19
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.
20
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 enduser 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.

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?
[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.
22
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!
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?
[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.
24