Re: sockets APIs extensions for Host Identity Protocol

Miika Komu <miika@iki.fi> Fri, 11 May 2007 21:18 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 1HmcVh-0007zS-9B; Fri, 11 May 2007 17:18:45 -0400
Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HmcVg-0007zN-HP for discuss-confirm+ok@megatron.ietf.org; Fri, 11 May 2007 17:18:44 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmcVg-0007yG-6m for discuss@apps.ietf.org; Fri, 11 May 2007 17:18:44 -0400
Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmcVe-00059S-SG for discuss@apps.ietf.org; Fri, 11 May 2007 17:18:44 -0400
Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 047D82CFB; Sat, 12 May 2007 00:18:37 +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 7F5042CA5; Sat, 12 May 2007 00:18:37 +0300 (EEST)
Date: Sat, 12 May 2007 00:18:37 +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: <4644D90B.1020304@cs.utk.edu>
Message-ID: <Pine.SOL.4.64.0705120006150.8816@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>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
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 Fri, 11 May 2007, Keith Moore wrote:

> please no.  don't try to hide this stuff from the app in the low-level
> API.   the rest of the network keeps trying to force routing decisions
> on the apps in the absence of routing information.  ideally, the app
> shouldn't have to be doing any routing or address selection or
> anything.  but at present, how to cope with this kind of world is an
> unsolved problem, and the only place where experimentation can be done
> towards learning how to solve that problem is at layer 7.    if you
> cripple the API, you prevent that kind of experimentation (at worst) or
> (at best) increase the burden on the app writer by forcing him to write
> his own kernel extensions.
>
> that, and you still need to expose IP addresses for diagnostic purposes.
>
> what do you gain from trying to hide the IP addresses?

First, to discourage the use of IP addresses as referrals because 
application developer would have to fetch them using a separate function 
call. But maybe this is a weak justification... Second, the socket address 
structure is constrained to 255 bytes. It will fit "only" 1 HIT and 15 
addresses. Is this enough for e.g. routers?

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