[e2e] Open the floodgate

[Theo Pagtzis]

Hi all,

after seeing with interest responses from jon, alex, bob, david et al, I 
feel obliged to voice aloud a thought.

For all intents and purposes, engineering (and its output) follows the 
behaviour of an evolutionary process. To stick around control systems, I 
would like to take the example of a predictor-corrector process since 
IMHO that represents to me what I see as "evolutionary reality".

Starting from 'nothing' we predict that we want and eventually achieve 
'something' (which was a lot better than that 'nothing'). As we go along 
  our usage, investigation, imagination and advertising provides a 
'corrector' sample to align this 'something' to the next available state 
which is 'something better'. By this time our specification or the 
original expectations and targets have _already_ changed! It would be 
thus a mistake to judge an initial solution as incomplete/bad/whatever 
since it achieved what it was _originally_ designed for (say, TCP: 
purpose --> congestion collapse).

Thus, one can see that there exists _no_ all-encompasing solution in 
engineering that can be achieved in one go! The reason for it is that 
since solution is tracked by specifications and specifications is 
tracked by our current state of knowledge on what we consider as 
'manifestation of the problem'. The solution, thus, reflects the best 
effort (another one) to the best of our knowledge towards THAT 
manifestation of the term semantics of the word 'problem' .

IMHO discipline is required in achieving an 'optimal' solution that fits
realistic assumptions and adhere to specs. The problem is that the 
realism of the assumption is bound by the state of the current 
manifestation (known info about it) of the 'problem', irrespective how 
'complete' (this is definetely NP-complete) this state is; in other 
words welcome to he famous Godel theorem of incompleteness.

Now there is a distinction between discipline in solving a problem to 
spec (fixed) and solving the problem for a constantly evolving spec 
(desired). A nice example is the one that the constituency of the list 
brought up..limitations of TCP..


 From the above a corrolary comes in mind: "Irrespective of how 
disciplined is the solution of the problem, the solution by itself will 
generate new input that will augment the information space about the 
problem (i.e. new aspects of the problem). Hence one will never - in 
absolute terms - solve the problem BUT evolve it!"

In other words "solutions point to the evolution of 'problem' as a 
necessary and sufficient condition". From that perspective I welcome 
every new ray of light that shows me the evolutionary path (in whatever 
direction  solution --> problem  \/  problem --> solution).


my 2p
t.




will always influence


Sam Manthorpe wrote:
> 
> On Wed, 21 Apr 2004, Cannara wrote:
> 
> 
>>David,
>>
>>Interesting that referrals to the poor security or performance designed into
>>the Internet by choice or omission leads to raising Il Duce (Mussolini) from
>>the dead.  So we just ignore the fantastic volume of undesired traffic on the
>>Internet because we're afraid of Mussolini-like discipline?  Being of Italian
>>descent, I recall relatives wanting to hang him, because he was a cheap
>>crackpot with a mistress, not quite the capable fellow you raise.  When we
>>talk personal discipline, let's think more on folks like Michelangelo,
>>Puccini, Da Vinci, etc.,
> 
> 
> I thought that Da Vinci was a total hacker?  I'm not sure that his
> helicopter plans would pass as a disciplined engineering approach
> to design, even at the IETF :-).
> 
> time-to-market (or deployment) wins.  Seems to me that discipline comes
> later, after the innovation and deployment.  We are still to this day
> driving vehicles that burn fossil fuels, which is a bad design choice
> IMO, but there are a lot of very disciplined engineers focused on
> implementing that design choice today.
> 
> Cheers,
> -- Sam
> 

-- 
theo
Nets & Mobile Systems Group
UCL-CS