Subject: RE: [arch-d] Defining terms

From: "Bound, Jim" <[email-masked]>
Date: Mon, 6 Mar 2006 18:31:06 -0500

Folks in what is NCOIC www.ncoic.org we defined the layer between
transport and application as infrastructure which leaves far more wiggle
room than the OSI concept of "session" in now public document called the
NCOIC Interoperability Framework (NIF). It is worth looking at is my
input.

NB: If someone here would post as URL I can send, it is 894KB I don't
have place currently to post?

/jim 

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

---

From: "Bound, Jim" <[email-masked]>
Date: Tue, 7 Mar 2006 06:56:51 -0500

this is an important part for discussion and debated widely. I agree
with Tony.
/jim 

> -----Original Message-----
> From: Tony Li [mailto:[email-masked]] 
> Sent: Monday, March 06, 2006 8:13 PM
> To: Fred Baker
> Cc: [email-masked]
> Subject: Re: [arch-d] Defining terms
> 
> 
> > Session Layer:
> > As defined by ISO, the session layer manages user sessions and
> > dialogues, controls establishment and termination of logic 
> links between
> > users, and reports upper layer errors. As defined by Xerox Network
> > Systems, the middleware application Courier provided a 
> Remote Procedure
> > Call service in which incoming sessions were all referred 
> to Courier and
> > transferred from there to other applications a deemed appropriate
> > through AAA policy and parameter acquisition procedures.
> 
> 
> IMHO, the session layer should be responsible for authentication and
> security at a level above the transports.  As a primary example, I'll
> point you to the interesting situation that the X window 
> system has with
> authentication, and the games that we play with SSH tunneling.  If a
> user has an existing session open with another host, then an 
> application
> should be able to inherit appropriate authentication credentials from
> the session layer without a separate interactive authentication step.
> 
> My $.02,
> Tony
> 
>

---

From: [email-masked] (Noel Chiappa)
Date: Tue, 7 Mar 2006 10:02:31 -0500 (EST)

> From: "Bound, Jim" <[email-masked]>

    > now public document called the NCOIC Interoperability Framework (NIF).
    > It is worth looking at is my input.

This is now online at:

  http://ana-3.lcs.mit.edu/~jnc/tech/archd/NCOIC_Interoperability_Framework_v1.pdf

for people to download and peruse.

	Noel

---

From: "Bound, Jim" <[email-masked]>
Date: Tue, 7 Mar 2006 10:06:44 -0500

Thank You Noel.
/jim 

> From: Noel Chiappa [mailto:[email-masked]] 
> Sent: Tuesday, March 07, 2006 10:03 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: [arch-d] Defining terms
>

---

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

Well maybe we should review that decision....the code is not in layers
or products.
/jim 

> From: John Day [mailto:[email-masked]] 
> Sent: Monday, March 20, 2006 9:19 AM
> To: Bound, Jim; Noel Chiappa; [email-masked]
> >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.
> 
> No, the reason we use layers is because the ARPANet did.
> 
> Take care,
> John
>

---

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

A connection is a shared state between two end points for
communications.

A session is is a shared state between two applications regardless of
the connection.

Both should be end-to-end.

/jim 

