Subject: [nbs] Working out a part of the name-based approach.

From: Javier Ubillos <[email-masked]>
Date: Wed, 01 Jun 2011 10:10:00 +0200

Hi everyone.

This list has been resting for a while now.

I'd like to (re-)kick start things with a few questions to you all.

At which layer should a name-based approach be at?

The way I see it, we already have a name-based interface in the high
level languages. However, these implementations are typically unilateral
and non-dynamic (in the id/locator-split sense).

I guess we're trying to shoot three monsters at the same time:

* A name-based network programming interface
* An (simple) id/locator-split framework (not hard-defining names to be
  FQDNs)
* A standardized way to check for bilateral support. E.g. to allow
signaling for integrated protocols.

These are the topics we've tried to address with the current name-based
sockets prototype.
Another decision in there was to place the bilateral-support check in
the network-layer. Which on the major OSes means kernel-space.
I guess this is bound to wherever one chooses to have the multiplexing
point for the id/locator split.

This also has implications for distribution, e.g. if we choose the
multiplexing point above the transport protocols, it can easily be
distributed as a user-space library to be used by applications.

Currently, we are still developing the name-based sockets prototype.
We have integrated it with shim6, multi-path TCP, and happy-eye balls.
We are looking at improving details and complementing naming
infrastructures, keeping DNS compatibility, but making names require
less infrastructure/overhead.

// Javier Ubillos

---

From: Denis Martin <[email-masked]>
Date: Tue, 07 Jun 2011 12:33:51 +0200

Hi,

> distributed as a user-space library to be used by applications.

Just for understanding: What would be the reason to have the
multiplexing point above the transport protocols?

At the network layer, you gain, e.g., mobility support through loc/id
split, and thus a certain flexibility during the life-time of a
communication. The transport protocol or service address (port) cannot
change during the communication. Initial flexible selection of a
transport protocol or a service discovery, however, is not affected
(i.e. can still be done).

Denis

-- 
Dipl.-Inform. Denis Martin

Institut für Telematik,  KIT   Tel +49 721 608 46420
Zirkel 2,  D-76131 Karlsruhe   Fax +49 721 608 46789
http://telematics.tm.kit.edu   Geb. 20.20,  Raum 371

---

From: Javier Ubillos <[email-masked]>
Date: Tue, 07 Jun 2011 14:58:43 +0200

> (i.e. can still be done).

Look at how e.g. MPTCP solves that issue.

The point is, using a name-based approach, we _can_ aggregate (almost)
arbitrarily, e.g. using multiple connections at a transport level.

Having the multiplexing point above the transport layer would allow
easier distribution of the solution. Looking at platforms as e.g.
Windows, OSX, linux, or frameworks as Java, Python and so on. They all
"cut" at the transport layer. Applications are allowed to open up a
socket and to pick a transport protocol, but that's about it.

Drawbacks are that you loose the ability to manipulate the other layers
headers, e.g. as we have chosen with the current prototype, to add
IP-extension headers for the extra signaling.

// Javier