Subject: [arch-d] RE: Defining terms

From: "Fall, Kevin" <[email-masked]>
Date: Tue, 21 Mar 2006 17:11:40 -0800

> 
> ----- Forwarded message from Fred Baker <fred at cisco.com> -----
> 
> 
>   Date: Mon, 6 Mar 2006 15:02:24 -0800
>   From: Fred Baker <fred at cisco.com>
>   Subject: [arch-d] Defining terms
>   To: architecture-discuss at ietf.org
>   X-Mailer: Apple Mail (2.746.2)
> 
> OK, so this takes off on one of the many topics we have been
discussing...
> 
> 
> Let me see what I can add to this.
> 
> 
> There are a variety of papers that have tried to define the concept of
a
> 'session" in a network that is connectionless at the network layer.
I'm
> not sure what the orgiginal document is, although I am sure that it
vastly
> predates RFC 1144, which is the oldest RFC that seems to use the terms
> "shared state" and "fate sharing". But bottom line, while the internet
> layer has no concept of what we now call a "virtual circuit" or
"virtual
> channel", it has been long recognized that the applications and the
> transports in question have to have some degree of shared state to
enable
> them to function, and that in the event that something goes completely
> south there is a necessity for "fate sharing" - all systems retaining
the
> shared state have to at some point decide that it is for nought and
delete
> it.

One of the things we have been interested in is when the session layer's
state is persistent and when multiple transports (across different
protocol families) can be used, perhaps simultaneously.  More
specifically, one can imagine a "socket" type of abstraction that is
neither protocol family dependent and whose "socket buffer" contents are
retained across (e.g.) reboots and long-term to moderate-term
interruptions.  In a world in which cell phones are arguably going to be
the most numerous hosts on the Internet (when they are connected to the
Internet, that is), the heterogeneity and persistence become I think
more compelling than they have been in the past.

Thinking along these lines brings up the question as to whether the app
interface to a would-be session layer looks more VC-like or more
message/packet-like.  I think there are arguments for both.

When beginning to undertake a high-level networking architecture
discussion it seems appropriate to consider what you want 'your network'
to ultimately do.  Several folks on this list have begun to suggest
this.  I think that is an interesting conversation by itself, before you
get into layering (primarily an implementation techique, imho).

> 
> 
> Before we get to what is "session" we should probably review the
degrees
> of shared state. It seems there are several:
> 
> 
> First there is the shared state associated with the 3 phases of
> communications:
> 
> Enrollment phase: the operations necessary to create the minimal
shared
> state necessary to allow an instance of communications to be created.
This
> is all that messy initial stuff we like to ignore like making sure
that
> both systems have operating instances of the same protocol machine,
> assigning addresses, and making them available to protocol machines,
etc.
> All the initial stuff that needs to be in place. It is information
held in
> common and so strictly speaking shared state.

Even here I would ask to what degree the state is persistent.
Traditionally the Internet version of this is not very.. but there may
be new requirements now and a different $/megabyte storage tradeoff.

> 
> Establishment Phase: (I prefer to call it Allocation) the operations
> necessary to allocate an instance of communication creating sufficient
> shared state to support the mechanisms of the data transfer phase.
This is
> generally what we think of as creating shared state.
> 
> And the Data Transfer Phase: On-going operations during data transfer
to
> maintain the shared state created in the Allocation phase.

If you believe in the "move your transport endpoint to a new place"
approaches, there might be another.

> 
> Allocation seems to have 3 forms/degrees of shared state:
> minimal: corresponding to a pure connectionless, such as UDP'

connectionless != never reliable

> moderate: corresponding to flows with only mechanisms involving the
> Transfer PDU and only need a 2-way handshake synchronization
procedure,
> strong: corresponding to flows supporting feedback mechanisms that
require
> a 3-way handshake synch mechanism.

I'm not clear why 2 vs 3 way is fundamental, except perhaps as to
whether your association abstraction is bi-directional.

...
> 
> 
> 
> This would seem to roll a lot of things into a session. Let me defer
> commenting on this for now. But do let me say, I would prefer a
definition
> that was more abstract and less in terms of specific things.

yes

> Assuming that
> "session" is something above "transport layer" I am uncomfortable with
it
> including information about the internal workings of "other layers."
Each
> layer should have its own addressing structure, so saying the Session
> Layer has addresses is a bit redundant.

I wonder how fundamental even this is.  For example, if you are on your
own non-IP Ethernet LAN, we can certainly imagine two processes
exchanging data without a formalized transport protocol.  Not that I
object, per se, but in our experience just what is "transport" v not a
transport protocol is sometimes not so straightforward.

