[RRG] Concerns about the RRG process ... & how not to design an airliner

[Robin Whittle <rw@firstpr.com.au>]

Short version:    I think the RRG's aim of creating a fresh design
                  for a future routing and addressing architecture
                  runs into problems due to the fact that each
                  viable alternative design involves many inter-
                  related specific technologies which only make
                  sense together.

                  So the questions the RRG is trying to answer
                  often need to be different for each different
                  practical solution - yet we haven't chosen
                  any one such solution yet.

                  Some highly speculative thoughts on what might
                  happen after the RRG completes its work.

                  Exploration of the difficulties of this process
                  by way of an RRG-like Airliner Research Group
                  and its task of designing an airliner from scratch
                  - when most of the group are members of design
                  teams with completely different concrete proposals
                  for a new airliner.


Here are some concerns I have about the RRG's process, as best I
understand it.  I don't have a clear alternative which would be
better, but I anticipate some problems in the way this work
will progress.

I am not intending to criticise individuals - or the RRG in
principle.  The only alternative I can think of is for the RRG not
to develop an actual architectural specification, but to host a
constructive debate about the current proposals, and to produce a
report on their relative merits - or more importantly, on the merits
of their differing assumptions, goals, architectural principles and
major low-level implementation techniques.

I am not sure the RRG could re-invent itself to do this.  I am not
confident enough about this alternative to suggest it seriously.

However I want to raise some concerns about the process as I
perceive it now and in the next year.


To illustrate my concerns about how this may work out, I refer to
an ARG - Airliner Research Group - which is charged with developing
a written spec which ideally would be chosen by a higher committee
and given to bunch of engineering teams.  The result of those teams'
work would be a practical and generally optimal design which could
be built by multiple companies, perhaps in somewhat different ways,
to suit a large part of the commercial passenger airliner market for
the next few decades.

My understanding of the RRG process is based on:

  http://www.irtf.org/charter?gtype=rg&group=rrg  Charter.

  http://tools.ietf.org/html/draft-irtf-rrg-design-goals

  http://psg.com/lists/rrg/2007/msg00686.html  Schedule to 2009-03.

  http://psg.com/lists/rrg/2008/msg00794.html  Intended results:
  the form of recommendation for a new architecture.

and also on recent messages from Tony opening up discussion on
"granularity of the mapping system" and "dynamics of the mapping
system".

On one hand, I think there are some good things about the current
approach - but overall I see it as becoming unwieldy and
unproductive.  I fear the final result would not be a good enough
document from which to build the optimally designed new
architecture.  "A camel is a horse designed by a committee" comes to
mind.

In all this, I am going to focus only on the five current map-encap
proposals LISP-ALT, LISP-NERD, APT, Ivip and TRRP.  The RRG is also
hosting discussion of non-backwards compatible architectural
changes, but I am not involved in this, since I think we need a
backwards compatible approach, and that such an approach could do a
pretty good job.

The positive elements I see about the RRG's process :

1 - Firstly, encouraging the various teams to discuss the problem,
    the potential solutions and their own proposals together on one
    mailing list - and in face-to-face meetings.

2 - Secondly, by raising high-level, relatively abstract, questions
    which may open up discussions which lead to new ideas, new ways
    of combining old ideas etc.

So I see great value in the RRG facilitating the "brainstorming
phase" of developing a new routing and addressing architectural
overlay.  I am sure this is the phase we are in, although I think
some LISP folks seem to think they have enough of the answers to
start substantial engineering work on the final system.

I think there is considerable potential value in the current process
aiming to discuss, develop and finally release an architectural
description, as described recently by Tony.

Firstly, the resulting discussion is likely to be illuminating to
all concerned, and to lead to improvements in each proposal, and an
improved understanding of the strengths and weaknesses of each proposal.

Secondly, I think the final spec could be very useful for the IESG
in deciding what to do next.

However, I find it almost impossible to believe that the final RRG
spec in March 2009 will be a better document for developing a
practical new architecture than every one of the map-encap proposals
at that time.

I think that what will happen is something like this, assuming that
there are no more entries into the map-encap race and that each of
the four current contestants I will call ME1, ME2, ME3 and ME4
remains in active development and gains some kind of team of supporters.

This is pure guesswork on my part and I imagine other people have
different views.  I am not trying to say this is what I want to
happen - just my guess of what may happen.

