Re: sockets APIs extensions for Host Identity Protocol

Miika Komu <miika@iki.fi> Mon, 14 May 2007 14:56 UTC

Return-path: <discuss-bounces@apps.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hnbyn-00052N-5L; Mon, 14 May 2007 10:56:53 -0400
Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Hnbyl-00051O-48 for discuss-confirm+ok@megatron.ietf.org; Mon, 14 May 2007 10:56:51 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hnbyk-00051C-Pv for discuss@apps.ietf.org; Mon, 14 May 2007 10:56:50 -0400
Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hnbyi-0008E2-Jo for discuss@apps.ietf.org; Mon, 14 May 2007 10:56:50 -0400
Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 06F922D82; Mon, 14 May 2007 17:56:48 +0300 (EEST)
X-Spam-Checker-Version: SpamAssassin 3.2.0-niksula20070322 (2007-05-01) on twilight.cs.hut.fi
X-Spam-Level:
X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.0-niksula20070322
X-Spam-Niksula: No
Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 1BF472D33; Mon, 14 May 2007 17:56:47 +0300 (EEST)
Date: Mon, 14 May 2007 17:56:46 +0300 (EEST)
From: Miika Komu <miika@iki.fi>
X-X-Sender: mkomu@kekkonen.cs.hut.fi
To: Keith Moore <moore@cs.utk.edu>
Subject: Re: sockets APIs extensions for Host Identity Protocol
In-Reply-To: <46486767.3070809@cs.utk.edu>
Message-ID: <Pine.SOL.4.64.0705141726090.7259@kekkonen.cs.hut.fi>
References: <Pine.SOL.4.64.0705041801060.14418@kekkonen.cs.hut.fi> <20070507082737.GB21759@nic.fr> <46413DD7.8020702@cs.utk.edu> <20070509121703.GA21070@nic.fr> <4641CA52.70504@cs.utk.edu> <Pine.LNX.4.64.0705091449360.26169@hermes-1.csi.cam.ac.uk> <4641D94C.9070304@cs.utk.edu> <Pine.SOL.4.64.0705102013550.10049@kekkonen.cs.hut.fi> <46436B10.5090706@cs.utk.edu> <Pine.SOL.4.64.0705102159020.10049@kekkonen.cs.hut.fi> <4643F873.3000501@cs.utk.edu> <Pine.SOL.4.64.0705110851440.24038@kekkonen.cs.hut.fi> <46442588.7020405@cs.utk.edu> <Pine.SOL.4.64.0705111344130.16213@kekkonen.cs.hut.fi> <4644779F.60805@cs.utk.edu> <Pine.SOL.4.64.0705111801430.8816@kekkonen.cs.hut.fi> <4644CD76.10900@cs.utk.edu> <Pine.SOL.4.64.0705112330070.8816@kekkonen.cs.hut.fi> <4644D90B.1020304@cs.utk.edu> <Pine.SOL.4.64.0705120006150.8816@kekkonen.cs.hut.fi> <4644E478.1070804@cs.utk.edu> <Pine.SOL.4.64.0705121809550.27730@kekkonen.cs.hut.fi> <46486767.3070809@cs.utk.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab
Cc: discuss@apps.ietf.org
X-BeenThere: discuss@apps.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: general discussion of application-layer protocols <discuss.apps.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/discuss>, <mailto:discuss-request@apps.ietf.org?subject=unsubscribe>
List-Post: <mailto:discuss@apps.ietf.org>
List-Help: <mailto:discuss-request@apps.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/discuss>, <mailto:discuss-request@apps.ietf.org?subject=subscribe>
Errors-To: discuss-bounces@apps.ietf.org

On Mon, 14 May 2007, Keith Moore wrote:

>
>>> perhaps strangely, the latter justification makes more sense to me.  no,
>>> 15 addresses is not enough.  but it's not acceptable to have the IP
>>> addresses passed implicitly from the resolver to the socket.
>>
>> Actually, the addresses passed from the resolver would be system level
>> "hints" rather than bound to a specific socket because getaddrinfo
>> resolver does not know anything about the sockets. What is the exact
>> reason why you see this as an bad idea?
>
> there are lots of reasons.  one is that it unnecessarily couples the
> resolver routines with the socket routines, and thereby imposes a
> dependency that isn't there now and shouldn't be there.  in other words,
> you shouldn't be expected to use the system resolver (e.g. maybe you
> want to use an asynchronous DNS library).  another reason is that it
> requires the kernel and/or library to manage state that's invisible and
> inaccessible to the application - and yet there will probably be
> situations that will cause the application to fail if the invisible
> state isn't managed like the application expects.  for instance,
> consider an app that uses HITs for referrals layered on top of a kernel
> that keeps HIT-to-IP mappings only for a limited time before discarding
> them.  if the app tries to send to a HIT after that time, the kernel
> isn't going to have the mapping any longer.

