Subject: Re: "The IETF has difficulty solving complex problems"

From: Pekka Nikander <[email-masked]>
Date: Fri, 9 Sep 2005 16:05:32 +0200

In a whimsical mood, I put up a web page that tries to
clarify the comments that I made about complexity during
the Paris IETF Thursday plenary.  So, for your bed time
enjoyment:

   http://www.tml.tkk.fi/~pnr/FAT/

--Pekka Nikander

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Richard Shockey <[email-masked]>
Date: Fri, 09 Sep 2005 14:35:21 -0400

>   http://www.tml.tkk.fi/~pnr/FAT/

Pekka this is a outstanding piece of work and I would suggest an 
alternative thesis that fits your model.

"Why IMS is similar to grotesque body fat --- the case for cranial 
liposuction among IMS engineers"

"Compulsive IMS ...how to reckgonise the problem and how to treat it"
  
"Bulimia networka ( aka IMS ) is defined as a period of uncontrolled 
definition of network elements. The network designer places up to10,000 
boxes in an archichectural design . Bulimia networka is commonly 
associated with excessive attendance at industry conferences and 
standards bodies ( Stockholm Syndrome ) followed by purging behaviors, 
i.e., service provider bankruptcy, layoffs, etc.

I'm sure we can expand on the model endlessly...

-- 

Richard Shockey, Director - Member of Technical Staff
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
sip:rshockey(at)iptel.org   sip:57141(at)fwd.pulver.com
ENUM +87810-13313-31331
PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683
Fax: +1 815.333.1237
<mailto:richard(at)shockey.us> or 
<mailto:richard.shockey(at)neustar.biz>
<http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

---

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 9 Sep 2005 13:55:15 -0500

This was quite funny - both of you!

Of course, the first thing to do when you want to lose "complexity" is "Stop 
adding to the problem" (as in "Put down the fork and push away from the 
table...").

See you in Vancouver,

Spencer

From: "Richard Shockey" <[email-masked]>
To: "Pekka Nikander" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, September 09, 2005 1:35 PM
Subject: Re: "The IETF has difficulty solving complex problems" or 
alternatively Why IMS is a big fat ugly incomprehensiable protocol

> associated with excessive attendance at industry conferences and standards 
> bodies ( Stockholm Syndrome ) followed by purging behaviors, i.e., service 
> provider bankruptcy, layoffs, etc.
>

---

From: Richard Shockey <[email-masked]>
Date: Fri, 09 Sep 2005 15:19:58 -0400

Spencer Dawkins wrote:

