[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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


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.


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.


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