[RRG] thoughts on the design space 2: upper layer implications

[Jari Arkko <jari.arkko@piuha.net>]

This is a follow-up mail that attempts to list the different upper layer 
implications the various design tree branches have.

DATAPLANE
========

The non-aggregatable designs such as ROFL have several issues:
- From what I understand, it is hard to implement routing policies. We 
can't take away functionality that today's Internet system parts rely on.
- Addresses no longer provide any information about location, which is 
something that some applications use today. Not clear how significant 
this is, but I'm listing it here nevertheless.

The host-based identifier-locator split designs have the following issues:
- they break the 1 interface - 1 address assumption that many 
applications have (draft-thaler 3.2.3)
- they cannot help with PI needs or avoid renumbering
- multihoming is not possible with existing peers, because they do not 
support the extension. You can still communicate with existing peers, 
however.

Host-based IP layer designs have the following additional issues:
- Interference between what upper layers are doing with respect to 
failure situations, for instance application fallback
- Interactions between transport layer actions and failure detection 
schemes at IP layer

HIP, one of the host-based IP layer designs has the following further 
issues:
- Addresses no longer provide any information about location
- If there is no mapping system from HITs to addresses, referrals become 
a problem

Transport and higher layer solutions do not have additional issues.

The core-edge separation branch restores the notion that hosts have just 
one address (by employing one prefix visible to the hosts). However, it 
also introduces this issue:
- addresses provide locality information only within a domain

The encapsulation branch introduces these issues:
- reduced MTU, which can cause issues where PMTUD does not work (and it 
does not work well today)
- difficulties in talking to the existing internet

All translation designs have issues with referrals.

Two-sided translation has the same issues as encapsulation, with the 
possible exception of MTU differences.

One-sided translation has the issue that the addresses seen by one side 
are not the same as those seen by the peer; NAT-like effects can be seen.

One-or-two sided translation has no additional issues when used to 
communicate to an upgraded network. When used to communicate with a 
legacy network, it has the same issues as one-sided translation.

MAPPING RESOLUTION
===============

The caching design has a number of issues:
- If packets are dropped while cache entries are being fetched, there 
may be deterministic loss
- If packets are routed through a secondary path while cache entries are 
being fetched, there may be deterministic delay

Both of these are issues (draft-thaler 3.1.6-3.1.7). Exactly how serious 
issues is left for further study, however.

In addition, all designs with a mapping resolution system may have 
incentive and reliability issues due to the fact that a third party is 
needed. And, the non-caching design may have scalability issues.

Jari


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