[RRG] Benchmark scenario for modeling

[ksriram@nist.gov]

I would like to request some feedback on a benchmark scenario I propose below
for modeling different proposals (or architectural choices) and evaluating
their performance. Let me mention upfront that the scenario we describe
here is to create a model of address migration and mapping dynamics, 
and is not meant to be considered as a real solution to the situation described.

I think it would be useful to have a plausible but somewhat stressful
kind of scenario involving subnetwork or group migration, but not
involving or requiring connection continuity for now
(we may introduce some connection continuity in a later phase
of creating the modeling scenario).

The benchmark scenario for modeling that I propose is as follows:

(Note: I start with the airline-related scenario because I feel it 
represents significant mapping dynamics / churn.  I mention other 
plausible applications or components of the overall scenario later.)

Consider a large airline company XYZ which has its hub in Chicago.
Several hundred of its airplanes fly to numerous destinations within
North America and many destinations in other continents every day.
They are providing WiFi-WiMax-based Internet access to passengers 
during these times:
(a) when the airplane is on ground until readying for takeoff,
(b) immediately after landing until arriving at the gate,
(c) while the airplane is at the gate and passengers
    are waiting in the gate area prior to boarding,
(d) for sometime after the passengers have deplaned
    but still linger near the gate to finish an email or check map etc..

While in-flight, no Internet access is available but they have 
intranet access with on-board servers providing regionally-tailored
services ? cached IPTV/video, video games, in-flight shopping, etc. 
This does not figure into our modeling directly, but influences 
the use of address space as noted below.

Let us say that the access control is done by requiring passengers
to login with flight number, name and confirmation number
(no need to model this -- mention it here just to indicate there is no
contention in the address allocation space within the subnetwork).

This overall benchmark scenario should ideally include many airlines
doing this on hundreds of their planes/flights while each has
its hub in a different city.

Let me try to articulate now the address space allocation
and subnetwork or group migration scenario we have here.

Let us say, the airline XYZ owns an IPv4 PI space denoted as x/12.
Let us say it splits this PI space into 1024 subnetworks or EID-groups,
each a subprefix of the form x(i)/22, where i = 1,2, ..., 1024. 
It allocates x(i)/22 to plane i for each of its 1024 planes 
(i = 1,2, ... , 1024) in use around the world.
A subset of this address allocation is used for on-board severs which
are updated automatically at times with downloads ? from
servers in the headquarters ? of regionally-tailored content 
such as cached IPTV/video, video games, in-flight shopping, etc.
This may be part of the reason why they want to use PI address space,
with willingness to migrate parts of it into the map-encap space 
as needed ? see explanation below.  

Airline XYZ originates x/12 from its AS in Chicago using eBGP
so that by default any x(i)/22 address will be routed to
its AS in Chicago unless EID-ETR mapping is currently available
for the longer match prefix (in an ITR accessible to the source).
When the plane i arrives at a destination, it registers
immediately with a locally contracted ISP and its subnetwork
PI space x(i)/22 is injected into the map-encap space by that ISP.
When the plane i departs from a destination, its address
space x(i)/22 is de-registered from the local ISP there.
This process repeats when the plane arrives at and subsequently 
departs from intermediate or final destination airport(s).
Whenever the plane i returns to its hub (Chicago),
all mapping information would have been withdrawn already for it
and routing to its address space x(i)/22 again happens via the DFZ
entry for prefix x/12 in the global routing table.
This makes sense because a large fraction of airline XYZ's planes
spend a reasonable amount of time at the hub site
(i.e. XYZ's domain in Chicago) everyday.

The model calls for thousands of planes belonging to many airlines
flying to thousands of different destinations. They are all doing
the above stated PI subnetwork address registrations with different
contracted ISPs at different destinations for varying durations
of time during a day. At those times, their corresponding subnetwork
or EID group/prefix is serviced using the map-encap scheme and
mapping distribution (push, pull/query, etc. choice) is invoked.
But when a plane is back at its hub (during whatever times of
the day), the DFZ routing is in play for it for that duration.

Thus what we have here are: (1) large PI address space split into many 
subnetworks, (2) these subnetworks are mobile (not requiring connection
continuity for the present scenario), (3) when at destinations away from 
hub they are serviced via map-encap method, (4) when they get back to the
hub (home), they are reposited (implicitly) in their respective parent 
PI prefixes (e.g., the x/12) which are routed by eBGP.

We can add to the above scenario other mapping dynamics such as subnetworks
migrating due to movement of trains and inter-state buses, and the mapping
changes due to the dynamics of multi-homing and traffic engineering.
All of this can be parameterized with suitable assumptions (TBD) to create 
mathematical models to input into a network modeling / simulation tool.  

I propose that we model and evaluate under this overall scenario the
various mapping distribution protocols and begin to understand the
pros and cons of various architecture choices such as push, pull, 
push-pull hybrid, strong hierarchy (as in ALT), full database ITRs,
default mappers, caching ITRs, distributed query servers, etc.,
and whatever combinations thereof constitute each proposal.
The performance metrics can be, for example, the query
response behaviors, initial packet delay/loss, cost of deployment, etc.

Perhaps not an easy task, but some efforts need to be made 
towards modeling.

Comments/suggestions to reshape/modify/expand this scenario 
would be very welcome. Suggestions about details of parameterization
and some realistic assumptions to assign ballpark values to 
those parameters in the modeling scenario would be very helpful.

Sriram

K. Sriram
E-Mail: ksriram@nist.gov
Web:  http://www.antd.nist.gov/~ksriram/

--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg