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

[Pekka Nikander]

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

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

[Iljitsch van Beijnum]

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

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

[Pekka Nikander]

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


I note that you could also associate HI to predetermined paths as  
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


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

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

[JFC (Jefsey) Morfin]

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

At 09:57 15/09/2005, 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?


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



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




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

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

[Pekka Nikander]

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?


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



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

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

[Iljitsch van Beijnum]

On 13-sep-2005, at 14:32, 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?

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


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

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

[JFC (Jefsey) Morfin]

On 14:32 13/09/2005, Pekka Nikander said:

OTOH, maybe I am just a  dreamer and totally off the ground here?


No, you are not!

However the problem with a "vision" is to know where the boarder is 
between dreams and real future. This is why I prefer a more prosaïc 
"model" which gives a simple image everyone can easily understand in 
the same way.


For example, everyone - knowing the e2e principles can escalate it to 
a b2b concept of brain to brain interintelligibility when it comes to 
human languages (inter-brains protocols). And understand very simply 
why internationalisation is e2e and multilingualisation is b2b. Two 
different layers.


For example, everyone - knowing the e2e principles car enlarge their 
"mono" vision to a 'n.(e2e)' "multi" vision:
- where e2e principles are respected in multilple parallel [split, 
into simpler - as per RFC 1958] relations,
- where link ends are welded together and the edges (OPES) to provide 
real final "added" value:  not on the wire [as an impossible "e2e 
added value" ] but as an "added e2e's value".
And understand that an OPESed SMTP does not need to read an e2e mail 
when a parallel e2e link told it the mail did not originate from the 
other end it claims.


Another way to be sure you are not a dreamer is to look if your idea 
worked in the preceding public international network deployments 
(Tymnet, OSI). Obviously you have to translate it in/from IETF words 
... and be opposed many "this is not an Internet way" 


Another way to discriminate between dreams and reality: if you are 
really alone of your opinion, you are right. Because it is not 
possible the words counts so many wise people. This is the 80/20 
rule. As long as the true majority is less than 80 the situation is 
stable. Over that the minority is probably the coming revolution. 
This is the difficulty in reaching a consensus. If 100% more or less 
the noise(rough consensus): we all agree, right or wrong. A 5 to 20% 
opposition is probably right. The big difficulty is to discriminate 
between noise and less than 5%. We are back to your question


jfc


PS. Here is a quote of a mail to a WG-Chair who prefers to stick to 
his charter and see his WG die, instead of working on its revamp 
based on the WG's acquired expeirence. Conflict between requested 
engineering and lack of IAB exciting architectural proposition.


"This is why I have decided to proceed in parallel, using IETF Drafts 
so information will continue to flow. May be will this increase the 
ad-hominems as the economics will also increase. But at least we will 
go ahead. The architectural error is democracy. I never asked my 
phone or my computer to be democratic: I ask them to work.


Reseach is not democractic. The error is the IETF "consensus": the 
consensus was OK in the early days when everyone was standardiser, 
experimenter and user. Now when seven employees of the members of a 
commercial consortium represent a "consensus" for a "BCP" against 
(RFC 3863 included) the users, the only solution for the users is to 
renew with the old system and to specify, test and use by themselves. 
The problem is that users are disorganised, so they will develop in 
parallel, and we will have balkanisation. Too bad."










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

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

[Pekka Nikander]

Jari Arkko wrote:

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



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?


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.


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


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

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

[Masataka Ohta]

Jeffrey Hutzelman wrote:

>>> If you have complicated requirements, you are wrong.
>>
>>
>> You are only ever wrong if you do not listen to your customers and as a
>> result fail to provide them with what they want.
> 
> 
> This is a vast oversimplification.  Even if you give your customers what 
> they want, you can still be wrong if your solution fails to behave 
> properly in relation to the rest of the world (stealing resources, 
> violating other people's rights, etc).

Once upon a time, telephone industry listened to its
customers (telephone companies) and provided them with what
ehy want.

As a result, telephone equipments becaome more and more
complicated with more and more complicated specifications.

Most of them are overtook by simpler equipments using IP.

>> The world is complex, sometimes solutions must also be complex. In those
>> cases the design choice is where you put the complexity.

> This, however, is right on target.

In theory, maybe.

However, I have never seen such a design choice necessary
for network protocols.

We don't need 3GPP for the mobile internetworking.

Masataka Ohta



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

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

[Jeffrey Hutzelman]

On Monday, September 12, 2005 10:13:52 -0700 "Hallam-Baker, Phillip" 
<[EMAIL PROTECTED]> wrote:





Behalf Of Masataka Ohta



If you have complicated requirements, you are wrong.


You are only ever wrong if you do not listen to your customers and as a
result fail to provide them with what they want.


This is a vast oversimplification.  Even if you give your customers what 
they want, you can still be wrong if your solution fails to behave properly 
in relation to the rest of the world (stealing resources, violating other 
people's rights, etc).




The world is complex, sometimes solutions must also be complex. In those
cases the design choice is where you put the complexity.


This, however, is right on target.

-- Jeff

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

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

[Hallam-Baker, Phillip]

> Behalf Of Masataka Ohta

> If you have complicated requirements, you are wrong.

You are only ever wrong if you do not listen to your customers and as a
result fail to provide them with what they want.

The world is complex, sometimes solutions must also be complex. In those
cases the design choice is where you put the complexity.

I have seen plenty of systems that have become complex and baroque
because the design was too simple. SMTP is a prime example, the
complexity of the modern email system is the direct result of failing to
acknowledge and make provision for important use cases such as mailing
lists and forwarders.

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

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

[Masataka Ohta]

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 
> to be because there was a decision to support both UDP and TCP (and 
> 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


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

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

[Harald Tveit Alvestrand]

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



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


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.


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


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

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

[Henning Schulzrinne]

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


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




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


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





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


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.



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


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


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

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

[Jari Arkko]

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.


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


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

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

[Harald Tveit Alvestrand]

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



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


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.


pgppNdJBNWGco.pgp
Description: PGP signature
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Richard Shockey]

Spencer Dawkins wrote:


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



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

Grumble Grumble ..< burp>



See you in Vancouver,

Spencer

From: "Richard Shockey" <[EMAIL PROTECTED]>
To: "Pekka Nikander" <[EMAIL PROTECTED]>
Cc: 
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




Pekka Nikander wrote:


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



--Pekka Nikander 





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




--





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


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

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

[Spencer Dawkins]

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 PROTECTED]>
To: "Pekka Nikander" <[EMAIL PROTECTED]>
Cc: 
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




Pekka Nikander wrote:


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



--Pekka Nikander 



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

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

[Richard Shockey]

Pekka Nikander wrote:


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



--Pekka Nikander


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




--





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
 or 


 ; 
<


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