Subject: Re: [[email-masked]: [arch-d] Defining terms]

From: John Day <[email-masked]>
Date: Thu, 16 Mar 2006 07:46:19 -0500

>----- Forwarded message from Fred Baker <[email-masked]> -----
>
>   Date: Mon, 6 Mar 2006 15:02:24 -0800
>   From: Fred Baker <[email-masked]>
>   Subject: [arch-d] Defining terms
>   To: [email-masked]
>   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.
>

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.

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.

Allocation seems to have 3 forms/degrees of shared state:
minimal:  corresponding to a pure connectionless, such as UDP'
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 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.
>

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.  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 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.
>
>
>   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. Examples 
>   of this include a fiber optic link, in which the means of signaling 
>   is transmission of photons of a known frequency in a known pattern, 
>   and the reception of those photons, or a radio link, in which the 
>   "medium" is electromagnetic space, and the signaling is performed by 
>   electromagnetic effects conveyed in that space.
>

Right. All that messy physical stuff.

>   link layer:
>   The link layer defines the procedures for operating physical 
>   communication links. It encodes network layer data as physical layer 
>   signals, and recovers and decodes these signals at the receiving end. 
>   It also manages rate of flow and errors on the link, which at minimum 
>   means reporting statistics, and may include FEC, retransmission, or 
>   other techniques. Examples of this include HDLC, Ethernet, and so on.
>

It may be a nit, but I would put the encoding of bits into signals as 
part of the physical layer.  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.  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.

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.  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. 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.
>
>   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 is described in the OSI Internal Organization of the Network 
Layer.  It might be worthwhile looking at it.  While the document is 
in normal OSI double speak, it does contain a description of some 
interesting cases.  It divided the Network Layer into 3 sub-layers:

Subnetwork Access: things like X.25 etc.
Subnetwork Dependent Convergence: Any and all functions necessary to 
support the Subnetwork Independent Convergence sublayer.
Subnetwork Independent Convergence corresponds to what you have 
called the Internet Layer.

But it was trying to address the same kind of issues you describe 
here although somewhat from the point of view of the late 80s.

>
>   <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.

>   Transport layer:
>   The transport layer is the lowest layer that runs end to end. 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.  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.
>

By 1983, OSI had determined that the Session and Presentation Layers 
didn't exist.  Well, that isn't entirely true.  The ITU faction held 
on to the idea that the Session Layer existed. But that was because 
they had hi-jacked it for Videotex.  In 83, OSI adjusted the protocol 
specs for Session and Presentation and ACSE (see below) so that the 
insightful implementor could implement them as a single state 
machine.  (The feeling was the politics prevented from dropping 2 
layers from the model and as I said ITU was still hanging on to 
Videotex at that point.) But most people saw these one layer.

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.

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.

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.

Take care,
John Day

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

---

From: John Leslie <[email-masked]>
Date: Fri, 17 Mar 2006 19:15:32 -0500

John Day <[email-masked]> wrote:
> part of the physical layer. 

   I suggest we recognize that things like "encoding of bits into signals"
is a function of the interface between link layer and physical layer. I
would agree with Spencer Dawkins that link layer deals in bits; so I
agree with John Day that "encoding" into something else isn't "part of"
the link layer.

   But we'd do well to allow ourselves to think that physical layer deals
in "something else than bits" (typically electrons or photons); thus
recognizing some interface which deals in electrons/photons on one side
and bits on the other. Fortunately, we need say little or nothing about
such an interface. ;^)

> 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.

   I agree; but we should be careful not to read too much into these
words. "Manage the access to" doesn't mean that every detail of the
connectors is a link-layer function: those connectors are mostly a
part of the physical layer. "Manage the access to" should mean to
adjust timing, etc. to match the limitations of the physical medium.

   This makes "flow control" an obvious essential: don't introduce
signals that the physical medium can't carry. "Error control" is not
as clear, and I worry folks may expect too much of it. Link layer
should introduce enough redundancy to recognize transmission errors,
and _may_ include formal mechanisms to correct such errors. That's
as far as we should go, IMHO.

   (Clearly, many implementations of link layer will go quite a bit
farther: I merely mean we shouldn't stretch our definition of link
layer to cover more than the minimum our architecture expects.)

> The data link layer provides sufficient error control to make error
> control at higher layers, i.e. Transport, cost effective.

   This statement actually worries me. There's nothing actually _wrong_
with it, except a suggestion that higher layers might "negotiate" what
constitutes "sufficient error control".

   (Again, many implementations of link layer in combination with a
higher layer _will_ negotiate exactly that: I mean we shouldn't stretch
our definition of link layer to cover more than the minimum our
architecture expects. A model is still useful even though an actual
implementation applies tweaks outside of the model.)

   John Day _is_ quite right to point out that higher layers _do_