Ok. FYI, there is a draft about HIT lookup using DHT:

http://www.ietf.org/internet-drafts/draft-ahrenholz-hiprg-dht-01.txt

>>> offhand, I'd say that a good compromise would be to allow some
>>> reasonable number of addresses to be specified using sockaddr_hip and
>>> to allow more peer addresses to be added using a setsockopt() call.
>>
>> I don't see how this would work with the resolver? I guess the only
>> way would be to output several HITs redundantly, but with different IP
>> addresses. Would this work for you?
>
> I don't think I understand the question.   You're going to need
> different routines to look up HITs, and HIT-to-IP mappings anyway.

It gets sort of complicated to do two separate lookups in separate 
function calls. In addition, the HIT lookup may or may not work because 
HITs are flat identifiers. I'd just a use single function call.

Let's take an example of looking up "foo.bar" which maps to HIT1, HIT2, 
HIT3 and IP1, IP2, IP3, IP4, IP5, IP6.

We can return the following from the resolver:

item1: HIT1+IP1,IP2,IP3,IP4,IP5,IP6
item2: HIT2+IP1,IP2,IP3,IP4,IP5,IP6
item3: HIT3+IP1,IP2,IP3,IP4,IP5,IP6

But then we have to modify the size of the family in sockaddr. 
Alternatively, we can return:

item1: HIT1+IP1
item2: HIT1+IP2
item3: HIT1+IP3
item4: HIT1+IP4
item5: HIT1+IP5
item6: HIT1+IP6
item7: HIT2+IP1
item8: HIT2+IP2
...

and now the family size does not change The drawback here is that this may 
reduce the latency to connect when some of the locators are broken 
especially when the application does not parallerize multiple connect() 
calls.

I'd choose the second approach based on the earlier discussion that the 
intelligence should reside on the application or socket wrapper library. 
So we can assume that the entity operating on top of sockets API can do 
the right thing.

The first approach is also inefficient. Even though longer socket address 
structures can be made to work, they require more sockaddr copying between 
userspace and kernelspace especially with datagram oriented sockets.

Comments?

> given that the flow label field in the sockaddr_in6 field isn't even
> used in the implementations I've seen (my understanding is that it's not
> supposed to be copied to the IPv6 packet), this seems like overkill.
> I'd just put a list of in6_addrs in there.

We have a tradeoff here between future compatibility (un, ipx, atmpvc, 
ax25, irda, rose, tipc, ash, ec), which requires sockaddr, and saving 
space for multiple IP addresses (in6addr).

> it bugs me a little bit that there's a port field in there, since HIP is
> a layer on top of IP, and there might be IP protocols that don't have
> ports.  what if someone wants to run SCTP over HIP?

This would call for the sockaddr structure and encapsulating the port 
number inside that when needed?

>> The HIT takes 16 bytes. For future extensions purposes, I would
>> actually suggest to take the "back-up" locator away and reuse its
>> space with 16 bytes of reserved space just after the HIT. This way, we
>> could have future expansion space for 256 bit HITs? And the single
>> locator would fit nicely to the resolver scheme described above.
>>
>> What about datagram oriented communications? What should happen when
>> the HIT and socket remain the same, but locator changes between two
>> sendto() calls? I guess it could be used for enforcing an handover.
>
> interesting question.  actually I think that a HIP association should be
> able to exist between two hosts independently of any transport-level
> connection, and it might be appropriate to have calls to setup and
> discard such associations independently of any connection setup.  that
> would yield two cases for datagram communications: in one case the HIP
> association would exist and the HIT-to-IP mappings would have been
> maintained to keep them current.  in that case the sendto() would just
> work, since the sending host would already know how to route to that
> HIT. in the other case either there would be no association or no usable
> HIT-to-IP mappings (say there had been a network outage and all of the
> mappings had expired).   in that case the sendto() would fail with
> something like "no route to host" and it would be up to the application
> to supply new mappings to the kernel.

Yes.

>> Does this make sense? I guess this is getting quite specific already,
>> so it may be a better idea to move the discussion to HIP mailing lists?
>
> somehow I think it would be better if the API details were hashed out
> here, where they can get wider exposure within the apps area.

Ok.

-- 
Miika Komu                                       http://www.iki.fi/miika/