There will be at least five sets of documents in front of the IESG:

 1 -  RRG Design Goals, RADIR Problem Statement, RRG proposed
      architectural description.  I assume this will be a single
      proposal, recommended for development in one or more WGs,
      rather than containing significant choices about the
      architecture - with recommendations on how to do each
      option.

 2 -  The ME1 IDs and whatever other material there is supporting
      this proposal.

 3 -  Likewise for ME2.
 4 -  Likewise for ME3
 5 -  Likewise for ME4.

Then I guess a lot of other people who weren't involved in the RRG
process will become interested and revisit the basic questions,
asking questions like how urgent it really is to save the DFZ
routers from the growth in the number of advertised routes.

I guess there will be questions about whether the proposed solution
will solve other future architectural needs, such as:

 1 - Mobility.

 2 - QoS.

 3 - Improved security, privacy of data or whatever - including
     spam reduction.

 4 - Transition from IPv4 to IPv6 or maybe something else.

A big discussion will likely ensue and I guess that towards the end
of 2009, the IESG will choose to develop at one map-encap scheme -
or perhaps two.

But I think it is unlikely that the RRG architectural specification
will be a 1:1 fit with any of the MEx proposals.

The initial human energy needed for developing a map-encap scheme
will probably be largely in the MEx teams.

I guess that no team would support the RRG architectural
specification in preference to its own.