depend upon some amount of error control at the link layer. We cannot
(IMHO) avoid that; but we should be very careful about writing it
into our architecture.

>  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.

   This is where it gets messy!

   Rather than go into details, let me try to label such considerations
"engineering" and distinguish them from "architecture". From an
engineering standpoint, recovering from noise-related errors is usually
far better if you can reduce the hysteresis. But from an architectural
standpoint, we need to recognize that we're designing for unknown uses.
The engineering tweak which makes the use we're thinking of right now
run twice as fast may well cause some future use to run slower, or even
in extreme cases fail to run.

   This brings us back to the smart-network / dumb-network tradeoffs.
I'm old-fashioned enough to generally prefer the dumb-network. YMMV.
Clearly, repairing all errors with TCP retransmissions is no longer
acceptable: but pushing error-correction expectations down to the link
layer is _not_ the only trick available. We should have an architecture
which is agnostic on that question.

> In some sense, a data link layer is "end-to-end" it is just that the
> ends are closer together.

   A link layer _can_ be designed "end-to-end". Some will be. But I
believe we should be dwelling on distinguishing features of layers:
not on similarities between layers.

> is distinct from the managing the medium function (MAC)

   Error control certainly can be distinct: we might want to discuss
the benefits and costs of considering it separately. Flow control, OTOH,
is essential to managing the medium.

> and depending on the nature of the medium a data link layer may have
> one or the other or both.

   I do not believe managing the medium can be avoided.

>  A point to point wire might only have the LLC aspect,

   I disagree: there's always a timing aspect.

> sufficiently reliable to require only minimal LLC or none.

   There are cases which _seem_ this way: that you get something
"reliable enough" or nothing at all. This, IMHO, is a degenerate case
of error control which discards all information except successful
transmission. Yes, it happens; yes, we deal with it; but IMHO it is
not an absence of error control.

====

   I'll skip the other layers: I think this email is long enough...

--
John Leslie <[email-masked]>

---

From: Fred Baker <[email-masked]>
Date: Fri, 17 Mar 2006 16:34:02 -0800

as we have discussed privately, I think we need to agree that at the  
boundary between the physical and link layer the encoding is binary,  
and leave off pontificating about the physical layer. There is a lot  
to understand there.

On Mar 17, 2006, at 4:15 PM, John Leslie wrote:

> is a function of the interface between link layer and physical layer.

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 17 Mar 2006 19:49:55 -0800

Hi -

> From: "John Leslie" <[email-masked]>
> To: "John Day" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Friday, March 17, 2006 4:15 PM
> Subject: Re: [arch-d] Defining terms
...
> which is agnostic on that question.
...

"Agnostic" might not be quite the right word.  I think we need an architecture that
recognizes that

    (1) that some functions may, for good engineering reasons, be performed
         at multiple layers;

    (2) that the quality of service requested for a particular information flow may
         influence what a particular protocol does with that data, including the
         quality of service it requests from lower layers, as well as what it negotiates
         with its peers;

   (3) that if a lower layer cannot guarantee the requested quality of service, then
        the upper layer protocol needs the flexibility to either choose some other
        means of delivery, provide the service itself, or signal the inability to deliver
        the requested service quality up to its invoker.

If that's what's meant by agnostic, cool.  If not, we disagree.  :-)

Randy

---

From: Jari Arkko <[email-masked]>
Date: Sat, 18 Mar 2006 15:51:37 +0200

>"engineering" and distinguish them from "architecture". 
>
I'm not sure what we should label engineering and what architecture,
but I'll just note that the issue of division of work between link and
higher
layers appears in many functions and not just in error correction. For
instance, the same arguments can be made about mobility mechanisms.

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Sat, 18 Mar 2006 16:22:33 +0200

That it is cost-effective for local (perhaps L2) mechanisms to
handle local movements, so that the global (perhaps L3) mechanisms
do not handle to deal with too many events.

John Day wrote:

> What argument would that be?
>
> At 15:51 +0200 2006/03/18, Jari Arkko wrote:
>

---

From: <[email-masked]>
Date: Mon, 20 Mar 2006 10:08:26 +0200

>        the requested service quality up to its invoker.

And if the upper layer can feasibly provide the service itself, why
should the lower layer be burdened with the capability to guarantee the
requested quality of service?

	Jarno Rajahalme

---

From: Fred Baker <[email-masked]>
Date: Mon, 20 Mar 2006 07:24:59 -0600

This is a trade-off, and not one that should be made lightly.