> From: John Leslie [mailto:[email-masked]] 
> Sent: Monday, March 20, 2006 9:22 AM
> To: Scott W Brim; [email-masked]
> Scott W Brim <[email-masked]> wrote:
> > On Mon, Mar 06, 2006 03:02:24PM -0800, Fred Baker allegedly wrote:
> > 
> >> I would therefore define a "session" as the shared state 
> in the end  
> >> systems and in the network, whatever it may be, which directly or  
> >> indirectly reflects the state of two or more communicating  
> >> applications. In Flow RED 
> (http://www.icir.org/floyd/red.html#flow),  
> >> this would include information stored in network nodes, and it  
> >> generally includes keys associated with security associations,  
> >> sequence numbers etc in TCP and SCTP, and the various 
> addresses that  
> >> are used by endpoints in a multihomed route.
> > 
> > Elsewhere people have come up with the concept that a "session" is a
> > relationship -- not a pipe, not a flow of packets -- 
> created to align
> > state information.  To do so it may use one or multiple 
> communication
> > events.  A successful session could be as simple as "are you there?"
> > with a response.
> 
>    I see a benefit to thinking of "session" as a relationship between
> endpoints. I'm not quite sure either Fred or Scott have stated this
> distinctly enough.
> 
>    Fred is talking "shared state" which, I suppose, is correct; but it
> tends to direct our attention to details of connection(s) 
> which I think
> deserve to be considered a different layer. IMHO, "session" may or
> may not imply an ordering in information transmitted over different
> connections.
> 
>    Scott talks of a "session" being "created to align state 
> information."
> I do not see that either as the "purpose" of a "session" or even a
> necessary function of a "session". IMHO, a "session" should identify
> endpoints which are processes invoked by users without regard to the
> path over which information will flow between them.
> 
>    (Whether or not a "session" implies ordering of data communicated
> might well be implementation-dependent.)
> 
> > Neither is a session the state information itself.  I think these
> > terms will be more useful in the future if you distinguish the
> > relationship between the endpoints -- the "session" -- from the
> > "session state" which reflects the relationship in the participants
> > and intermediate nodes.
> 
>    I agree with Scott.
> 
> > How is a session different from a connection?  Just barely.
> 
>    I think we can draw a fairly clear distinction, actually.
> 
>    A "connection" is something maintained in a fully automated manner,
> without messy interactions. Our network must find a way to 
> route packets
> from one end to the other. Thus, the endpoints of a connection must be
> machine-comprehensible addresses, most often globally unique.
> 
>    A "session" is something created in response to human action. In
> all likelihood, it depends upon rather messy DNS processes to resolve
> to IP addresses which routers can use. If conditions change so that
> those IP addresses no longer serve the necessary function, 
> the human(s)
> creating the "session" would generally prefer that some further DNS
> magic makes the change transparent.
> 
> >  A TCP "connection" can be used by HTTP for one exchange, 
> then allowed
> > to lie fallow, then used for a different one.
> 
>    Agreed.
> 
> > That's one "flow" from the point of view of the network but multiple
> > communications events from the point of view of the applications.
> 
>    True, but in practice all the communications events are likely to
> represent the same "session".
> 
> > One possible difference between session and connection might be that
> > in a connection the participating endpoints are the same for all
> > communication flows, while in a "session" involving multiple
> > communication events, different parties could be involved 
> in different
> > ones.
> 
>    I think I've missed Scott's point here.
> 
>    "Participating endpoints" could mean a number of things. IMHO, we
> can correctly talk of "participating endpoints" for both "connections"
> and "sessions", and mean quite different things.
> 
> > You don't buy it? In that case, really, the only difference 
> I know of
> > is that "connection" is used for lower layers, L4 and below, while
> > "session" is used for L5 and above.
> 
>    Alas! We can't accept that kind of definition. ;^(
> 
> --
> John Leslie <[email-masked]>
>

---

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

Agree with that diff yes.  L1 too.
/jim 

> Sent: Monday, March 20, 2006 9:52 AM
> To: Bound, Jim; John Day; Jari Arkko
> At 9:37 -0500 2006/03/20, Bound, Jim wrote:
> >Perfect example where L2 and L3 are meaningless at least to me.
> 
> Layer 2 and 3 as traditionally described have very different scopes. 
> This is a very significant difference.
>

---

From: "Bound, Jim" <[email-masked]>
Date: Tue, 21 Mar 2006 19:30:39 -0500

Hey John no disagreement here good response.  I was throwing out some
fodder from short period in career when I worked in pure research and
the manager would assign the same task to 3 of us and also ask questions
like I did about layers (and I lapsed on ARPA clearly). I agree we are
about architecture, but a logic check with implementation principles is
a good thing too.  
/jim 

> Sent: Tuesday, March 21, 2006 6:47 PM
> To: Bound, Jim
> Bound, Jim <[email-masked]> wrote:
> > 
> > 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?
> 
>    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.
> 
> > 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.
> 
>    "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.
> 
> > 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.
> 
>    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.
> 
> --

---

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

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

    > destination.

Which is why a lot of router geeks use the term "forwarding" to refer to the
actual handling of user data packets, and reserve the term "routing" for all
activity related to finding paths (i.e. running the routing protocol,
entering the results in the routing table, etc).

    > The IP address, BTW, _defines_ endpoints for layer three.

Terminology alert: the term "endpoint" is overloaded, and has other meanings
too (but you knew that, I expect).

	Noel

---

From: "Bound, Jim" <[email-masked]>
Date: Wed, 22 Mar 2006 10:39:26 -0500

Much wisdom from Noel and I agree 100%   Very hard stuff to do though
but I think we can if we keep this wisdom as background process in our
minds.
/jim

> Sent: Wednesday, March 22, 2006 8:52 AM
>     > From: Alexis Turner <[email-masked]>
> 
>     > the current Internet is nothing but a series of patches 
> building upon
>     > endless series of patches. At some point, engineering a 
> system that is
>     > held together by tape and string .. becomes an excercise in both
>     > futility and stubborness .. 
>     > Who on this list would realistically disagree with that? Can we
>     > honestly say the current system is not broken as hell?
> 
> Basically nobody (maybe nobody at all) disagrees with that. 
> The problem
> arrives when you get to the next step:
> 
>     > It is at that point that the system designers must take 
> a step back,
>     > learn from their mistakes, and start over from the beginning.
>     > ...
>     > If we continue to insist on making something that works with the
>     > current system, the predecessors will remain broken.
> 
> I'm not sure if quite as many agree with this position (that 
> a re-think is
> needed), but that's not the issue. The problem comes when you 
> consider any
> non-incremental change - and moreover consider *how to get it adopted
> widely*.
> 
> It's relatively easy for me (or any number of other talented system
> architects) to sit back, reflect on what went wrong, and what 
> we've learned,
> and come up with cool new architectures. (Been there, done 
> that, as have
> several others.) It's also relatively easy for me (or any 
> number of other
> talented engineers) to figure out an interoperable way to deploy this
> wonderful new architecture. (Been there, done that too.)
> 
> 
> What nobody has ever figured out a good way to do is get such a new
> architecture actually deployed, i.e. get community consensus that this
> wonderful new architecture is the way to go. By definition, any
> non-incremental change represents something of a leap into 
> the dark - and a
> system this size, and in widespread production use, contains 
> a lot of people
> who have the kidney-output-fluid scared out of them by the 
> concept of large
> jumps into the dark.
> 
> Plus to which there will be large fractions of people who say 
> "oh, that's a
> bad idea, we need to do this other thing instead" - and of 
> course, the more
> radical the change, the more likely there are to be people 
> (smart people,
> people with experience) who have a different view of what the 
> Right Thing is.
> 
> Look at how difficult it is for something as simple as HIP to get any
> traction - and even now, it's still pretty much a fringe 
> thing, which will
> take many years, if ever, to really catch on widely and 
> ubiquitously. Now
> multiply the difficulty of doing anything that relatively minor by an
> exponential factor for anything major - e.g. a whole new routing
> architecture. (Been there too...)
> 
> 
> I wrote a longer screed on this issue a month or two back, in 
> reply to Tony
> Li (can't be bothered to dig up a URL for it, sorry - gotta 
> run) - you might
> want to re-read that for a longer discussion of this problem.
> 
> 	Noel
>

---

From: <[email-masked]>
Date: Thu, 23 Mar 2006 11:07:08 -0000

JFC (Jefsey) Morfin [mailto:[email-masked]] said on Wed 2006-03-22 19:13:
> I am afraid I was not clear enough.

No change there, then.

L.

<http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

---

From: <[email-masked]>
Date: Thu, 23 Mar 2006 11:07:08 -0000

No change there, then.

L.

---

From: John Day <[email-masked]>
Date: Thu, 23 Mar 2006 08:39:08 -0500

Oops. Forgot to send this to the whole list.

>>     > the current Internet is nothing but a series of patches building upon
>>     > endless series of patches. At some point, engineering a system that is
>>Basically nobody (maybe nobody at all) disagrees with that. The problem
>>     > It is at that point that the system designers must take a step back,
>>I'm not sure if quite as many agree with this position (that a re-think is
>>needed), but that's not the issue. The problem comes when you consider any
>>architects) to sit back, reflect on what went wrong, and what we've learned,
>>and come up with cool new architectures. (Been there, done that, as have
>>several others.) It's also relatively easy for me (or any number of other
>  A word of caution:  While we all know that getting something 
>adopted is important and an easy effective transition is very 
>important, worrying too much about it too early is precisely what 
>got us in the fix we are in.  We need to figure out where things 
>need to go.  In some sense, it would be good to throw "caution" to 
>the wind and be a little idealistic, knowing full well we will never 
>get there.  Once we understand what that is we can better understand 
>the many steps that it will take to move in that direction.  To 
>worry about transition too much at this stage would be giving up 
>before we begin.
>
>Committees even one like this will behave conservatively if left to 
>their own devices.  My experience is that often more can be 
>accomplished than a committee believes is possible.  If we start at 
>this early stage putting up subtle boundaries, we will end up with 
>YABA (Yet Another Band-Aid).
>
>Perhaps the reason that something as simple as HIP has trouble 
>getting traction is that it doesn't do enough.  The age-old problem 
>that there is not sufficient benefit to warrant fast adoption. 
>Perhaps its sights were set too low.
>
>Given what several people (Eric, Alexis, etc) on this list have said 
>about the lack of an architecture and the current "stuff" being a 
>collection of band-aids, in some sense we need to determine what the 
>logical principles behind building internets are before we start 
>worrying about what architecture the Internet should have and how we 
>expect to transition to it.  It is a scary thought, but it sounds 
>like we are a long way from starting to work on the problem we need 
>to solve.
>
>To some extent, I think this is reflected in current textbooks. 
>Browse through one, consider how much of what is there is reporting 
>what is done and how much are the underlying principles that would 
>allow one to do a good job developing a new protocol or 
>architecture.  They are mostly at the level of vocational-ed, not 
>university.
>
>Yes, we have to make a successful transition and it has to be 
>practical and it has to address real problems people want to solve. 
>But even pushing on that now is going to yield more of the same.
>
>Sorry,
>John

---

From: "Bound, Jim" <[email-masked]>
Date: Thu, 23 Mar 2006 14:30:01 -0500

I don't think so John but lets go play mine is bigger than yours
offline.  1978 at this end.
offline
/jim 

> Sent: Thursday, March 23, 2006 12:06 PM
> To: Bound, Jim; John Day; Noel Chiappa; [email-masked]
> At 11:55 -0500 2006/03/23, Bound, Jim wrote:
> >John, all opinions are important and there is no gospel for layers or
> >architecture. I hear you but several of us who have lived this too
> >simply don't agree.  Noel is spot on.
> >/jim
> 
> 
> Jim, I have been living with this far longer than you have.  And it 
> would appear spent far more time thinking about it.  I sense that 
> Noel is just discouraged. ;-)
> 
> As I pointed out the other day, you can argue it all you want.  There 
> is some sort of distributed black box involved here and there is no 
> way to escape it.  So you may as well learn to live with it. 
> However, it is not clear that layers we came up with in the early 70s 
> were in fact layers we should have.  We hadn't seen much of the 
> problem space then.  Any more than the layers of an OS today follow 
> the layers of Dijkstra's THE paper.
> 
> I contend there is a solution that recognizes layers, is simple, 
> elegant and solves many problems.  There is lots of data.  As 
> Kettering says, one must learn to listen to the problem.  The 
> statement of every problem contains its solutions.
> 
> Take care,
> John
>

---

From: [email-masked] (Noel Chiappa)
Date: Thu, 23 Mar 2006 18:03:16 -0500 (EST)

> From: "Tony Li" <[email-masked]>

    > The ARPANet was architecturally identical to the Internet that we know
    > today.

Ah, no, at least for the classic ARPANET, which was significantly different.

For one thing, the reliability (including timeouts and retransmissions) were
the responsibility of the network, not the hosts. For another thing, the
congestion control was also the responsibiity of the network - it could
actually physically stop hosts from sending data (whether they wanted to stop
or not) if the network became overloaded.

There may be other really significant differences, but those are two, right
off the top of my head.

    > No significant architectural changes have been made since 1/1/83.

Well, yes and no - it all depends on how you define "significant".

Things like VJCC are elaborations of algorithms within the existing
framework, not changes thereto, and don't count.

However, the addition of subnetting was an architectural change of some note,
since it got hosts totally out of the business of understanding anything
about addressing, other than the "on my network/not on my network" divide.
Ditto for DiffServ, which by adding multiple forwarding queues, etc, changes
the basic service model somewhat.

Some of the security stuff might be classified as an architectural change,
althogh I'd have to think about it, since we did have security stuff in the
TCP stack before then. HIP, with its new namespace for end-end, probably
counts as an architectural change, but it's not widely adopted.

NAT, which is now extremely widely deployed, and without which the network
could not survive, is certainly an architectural change (albeit an incredibly
kludgy and bad one).

The transition from GGP to the EGP/BGP group is an architectural change,
because it breaks up the network into areas of discrete control, something
which the GGP generation of stuff didn't provide.

Etc, etc...

	Noel

---

From: [email-masked] (Noel Chiappa)
Date: Thu, 23 Mar 2006 18:12:09 -0500 (EST)

> From: Vince Fuller <[email-masked]>

    > that kind of depends on what you define as "the ARPANET".

Good point.

    > After 1/1/83, when the IP protocol suite was mandated on the ARPANET
    > (and, imho, the "Internet" was born)

I would beg to differ with that date, because prior to 1/1/83 people were
using the Internet for real services, e.g. mail and file transfer to various
hosts connected to local area networks, hosts which had no ARPANet
connection. However, it is certainly true that which date should be considered
The Date is a matter of some dispute...

    > Prior to 1/1/83, the ARPANET architecture was built on other protocols,
    > such as NCP and X.25 transport, GGP and EGP routing protocols, etc.,
    > that were quite different than the IP suite. 

Ah, GGP and EGP *were* IP protocols. The ARPANet itself used two generations
of routing protocol, both completely hidden from the hosts, and implemented
inside the BBN supplied IMP code. The first was a destination-vector design,
and the second a link-state system; both had load-dependent functionality.

Also, X.25 was just a host interface option; internally, it was supported by
tweaks to the IMP-IMP protocols which were already there to support the 1822
Host-Host basic data carrying protocol.

	Noel

---

From: "Bound, Jim" <[email-masked]>
Date: Fri, 24 Mar 2006 00:49:13 -0500

Good analysis.
/jim 

> From: Scott W Brim [mailto:[email-masked]] 
> Sent: Thursday, March 23, 2006 3:15 PM
> 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%20functi
> onal%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.
>

---

From: "Bound, Jim" <[email-masked]>
Date: Fri, 24 Mar 2006 00:49:26 -0500

I agree.
/jim 

> Sent: Thursday, March 23, 2006 3:17 PM
> On Thu, Mar 23, 2006 02:52:15PM -0500, Bound, Jim allegedly wrote:
> > Valid point but I took the BGP more as abstraction to define a layer
> > called routing for discussion. IP model don't call out a 
> routing layer.
> > Forwarding is different than extraplation of routes and discovery
> > clearly.
> 
> Planes are your friend.
>

---

From: "Bound, Jim" <[email-masked]>
Date: Fri, 24 Mar 2006 00:53:17 -0500

That is how I took it too.  And I agree it will get in the way to think
to strictly in terms of layers.  Might be that at the physical and link
layer to violate those layers (or planes I I like planes analysis too)
for hardware processing reasons is not optimal, but there is research
even looking at doing that now.  See IEEE ETA paper I sent some time ago
to the list.

/jim 

> From: Tony Li [mailto:[email-masked]] 
> Sent: Thursday, March 23, 2006 3:29 PM
> To: 'John Leslie'; Bound, Jim
> Cc: [email-masked]; 'Noel Chiappa'; 'John Day'
> > >>> Yes, but, it uses TCP. So it's above the transport layer, right?
> > 
> >    This statement at least makes sense. The BGP routing function
> > can be considered "above" the transport layer.
> > 
> >    But we have no need to enter that argument. From an architectural
> > standpoint, we should see "exchanging information about 
> connectivity"
> > as a network function which is out-of-band to the 
> inter-network layer,
> > and the rest of "routing" (in the Routing Area usage) as not network
> > functions at all.
> 
> 
> I think that we're having a bit of miscommunication here.  At the risk
> of speaking for Noel...  
> 
> BGP is certainly part of the routing function.  Within the 
> conventional
> "layering" that is normally discussed, it is always placed within the
> internetworking layer, along with all of the rest of routing. 
>  The fact
> that BGP uses a transport protocol that actually exists at a higher
> layer is certainly a layering violation to those who are 
> pedantic about
> layering.
> 
> However, I suspect that Noel is not one of those people and is NOT
> defending the pedantic layerists.  Quite the opposite: his 
> point is that
> layering is an obsolete concept and adhering to it excludes 
> an important
> and beneficial part of the architectural solution space.  Good
> architecture is partitioning functionality into a loosely coupled DAG.
> 
> Tony
> 
> 
>

---

From: "Bound, Jim" <[email-masked]>
Date: Fri, 24 Mar 2006 00:56:29 -0500

This is good scientific inquiry to note the past from those that were
there and important to the list for analysis.
Thanks to all of you,
/jim 

> Sent: Thursday, March 23, 2006 6:03 PM

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Fri, 24 Mar 2006 14:26:13 +0100

Further to my response to John Day on the three International Network 
technologies, I count Tymnet I and Tymnet II as a single 
architecture. They were however worlds apart. It seems from private 
comments received that a few still remember Tymnet, but only know the 
early days and Tymnet I. Tymnet I was an home made timesharing 
oriented system. It had been enhanced on experience. It was initially 
close to the Tymshare Operating System which supported network functions.

Tymnet II was a totally different solution. It was built on ISIS - a 
network wide operating system managing Tymnet II machines. It offered 
backward compatibility to Tymnet I as a foriegn technology. It 
permitted a incredible architectural versatility and a quasi 
illimited ability to support different architectures and services. 
However much of the possbilities of Tymnet - alternative routing, 
daisy chaining, user's choice of the routing strategy, filtering, 
statistics, externets, virtual gateways, etc - depended on a 
centralised supervision. The system was reliable but not designed for 
datagrams (however it was [and the architecture still is] a leader in 
credit card transaction). Connectionless datagrams were fully 
implemented in Tymnet III, with many new additional features and 
services. This was (as far as my own epxerience goes) interrupted by 
the purchase of the Tymshare corporation and the progressive 
disbanding of the Tymnet management and R&D.

The way Tymnet II was used internationally (national gateways and 
networks, multinational private networks) was very different from the 
domestic operations. This shown the huge capacities of the concepts. 
I never coded a Tymnet program, but the speed of the deliveries of 
new services and the experimented total lack of bugs (except some 
wrong parametering by field engineers) shows the high level of QA; 
and the relative programing simplicity insured by the ISIS 
architecture. This being said I have no experience of the Tymnet 
protocols and architectures when submitted to heavy traffic. However 
we supported stop-TV, compressed TV and compressed international 
phone links without degradation.

Tymnet I was an access solution with proprietary high speed host to 
host services. Tymnet II was a full valued added virtual circuit 
switch multilateral system. Tymnet III was a fully distributed 
user-centric service-oriented fast, secure, sure, scalable 
architecture. I was actually an internal Tymnet technology user with 
complex needs (to address monopolies requirements, to implement 
extended services and to deploy the multinational services). Our 
initial demands permitted further on to swiftly and smartly address 
domestic security and load management issues. As a result we had the 
attention and the support of R&D. Snce then, I never read any new 
network technology proposition which would deliver as much as what 
Tymnet III would have delivered.

However, past glory of a technology ignored by most is not the point. 
Neither the way its protocols worked. What is of interest is the 
experience of the services it delivered, and the public adopted. And 
the architecture which permitted it to be accepted by nearly one 
hundred sovereign or independent entities in a multilplicty of 
real/virtual network designs and changes.This to support the paying 
(on traffic/connect time basis) international users of a catenet 
counting millions of users and interconnecting all the existing 
technologies. Also  to deploy three versions, two technlogies (its 
own one and OSI), two adressing systems (name space and numeric 
addressing - in a way similar to HIP), to introduce a third 
technology (Internet) within 10 years time.

