Re: "The IETF has difficulty solving complex problems"

[Brian E Carpenter <[e-mail]>]

Well, this didn't come up in the Thursday plenary unless
my brain is more than normally fuzzy.

Firstly, it's worth re-reading section 2.3 of RFC 3774...

...OK, now you've read that, I wouldn't necessarily agree
with every word, but I think it's basically true. What I
meant to argue is that what we *are* good at is defining
elements of the Internet architecture, and the way we do
that tends to favour scaling and robustness without
needing an over-arching scalablity framework or robustness
framework. The latter part is the feature I was thinking of.

     Brian

Scott W Brim wrote:
> This conjecture was disturbing, but calling it a feature was even more
> disturbing.  After a bit of pondering, and wondering what different
> groups in the IETF might mean by "complex", my first thought was that
> the IETF has never, ever solved one.  For example, we do QoS in small
> pieces that don't fit together well.  Some claim that CIDR was such a
> solution but imho it was just a tweak on what we already had.  Our
> routing protocols have been fertile ground for evolution but not
> revolution -- the path vector idea came directly from deprecating EGP
> "metrics", we still aren't very stable and our policy capabilities are
> frustrating.
> 
> However, after talking to a few people I thought that perhaps we are
> very good at solving complex problems but we don't recognize our
> greatness.  Again let me take QoS as an example.  The problem is huge
> and essentially intractable because of all the competing goals.  What
> we have done, without a lot of architectural planning that I am aware
> of, is to find ways to divide the problem up where there is minimum
> coupling across the boundaries (see footnote (*)).  That lowers the
> complexity greatly.  It is a lot cheaper to have independent,
> apparently "unarchitected" solutions for different kinds of traffic
> and situations.  
> 
> I want us to understand what our skills are and use them consciously.
> I don't know if we will have time tonight, but I'd like to hear from
> the IESG/IAB on the foundation for Brian's statement and what was
> initially a negative assessment of our skill.  Let's look at some
> example problems and think about what we have done poorly and well.  I
> predict we are better than we think, but that we are hard to satisfy.
> We may think of some of the things we have done as crude hacks but
> they are actually pretty good solutions.  Look at tunnels, for
> example.  They are kind of abhorrent when thought of in isolation but
> turn out to be an appropriate means to reduce complexity in specific
> situations.  Reducing complexity through cutting up the problem at the
> right points is implicit now.  We could make it one of our explicit
> basic paradigms.  
> 
> As a corollary to making it explicit, we should be aware of where we
> use this kind of decoupling and be vigilant about it.  Some users of
> the IETF "product set" want to reintroduce coupling that we have
> eliminated.  Be sure the trade-offs are explicitly examined.
> 
> swb
> 
> 
> (*) like Chuang Tzu's butcher ...
> 
>       "The joints have openings,
>       And the knife's blade has no thickness.
>       Apply this lack of thickness into the openings,
>       And the moving blade swishes through,
>       With room to spare!
> 
> _______________________________________________
> Ietf mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/ietf
> 


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