The thing I think we need to be careful with is knee-jerk application  
of the end to end principle. Saltzer and Reed's description was that  
"things should be done in the right place, once, and as simply as  
possible"; Isenberg's extension in "Dawn of the Stupid Network" is  
"everything should be done at the edge". 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. Also, the logical outcome of that line of  
reasoning discards TCP in favor of UDP with application layer flow  
control and retransmission. So while I will agree with Isenberg on  
most of the cases he will bring up to discuss, I can't agree with him  
categorically, because the reasoning is faulty.

If we are taking the model that things should be done in the right  
place and once, then 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. If only one upper  
layer protocol needs it, then it probably belongs there.

---

From: John Leslie <[email-masked]>
Date: Mon, 20 Mar 2006 09:30:53 -0500

Randy Presuhn <[email-masked]> wrote:
> "Agnostic" might not be quite the right word.  I think we need an
> architecture that recognizes
> 

   Agreed. However, _architectural_ definition of how the tasks are
divided gets messy pretty fast...

> (2) that the quality of service requested for a particular information
>     flow may influence what a particular protocol does with that data,
>     including the quality of service it requests from lower layers,
>     as well as what it negotiates with its peers;

   Agreed, except that QoS requests remain a largely unsolved problem.

> (3) that if a lower layer cannot guarantee the requested quality of
>     service, then the upper layer protocol needs the flexibility to
>     either choose some other means of delivery, provide the service
>     itself, or signal the inability to deliver the requested service
>     quality up to its invoker.

   I fully agree.

---

From: John Day <[email-masked]>
Date: Sat, 18 Mar 2006 09:57:31 -0500

>and bits on the other. Fortunately, we need say little or nothing about

Also in the past, it has proved useful to distinguish the Physical 
Layer from the Physical Media.

But I agree there is not much need to say much about this interface. ;-)

>as far as we should go, IMHO.

Agreed, as I elaborate further below.  One must keep in mind that it 
is cheaper to recover errors in the lesser scope of the link layer 
than in the broader scope higher up.  But one doesn't want to get too 
intent on it.

>constitutes "sufficient error control".

Not the intent.  The higher layers put requirements on the lower 
layers in some general way.  When I teach this, I describe link layer 
error control as dealing with keeping media-related errors within the 
range expected by the network and transport layers.  The errors 
recovered by the transport layer are those that occur as a 
consequence of relaying in the network layer, i.e. lost and duplicate 
PDUs and single bit errors caused by memory glitches during relaying. 
The job of data link error control is to stay within the tolerances 
transport expects of the network layer.

>(IMHO) avoid that; but we should be very careful about writing it

Glad you agree. ;-)  See above for what I hope was a better characterization.

>in extreme cases fail to run.

One has to have a clear definition of the service provided by the 
data link layer.  Also there is not one data link layer.  The data 
link layer is media-specific.  You can't always make a silk purse 
from a sow's ear.

>which is agnostic on that question.

I am not sure what the smart network/dumb network means anymore. In 
1972, packet switches were pretty dumb.  Today core router does far 
more computation than the biggest CO circuit switch ever did.  The 
other day, I was sort of constructing this model in my head and 
realized that perhaps a more proper analogy was that that the phone 
set corresponded to the dumb terminal and the first CO switch to a 
TIP. ;-)

I prefer a model where there is crisp definition of that a layer 
does, so you know a priori what is in and what is out and not worry 
about whether it is dumb or smart.

>not on similarities between layers.

I don't think we meant end-to-end in the same sense. ;-)  If a data 
link layer is end-to-end in the usual sense it is just a small 
network.

>    I do not believe managing the medium can be avoided.

It would seem to be difficult to do that. ;-)

>    I disagree: there's always a timing aspect.

Not sure I understand this comment.

>not an absence of error control.

I would agree.  I am glad you made this point, it was what I had in mind.

I always prefer degenerate cases, or as I like to say:

Architecture is maximizing the invariances and minimizes the discontinuities.

Take care,
John

---

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

>Because the lower layer has less scope and by doing it at the lower 
>layer it will put less work on the network as a whole, rather than 
>foisting the problem on a wider scope where it is not everyone's 
>problem.
>
>Also as I said earlier a variation of the 90/10 rule applies. If a 
>function like error control in a layer gets Y% of the problem and 
>there is significant cost associated with getting the last X%, where 
>X << Y and X is less than the probability of errors compensated for 
>by the layer above, then let the layer above deal with that last X%.
>
>However, that said, each layer is responsible for managing a set of 
>resources. Providing QoS in general requires affecting the 
>allocation of resources. If the resources to be affected are the 
>responsibility of a particular layer then it has to do it.
>
>Take care,
>John

---

From: John Day <[email-masked]>
Date: Sat, 18 Mar 2006 09:33:14 -0500

>do not handle to deal with too many events.

Couldn't agree more.

John

---

From: John Day <[email-masked]>
Date: Sat, 18 Mar 2006 08:58:15 -0500