It is possible that, by some objective measure (which can't be done)
the RRG spec would in fact a better basis for developing the future
architecture than any one of the MEx proposals.  However, I find
this hard to imagine, for reasons I discuss below.

In that case, I guess the IESG might look at all the material before
it and use the RRG spec as a guide to choosing one of the MEx
schemes.  A major deciding factor in this choice would probably be
how many people are in each team, how experienced they are, how well
placed they are to do the work etc.  Also, if two schemes were
pretty similar, perhaps some folks from the team which is not chosen
would be happy to work on the proposal which is chosen.

But the only good reason I guess the IESG would have for deciding to
develop the RRG spec directly would be something like it doesn't
think any one of MEx is good enough, and that the RRG spec is better
- and it thinks that there will be sufficient human energy to
develop the RRG spec - presumably from the MEx teams, once all the
MEx proposals have been rejected.

For this to be true, the RRG process would have to work better than
I can currently imagine, and every one of the MEx teams would have
to have to be stuck to its own initial ideas, rejecting
improvements, cross-pollination etc. so it didn't improve itself over
the next year to be a better, more coherent, more detailed, more
optimised, integrated proposal than whatever the RRG produced.


I tend to think that one MEx scheme MEP (the most popular map-encap
scheme in 2009-03) will become generally favoured due to technical
excellence and would gain a greater support base and bigger team of
developers than the other.

Then, the RRG spec would probably be more compatible with MEP than
with the others.

Then the IESG would probably favour development of MEP rather than
the RRG spec because:

  1 - The largest team of map-encap developers favours MEP over
      the RRG spec.

  2 - MEP is closer to the RRG spec than the others.

  3 - The IETF thinks it is better to choose a complete, integrated,
      already reasonably developed scheme rather than use the more
      abstract RRG spec, which would require many questions be
      revisited, and which contains some characteristics which the
      largest team of developers think are a bad idea.

  4 - The IETF thinks it is best to start standardisation now,
      rather than create some other stage of RRG-like research,
      attempt at convergence etc.


There are other possibilities - such as two map-encap schemes which
are completely different, both having large teams of supporters,
with it not being completely clear to the IESG that one is
substantially better than the other from technical or likely
deployment perspectives.  Then, I guess, the IETF might let them
both be developed in separate WGs.   This is my guesswork -  most
list members know a lot more about the IETF and IESG than I do.


Here are my concerns about the RRG process as I understand it, by
way of the ARG process.

Ivip Aviation has a novel design with some unusual elements which
supposedly make sense together.  Carbon fibre fuselage and wing
spars are made to work, despite their brittleness (for which reason
they are normally rejected) due to a combination of the materials in
the skin and special dampening of stresses with novel, slightly
flexible, epoxy bonding resins which attach the spars to the skin.

APT Aerospace has an unlikely looking biplane design that catches
everyone's eye.  But it is not a gimmick - the upper and lower wings
have completely different structures due to their differing roles
(compression and extension forces dominating their loads).  Some
highly developed inter-wing struts and boron-passivated carbon fibre
cables give the entire structure much greater strength than would
otherwise be the case with a mono-wing design.

Plus, the wingspan is small for the required lift, so it can fit
into a 737 airport bay while carrying 747 passenger loads.  Also, it
is designed to do 2G 60 degree bank turns, recover from stalls and
perform aerobatic rolls and loop-the-loops.  The APT design promises
to open new lines of business in mass-market aerobatics, to be
developed from an amusement park marketing base.

Herrin Developments has a flying wing proposal, straight out of 1957
Popular Mechanics, but which makes a great deal of sense due to the
integrated structural nature of the craft, and the use of four
pusher turbo-prop engines.

Cisco Aviation, true to its history, uses relatively conventional
techniques (aluminium structural components, etc. just like 1980s
airliners), but the craft closely resembles the Lockheed
Constellation.  (Is this the most beautiful airliner ever?  I saw
one gleaming in the sun and heard its engines brought to life, one
by one, each with an awesome roar and with streams of smoke and
flames erupting from the exhausts.)

The Cisco design uses turbocharged, diesel, radial engines which
resemble those in the Constellation.  These perform better than jet
engines, and run on a wide range of less refined fuels.


Now to the ARG discussion list.

The first question is how many passengers the craft is supposed to
take.  Debate ensues, and some figure is tentatively arrived at
which is not too far out of line with the four proposals.

Then the question of maximum range, maximum altitude, robustness in
turbulence etc. is resolved in a similar fashion.

So far, so good.

Then a debate occurs about what the ARG should be aiming for in an
airliner.  Some people maintain that there is really a big
application for ARG-style aircraft in freight, which is outside the
ARG's terms of reference.  They argue that if the design could be
used for freight - ideally with each plane easily converting to
freight or passenger formats or handling a variable mixture of the
two - then there would be much greater demand and therefore
economies of scale in final production.  However the ARG is wary of
being distracted from its task of building a passenger airliner,
despite some teams insisting their plans for freight don't add
complexity to the passenger version of their design.

Next the ARG needs to decide on some fundamental aspects of the
wings: their inner structural elements and their skin.

It proves impossible to create a single spec, because each proposal
has a fundamentally different design, which poses different
questions - which in turn leads to different answers and the need
for quite different types of design spec.

This is where the ARG gets bogged down.  Each proposal has
interesting and novel techniques, but they can't be picked as if
from a smorgasbord and combined into a proposal which will work.

Cisco Aviation's design relies for its performance on a novel
riveting system - carbon-fibre titanium composite rivets with the
same coefficient of expansion as its specially developed skin, which
is a stainless-steel - titanium - stainless-steel molecularly bonded
sandwich.

The ARG can't very well have a question about "skin bonding"
techniques and resolve that the ARG plane will use these excellent
Cisco rivets, unless it goes with the whole Cisco wing and spar
design.  This rivet system would be at odds with most elements of
the Ivip design, and would not be needed at all in APT's lightweight
biplane structure where the strength is in the inter-wing spars and
cables, rather than primarily in the wings.

Meanwhile, Boeing Aerospace (which for some reason doesn't have a
proposal) reminds the ARG that it really needs to consider how the
ARG craft will fit into existing airports.

The Ivip and Herrin crafts already have folding wing-tips, so they
pass muster.  APT's biplane has a short wingspan, so it is fine too.
Cisco Aerospace assures the ARG that airports are getting bigger
all the time, but that if during the initial test flights, their
magnificent craft take out more than a TBD number of terminal
buildings while taxiing, the wings will be redesigned to rotate on
their axis - and the airplane will perform Vertical Take-off and
Landing wherever needed.

Likewise there are problems when the ARG tries to frame questions
which will lead to a specification for the optimal fuselage design.

The Herrin craft doesn't have a fuselage.

Problems arise again with tailplane design.  The Cisco plane has
three vertical stabilizers (AKA rudders or fins) and the APT and
Ivip planes have one.

The Herrin flying wing has no tailplane.  One of the key attributes
of the design is that the number of vertical stabilizers is user
selectable - since they can be spaced out all along the flying wing.
 A variety of different lengths and profiles of vertical stabilizers
can be plugged in prior to service on a particular route, according
to expected turbulence, airport approach flight paths etc.  These
are exceptionally thin, strong, vertical stabilizers with much
reduced drag compared to those used in the other design.

When it comes to the environmental sustainability section of the
spec, how can the ARG formulate a single recommendation when each
technique depends so much on the other elements of the design?

Stock-market rumours have it that Cisco's diesel radial engine works
fine on a blend of reclaimed cooking and motor-car engine oil - but
the company won't confirm or deny it.  Each cylinder has a multi-CPU
chip simulating the next combustion cycle in order to optimise the
timings of the multi-element injector, according to the results of
real-time fuel analysis and all operating conditions.

Ivip's contribution to the environment is that its airframe is
supposed to last as long as that of a DC3 (many 60 years old and
still flying).

One of the major design features of the Herrin craft is that the
vertical stabilizers have no moving parts and are steered as a
complete unit from below.  The stabilizers are a balsa core with
carbon-fibre composite.  (Balsa wood exceeds all man-made materials
in certain characteristics which make it the optimal material for
some sandwich structures.)  They are cheap, have a limited service
life - like helicopter rotors blades - and can be recycled as
firewood.  However the company is researching a plan to eject end-of
life stabilizers over third-world countries where they will flutter
safely to the ground and be used as roofs for a modular housing
system.

Again with avionics software, the ARG finds it hard to specify the
structure and function which is best for its still-developing
design.  Ivip uses one open-source system and APT another.  Cisco's
plane uses its proprietary avionics software, well known in the
industry since the company's first World War I canvas and wood
biplanes.  Herrin Development's plane uses YAAP (Yet Another
Avionics Package) - with patches for the variable number of vertical
stabilizers.  All these systems have fundamentally different
structures and rather different goals - so the ARG can't formulate a
functional description for its design which both matches what is
possible, and which most people are happy with.