jfc

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Fri, 24 Mar 2006 19:15:12 +0100

At 15:37 23/03/2006, John Day wrote:

>I completely agree with Jefsey on this.
>But I do have one question.  If the Internet is the 3rd 
>architecture, what were the other 2?
>ARPANet and CYCLADES?

This post is long. It could be the basis of a Draft if others joined 
to gather and report the passed experiences we could jointly table on.

To be of use I thought necessary to introduce the answer with some 
references, including historic architectural experience. I tried to 
keep it limited to what I think of (key?) interest today. I tell what 
I saw/made. I took some decisions because I was in charge. I was not 
a geek but at a key position. I learned from that position. I only 
try here to pass what I learned, in the hope it may help. Until 1998 
I only known "the Internet" from outside. If I am incorrect or if I 
miss infos, thanks to correct me. History is not an easy task. If 
people who shared into some of this, I would be glad to get their own 
inputs. Thanks.

jfc

Response:

ARPANET and Cyclades were experimental networks which only developed 
locally. ARPANET in the USA and Cyclades at INRIA in France. You all 
know about ARPANET. Cyclades was conducted by Louis Pouzin. John Day 
pointed out some technical influences. From what I understand Louis 
Pouzin hired consulting services from ARPANET when he started the 
project in 1972, hence cross-polinization.

I would like to underline I talked of the "International Network" and 
therefore of architectures of global deployment and operations. In 
that case the protocol becomes potentially global. But this is a 
consequence, not the root of the architecture. What counts first are 
the purpose and the basic concepts. To quote some concepts this 
community is familiar with: network concatenation, addressing, 
naming, routing, end-to-end, multitechnology, etc  But there are 
others this community is not familiar with or has not commonly 
defined yet. This is where passed experience may help illustrating 
them, and understanding if they may serve the future.

Louis Pouzin

When considering a revamp of the network architecture, I think worth 
to spend lines on Louis Pouzin first. I wished to propose him for the 
ISOC award last year. He is the one who matches the best my own 
vision. Many supported the project, but Vint Cerf pointed out that 
his contribution was wider than the Internet, and not oriented 
towards the Internet community (the focus of this ISOC award, Vint 
created)- he proposed some other good ideas to pay Louis the tribute 
he deserves. The lack of knowledge of Louis' founding proposition may 
be our main problem today - missing the very conceptual roots of our 
technology. I first met Louis in 5/78. Vint wrote great things about 
him. We created together Eurolinc for a European Multilingual 
Internet (first Chair was Jean-Louis Grangé of his Cyclades team). He 
was quite active and influent at the WSIS. And an advisor of European 
and International instances.

Louis invented the prompt, the script, the mail (developed by Tom Van 
Vleck), the datagram as it is today (IP windowing). In our today area 
obviously Louis' most important contribution is the "catenet" 
concept. Vint applied it in http://www.isi.edu/in-notes/ien/ien48.txt 
to introduce the  Internet: "THE CATENET MODEL FOR INTERNETWORKING, 
July 1978, The Catenet Model for Internetworking - Introduction - The 
term "catenet" was introduced by L. Pouzin in 1974 in his early paper 
on packet network interconnection [1].  The U.S. DARPA research 
project on this subject has adopted the term to mean roughly "the 
collection of packet networks which are connected together.".

Brian Carpenter

Louis Pouzin's concepts were well understood by Brian Carpenter. He 
wrote a key consideration enlarging Vint's vision. I think important 
to quote it as I consider this text of IETF culture is the nearest 
from my own experience and vision. Even if Brian might dispute it.

"When the catenet concept (a network of networks) was first described 
by Cerf in 1978 [IEN 48] following an earlier suggestion by Pouzin in 
1974 [CATENET], a clear assumption was that a single logical address 
space would cover the whole catenet (or Internet as we now know it). 
This applied not only to the early TCP/IP Internet, but also to the 
Xerox PUP design, the OSI connectionless network design, XNS, and 
numerous other proprietary network architectures.

"This concept had two clear consequences - packets could flow 
essentially unaltered throughout the network, and their source and 
destination addresses could be used as unique labels for the end systems."

"The first of these consequences is not absolute.  In practice 
changes can be made to packets in transit. Some of these are 
reversible at   the destination (such as fragmentation and 
compression). Others may be irreversible (such as changing type of 
service bits or decrementing a hop limit), but do not seriously 
obstruct the end-to-end principle of Section 2.1. However, any change 
made to a packet in transit that requires per-flow state information 
to be kept at an intermediate point would violate the fate-sharing 
aspect of the end-to-end principle."

"The second consequence, using addresses as unique labels, was in a 
sense a side-effect of the catenet concept. However, it was a 
side-effect that came to be highly significant. The uniqueness and 
durability of addresses have been exploited in many ways, in 
particular by incorporating them in transport identifiers".

