Re: [Int-area] Re: Architectural reasons why tunnelling is an indication of a failure

[Joe Touch <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Pekka Nikander wrote:
> Brief summary of the discussion so far:
> ---------------------------------------
> 
> I made the claim that tunnelling, while being sometimes (but not 
> always) a fine tool, is an indication that the architecture has 
> shortcomings, and therefore has "failed" in some sense of the word.  
> [Apparently the word "failure" was too strong, but at least it 
> generated some discussion :-)]
> 
> A number of people replied that tunnels are a useful tool for 
> virtualising the address space, similar to virtual memory in von  Neuman
> architecture.  One could claim it even to be similar to  virtual machines.
> 
> Clarifications on my side:
> --------------------------
> 
> I am definitely not saying that tunnelling is bad and that we should 
> ban it; quite converse.  As several people mentioned it is a fine  tool,
> often allowing much faster evolution and often leading to  easier
> operations.
> 
> What I am trying to do is to understand the pressures that lead to  the
> currently very common use of tunnelling (with its apparent more 
> technical problems).  One way to express my feeling is the  following: 
> I think that we should not need tunnelling; i.e., our  architecture
> should be powerful enough so that (most current) needs  of tunnelling
> would disappear.

That's like, IMO, saying that a sufficiently powerful computer
architecture would not need virtual memory.