The LISP, APT and Ivip folks don't have a lot to say when it is time
to discuss the "Sprung Dance Floors" part of the ARG spec.

All Herrin airliners are flying wings and have a large disco /
aerobics room.  The company made its name initially on sales to
airlines concerned about deep-vein thrombosis and then had further
successes when these airlines discovered a whole new market for
party flights.  Now that "Herrin" is a verb universally understood
as meaning "partake in an off-the-planet flying dance party", the
company is seeking to broaden its franchise - first targeting the
retiree demographic by making the disco / aerobics room double as a
ballroom with 19th century-style sprung floors.


While the Herrin engineers scour historical records for information
on sprung dance floors, whilst trying to figure out how to make
their version from transparent polycarbonate panels to maintain the
fabled view, we now return you to normal programming . . .


The fundamental problems seem to be:

  1 - The optimal design for any airplane (routing addressing
      architecture) will involve a carefully integrated set of
      principles and techniques where the trade-offs and
      synergies bind the elements together in a unique and
      highly productive manner.

  2 - Two or different designs could aim to achieve similar or
      identical goals in radically different ways.  They might
      achieve the same performance, or two different sets of
      performance values, one not obviously better than the other.

  3 - The ARG (RRG) process constrains it to developing a
      single proposal.

  4 - At many stages of deciding what individual parts of the ARG
      will entail, different answers would be optimal, depending on
      what was chosen for other elements of the design.  But many
      of those choices have not yet been made - and some of those
      which have been are at odds with the wishes of some of the
      teams of designers.


The RRG is currently considering "Dynamics of the Mapping Function".
Each of the map-encap scheme has a different approach to mapping -
and so the design criteria are different for each such scheme.

My initial thought is that the only way the RRG could properly
answer this question is on the basis of multiple answers based on
multiple sets of assumptions about the rest of the design.

For instance, when asking the question "How many alternative ETR
addresses should the mapping and ITR system be optimised to cope
with, and what is the maximum number of ETR addresses it should be
able to cope with?"

The answer from the LISP, APT and TRRP camps will come back in
somewhat similar forms, but the Ivip camp says:

  If the entire mapping, fast push, query server and ITR system
  can propagate mapping changes to all ITRs in a few seconds, then
  it is not necessary to have multiple ETR addresses at all.

So does the RRG decide on a two-part answer to this?

   For all schemes which lack the ability for effectively real-time
   control of ITRs' mapping, optimise performance for X ETR
   addresses and cope with a maximum of Y ETR addresses.

   For schemes which have real-time control, there is only a need
   for a single ETR address.

Likewise, there could be two-part answers to questions about how
ITRs detect reachability to ETRs and decide about which alternative
ETR to use - since Ivip (and I think APT) ITRs don't do that.

Maybe the RRG will pursue this multiple conditional answer approach.
 I think it would be good if it could be done systematically.

However, I can imagine us getting tangled in debates.  For instance
even within the above example, the LISP, APT and TRRP camps would
probably have different values for X and Y, due to some important
differences between their architectures.


 - Robin                 http://www.firstpr.com.au/ip/ivip/




--
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