We discuss the transition to new technologies. I said that an 
architectural transition was the interconnection of a new community 
of users. This text gives many clues from the very "inside" of the 
current internet on how to address this situation. Let me add that, 
from my brainware + user-centric + extended services (network 
services to the content) point of view, I read catenet as "the 
networks of the network of the networks" (cf. conclusion). IMHO this 
is the - long, long delayed - evolution of the architecture we need.

Tymnet

Now, I can address the question. The International Network really 
started a few years before Vint's IEN 48 proposition. Larry Roberts 
had created a commercial network service named Telenet, using BBN 
machines. They had applied to the FCC for a public operator licence. 
To force an FCC decision they threaten to sue those who operated a 
public packet switch service without a licence. There were two of 
them: Tymnet and Uninet.

Tymnet had issued the first packet-switch service bill (we would name 
it an ISP today) on Feb, 28th, 1972. It was the affiliated network of 
Tymshare Inc., the third US timesharing service, with affiliates in 
UK, France, Belgium, Germany and Japan. At that time it offered 
domestic and international access to more than one hundred 
information databases, banks, corporations and specialised services. 
Its CEO, Bill Combs, and Tom O'Rourke, Tymshare Chair, found its was 
a good idea. They also applied for a licence. FCC gave both a 
temporary nationwide Value-Added-Network licence. Tymnet used names 
and addresses: FCC also gave Tymnet responsibility for the namespace. 
Tymnet negotiated interconnections - along with FCC and ITU rules - 
with the US International Record Carriers (first ITT, RCA and WUI) 
and to transfer its foreign users and services to the foreign monopolies.

Bob Tréhin had to "sovereignise parts of an existing network" (1977). 
This was very much like what need to do today after, Tunis and China 
started with Chinese Names, without balkanising the Internet. He was 
assisted by Joe Rinde who designed the Tymnet core system. Bob 
introduced the "root name" principle 
(http://jefsey.com/rootname.pdf). This compartimented the network 
into "externets" ("external network look-alike, possibly within the 
same network, possibly through a virtual gateway" - the term came 
later on, when discussing Internet 'external networks' interconnects 
- RFC 920). When we met Louis Pouzin to hook Cyclades in 5/78, the 
International Network "catenated" already the French, British, 
German, Belgium, Swiss, Italian, Spanish, Dutch public externets. 
They had a local gateways, their own registry, their independent 
management, stats, accounting, etc. an interconnect (through Tymnet 
and the IRCs) to Telenet and Uninet networks. We also supported the 
ESA (European Space Agency) private net. ARPANET was indirectly 
connected in several places, including in Versailles for Ichbiah's 
development of ADA during the next year.

The initial Tymnet I, architecture was replaced on the end of the 70s 
by Tymnet II and ISIS a networked OS offering huge possibilities. 
Tymnet from then on opened every new US international relation and 
most multinational relations until 1986. We operated 90% of the 
International traffic (foreign end) and 100% of the US international 
traffic. I opened the first foreign/foreign relation 
(Belgium/Netherlands) and hooked the first large Tymnet International 
private network (at Philips - where "com" and "net" where created and 
then pasted everywhere). Bob Tréhin implemented the Swedish Public 
Network, while Telenet built PSS the UK network. Germany then opened 
their Northern Telecom Datex-P. The French Transpac soon became the 
largest network in the world, quickly reaching one million users, and 
then 80% of the French people by mid-80s, with Minitel. We teamed 
with many for experimentation in the US and in Paris. Web like 
applications were developed using stop-TV, local TV, etc. Tymshare 
hired Doug Engelbart (I tried to implement his "Augment" solutions on 
my international new machines, but we found that networking "extends" 
services [and errors :-)], far far more than it "augments" people's 
IQ. The next generation systems we experimented included local proxy 
databases for image, text, etc. and content oriented extended services.

Tymnet III was specified from this accumulated field proven 
experience. The Extended Network System model was worked on. I have 
not  read yet a proposition which offered something which was not 
easy with Tymnet III, ISIS II and the new generation of Tymnet 
Engines under test. Tymnet having been purchased by McDonnell 
Douglas, we progressively disbanded. The status of the International 
Network, mainly under Tymnet technology, when the Internet was 
created is documented at http://intlnet.org/intlhist.htm . A service 
description is at http://intlnet.org/intl84.htm (my draft for the 
document we distributed). Tymnet brought the support of global 
communications from nil to millions of users.

OSI

Tymnet technology supported smart interfaces or services in the 
network nodes (named "slots"). Located at the "edge" as we would say 
today, they permitted to support any other technology (DECNET, SNA, 
SWIFT, OSI, etc ..). Along with one of the possibilities described in 
RFC 2775, it transmitted protocols metadata separately from data. 
Tymnet had introduced the virtual circuit concept [as a secure "pipe" 
- no spoofing permitted]: it was actually a reliable virtual circuit 
switch. It used internode multiplexed packets: offering impressive 
end to end  keyboard echoing at no extra load/cost. There was a 
proportional decrease of the resulting overhead with the traffic 
load. Liaisons were fast and efficient (for the time). This permitted 
to translate protocols, and to provide TCP/IP-X.25 liaisons for 
example. The initial architecture was not datagram oriented (Tymnet 
was however intensively used for credit card transactions). The 
architectural evolution underway would have progressively lead to 
their full support, while keeping the speed, security and surety benefits.