> Of course, the first thing to do when you want to lose "complexity" is 
> "Stop adding to the problem" (as in "Put down the fork and push away 
> from the table...").

Oh..darn ..you mean I cant have a Session Border Controller for dessert ?

Grumble Grumble ..< burrrrrp>

>> definition of network elements. The network designer places up 
>> to10,000 boxes in an archichectural design . Bulimia networka is 
>> commonly associated with excessive attendance at industry conferences 
>> and standards bodies ( Stockholm Syndrome ) followed by purging 
>> behaviors, i.e., service provider bankruptcy, layoffs, etc.
>>

--

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Sat, 10 Sep 2005 16:38:41 +0200

--On 9. september 2005 13:55 -0500 Spencer Dawkins <[email-masked]> 
wrote:

> "Stop adding to the problem" (as in "Put down the fork and push away from
> the table...").

standards bloat solution:

anyone proposing a new feature has to propose two features to be retired.
anyone proposing a new standard has to propose two standards to be retired.

the proposal for retirement has to be accepted before the proposal for the 
new thing.
_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Jari Arkko <[email-masked]>
Date: Sun, 11 Sep 2005 23:58:40 +0300

> anyone proposing a new standard has to propose two standards to be 

This is a fun thread, but if we ever decide to get serious
about complexity, we can't assume a static Internet or
static environment. When you keep on increasing the
number of users by orders of magnitude, increasing
the types of applications, and expanding to very different
types of devices, you ARE going to need more functionality.
Sign of success. There's no going back to the times of
telnet and ftp, even if many of us may think of those times
as the good old times when life was simple...

A bad sign, however, would be if we were
producing all this functionality in the wrong way,
making it unnecessarily complicated or limited, or if
the stuff that we produced would not match what people
really use in the Internet. I'm sure we can come up
with examples of all of these bad signs... but its harder
to determine how serious the situation is or is not.
Anyway, some of the tools that we can use going
forward include

- Good architecture and good design. Placement of
  functionality in the right place. I suspect that we
  don't do enough work in this area. Almost all
  of our activities are related to specific protocol
  pieces, not so much on how they work together,
  what the whole needs to do, what etc.

- Generalization of point solutions. Even major new
  functionality often starts out as the need of a specialized
  group of users. If you always do only what is needed
  right now and don't think ahead -- you will get bloat
  and an architecture that does not work well.

- Processes that ensure proposals and standards that
  don't get widely adopted are killed in a timely manner.
  We can decide that proposals don't have enough
  support behind them. We can deprecate standards.
  (Note that "widely" is relative term. I don't mean that
  we should never answer the needs of small
  groups. But if a solution for X does not appear to
  be used even in the potential user group, that's bad.)

- Allowing paths for experimentation, innovation, and
  market forces. E.g., some protocol proposals may be
  better produced in IRTF and tested & evolved, rather
  than being cast from day 1 as standards that affect
  all devices.

--Jari

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 11 Sep 2005 17:57:29 -0400

>  what the whole needs to do, what etc.

These days, this seems to be the domain of the "systems" standardization 
bodies, such as 3GPP and CableLabs. The 3GPP architecture diagram seems 
to be a good demonstration object, although it is not directly the fault 
of the IETF. (I think there are some interesting reasons for complexity 
here, in particular the need for interworking with legacy technology, 
that also appear elsewhere.)

>  and an architecture that does not work well.

The converse also happens: The assumption that specialized protocols are 
needed for every new application. The world outside the IETF bubble is 
starting to largely ignore this for new applications, yielding SOAP and 
OASIS. (The number of applications that people want to standardize is 
far larger than the number of IETF working groups ever could be and 
larger than the number of even semi-trained protocol designers, so this 
is probably the only scalable solution.)

For example, given a generic RPC mechanism, it is not clear that there's 
a fundamental need for POP, SMTP and IMAP as wholly different protocols, 
rather than just (three disjoint) sets of RPC operations. It is unlikely 
that we can unwind this one, but there haven't been any major new 
applications proposed for standardization since the interesting 
IM/presence discussions a few years ago. (One exception I can recall: 
the BOF on app sharing in Paris.)

>  support behind them. We can deprecate standards.

Our current deprecation mechanism is only designed to remove standards 
that are essentially no longer used (in new designs). This potentially 
reduces the number of RFCs claiming to be PS, but doesn't really reduce 
the deployed complexity. Obviously, we aren't even making a whole lot of 
progress on that more limited score.

>  than being cast from day 1 as standards that affect

I suspect a fair amount of complexity is because we had to bolt on 
various things (NAT traversal, security, reliability or large messages 
seem common after-market add-ons) or couldn't arrive at decisions during 
protocol design time. As an example, SIP is more complicated than it has 
to be because there was a decision to support both UDP and TCP (and 
other reliable transport protocols). This was expedient in the mid-90s 
to get deployment, even though we now tell people that you really should 
run this (only) over TLS.

Henning

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 12 Sep 2005 15:56:22 +0200

--On søndag, september 11, 2005 17:57:29 -0400 Henning Schulzrinne 
<[email-masked]> wrote:

> OASIS.

In some (many?) cases, I'd actually argue that they ARE desiging new 
protocols, but build them on quite complex substrates.

The management protocols that the Storage Networking people are building on 
top of Web Services using CIM data models still have to face the same 
issues as a CLI interface on top of Telnet, or a MIB interface on SNMP - 
are the right objects defined? are the operations correctly identified? are 
access controls at the right level of granularity? are the entities 
participating in the process correctly identified?

Once these things are "right" (or at least agreed upon), getting the bits 
on the wire to work is relatively easy (in comparision).

that said - sometimes the problems DO fit the tools.

                            Harald

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 13 Sep 2005 01:10:38 +0900

Henning Schulzrinne wrote:

> The assumption that specialized protocols are needed for every
> new application.

That's irrelevant.

The question is whether the application is complicated or not.

> As an example, SIP is more complicated than it has 
> other reliable transport protocols).

SIP, of course, is an example of complicated protocol for
experimental mbone used by people who did not (and still
do not) understand the nature of multicast very well,
which was fine as long as SIP had remained purely multicast
research.

Later, there was a desire to extract the fully capability of
complicated telephone network by IP based protocols, which itself
is wrong.

And, SIP, which was designed for complicated multicast applications,
was future complicated.

It has little to do with TCP and UDP.

The point is to make application requirements clearly simple, which
was not the case with SIP.

If you have complicated requirements, you are wrong.

For example, if you think you have to simulate complicated telephone
network protocols on the Internet, you are wrong.

						Masataka Ohta

---

From: Pekka Nikander <[email-masked]>
Date: Tue, 13 Sep 2005 14:32:21 +0200

Henning Schulzrinne wrote:
> These days, this seems to be the domain of the "systems"  
> standardization bodies, such as 3GPP and CableLabs. The 3GPP  
> architecture diagram seems to be a good demonstration object,  
> although it is not directly the fault of the IETF. (I think there  
> are some interesting reasons for complexity here, in particular the  
> need for interworking with legacy technology, that also appear  
> elsewhere.)

I don't think "architecture" necessarily means the kind of "systems"  
architecture that the "systems" standardisation bodies are  
producing.  While the Internet architecture has never been defined in  
terms of nodes and interconnections like the 3GPP architectures  
typically are, I still think we had a fairly well functioning and  
beautiful Internet architecture some 10-15 years back.  So, it may  
just be harder to pinpoint what the Internet architecture was, even  
though I think that, for example, some of Bob Braden's slide sets  
give quite a good idea.

Consequently, the kind of "new" architecture work that I think we  
need might be called by some people something else, perhaps "vision",  
rather than "architecture".   That is, like we've had the e2e  
principle for quite a long time, maybe we should try to develop a  
number of almost as fundable principles, like ones for wireless  
operations, mobility and multi-homing, o & m, distributed security  
management, etc.  Then, by consciously applying those principles to  
existing protocol designs, sometimes perhaps working on  
simultaneously in enhancing an existing protocol and in creating a  
new "version" of the particular protocol, based on a completely  
different architectural design, we might be able to inch to a  
somewhat less complex overall architecture.  OTOH, maybe I am just a  
dreamer and totally off the ground here?

> various things (NAT traversal, security, reliability or large  
> messages seem common after-market add-ons) or couldn't arrive at  
> decisions during protocol design time.

I pretty much agree.  Furthermore, more generally, I think that the  
current state of the architecture is pretty much a consequence of  
collectively not accepting the reality for a too long time.  In my  
quite humble opinion, a number of vocal people at the IETF have far  
too long been preaching the architecture as it used to be 10-15 years  
back, disparately trying to clung to the ideal and ignoring the  
reality.  As a result, the Internet architecture as-out-there-in-real- 
life has ran over the architecture-as-in-our-heads, causing a  
multitude of point solutions to be built to work around the problems  
in the ideal architecture.

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, but I also try to stretch myself here to be as open  
minded as I can in order to better understand the concerns from all  
of the community.  My problem is that I don't know how best to engage  
the community in this kind of discussion, and relatedly, whether  
creating "a vision of a new waist" is possible at all, or at least  
whether it is possible to get any level of acceptance of such a  
vision within the community.

--Pekka Nikander

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 14 Sep 2005 23:11:50 +0200

On 13-sep-2005, at 14:32, Pekka Nikander wrote:

> 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?

(As far as I can tell the "architecture" that so many IETFers ignore  
is "anything that doesn't cause too much visible breakage goes",  
against which resistance is exactly the right response.)

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 15 Sep 2005 09:57:37 +0200

>> 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,
>

Since you ask:

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.  I would focus on the following three  
papers, roughly in this order:

1. Pekka Nikander, Jukka Ylitalo, and Jorma Wall, "Integrating  
Security, Mobility, and Multi-Homing in a HIP Way," in Proceedings of  
Network and Distributed Systems Security Symposium (NDSS'03),  
February 6-7, 2003, San Diego, CA, pp. 87-99, Internet Society,  
February, 2003.

2. Jukka Ylitalo, Pekka Nikander, "A new Name Space for End-Points:  
Implementing secure Mobility and Multi-homing across the two versions  
of IP," in Proceedings of the Fifth European Wireless Conference,  
Mobile and Wireless Systems beyond 3G (EW2004), pp. 435-441,  
Barcelona, Spain, February 24-27, 2004.

3. Pekka Nikander, Jari Arkko, and Börje Ohlman, Host Identity  
Indirection Infrastructure (Hi3)," in Proceedings of The Second  
Swedish National Computer Networking Workshop 2004 (SNCNW2004),  
Karlstad University, Karlstad, Sweden, Nov 23-24, 2004.

Especially the last one is pretty dense; it takes time to understand  
all that we are trying to say there.

All three (and more) are available at
http://www.tml.tkk.fi/~pnr/publications/index.html

If you prefer slideware, see our IETF 62 plenary slides:
http://www3.ietf.org/proceedings/05mar/plenaryt.html
http://www3.ietf.org/proceedings/05mar/slides/plenaryt-1.pdf

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.

--Pekka Nikander

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Thu, 15 Sep 2005 15:17:22 +0200

Dear Pekka,
I went through a few of your documents to better understand the basic 
of HIP. When I told you I prefer models: your proposition could fit 
my model. But if I see identification, authentication and routing 
matters being addressed, I see proposed changes enough to suspect 
that this will affect the level above (DNS) and below (IP 
addressing). I would suggest you try to think of simple, robust, 
scalable global Internet architecture which would include your 
proposition and permit a transparent transition. I think this is 
possible in what I call the "multi-Internet", I do not know if this 
is possible in the "mono-Internet" you refer to. Because I feel you 
add an intelligence on the wire?

May I suggest a test? How would you support "ISP rotation": your Elm 
Street person has several addresses and wants to rotate them with a 
defined pattern within the same relation, for example for security 
purposes? (you might call this a directed multi-homing?)

I note that you could also associate HI to predetermined paths as 
well (anti-tapping protection)?
jfc

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 15 Sep 2005 15:45:18 +0200

> ... But if I see identification, authentication and routing matters  
> being addressed, I see proposed changes enough to suspect that this  
> will affect the level above (DNS) and below (IP addressing).

I don't see any *necessary* changes to IP addressing; OTOH wide  
spread use of HIP would certainly open new possibilities, like easier  
network renumbering and easier interworking between IPv4 and IPv6.

DNS, changes or at least extensions, definitely.  That is an area of  
active research.  The Hi3 paper covered that from one point of view  
briefly, but there are other proposals around.

> I would suggest you try to think of simple, robust, scalable global  
> Internet architecture which would include your proposition and  
> permit a transparent transition.

I don't know what you mean with "transparent transition".

> How would you support "ISP rotation": your Elm Street person has  
> several addresses and wants to rotate them with a defined pattern  
> within the same relation, for example for security purposes? (you  
> might call this a directed multi-homing?)

I don't understand why you call that "ISP rotation", but yes, based  
on your functional description, that should be fairly trivial.  With  
IPv6 and RFC3014(bis) addresses you might even get some level of  
privacy, but see also our "BLIND" paper, on my publications page.

> well (anti-tapping protection)?

Maybe, but I don't see any easy way to do that.  One of the points in  
HIP is to loosen the currently tight binding between routing and  
transport.

--Pekka

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Thu, 15 Sep 2005 20:16:25 +0200

At 15:45 15/09/2005, Pekka Nikander wrote:
>spread use of HIP would certainly open new possibilities,

Dear Pekka,
Correct. I meant "affect" in the way of opening new possibilities.
Also probably leading to a directory structural applications.

>like easier

I meant also things like I ask at the end: to address a path, so I am 
sure the packet will travel the way the other end wants.

>briefly, but there are other proposals around.

Certainly. The DNS can be considered as a part of a more general, for 
example ISO 11179 related, DRS (distributed registries system). HI is 
a registry element as any other one. Its major advantage on names is 
that it could be numeric, hence multilingual.

Also, a public key could be associated to every lingual space of 
exchanges, trust and services.(SETS). This

>I don't know what you mean with "transparent transition".

That a transition from current usage could be made as transparent as 
possible to the users.

>I don't understand why you call that "ISP rotation",

Let assume I have three ISPs on three lines. I want packets in a same 
connection to travel through each of them on an equal or a given 
basis. The rotation continuing on two if one loses connectivity, etc.

>but yes, based

I understand it is a possibility. But if you point an HIP to a IP 
list in a registry and use it?
All the best.
jfc

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 17 Sep 2005 15:48:13 +0200

> should give a fairly good view.

[HIP]

> "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.  :-)

---

From: Pekka Nikander <[email-masked]>
Date: Sun, 18 Sep 2005 08:58:18 +0200

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:

>> 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.
>
> 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.
>
> 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  
> 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.
>