Subject: [RRG] On identifiers, was: Re: Does every host need a FQDN

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 13 Aug 2008 12:09:01 +0200

On 12 aug 2008, at 19:01, Scott Brim wrote:

>> And don't MIPv6, SCTP and TCP-over-shim6 all use regular IP  
>> addresses that come with locator functionality as their ID?

> You want something that is stable despite changes in topological  
> location.  As Brian says, MIP uses the home address as an identifier  
> -- an anchor point for authentication.  I don't know mobile SCTP or  
> shim6 very well (help?) but they seem to use a similar stable anchor  
> point. It seems that none of these use a pure network layer  
> identifier.

I was talking about SCTP and TCP-over-shim6 in a multipath transport  
context (although neither are capable of using multiple paths  
concurrently at this time), not a mobility context. SCTP manages  
multiple addresses, I don't think any of them are special or stable.  
shim6 uses the addresses used by the upper layer (such as TCP) as the  
stable identifier, but it also requires these addresses to be working  
locators at the time the shim6 capability is negotiated and other  
locators are exchanged.

Let's inventory what we need identifiers for:

1. demultiplexing
2. access control
3. error detection
4. referrals

And what we need locators for:

5. forwarding packets
6. sending back control messages

Note that all of these uses of identifiers can be limited to the  
application or session layers so there is no need for identifiers to  
appear in any layer 3 or 4 headers - if we don't mind changing  
applications and APIs to map application layer identifiers to  
transport and lower layer locators.

But changing applications is a non-starter, because the number of  
applications is so huge and application writers simply lack the  
knowledge to interact with the network properly. After 10 years there  
are still applications that don't know how to work over IPv6, for  
instance.

Now NOT changing applications means that the identifiers must look a  
lot like regular IP addresses. With shim6, we avoided a mapping system  
at significant cost: we need assistence from applications when the  
initially chosen identifier is not currently a reachable locator.  
Also, shim6 feedback indicates that a pure host solution is not what  
most people want, and requiring changes on both ends is a big  
deployment barrier.

If we want to do all of this in middleboxes we pretty much end up in  
LISP territory. The data plane issues with that are fairly well  
understood by now, but this requires a identifier-to-locator mapping  
service, which is not that well understood currently.

Do we have consensus yet on what would be the best place to solve the  
problem?

--
to unsubscribe send a message to [email-masked] 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

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 14 Aug 2008 10:54:23 +1200

...
> Let's inventory what we need identifiers for:

What about session labels, e.g. for security associations? That
is more than demultiplexing.

What about multipath management? Again, that seems more than
just demultiplexing.

> appear in any layer 3 or 4 headers - 

True, but they will "appear" invisibly in transport and cryptographic
checksums. Decoupling these from locator-addresses seems to be
a feature (among other things, it makes NAT transparent to checksums).

> if we don't mind changing
> applications and APIs to map application layer identifiers to transport
> and lower layer locators.
> 
> are still applications that don't know how to work over IPv6, for instance.
> 
> Now NOT changing applications means that the identifiers must look a lot
> like regular IP addresses. 

More precisely, it means we can't change the socket API, so I think
a shim in the socket layer may be the way to go.

   Brian

> With shim6, we avoided a mapping system at
> significant cost: we need assistence from applications when the
> initially chosen identifier is not currently a reachable locator. Also,
> shim6 feedback indicates that a pure host solution is not what most
> people want, and requiring changes on both ends is a big deployment
> barrier.
>

---

From: "Tony Li" <[email-masked]>
Date: Wed, 13 Aug 2008 16:20:53 -0700

|> Now NOT changing applications means that the identifiers 
|must look a lot
|> like regular IP addresses. 
|
|More precisely, it means we can't change the socket API, so I think
|a shim in the socket layer may be the way to go.

This seems a bit backwards.  Shouldn't the socket API in BSD have been the
correct abstraction that matched the semantics that we wanted our various
network namespaces to have?  Sure, it's 20/20 hindsight, but should
applications really have to worry about resolving a name and then explicitly
binding to an IP address?  Isn't that necessarily broken in the case of a
multi-home host?  Shouldn't that be abstracted away from the application?

In one sense, accepting the socket API as immutable is to ossify the entire
architecture perennially when we can all clearly see that mistakes were made
(albeit with the best of intentions and all available foresight at the
time).  Shouldn't we, as a research group, be looking past that to what a
new socket API might also look like?

Before the flames start, please consider the ability of a host to support
both a new and old version API simultaneously, with the older API being
deprecated.

Tony

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 14 Aug 2008 13:14:45 +1200

> both a new and old version API simultaneously, with the older API being

