Re: "The IETF has difficulty solving complex problems" or alternatively Why IMS is a big fat ugly incomprehensiable protocol

Pekka Nikander <pekka.nikander@nomadiclab.com> Sun, 18 September 2005 06:58 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGt8Y-0008UZ-CC; Sun, 18 Sep 2005 02:58:54 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGt8V-0008UJ-L1 for ietf@megatron.ietf.org; Sun, 18 Sep 2005 02:58:51 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08712 for <ietf@ietf.org>; Sun, 18 Sep 2005 02:58:49 -0400 (EDT)
Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGtDr-0002ge-Lt for ietf@ietf.org; Sun, 18 Sep 2005 03:04:24 -0400
Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id B81A9212C46; Sun, 18 Sep 2005 09:58:20 +0300 (EEST)
In-Reply-To: <E4E0DF09-BEE7-4392-B9E2-DFC4CEE4CF58@muada.com>
References: <20050804050502.GB6084@sbrim-wxp01> <42F89F9F.5070008@zurich.ibm.com> <C5A01F62-A076-46C7-8C67-6568E752A1E7@nomadiclab.com> <4321D5E9.9010609@shockey.us> <151701c5b570$052a25a0$0500a8c0@china.huawei.com> <C0DE65F6343F8BD987425795@B50854F0A9192E8EC6CDA126> <43249A80.3020303@piuha.net> <4324A849.4060509@cs.columbia.edu> <BB8C050D-B298-4A8A-9325-45B149FC04AD@nomadiclab.com> <4A763861-D4E9-44DD-A193-8E73EC4E03A7@muada.com> <4A09791C-AF36-4C86-923A-D38343C2E037@nomadiclab.com> <E4E0DF09-BEE7-4392-B9E2-DFC4CEE4CF58@muada.com>
Mime-Version: 1.0 (Apple Message framework v734)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <CF66BDE3-3EF4-44BA-86AD-5A715E7B504D@nomadiclab.com>
Content-Transfer-Encoding: 7bit
From: Pekka Nikander <pekka.nikander@nomadiclab.com>
Date: Sun, 18 Sep 2005 08:58:18 +0200
To: Iljitsch van Beijnum <iljitsch@muada.com>
X-Mailer: Apple Mail (2.734)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2
Content-Transfer-Encoding: 7bit
Cc: IETF Discussion <ietf@ietf.org>
Subject: Re: "The IETF has difficulty solving complex problems" or alternatively Why IMS is a big fat ugly incomprehensiable protocol
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

IMHO, this thread of this discussion belongs to the HIP WG list.  I  
am replying there.

--Pekka Nikander

On Sep 17, 2005, at 15:48, Iljitsch van Beijnum wrote:

> On 15-sep-2005, at 9:57, Pekka Nikander wrote:
>
>
>>>> So, as I state in my little web page, I think we really should  
>>>> work hard to create a new waist for the architecture.   I, of  
>>>> course, have my own theory where the new waist should be and how  
>>>> it should be implemented,
>>>>
>
>
>>> Well, don't be shy: where can we absorb these insights?
>>>
>
>
>> Unfortunately I don't have any concise summary of my "theory", but  
>> wading through my academic papers (available through my home page)  
>> should give a fairly good view.
>>
>
> [HIP]
>
>
>> But, as I wrote, I am trying to take distance from these and  
>> trying to understand alternative approaches, like "virtualising  
>> IP" or "domain-based internetworking" that some people are  
>> thinking about.  It is now mostly other people that are continuing  
>> the HIP-based work, for example, at the CEC funded Ambient  
>> Networks project and at the IRTF HIP Research Group.
>>
>
> I think HIP is on the right track in some areas, but I don't like  
> the protocol as such because the overhead is too large, and I think  
> even though it's fairly radical in some ways, it doesn't go far  
> enough.
>
> For instance, the first sentence of any new internet architecture  
> would have to be: one size does NOT fit all. The assumption that it  
> does has allowed a lot of great work in the past. For instance, for  
> some time, TCP was able to accommodate the slowest possible links  
> and the fastest. But that's no longer true, so now we have to  
> choose between enabling RFC 1323 high performance options to allow  
> high speed downloads across the globe, or disable them and allow  
> for header compression to optimize for low speed links.  
> Unfortunately most operating systems enable the options, killing  
> header compression, while applications fail to use buffers that are  
> big enough so long distance high speed downloads aren't possible  
> either.
>
> That kind of stuff is very common in today's internet.
>
> We also need to address the need of intermediate systems to  
> influence the communication between two endpoints in various ways,  
> without killing the end-to-end principle wholesale.
>
> Routing, naming, addressing and layering is a big mess in the  
> current "architecture". (I'm using quotes because all of this  
> evolved over time without noticeable architectural oversight.) CIDR  
> was a step in the right direction, but now it's time for the next  
> step: make addresses variable length. (One size doesn't fit all.)  
> Port numbers should be part of the address to allow for easier  
> filtering. Having DNS names is great, but applications shouldn't  
> have to deal with name to address mappings: we need a new API that  
> hides addresses from applications that don't have any need to look  
> at them. HIP does get the locator/identifier idea right. In  
> addition to that, we need to abandon the notion of one single  
> network with a fixed root. By allowing each point in the network to  
> be the root, and map all other parts of the network to arbitrary  
> parts of the hierarchy as seen from a given root, we can impose the  
> constraints required by many organizations. Interdomain routing  
> needs more link state like mechanisms in order to get rid of BGP's  
> version of the count to infinity problem. It also needs to work  
> when the view of the network is incomplete, while at the same time  
> taking advantage of additional topological information when  
> available. (This includes taking advantage of geography in  
> routing.) And interdomain routing shouldn't be subvertable like it  
> is today.
>
> Coming back to IPsec: we need more of this. TLS is broken because  
> it doesn't protect the underlying TCP session. We need an API that  
> allows applications to do an IPsec version of "STARTTLS". (It would  
> be nice if we could do authentication first and then encryption,  
> unlike it's done today, to get rid of at least SOME of the huge  
> IPsec overhead: the auth data can then be the encryption IV.)
>
> In other words: we now need to do everything that we didn't do  
> until now because it was too hard.
>
> Ok, that's my rant for today.  :-)
>
>


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf