Subject: RE: [arch-d] Defining terms

From: "Bound, Jim" <[email-masked]>
Date: Mon, 20 Mar 2006 09:07:41 -0500

I think we should for a moment imagine a world without layer but as
modules.  Really that is how the actual code is and not in layers.  Sure
IP packet gets parsed before TCP, and TCP makes decisions before passing
data, as example here only, but is that layers or as Noel states
modules?

As far as the edge doing routing I think that is the wrong question?
Once a packet has a destination path it should be move to that path?
That is done with routing.

Now finding the most optimal path at a point on a network is fine any
time whether at the edge or within the core.  So I think this may be a
moot point.

Also should we define what we mean by the "edge".

Also is the only reason we use "layers" for the IP Reference Model
because OSI did?  If so that was a bad reason?  I don't think that work
in IEEE had anything right for an "Internet" model, as a bias clearly on
my part.

Noel I would like to see your design as one person here.

Also I have interpretation of Saltzer/Reed for end-to-end which could
take us down the religious path, but end-to-end to me is routers only
get to forward based on the IP address and end-to-end cannot be possible
unless each client on either end of the commo both have a globally
routable source and destination address.  Changing the IP address in a
header breaks end-to-end.

/jim

> -----Original Message-----
> From: Noel Chiappa [mailto:[email-masked]] 
> Sent: Monday, March 20, 2006 8:53 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [arch-d] Defining terms
> 
>     > From: Fred Baker <[email-masked]>
> 
>     > Everything *can't* be done at the edge; for example, 
> where do we do
>     > routing? Not at the edge, and we in fact have a 
> knee-jerk response
>     > *against* having the edge involved in routing. 
> 
> I'm not sure exactly what you meant here, but please note 
> that although we
> do routing (path selection) in the network today, it doesn't 
> *have* to be
> done there; you *can* do routing (path selection) at the edge.
> 
> (I produced such a design, and I feel that for architectural 
> reasons it
> would be superior to do it at the edge, but I don't expect to 
> see it in my
> lifetime - and that's not a rhetorical device, I'm already almost 50.)
> 
> 
>     > if multiple upper layer protocols require the same 
> service and the
>     > network layer is capable of delivering it, doing it 
> once instead of
>     > many times makes sense to me. 
> 
> Right - but that doesn't mean the network layer should do it. 
> The added
> functionality will make the network layer more complex, and 
> applications
> which don't need that capability will have to pay the price 
> even if they
> don't need it.
> 
> As others here have pointed out, the whole "layer" concept is 
> the wrong way
> to look at it. It's a modularized system, just like any other 
> large system,
> and we need to look at it as a module dependency graph, hopefully one
> without any dependency loops (operating systems were the 
> earliest to develop
> this whole model, but it's common now).
> 
> So, yes, only implement that service once - but as a 
> subsystem that other
> subsystems can call on when they need it.
> 
> The only reason I can think off off the top of my head to 
> make something
> mandatory, and part of some low-level abstraction, is when 
> you want clients
> not to be aware that they are using it - e.g. paging 
> (operating systems), or
> mobility (networks) - so that clients don't have to do 
> anything "unusual" to
> get it, and so that users always have the capability, and the client
> designer/implementor can't screw up and take that capability 
> away from the
> user.
> 
> 	Noel
> 
> _______________________________________________
> Architecture-discuss mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/architecture-discuss
> 

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

---

From: John Day <[email-masked]>
Date: Mon, 20 Mar 2006 09:18:34 -0500

>in IEEE had anything right for an "Internet" model, as a bias clearly on

No, the reason we use layers is because the ARPANet did.

Take care,
John

---

From: John Leslie <[email-masked]>
Date: Tue, 21 Mar 2006 18:46:52 -0500

> data, as example here only, but is that layers or as Noel states

   Let's not forget that layers are an abstraction, intended to limit
the complexity which any one process needs to deal with. If we do layers
correctly, every process can ignore most of what's happening at lower
layers as well as everything happening at higher layers.

   Tunneling doesn't break the abstraction: it merely confuses the folks
who try to visualize the whole system and think there's something wrong
when a layer-four procedure is used to implement a layer-two function.
The abstraction still works fine: the layer-three built on top of that
tunnel need know nothing about how the layer-two is actually implemented
over a layer-four tunnel.

   It's true that implementation may blend layers and implement the
combined layers as modules. This doesn't break the abstraction either
(unless the implementation is buggy). I used to write implementations
like that, when processing cycles were expensive. The implementor can
still think of layers even if the implementation isn't layered.

> That is done with routing.

   "Routing" is two almost-unrelated things: generating a path which
"should work" vs. passing packets to another router "closer" to the
destination. Both of these get arbitrarily complex as topology changes.
(And, believe me, it does!) The abstraction says that passing packets
from router to router exists in a layer separate from encoding bits
(a lower layers) and also separate from establishing and tearing down
"connections" (a higher layer).

   The other "routing" function is quite a different matter; and might
as well be considered out-of-band communications.

> time whether at the edge or within the core.  So I think this may be a

   Agreed. It is mostly orthogonal to our layering model.

> Also should we define what we mean by the "edge".

   A bit late to start that... ;^)

> because OSI did?

   No.

> If so that was a bad reason?

   It wouldn't have been a bad reason.

   We have formed an abstraction we call "layers" totally separate from
what OSI called "layers". That the two have converged at all over the
years is, IMHO, a good thing.

> ... but end-to-end to me is routers only get to forward based on the
> IP address

   "End-to-end" IMHO means that we didn't want routers guessing what
something at layer four or above wanted to do with the data: we wanted
routers doing a simple-minded task that was easy for layer four to
model; and that layer four would do all the worrying about anything
beyond that simple model that it might need.

   This has led to things like the Web just happening, without any
waiting for routers to learn how to serve the needs of browsers and
servers better. (We certainly know now how to serve those needs
better; but most folks prefer that the Web happened when it did.)

   The IP address, BTW, _defines_ endpoints for layer three. The fact
that it serves any other purpose is immaterial to layer three.

> and end-to-end cannot be possible unless each client on either end
> of the commo both have a globally routable source and destination
> address.

   Fully agree. (That's pretty much the definition of layer three...)

>  Changing the IP address in a header breaks end-to-end.

   Um... I'd really like to agree. (I hate NATs.)

   But actually, NATs kludge the actual layer three so that it looks
just like a layer three to unsuspecting layer-four processes, despite
having been thoroughly broken in the middle. Thus end-to-end still
works (mostly).

   (BTW, NATs could be much cleaner and less buggy if we kept "session"
endpoint addressing entirely separate from level-three IP addressing.)

   To summarize: Jim is correct about implementation; but we should
be discussing architecture. Implementation is engineering, not
architecture.

--
John Leslie <[email-masked]>

---

From: [email-masked] (Noel Chiappa)
Date: Tue, 21 Mar 2006 21:15:31 -0500 (EST)

> From: John Day <[email-masked]>

    > Now of course, this collection of users can also cooperate to do
    > something and provide a black box to their users.
    > So now, if these are not layers what are they? pancakes? waffles?
    > I would contend that layers are a means of organizing functionality

The problem with layers is that are a simplification of reality - and,
moreover, a simplification that rapidly becomes stultifying and confusing.
The reality of the subsystem/protocol dependency graph, in real networks, is
too complex to be captured with the simple ordered layer model.

As one example, look at BGP. It's used for passing around routing info - so
it's part of the inter-network layer, right? Yes, but, it uses TCP. So it's
above the transport layer, right? "Does not compute! Does not compute!" Or
what about those things that open a PPP link over a TCP connection? Similarly
confusing.

What's really important, for a system architect, is the subsystem dependency
graph. Anything which confuses that representation is non-optimal - and an
ordered layer model definitely counts.

To put it another way, layers may a fine device for introducing basic
networking concepts to beginning students, but they are really a bad idea for
use by anyone past the level of "initial introduction". To mangle one of my
favourite military axioms, "Beginners think in layers, everyone else thinks
in subsystem dependency graphs."

    > So we have a collection of things in different systems all cooperating
    > with some amount of shared state and doing it in some black box to hide
    > the complexity from the user of the black box.

Right - and this touches on a point I like to rant about, which is that too
often: In drawing block diagrams, people treat "the part of subsystem X in
machine A and "the part of subsystem X in machine B" as more distantly
related than "the part of subsystem X in machine A" and "the part of
subsystem Y in machine A". In other words, they tend to draw diagrams in
which the main boxes are machine A and machine B, with maybe little sub-boxes
inside those boxes for subsystems X and Y. However, when you're trying to
understand the subsystem dependency issues, this makes those dependencies
much harder to see. The other kind of diagram, in which the main boxes are
subsystems X, Y, etc are much rarer - alas.

    > Although, if you *need* a boundary for some reason, some place a layer
    > boundary is a good place to do it, if you have chosen your layers
    > wisely.

A layer boundary is, in many ways, just a subsystem interface definition.

Of course, anytime you break a system up into subsystems, the issue of where
you put the boundaries, and what info is passed across them - that is (to me)
the heart of architecture.

	Noel

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Wed, 22 Mar 2006 14:36:23 +0100

>in subsystem dependency graphs."

To put it in another way, layers are terms of reference that permits 
architects with different visions to understand (interface, converge) 
each others - and to check their own consistency. They are to 
describe the underlying reality, not the proposed solutions. The role 
of an architect is to curb reality to make it beautiful and efficient 
(what we often phrase KISSS - simple, stupid, scalable).
jfc

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Wed, 22 Mar 2006 14:36:23 +0100

---

From: "Fleischman, Eric" <[email-masked]>
Date: Wed, 22 Mar 2006 09:58:28 -0800

From: John Leslie [mailto:[email-masked]] 
>Tunneling doesn't break the abstraction: it merely confuses the 
>folks who try to visualize the whole system and think there's 
>something wrong when a layer-four procedure is used to implement 
>a layer-two function. The abstraction still works fine: the 
>layer-three built on top of that tunnel need know nothing about 
>how the layer-two is actually implemented over a layer-four tunnel.

Tunneling usually makes network management more difficult: the reason
for a failure within a "black boxed entity" is harder to discern -- and
fix. For large deployments, which are inherently difficult to manage
because of scale and device diversity, this added difficulty can be very
onerous indeed. 

Configuration management is a difficult problem for which better tools
are definitely needed. Tunneling exacerbates this difficulty.

Tunneling often also has performance implications related to latency and
capacity consumption.

Nevertheless, tunneling has become very prevelent in today's networks.
Nothing is for free.

---

From: John Day <[email-masked]>
Date: Thu, 23 Mar 2006 09:01:59 -0500

Running a little behind.

>layers as well as everything happening at higher layers.

Agreed.

>when a layer-four procedure is used to implement a layer-two function.

Disagree.  There is nothing wrong with both layer 2 and layer 4 
having the same functions, because they are performing the same 
function over different scopes.

>over a layer-four tunnel.

I prefer to think of tunneling as a somewhat "bad" short cut.  It is 
what happens when you try to use only part of a  layer without 
bringing along the rest of its machinery.  Generally, it creates as 
many problems as it solves.

>still think of layers even if the implementation isn't layered.

Absolutely.  Layer boundaries only have to be "real" if the 
implementation happens to need a boundary somewhere.

>"connections" (a higher layer).

Actually, I would say routing is 3 distinct tasks:  exchanging 
information about connectivity and other information, calculating 
connectivity based on what you have collected, and then choosing a 
next hop/path based on the calculation and the other info.

>that it serves any other purpose is immaterial to layer three.

That is a bit nebulous.  IP addresses define layer 3 points of 
attachment, which is the same as a layer 2 protocol machine.

>    Fully agree. (That's pretty much the definition of layer three...)

Actually disagree.  A transport protocol can operate end to end over 
relays that change addresses.  TCP can't, but in general a transport 
protocol can.

>  >  Changing the IP address in a header breaks end-to-end.

Only with TCP.

>    Um... I'd really like to agree. (I hate NATs.)

NATs only appear to cause pain because we currently have half an 
addressing architecture.   NATs merely create multiple layer 3s of 
different scope.  Just like we have  multiple layer 2s of different 
scope.

>having been thoroughly broken in the middle. Thus end-to-end still

yep. See above.

>endpoint addressing entirely separate from level-three IP addressing.)

ABSOLUTELY.  Thank you for saying this.  Actually it isn't session so 
much as application.  To paraphrase Bucky Fuller, NATs only break 
broken architectures.  If we had a full addressing architecture it 
wouldn't be a problem.  I have often described applications passing 
IP addresses as similar to a JAVA program passing absolute pointers. 
;-)

Take care,
John

---

From: John Day <[email-masked]>
Date: Thu, 23 Mar 2006 09:01:59 -0500

Running a little behind.

Agreed.

Only with TCP.

yep. See above.

Take care,
John

---

From: John Day <[email-masked]>
Date: Thu, 23 Mar 2006 09:25:10 -0500

>moreover, a simplification that rapidly becomes stultifying and confusing.

Then you don't have the layers right.

>it's part of the inter-network layer, right? Yes, but, it uses TCP. So it's

Is it?  What is its scope?

>above the transport layer, right? "Does not compute! Does not compute!" Or

No.  There is no rule that says a protocol and the layer it is used 
in are fixed.  Protocols are means to providing certain kinds of 
coordination.  I can use any protocol in any layer where it does what 
I need done.  Sure it computes.

>what about those things that open a PPP link over a TCP connection? Similarly

Not in the least.  In fact, they show a deep understanding of what 
network architecture is all about.

>ordered layer model definitely counts.

Yep.

>in subsystem dependency graphs."

Then you haven't gotten your layers organized right.  When they are, 
they not only work but they do more things than we are currently 
doing and do them well and easily.

C'mon Noel, I know you better than this.  Step back and look 
carefully.  Use all of these as data.  Consider what the data is 
telling us.

>subsystems X, Y, etc are much rarer - alas.

Indeed they do. This (as you know) is usually to indicate the degree 
of coupling.  modules in the same system are generally more tight 
coupled than those that are not.  At the very least modules in the 
same system can coordinate with a test-and-set.

>the heart of architecture.

Most definitely.

Take care,
John

---

From: "Mark Handley" <[email-masked]>
Date: Thu, 23 Mar 2006 16:53:30 +0000

> data, as example here only, but is that layers or as Noel states

I made one attempt to do this a few years ago with Role-Based Architecture:
  http://www.cs.ucl.ac.uk/staff/M.Handley/papers/rba-hotnets.ps

The idea was not to layer functionality, but to address it to agents
that performed specific roles.  In this way, you could address boxes
along the path (such as firewalls, etc) and in the end-systems without
specifically knowing of their existence in advance.

Is this the sort of thing you're thinking about?

 - Mark

---

From: Scott W Brim <[email-masked]>
Date: Thu, 23 Mar 2006 14:15:11 -0600

On Tue, Mar 21, 2006 09:15:31PM -0500, Noel Chiappa allegedly wrote:
> As one example, look at BGP. It's used for passing around routing
> info - so it's part of the inter-network layer, right? Yes, but, it
> uses TCP. So it's above the transport layer, right? "Does not
> compute! Does not compute!" Or what about those things that open a
> PPP link over a TCP connection? Similarly confusing.

There is a layer network which provides (at least) IP packet service.
It can run over other layer networks (e.g. SDH).  BGP is part of the
control plane of this layer network, while the usual packet forwarding
functions are in the forwarding plane.  The transport functions which
both packet forwarding and BGP take advantage of can be viewed as
being in both planes -- they are functions, and functions can perform
in multiple planes (and even multiple layer networks).  Just because a
BGP "session" takes advantage of the same forwarding functions as a
forwarding plane capability does does not put BGP "in" or "above"
anything in the forwarding plane.  The planes are orthogonal.  

swb

Lengthy Skippable Background Appendix: The layer network concept comes
out of ITU-T SG15.  Each layer network has its own identifier space
for the points between which it moves data, and can include multiple
classic OSI "layers".  ATM provides a layer network, and can have 4
layers (more?).  IP can have its own set of OSI layers and run over
ATM.  The following excerpt comes from
http://www.niven-jenkins.co.uk/An%20introduction%20to%20functional%20architecture.pdf

    As noted in G.805, the term layer (or layer network) is used by
    both G.805, G.809 and X.200 when describing and decomposing a
    given layer network stack. However, layer networks defined using
    functional modelling (as described by G.805 and G.809) should not
    be confused with the layers of the OSI Model (ITU-T Recommendation
    X.200). Each layer in the OSI model can only offer a specific
    service and the protocols defined at each layer perform a specific
    function corresponding to that layer.  For example the OSI
    transport layer (Layer 4) accepts data from the OSI session layer,
    and passes it onto the OSI network layer providing an end-to-end
    delivery service. In contrast, each layer network in a functional
    model based on G.805 or G.809 offers the equivalent services to
    OSI layers 1, 2 and 3 (although one or more of OSI layers 1, 2 or
    3 maybe non-existent for some layer network technologies), in
    other words functional models based on G.805 and G.809 provide the
    transport of information (bits/frames) between inputs and outputs.