Subject: RE: [arch-d] Defining terms

From: John Day <[email-masked]>
Date: Tue, 11 Apr 2006 09:47:08 -0400

At 17:03 +0200 2006/03/28, LEVIS Pierre RD-CORE-CAE wrote:
>  Following the exchange on this list with interest I would like to 
>bring up some comments:
>
>- A layered model should not be considered as something stalled and 
>rigid, where any digression would appear like a break in the model. 
>Tunnelling, layers in different orders, should appear as variations 
>on the reference model and normal behaviour, not as faults. That 
>said, I don't mean that

Actually, they should be seen as data.

>any reorganisation is legitimate but only that it should not been 
>rejected just because it does not correspond to the reference model 
>per se. Without being pedantic, this is very much like language, you 
>have grammar that captures the usual way to express things and you 
>have great novelists and great poets that very often use variations 
>from the traditional rules. Would you say Shakespeare didn't write 
>correct English? because it simply didn't write the same way his 
>contemporary fellows used English in there daytime occupations?

Errr, bad example.  One of the theories currently in vogue in 
Shakespeare research is that this is precisely how late 16th C 
English was spoken that Shakespeare merely made good use of it and 
improved on it.  Tom Stoppard has great fun with this in the movie 
Shakespeare in Love, where there are many points in the dialogue 
where some character starts (or ends) a sentence with a part of a 
well-know Shakespeare quote from a later Shakespeare play but then 
the sentence ends (or starts) with something really mundane. 
Stoppard has many references (okay, really in-jokes) to Shakespeare 
research in the movie.  Stoppard is fabulous. Rosencrantz and 
Gildenstern are Dead is one of my all time favorites!

>- I don't see the architectural problem for BGP to be upon TCP if it 
>needs to be. We find routing protocols in various places: RIP is on 
>top of UDP, OSPF is on top of IP. For me, no matter where

Actually this makes all the sense in the world.  OSPF uses IP because 
it exchanges information with nearest neighbors, so the layer below 
provides any error and flow control that is needed.  BGP communicates 
with systems that may be more than one hop away so it needs a 
protocol that will provide that facility and can't rely on the data 
link layer which doesn't have sufficient scope.

It would appear that RIP was early enough that it was unclear to the 
designers exactly where things were.  I think the more interesting 
questions arise when you assume the people who did these were not 
stupid, but may not have had a complete understanding.  So assume 
they were smart enough to have good reasons for doing it, then ask 
what is this telling us about what the architecture should be.  What 
do all of these things tell us about what is going on?  I will 
suggest that while similar to what we have been doing it is 
fundamentally different in some ways.

>the routing protocol is, it is application layer in the sense that 
>there is no layer above. In any layered model, application is the 
>top layer. The ultimate purpose of any network exchange is to convey

Not necessarily.  Applications may operate on top of any layer with 
sufficient scope to reach what ever other application it needs to 
talk to.

>application data from a source where it is generated, to a 
>destination where it is handled. There is nowhere such a statement 
>as data application should be anything but routing information. 
>Applications are not only end-users applications.

Completely agree.

