Why don't we talk about segments/objects instaead of layers? Re: Lost Layer?

Am 11.02.2014 15:39, schrieb Joe Touch:
>
>
> On 2/11/2014 1:09 AM, Fred Baker (fred) wrote:
>>
>> On Feb 10, 2014, at 6:31 PM, Joe Touch <[email protected]> wrote:
>>
>>> There are three layers, but it's TCP that's incomplete. I don't at
>>> all understand the difference between a "network layer" and an
>>> "internetwork layer".
>>
>> Well, the deal is that layers can be sub-layered.
>
> If you mean that every layer expects similar things from the layer
> below, I agree (that's RNA). It expects a way to transit a set of
> nodes using a path, and accepts that there will need to be a way to
> map nodes at the upper layer to nodes at the lower layer (e.g.,
> resolution, ala Google, BGP, and ARP, depending on what layer you look
> at).
>
>> Yes, the
>> Internetwork layer is perhaps unfortunately named, in that it doesn't
>> always interconnect networks.
>
> But you can't tell the difference when it isn't.

I think we are talking at cross purposes here.

Basically, each and every link along the path constitutes a "network" by
itself, this no rocket science, this is the definition of a network.

The problem is how a concatenation of networks ("a catenat") is
presented to upper layers and what the properties of the concatenated
networks are. And of course this is not independent from the protocol in
use:
- UDP is unreliable,
- TCP is reliable, hence on a TCP path you may require a recovery layer.
(Which is particularly part of each and every mobile network around this
world and first, I was forbidden to understand this and now I'm
forbidden to admit and to discuss this and this drives me crazy.)

And yes, data corruption is a local problem as it is network congestion
and yes, both problems are to be solved locally.
Sorry for that.

And yes, when recovery cannot be solved on a link, there will be some
kind of escalation strategy to solve this problem from a less local but
more global perspective, however there are more than the two alternatives
- local retransmission and
- global retransmission.

However, to become acceptable for some kind of "part of TCP flow" this
part has to provide a mechanism for reliable transmission
which is best modelled by some kind of delivery time and some kind of
SDU corruption probability. So we have some criteria whether the piece
of network is acceptable as a "part of TCP flow"  - or not.

It doesn't matter whether an architecture with sets up, maintains and
tears down this kind of flows is called a "layer" or "plate with popcorn".
I am not interested in how things are named but which service they provide.

Some evil tongues call this "object oriented thinking".

And we're doing so
- in multimedia architectures,
- in software defined networks,
- in component based middleware, CORBA and the like,
- in programs
- in Delay Tolerant Networks
- in Overlay Networks
however with respect to TCP, mankind sits in caves and thinks in the
layers of 1970 or so.

>
>> But it comes down to this.
>>
>> First, consider that each layer answers a fundamental question.
>
> Each answers exactly the same fundamental question - how do I transit
> hops at my layer using what I think are links at my layer, by using
> what look like hops and links that are really a service provided by
> the next layer down.

Hang on.

A TCP path is a chain of concatenated segments. So, why do we look at
"layers"? Why don't we ask what we expect from the segments?
And of course, each segment will provide a "packet transport service"
with some properties (delivery time, SDU corruption ratio...) presented
to the outside world and when we set up or maintain or tear down a flow,
we have to assess whether the segments are suitable for our needs or
not, what's the problem with this?

And of course, each of these segments will encapsulate a system which
implements some of the well known layers.

I have to apologize for being a bit upset here. But sometimes I get the
impression that many people have only worked with Ethernet so far,
perhaps Fast Ethernet or Gig Ethernet. But whoever worked with mobile
networks or point to point "links" passing an ATM cloud or a Frame Relay
cloud which actually provide mechanisms like "tunnel bridges" should be
familiar with this way of thinking and should have accepted the
"OSI layers" as a neat picture from the text books and learned this
stuff for exams - but I sincerely expect that none of us
took this really seriously, at least not too much ;-)

So start the encapsulation here:
>
>> The
>> physical layer provides the physical interconnect between a system and a
>> neighboring system.
>
> The physical layer is just the base case where the signal receives
> this 'service' from a real, physical entity.
>
> > The Link Layer provides the interpretation of
>> signals on the physical medium connecting neighboring systems.
>
> That translation of format can happen at every layer in a stack of
> layers. It happens when tunnels encrypt/decrypt. It happens when a
> stream of messages are FEC encoded. It happens when we stripe over
> different channels to emulate a mega-channel.
>
> > The
>> network layer connects a system to another system that it is not
>> necessarily directly connected to.
>
> That happens at every layer, because every layer can include
> forwarding. Link layers forward, and transport layers can relay
> (forward) too.
>

and end it here.

IP - Segment - IP.

Period.

Yes, in a sense similar to VJCC and others. But not for the whole
Internet cloud but restricted to a segment where this abstraction makes
sense!

The rest might be called "object oriented networking" and instead of
"routing" we would have something like "dynamic flow construction".

> And SONET provides a stream over frames. Ethernet provides packet
> relay over packet links, as does IP.
>

>From the perspective I tried to explain, it does not matter what SONET
provides. (Or cell relay, or SDH which is slightly different from SONET,
or PDH. Or a point to point net with a laser system. Or a satellite
network. Or, very classic, carrier pidgeons. Of course no robins....)

It must be suitable as a segment in a TCP flow, so it should provide a
packet transport service with acceptable reliability and acceptable
service time, the limits for both of which must be provided by the user.

So, why don't we think in concatenated segments, call it "network
objects" or "network path objects", whatever you like, and why
don't we talk about the properties of these and talk about a much too
coarse "layer model" instead?

Detlef

-- 
------------------------------------------------------------------
Detlef Bosau
Galileistraße 30   
70565 Stuttgart                            Tel.:   +49 711 5208031
                                           mobile: +49 172 6819937
                                           skype:     detlef.bosau
                                           ICQ:          566129673
[email protected]                     http://www.detlef-bosau.de