We therefore soon became the main (and quasi only) international 
implementors of OSI of the time. First X.25 and then X.75 once we had 
stabilised common parameters with PTTs through an operator/user club. 
We established X.75 real or virtual links to all the operators and 
X.25/PAD local support, operating a catalog of more than 40 X.25/75 
brands. This lead me to create and deploy (with Dominique Marchand) 
the X.121 addressing scheme of all "our" countries externets - 
everyone but an handful. We treated them as numeric addresses, 
numbers or names, depending on the used architecture (OSI, 
Telephone/Teletext/Fax  or Tymnet).

Tymnet was later on purchased by BT and standardised to X.75. OSI 
brought the International Network to one hundred million users. 
Mostly in Europe and Japan. It supported Videotext, etc.

Internet

End 1983 the DoD asked Tymnet to interface the ARPANET Internet. This 
was for international connections, local virtual links to some 
Universities and remote public access and out-dial (Tymnet at that 
time had 500 access/out-dial (to private hosts/PC) nodes nationwide). 
We announced TCP/IP support in Dec. 83. The technical dialog was with 
our "Federal" office (probably until mid-84?). I supervised all the 
interconnects being responsible for International operations for 
naming and addressing compatibility.

We had two main issues: naming and tunnelling (I made the mistake not 
to press for addressing, otherwise we would be IPv6 for a long).

1. the target was to provide a tunnel with Internet foreign 
communities (standard "virtual circuit" - or a "pipe") at better 
price than a dedicated line or/and as a back-up for dedicated lines. 
This was called "refilling". It was also to provide access to DoD and 
State Department personnel when travelling, and to Embassies. 
Refilling had been actively explored by Jack McDonnell (Chair of TNS 
Inc.) and was mostly used by private international telex operators 
(another architecture partly supported). For this reason, refilers 
were named after ISO 3166 Alpha2 [telex codes] (Public services 
registries were named after ISO 3166 Alpha3 [Radio codes]). This 
created the ccTLDs as documented in RFC 920.

IP clusters were easily supported this way when introduced in 1986 - 
if I am correct - in Wien. The path was TCP/IP to the Gateway, Tymnet 
Protocol to the X.25/PAD service of Radio Austria

2. International naming was then left to right, one single string 
(root-name [TLD] + network-name [domain name] + local-name [3rd+LD]). 
This was less flexible than the right to left doted format. But it 
permitted a direct support of X.121 (DNIC+Numbers) and Out-dial 
(local telephone numbers). Internet was reluctant to change their 
inner naming to the international naming: the  number of networks 
they had to concatenate was large, and this made the caller to decide 
the routing (via Internet or via a gateway when this was possible). 
So they came from "name" to "name.arpa" to train everyone. Then to 
"name.com" through the Gateway. We first only checked if there was a 
"." in the name to accept the call, reversing the order. But this 
created a problem with IP addresses. We asked that names would come 
from the Internet with a final dot ("dot-root") and checked it. We 
also decided that all numeric names would not be changed.

Internet has now brought the International Network to one billion 
user. We now look for the approach which will rise usage to 10 
billions people and stations.

Some resulting experience

Among other (this is just a rushed mail) I think this shows from experience:

- the user is the decision maker. The QoS they get and the respect of 
the user (operator) needs/decision/interests makes the adherence and 
the decision. When we talk of market acceptance, we only say "if 
users think they get enough for their money". If they poorly 
understand a brilliant concept, it will not fly. What flies is are 
rustic, simple, secure solutions which works and people understand. 
In fact, the network is not what the designers designed, but what the 
users think/want it is. If both do not match, forget about it!

- This is important because it means that the IAB/IETF is _not_ in 
charge of the future network (which should be backward compatible) 
and has the divine right to design it, based upon a TCP/IP+. It means 
that we all are in competition to deliver something appealing to the 
next generation people. There is no exclusive of situation. If I 
fought (and globally won) toughly the RFC 3066 Bis proposition to get 
a consensus I was denied and they now challenge, it was because it 
concerns the core of the Multilingual Generalised NGN (MGN). A 
proposition that people will _refuse_, killing the chances of any 
IETF new architecture proposition.

- packet massaging on the plug to plug interoperability path is not a 
violation of the "end to end" concept, nor of the [more interesting 
to the user] brain to brain interintelligibility one.

- we need to go one step further, accomplishing the whole catenet vision.
   o "the networks" is the hardware oriented infrastructure which 
supports the convergence.
   o "the network of the networks" is the software oriented 
superstructure we live with.
   o "the networks of the network of the networks" is the brainware 
oriented metastructure where the network architecture evolution has to deliver.

etc.