Subject: [multipathtcp] Fwd: [rrg] New Paper On Name-Oriented Sockets Interface

From: Lars Eggert <[email-masked]>
Date: Fri, 27 Nov 2009 11:09:26 +0200

FYI, since a similar idea was just discussed here.

Begin forwarded message:

> From: Christian Vogt <[email-masked]>
> Date: November 10, 2009 11:37:56 GMT+02:00
> To: Routing Research Group Mailing List <[email-masked]>
> Subject: [rrg] New Paper On Name-Oriented Sockets Interface
> 
> Dear all -
> 
> A few meetings ago, we had an interesting discussion on evolving the
> traditional sockets interface towards one that is name-oriented.  A
> significant part of the research group deemed this idea a candidate
> solution to the routing scalability problem, since the resulting
> identifier-locator separation would enable multi-homing and reduce the
> cost of network renumbering.  I would like to point you to a paper that
> elaborates on the name-oriented sockets interface, considering the
> comments from the discussion we had:
> 
> http://christianvogt.mailup.net/pub/2009/vogt-2009-name-oriented-sockets.pdf
> 
> Your comments are welcome as usual.  Although the paper is yet to be
> completed, it contains all major aspects of the solution proposed.
> 
> - Christian
> 
> 
> _______________________________________________
> rrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/rrg

---

From: Scott Brim <[email-masked]>
Date: Fri, 27 Nov 2009 05:57:46 -0500

IIRC in Christian's idea the transport layer itself works on names.
It's more than a proposal for a name-based API.

Scott

Lars Eggert allegedly wrote on 11/27/2009 4:09 AM:
> ------------------------------------------------------------------------
> 
> multipathtcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multipathtcp

---

From: Christian Vogt <[email-masked]>
Date: Sat, 28 Nov 2009 00:36:45 -0500

On Nov 27, 2009, Scott Brim wrote:

> IIRC in Christian's idea the transport layer itself works on names. It's
> more than a proposal for a name-based API.

Scott -

The use of names at the transport layer is a concept to enable session
continuity across IP address changes.  It doesn't have to be implemented
this way as long as the transport layer can provide session continuity
otherwise.  As a matter of fact, I am more and more endorsing the idea
of using multi-path TCP below the proposed name-based sockets interface.
I think this combination would be powerful and elegant.

- Christian

---

From: Rémi Després <[email-masked]>
Date: Mon, 30 Nov 2009 13:48:30 +0100

> It's more than a proposal for a name-based API.

Agreed.
I haven't studied all details of Christian's proposal, but I fully support that:
- A name-capable API is an essential objective.
- Extending TCP (and MPTCP etc.) to convey some name information, e.g. in some ad hoc option, is a logical complement.

If the transport layer of a connection-acceptor, not only receives the address of the connection initiator, but also receives its name, it can check by a DNS query that the received address is a valid address for the received name.
This doesn't depend on any reverse mapping being available in the DNS, and is therefore compatible with DNS dynamic updates, and even with DNSSEC.  
Once the validity of the name-address couple is checked, the name of the initiator can be safely communicated, across the name-capable API, to the called application.

Properly designed, the complete name-capable API can be a backward compatible extension of current address-based APIs.

Regards,
RD

---

From: Christian Vogt <[email-masked]>
Date: Mon, 30 Nov 2009 22:13:59 -0500

[Resending this email, since it didn't make it to the list.]

On Nov 30, 2009, Rémi Després wrote:

> - Extending TCP (and MPTCP etc.) to convey some name information, e.g. 
>  in some ad hoc option, is a logical complement.
> 
> If the transport layer of a connection-acceptor, not only receives the
> address of the connection initiator, but also receives its name, it can
> check by a DNS query that the received address is a valid address for
> the received name. This doesn't depend on any reverse mapping being
> available in the DNS, and is therefore compatible with DNS dynamic
> updates, and even with DNSSEC.   Once the validity of the name-address
> couple is checked, the name of the initiator can be safely communicated,
> across the name-capable API, to the called application.
> 
> Properly designed, the complete name-capable API can be a backward
> compatible extension of current address-based APIs.

Exactly, Rémi.  In fact, your reflections on security and backwards
compatibility are both included in the paper at:

- Christian