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

[Pekka Nikander <[e-mail]>]

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
[e-mail]
https://www1.ietf.org/mailman/listinfo/ietf