Re: "The IETF has difficulty solving complex problems" or alternatively Why IMS is a big fat ugly incomprehensiable protocol
Iljitsch van Beijnum <iljitsch@muada.com> Sat, 17 September 2005 13:48 UTC
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGd3L-0003w4-2M; Sat, 17 Sep 2005 09:48:27 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGd3C-0003vy-TA for ietf@megatron.ietf.org; Sat, 17 Sep 2005 09:48:19 -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 JAA13622 for <ietf@ietf.org>; Sat, 17 Sep 2005 09:48:17 -0400 (EDT)
Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGd8Q-0008QG-NH for ietf@ietf.org; Sat, 17 Sep 2005 09:53:43 -0400
Received: from [82.192.90.27] (alumange.muada.com [82.192.90.27]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id j8HDm0KY076886 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Sat, 17 Sep 2005 15:48:01 +0200 (CEST) (envelope-from iljitsch@muada.com)
In-Reply-To: <4A09791C-AF36-4C86-923A-D38343C2E037@nomadiclab.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>
Mime-Version: 1.0 (Apple Message framework v734)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <E4E0DF09-BEE7-4392-B9E2-DFC4CEE4CF58@muada.com>
Content-Transfer-Encoding: 7bit
From: Iljitsch van Beijnum <iljitsch@muada.com>
Date: Sat, 17 Sep 2005 15:48:13 +0200
To: Pekka Nikander <pekka.nikander@nomadiclab.com>
X-Mailer: Apple Mail (2.734)
X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00, ILJQX_SUBJ_QUOTE autolearn=no version=3.0.2
X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on sequoia.muada.com
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac
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
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
- "The IETF has difficulty solving complex problems" Scott W Brim
- Re: "The IETF has difficulty solving complex prob… JFC (Jefsey) Morfin
- RE: "The IETF has difficulty solving complex prob… Hallam-Baker, Phillip
- Re: "The IETF has difficulty solving complex prob… Brian E Carpenter
- Re: "The IETF has difficulty solving complex prob… JFC (Jefsey) Morfin
- Re: "The IETF has difficulty solving complex prob… Pekka Nikander
- Re: "The IETF has difficulty solving complex prob… Richard Shockey
- Re: "The IETF has difficulty solving complex prob… Spencer Dawkins
- Re: "The IETF has difficulty solving complex prob… Richard Shockey
- Re: "The IETF has difficulty solving complex prob… Harald Tveit Alvestrand
- Re: "The IETF has difficulty solving complex prob… Jari Arkko
- Re: "The IETF has difficulty solving complex prob… Henning Schulzrinne
- Re: "The IETF has difficulty solving complex prob… Harald Tveit Alvestrand
- Re: "The IETF has difficulty solving complex prob… Masataka Ohta
- Re: "The IETF has difficulty solving complex prob… Pekka Nikander
- Re: "The IETF has difficulty solving complex prob… Iljitsch van Beijnum
- Re: "The IETF has difficulty solving complex prob… Pekka Nikander
- Re: "The IETF has difficulty solving complex prob… JFC (Jefsey) Morfin
- Re: "The IETF has difficulty solving complex prob… Pekka Nikander
- HIP new possibilities JFC (Jefsey) Morfin
- Re: "The IETF has difficulty solving complex prob… Iljitsch van Beijnum
- Re: "The IETF has difficulty solving complex prob… Pekka Nikander