I completely agree, but I was accepting Iljitsch's stipulation that
we can't touch the apps. Actually it turns out that Java apps have
very little trouble using IPv6, because all the socket gubbins is
hidden in the Java run-time. So there's an existence proof that you're
correct, or alternatively that I am, according to whether you regard
the Java run-time as a better socket library or as a shim on top
of the old one.

    Brian

---

From: "Flinck, Hannu (NSN - FI/Espoo)" <[email-masked]>
Date: Thu, 14 Aug 2008 09:49:04 +0300

Hello Brian

Can you bit elaborate what do mean by multipath management? It seems to
go beyond <src, dst, sport, dport> tuple. Having multipath management in
the hosts requires some visibility into the network topology beyond
having multiple src, dest addresses or multiple locators. 

- Hannu

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf 
>Of ext Brian E Carpenter
>Sent: Thursday, August 14, 2008 01:54
>To: Iljitsch van Beijnum
>Cc: Scott Brim; rrg Group
>Subject: Re: [RRG] On identifiers, was: Re: Does every host need a FQDN
>
>...
>What about session labels, e.g. for security associations? 
>That is more than demultiplexing.
>
>True, but they will "appear" invisibly in transport and 
>cryptographic checksums. Decoupling these from 
>locator-addresses seems to be a feature (among other things, 
>it makes NAT transparent to checksums).
>
>> lot like regular IP addresses.
>
>More precisely, it means we can't change the socket API, so I 
>think a shim in the socket layer may be the way to go.
>
>   Brian
>
>
>> With shim6, we avoided a mapping system at significant cost: we need 
>> assistence from applications when the initially chosen identifier is 
>> not currently a reachable locator. Also,
>> to unsubscribe send a message to [email-masked] with the word 
>> 'unsubscribe' in a single line as the message text body.

---

From: "Heinrich Hummel" <[email-masked]>
Date: Thu, 14 Aug 2008 09:45:58

Multipath management requires the posibility to deal with all forwarding paths to a given destination: best paths, detouring but loopless paths, detouring paths which include a crankback loop but are safe against endless loops. And to take care that a once selected path is consistently pursued. To enforce compliant forwarding the packet needs to convey a respective information. IMO, the hardly used v6FlowLevel should rather be redefined to become such a respective multipath-directive information ( I know, Robin suggested another usage)

But in order to provide all such capabilities you need to do routing "right".
Fundamentally right !!! Which includes the elimination of the scalability problem once and forever just as a side effect.

Heiner

-------- Kabel E-Mail Reply ---------------
From: [email-masked]
To : [email-masked]
Date: 14.08.2008 08:58:41

Hello Brian

Can you bit elaborate what do mean by multipath management? It seems to
go beyond tuple. Having multipath management in
the hosts requires some visibility into the network topology beyond
having multiple src, dest addresses or multiple locators. 

- Hannu

>> archive: & ftp://psg.com/pub/lists/rrg
>> 
>
>--
>archive: & ftp://psg.com/pub/lists/rrg
>

--
to unsubscribe send a message to [email-masked] with the
word 'unsubscribe' in a single line as the message text body.
archive: & ftp://psg.com/pub/lists/rrg

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 14 Aug 2008 11:50:11 +0200

> new socket API might also look like?

Is this something that we as the RRG want to take on?

(We do seem to have a fair contingent of computer science professors  
in our midst so why not...)

We need to be realistic and recognize that fixing the API isn't going  
to do anything to solve the current routing scalability problem.  
Fixing the API is a worthwhile goal from an architectural perspective,  
but I'm afraid that's not reason enough to actually do the work, let  
alone get it deployed.

So: what would be the benefits of such a new API? As someone who has  
just enough experience programming with the current socket API to be  
utterly frustrated by it, I can see how cleaning everything up and  
bringing it into the 21st century would be useful, but probably still  
not enough to justify the work. (Re mundane but annoying stuff like  
expressing disambiguated IPv6 link locals in applications.)

I think the answer lies in the areas of cryptographic identifiers and  
multiaddressing and multipath. The SCTP people were forced to create  
their own API because SCTP does all kinds of stuff that TCP doesn't  
do. I'm not familiar enough with HIP to know how they handle this, but  
I'm guessing HIP has some API hooks as well. If we can unify all of  
this stuff in such a way that applications can work over things like  
SCTP and HIP without actually needing to understand those protocols,  
and not just in some compatibility mode, and, very important, be able  
to do referrals without loss of information, that would be a  
compelling reason to do this work. (Note though that fixing referrals  
probably means updating dozens of RFCs that do referrals by IP address.)

Then at some later point we can drop in loc/id stuff without needing  
to revisit applications.

> both a new and old version API simultaneously, with the older API  

Oh, I thought you wanted to remove the existing socket API to give  
people an incentive to adopt the new one...

---

From: Brian Carpenter <[email-masked]>
Date: Fri, 15 Aug 2008 10:32:58 +1200

[re-sent because once again psg.com is rejecting messages from gmail]

> having multiple src, dest addresses or multiple locators. 

Not necessarily, if you believe Mark Handley. In his model, transport
congestion management automatically finds the best paths without any
topological knowledge. And in shim6, the reachability detection finds
working paths without any topoloogical knowledge. In these cases
we don't need any routing-type imformation in the hosts.

   Brian

---

From: Christian Vogt <[email-masked]>
Date: Fri, 15 Aug 2008 14:08:52 -0700

> to do anything to solve the current routing scalability problem.

Iljitsch,

you are right that the RRG is, in fact, looking at two problems:

- the routing scalability problem

- the convolution between locators and identifiers in host stacks

But: You are arguing that (1) solving the second isn't worthwhile (2)
because it would fail to help solving the first.  I don't quite agree
on either of these arguments.

Regarding (1):  Improving the API would have the following benefits:

- easier application programming
- clean separation of identifiers and locators, hence simpler mobility
   and multi-homing support
- easier NAT traversal
- less complex network renumbering because applications are unaffected

Hence I believe a new API would be worthwhile.

Regarding (2):  A new API may be a building block in a new routing
architecture.  Since a new API would make renumbering easier as noted
above, it may facilitate the wide class of routing scalability
solutions that require edge network renumbering on provider changes.

- Christian

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 16 Aug 2008 11:57:45 +0200

> because it would fail to help solving the first.

No, I was saying that because 2 doesn't solve 1, 1 can't be used as a  
sufficient argument for doing 2.

> - less complex network renumbering because applications are unaffected

Right. (Well this depends on what the API looks like, of course.)

I'm thinking that if we want to make such an API so abstract that it  
doesn't care about mundane details such as the transport protocol or  
NAT, we probably need significant additional logic that does discovery  
and resolving, probably to the degree that we need additional protocol  
logic, for instance to discover whether a remote service is reachable  
over TCP vs SCTP or UDP vs DCCP.

I think this is worthwhile work, but my question remains: should we  
take this on in RRG?

> solutions that require edge network renumbering on provider changes.

Well, IPv6 solves the address depletion problem and yet the  
availability of an IPv6 API hasn't helped us much here, so far at least.

But I guess we can come up with a compatibility layer at some point.

---

From: Christian Vogt <[email-masked]>
Date: Sat, 16 Aug 2008 18:06:24 -0700

Hi Iljitsch -

> sufficient argument for doing 2.

Ok.

<snip>

> NAT, [...]

Hiding the transport protocol from applications would go far beyond
simply hiding IP addresses (and therefore the existence of NATs).  I
was thinking of only hiding IP addresses.

> [...] we probably need significant additional logic that does  
> discovery

Some functionality that used to reside at application layer will have
to move to lower layers, that's right.  How much extra functionality
is needed at lower layers depends on what you want to hide from
applications.  If you only hide IP addresses from applications and
transport protocols, IP-address-specific functions such as hostname
resolution, IP address selection, or NAT traversal would have to be
moved from the application layer to the IP layer.  If you also wanted
to hide the transport protocol from application, you would have to go
further.  But I don't see a good reason to hide the transport protocol
from applications.

> I think this is worthwhile work, but my question remains: should we

Right, this question should be thought about.  I would argue that the
new API is within the scope of RRG.  As I mentioned in my previous
email:  A new API would make renumbering easier, and therefore
potentially facilitate the class of routing scalability solutions that
do not eliminate edge network renumbering.

> availability of an IPv6 API hasn't helped us much here, so far at

Well, that comparison is a bit off, isn't it?  The reason why IPv6
solves the address depletion problem is not its new API.  As a matter
of fact, the IPv6 API is conceptually no different than the IPv4 API.
What I am after is a conceptual change to the API.

> But I guess we can come up with a compatibility layer at some point.

Definitely.  The new API needs to be backwards compatible.  Fully
agree.

- Christian

---

From: Scott Brim <[email-masked]>
Date: Wed, 20 Aug 2008 14:57:52 -0400

> we don't need any routing-type imformation in the hosts.

The scheme Mark presented (leaving out all the other multipath ideas
being tossed about) can specify the endpoint addresses but not the paths
taken to reach them.  It will in theory find which address pairs
experience the least congestion, but there is no reason to think that
paths to different endpoint addresses will be different until you get
close to the end site.  I believe that explicit TE in the core is still
going to be useful.

Scott