>- I'm very surprised to hear that IETF experts asked by Eric don't 
>see any IP architectue at all. I see at least one great 
>architectural principle: the network layer (or may be better 
>internetwork, or SubNetwork Independent Convergence Protocol for OSI 
>buffs is connectionless and provides a single service to the layers 
>just above(see the hourglass model proposed by Steve Deering). I 
>guess TCP/IP has no more and no less architecture than other 
>challengers like OSI, ATM, or UMTS. Making the statement that IP is 
>only ad hoc assemblage of technologies and techniques is reassuring 
>IP opponents that pretend their protocol stack is very cleverly and 
>truly designed whereas TCP/IP is something cheap and shapeless and 
>don't understand that the current Internet has been possible not 
>despite IP but because of IP.

I guess I would have to agree that what we have is more a Karnack 
architecture.  The problem isn't so much to have a rigid plan of what 
to build, but to have a model that makes predictions about what 
problems we are going to run into and provides the framework for 
solving them.  Whatever Internet architecture we have it has not been 
making a lot of predictions about how to solve the problems we have.

>
>-Layer, plane, module, well ! may be these can be helpful concepts 
>but be sure they don't only bring complexity. A concept is helpful 
>only as far as it helps resolving a specific problem. So if we want 
>to bring a new concept we should be able to show what the associated 
>problem is and how it resolves it. We should avoid defining terms 
>just for the pleasure of providing definitions. However I found in 
>this list interesting reasons raised to consider modules and not 
>only layers, the problem being layers don't correspond to 
>implementation and don't provide enough flexibility.

I would say that for concepts to be useful and considered as concepts 
for moving forward, they have to have two components:  one those 
concepts/structures that are inherent to the problem and those that 
help in resolving multiple problems (one isn't enough.  If we need 
one new concept to solve every problem, we have failed to listen to 
what the problems are telling us.)   As I described earlier, it seems 
that there is something like a "layer" inherent to the structure of 
the problem.   Rather than fight it, perhaps we should consider 
whether we know what a layer is. Perhaps we have not been listening 
to the problem closely enough. There is considerable evidence that 
layers do solve multiple problems, albeit perhaps not the layers we 
were raised on but layers nonetheless.  It does seem that layers are 
less important for implementation, although they can simplify them.

Take care,
John

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

---

From: John Day <[email-masked]>
Date: Wed, 12 Apr 2006 08:14:11 -0400

>>per se. Without being pedantic, this is very much like language, 
>>you have grammar that captures the usual way to express things and 
>>you have great novelists and great poets that very often use 
>>variations from the traditional rules. Would you say Shakespeare 
>>didn't write correct English? because it simply didn't write the 
>>same way his contemporary fellows used English in there daytime 
>>occupations?
>
>>- I don't see the architectural problem for BGP to be upon TCP if 
>>it needs to be. We find routing protocols in various places: RIP is 
>>on top of UDP, OSPF is on top of IP. For me, no matter where
>
>Actually this makes all the sense in the world.  OSPF uses IP 
>because it exchanges information with nearest neighbors, so the 
>layer below provides any error and flow control that is needed.  BGP 
>communicates with systems that may be more than one hop away so it 
>needs a protocol that will provide that facility and can't rely on 
>the data link layer which doesn't have sufficient scope.
>
>>internetwork, or SubNetwork Independent Convergence Protocol for 
>>OSI buffs is connectionless and provides a single service to the 
>>layers just above(see the hourglass model proposed by Steve 
>>Deering). I guess TCP/IP has no more and no less architecture than 
>>other challengers like OSI, ATM, or UMTS. Making the statement that 
>>IP is only ad hoc assemblage of technologies and techniques is 
>>reassuring IP opponents that pretend their protocol stack is very 
>>cleverly and truly designed whereas TCP/IP is something cheap and 
>>shapeless and don't understand that the current Internet has been 
>>possible not despite IP but because of IP.
>
>architecture.  The problem isn't so much to have a rigid plan of 
>what to build, but to have a model that makes predictions about what 
>solving them.  Whatever Internet architecture we have it has not 
>been making a lot of predictions about how to solve the problems we 
>have.
>
>>
>>to bring a new concept we should be able to show what the 
>>associated problem is and how it resolves it. We should avoid 
>>defining terms just for the pleasure of providing definitions. 
>>However I found in this list interesting reasons raised to consider 
>>modules and not only layers, the problem being layers don't 
>>correspond to implementation and don't provide enough flexibility.
>
>I would say that for concepts to be useful and considered as 
>concepts for moving forward, they have to have two components:  one 
>those concepts/structures that are inherent to the problem and those 
>that help in resolving multiple problems (one isn't enough.  If we 
>need one new concept to solve every problem, we have failed to 
>listen to what the problems are telling us.)   As I described 
>earlier, it seems that there is something like a "layer" inherent to 
>the structure of the problem.   Rather than fight it, perhaps we 
>should consider whether we know what a layer is. Perhaps we have not 
>been listening to the problem closely enough. There is considerable 
>evidence that layers do solve multiple problems, albeit perhaps not 
>the layers we were raised on but layers nonetheless.  It does seem 
>that layers are less important for implementation, although they can 
>simplify them.
>
>Take care,
>John