The current uses of tunneling may be point solutions, rather than more
comprehensive architectural extensions, but many (not having done an
exhaustive search, I won't say 'all') are based on the need for exactly
the layer of abstraction and address isolation that virtualization provides.

Again, recalling VM, earlier point-solutions like memory overlays, and
loadable modules explored aspects of VM and were based on the need for
what VM provided, but lacked the integrated, coordinated capabilities
that VM provides (i.e., to share pages between processes, coordinate
resource use, etc.)

> In this message I am still trying to argue in favour of my position 
> that tunnelling is an indication of something missing, mainly  pointing
> out that there are alternatives to virtualisation, both in  computer and
> network architecture.
>
> If we can go further and try to understand the alternatives and there 
> potential implications, that would be even better.
> 
> Going further:
> --------------
> 
> I think comparing tunnelling to VM is a good analogy, and certainly 
> something that I missed in my original thinking.  [Thanks to  everybody
> that pointed it out.]  However, I also think that we are  not doing a
> very good job there.
> 
> I am framing my argumentation below as follows:
> 
> 1. There are architectural alternatives to today's virtual memory.
> 2. Virtual machine is more than virtual memory.
> 3. None of our current tunnelling practises come even close to the 
> level of abstraction provided by either the virtual memory or virtual 
> machine abstractions.
> 4. Even if we may get a clean virtualisation architecture with IPv6,  we
> are not there yet, and may not be clear where, exactly, we should  be
> going.
> 
> Details:
> 
> 1. Architectural alternatives to virtual memory
> ===============================================
> 
> If we think about today's virtual memory systems it consist of two 
> apparent mechanisms that seem to be orthogonal:
> 
>  a. Mapping virtual addresses to (different) real addresses
>  b. Protection bits, providing lots of functionality
> 
> If we consider address mapping first, there are certainly  architectural
> alternatives.  For example, if you have a large enough  address space,
> you could use position independent code.  With proper  support at the
> processor level that can be done as convenient as  virtual-memory-based
> mapping.  The amount of hardware needed is  basically the same; the
> difference is on the abstraction.
> 
> I am not going to the protection part.  It is apparently a very  useful
> abstraction, providing lots of useful functionality such as 
> copy-on-write, flush-on-dirty, etc.
> 
> The point is that even a good virtualisation abstraction seems to 
> consist of several components, some of which don't _necessarily_  imply
> others.

What you've shown is that you can achieve aspects of VM with
alternatives, but not that you can replace what VM does.

Position-independent code means "make the compiler/machine aware of the
need to run anywhere in memory", which isn't the same as "provide an
environment where the compiler/machine doesn't need to know or care".
The latter is what VM provides, and PIC hasn't replaced it.

> 2. Virtual machine is more than virtual memory
> ==============================================
> 
> The majority of today's hardware does not support full virtual  machine
> functionality, i.e., virtualising also the protected mode.   In the main
> stream architectures it has been appearing only  recently. 
> Consequently, many of today's virtual machine products  either use
> software to "cheat", resulting in architecturally ugly  (but useful!)
> solutions, or are fully implemented in software, with  the apparent
> performance penalty.
> 
> My point here is full virtualisation, such as in the case of virtual 
> machine, requires much more than just virtualising the address space.

Yes - see some of our work on the X-Bone for a discussion on what else
is needed, a more recent version of the overview of which is in:

J. Touch, Y. Wang, L. Eggert, G. Finn, "Virtual Internet Architecture,"
ISI Technical Report ISI-TR-2003-570, March 2003.
http://www.isi.edu/touch/pubs/isi-tr-2003-570/

> 3. Our current tunnelling practises are not very clean
> ======================================================
> 
> Returning now to the current IP-over-IP tunnelling practises (which 
> seem to be closest to virtualisation), I claim we could do much better.
> 
> The first issue, which I already touched, relates to muddled address 
> space semantics.  While one could argue that RFC 1918 addresses are 
> like the virtual address space in a virtual memory system, that  AFAICT
> doesn't quite hold.  The difference lies in how you  communicate with
> components outside of that virtual space.

1918 addresses are equivalent to a VPN-ID, except for the number of bits
in the per-overlay address space. Second, communicating between virtual
spaces is not something the basic version of virtual nets get for free -
what they need is something - akin to a gateway - that sits in both
address spaces, and translates between the two. This isn't anything like
a router, though.

> Having a very large address space with no overlapping addresses seems 
> to lead to a cleaner architecture than mapping address spaces.  For  us,
> going to IPv6, Unique Local IPv6 addresses (draft-ietf-ipv6-
> unique-local-addr-XX.txt; sometimes called Hinden-Haberman addresses) 
> may help.

If you're completely ignoring the address space differences, then, going
back to VM, you're proposing PIC with a single large address space. That
doesn't allow you to support large programs in a small amount of memory
- - akin to 'revisitation' in virutal nets.

If you consider the large address space split into chunks, that's just
moving the VPN-ID outside to the front of the address and calling the
concatination one large address. That's basically what VM does
(large-memory address = page + small memory address).

> If you go there and get rid of RFC 1918 addresses, returning to 
> addresses that are globally unique, what remains is the question of 
> routing.  For practical reasons, it looks like that people may need  to
> use tunnelling even for Unique Local IPv6 addresses.  The reason  for
> this is that the routing system does not easily allow them to be 
> globally routable, which, in turn, leads to another architectural 
> question:

The question I would place here is: where are the 'links' in your
virtual topology? Tunnels are those links, which is why you still need
them, IMO.

>   Should the routing system better support local-only routes?
> 
> [There are lots of potential answers to both the narrower practical 
> question and to the larger architectural one; e.g. use MPLS, use  source
> routing, etc., but that is not the point of this message.  The  point
> here is that the fact that tunnelling is needed may, again, be  an
> indication that some functionality is missing elsewhere, in this  case
> in routing.]
> 
> 
> A second (perhaps converse) issue here relates to layering.  Some 
> people expressed their belief that IP is such a useful service that 
> building virtual topologies over an existing one is beneficial.  
> Certainly so, but my question is now much of this is caused by  current
> architecture, i.e., the fact that IP addresses are  simultaneously used
> as identifiers and locators.  If these two roles  were separated (most
> probably leading to two having (sub)layers  instead of the currently one
> IP layer), what would that virtual  topology bring?

I've already listed the things it brings above, and it's more than just
address space management (below).

> My claim is that if we did the split, there would be much less need  for
> "managing" the IP address space, leading to a situation where  most (if
> not all) long term needs for IP virtualisation would disappear.
> 
> 4. Full virtualisation for IPv6
> ===============================
> 
> A major question now appears to be what we should do about IPv6 and 
> tunnelling?  Based on the discussion to far it appears to me that it 
> may be a good idea to try to figure out a full virtualisation 
> architecture for IPv6, i.e, one resembling virtual machines (instead  of
> virtual memory).  That leads to a number of more practical questions:
> 
> - Who would need it?
> - What would be the requirements that it would fulfil?
>   - e.g. what do people need topology abstraction for?

P2P nets are a good example where forwarding matches a virtual topology.
There are challenges to supporting forwarding based on application-level
information; that info needs to be at the network layer, e.g., in flat
IDs (hashes) or IDs with other structure than what we currently use.
I.e., we need to be able to use other IDs and other forwarding
algorithms to make this work, but that too is being explored (e.g., our
own Datarouter in Proc. IWAN 2003, also in Carzaniga, A., Wolf, A. L.,
?Forwarding in a Content-Based Network,? Proc. Sigcomm 2003, Aug. 2003,
pp. 163-174.).

>   - what level of emulation are we expecting
> - What is missing (if anything) in the current solutions we have?
> 
> Maybe all we need is a BCP explaining how to use existing components  in
> the best possible way for virtualising IPv6 in a local network,  with
> appropriate barriers between the local and outside world?
> 
> But before that I'd like to here what are the real benefits that  people
> would expect to get from it, as I am personally having hard  time seeing
> them.
> 
> --Pekka
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFC+SSAE5f5cImnZrsRAkFjAJ9GtXJ4T8veaQ8XZMJ7xHKqF6c/5gCgkOAL
ktB4LhhI/ntnnHfFExzC6fk=
=Nqw9
-----END PGP SIGNATURE-----

_______________________________________________
Int-area mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/int-area