> I would suggest that we start out with a rational definition of the
> various layers. I include a questioned layer, which I think Tony is
> alluding to, and the ISO and XNS Session models, which have some
history.
> I suspect that we will have various comments on these architecturally,
and
> when we get this part of the question sorted out, we will have a
better
> notion of what further we might want to say.

I would suggest that comes just after figuring out what your really want
the network to do.

(that said, I'll comment on the layers anyhow :o).
> 
> 
> physical layer:
> The physical layer is the lowest communication layer
> consisting of the
> physical medium of communication and the means of signaling over
> it. It is responsible for defining the physical means of sending data,
> interfacing between network media and devices, and defining the
media's
> optical, electrical and mechanical characteristics.

(and acoustic, if you've been hanging out with people building
underwater acoustic networks like I have)

> Examples of this
...

> link layer:
...
> 
> 
> It may be a nit, but I would put the encoding of bits into signals as
part
> of the physical layer.

Yes, agreed.. in fact the 'modulation sub-layer' if you are willing to
divide up the physical layer... or media-dependent phys layer if you
like IEEE-speak.

> The purpose of the Data Link Layer is to manage the
> access to the physical medium, and provide error and flow control
tailored
> to the characteristics of the media. The data link layer provides
> sufficient error control to make error control at higher layers, i.e.
> Transport, cost effective.

Hmm.  That's sort of subjective, and (unfortunately) not generally true.
For various wireless systems it just might not be possible to provide
that.

> Also the Link Layer has less scope than the
> higher layers so in some sense it is often more cost-effective to
recover
> from errors in the smaller scope rather than propagating them to the
> greater scope of a higher layer and recovering from them there. In
some
> sense, a data link layer is "end-to-end" it is just that the ends are
> closer together.

Or maybe end-to-end(s), given shared multiaccess networks which would be
the focus of the next point:

> 
> I would also contend that this error and flow control function (LLC)
is
> distinct from the managing the medium function (MAC) and depending on
the
> nature of the medium a data link layer may have one or the other or
both.

Sure.  Well-covered by IEEE I think.  Even MAC can be further divided
into the stuff to manage access to the channel that's common across
modulation/coding schemes and those that are dependent.

> A point to point wire might only have the LLC aspect, while a LAN
> supporting multiple endpoints might have the MAC but sufficiently
reliable
> to require only minimal LLC or none. To media that require both.
> 
> 
> Network layer:
> The communication layer that builds networks out of link layer
> relationships and enables systems to communicate information between
> systems that are not directly connected at the link layer.

Wouldn't a bridged L2 network meet this criteria?  I guess you answer
that next...

> The network
> layer contains at least two major sublayers, and these may be
implemented
> recursively.
> 
> Intranet Layer:
> The Intranet layer is the lower sublayer of the network layer. It
connects
> systems that are under common administration, are intended to be
connected
> in a simple manner, and generally applies no administrative policy
within
> the network. Examples of this include X.
> 25, Frame Relay, ATM, MPLS, IEEE 802.1 Transparent Bridging, IEEE
> 802.1/802.5 Source-Route Bridging, and IEEE 802.11 wireless
networking.

Ok, but certainly there can be administrative policy even among bridges
or within 802.11 ESS's.

> 
> Internet Layer:
> The Internet layer is the upper sublayer of the network layer. It may
be
> used to connect systems under common administration and implementing
> common policy, but is also commonly used to connect systems under
> different administration or with differing administrative policy.
Internet
> nodes include the internet layer in hosts or in routers, and each
support
> at least one address by which they are reachable by their
administration.
> In the Internet, IPv4 and IPv6 are examples of the Internet layer.
> 
> These 3 are an interesting characterization. And very much reflects
what
...
> 
> 
> 
> <should we describe IPsec as a layer? What is it? As I am about to
> describe transport, it is a sublayer of the transport layer, although
IPv6
> incorporates it and other end-system to end-system capabilities like
> fragmentation and reassembly into IPv6. Are these functions of a
session
> management layer? Is the session management layer in fact the lowest
end-
> 2-end communications layer?>
> 
> 
> 
> No, IPSEC is not a separate layer, but an add-on. It seems that its
being
> a separate protocol is more an artifact of history than the way it
really
> wants to be done.

I think maybe you don't try to describe it :), at least for now.

> 
> 
> Transport layer:
> The transport layer is the lowest layer that runs end to end.

So, eh, is "split-TCP" a transport layer, or no?  Also, it seems to me
that IP/network layer is 'end to end' in which end ends are whatever
have network layer addresses.

> It may be
> viewed as the end-to-end counterpart to the link layer, enabling
> applications running in end systems to communicate effectively across
the
> network connecting them. "Effective communication" are application
> concepts; many applications call for reliable sequential delivery of
data
> within a transaction, and a subset can handle transactions in
arbitrary
> order. TCP and SCTP are examples of protocols which run at the
Transport
> layer; there are other examples. UDP is not an example of a transport,
> although it may be considered an example of the multiplexing sublayer
of
> the transport, as the methods used to make communication effective are
> implemented in the application.
> 
> 
> 
> I pretty much agree, but I would consider UDP part of this layer. The
> question here is what is the layer, not how the protocols work.
> Applications request service with certain characteristics.

And presumably layers can signal to layers above about what they can do,
possibly as a time-varying function (e.g. 802.11b can change data rates
on you).

> The layer can
> use any set of mechanisms it likes to provide that service. If the
layer
> below it is very reliable, then it may chose to use UDP for even a
request
> wanting a reliable transfer. So UDP is just a degenerate case and it
does
> carry necessary identfiiers, i.e. ports.
> 
> 
> 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.
> 
> Application Layer:
> In the Internet, the application generally includes the ISO concept of
the
> presentation layer, which deals with encoding and deciding data. This
is
> the communication layer or program that directly serves
> the user, whether directly or remotely.

In a world of network coding or erasure coding wherein you may wish to
select the coding based on path properties (or properties of multiple
paths), I wonder if the presentation layer belongs where it once does
(or maybe it is in >1 place).  A related question goes to fragmentation
types of functions which I am now convinced may be required for at least
two orthogonal purposes:  1. MTU adaptation-- what IP does not, and 2.
efficient utilization of network capacity (e.g. across multiple paths
simultaneously).
> 
> By 1983, OSI had determined that the Session and Presentation Layers
...
> 
> What OSI did find was that applications required a common
establishment
> mechanism. All applications used the same application connection
> establishment mechanism, called ACSE. This is needed to carry the
> application naming information and probably initial security
parameters.
> If you don't have it then someone needs to understand the format of
the
> first message of every application protocol. This also allows one to
avoid
> the well-known socket stop-gap that the ARPANet had done to get ready
for
> the ICCC 72 demo. Its okay when you only have 3 applications but
doesn't
> really scale.
> 
> ACSE corresponds fairly closely to what is described as Session in
other
> schemes, such as XNS. (An aside: OSI saw application made of building
> blocks called ASEs that were essentially modules of a protocol. ACSE
was
> an ASE that every application protocol included to create the
application
> connection. (There was also a Unit-Data version of ACSE as well.)
Other
> ASEs might be defined for common functions like one or two phase
commit,
> or ASEs specific to the application. These were bound by a "control
> function" that maintained coordination and sequencing of the ASEs
making
> up an application protocol. It probably sounds more complicated than
it
> was. OSI basically saw application protocols as being constructed of
> several modules.) Eventually, ACSE was modified to allow completely
> general nesting of application protocols.

Is it the case that this approach had all the modules as part of the
'network' achitecture, whereas most of the time now we just put them in
programming libraries so we don't have to talk about them as part of the
network?
> 
> If OSI had been left to its own devices, ACSE would probably have
ended up
> as the Session Layer. But with ITU usurping Session, this seemed to be
the
> easiest way around it. It wasn't really. If you look at the
"functional
> units" that were defined in the Session Layer, they are really just
simple
> ASEs. Other problems arise with having these functions in the Session
> Layer when more complex applications are attempted but we won't go
into
> that here.

Do you have a readable reference on this?

> 
> Also, if one goes back to our early discussions of "Session" in the
early
> days, the term reflects a narrow view we had of what computers were
all
> about in the 1970s. Had we pursued that I think it would have taken us
> toward something more like Netware, which while one useful application
> environment would be too narrow for the variety of things that need to
be
> supported. So it turns out that ACSE is probably what you want for the
> general case and include specific ASEs if you need something more
narrow.
> 
> So that is how Fred's characterization stacks up against what OSI was
> thinking. Actually all of these are fairly traditional descriptions.
And,
> while not entirely "wrong," I think this view isn't quite right either
and
> a much simpler scheme is possible.

Yeah, sort of sounds like it, although where the 'system boundary' is
here (see last comment) might be different [?]

Cheers,
- Kevin

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

---

From: "Fleischman, Eric" <[email-masked]>
Date: Wed, 22 Mar 2006 10:03:17 -0800

This observation has been historically useful for designing mechanisms
to convey applications devised for non-IP protocol stacks over IP: e.g.,
RFC 1001, RFC 1002, RFC 1006, the IBM Multi-Protocol Transport
Networking (MPTN) protocol suite, etc.