<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">So, x.25 lacks the required e-2-e
reliability. Correct?<br>
<br>
<br>
<br>
Am 26.04.2013 19:29, schrieb John Day:<br>
</div>
<blockquote cite="mid:a06240818cda06005fccd@%5B10.0.1.3%5D"
type="cite">
<meta http-equiv="Context-Type" content="text/html;
charset=us-ascii">
<title>Re: [e2e] Port numbers in the network
layer?</title>
<div>As Jon indicated the reliability semantics of X.25 were a bit
complicated to some degree by perceived constraints on the
economic
desires of its supporters.</div>
<div><br>
</div>
<div>Its supporters claimed that it was reliable and therefore a
Transport Protocol was unnecessary. However, X.25 would under
certain
conditions do a Reset which would cause the loss of data, which
was
not recovered. This and the degree to which some believed the
claims of reliability lead to OSI Transport Classes 0, 1 and 2.
(Class 0, was for Study Group VIII and had the minimal
placeholder
header;' Class 1 was for Study Group VII, that believed users
should
pay for each connection and so did not support multiplexing; and
Class
2, for users of X.25, who didn't want to be charged for every
connection and believed that X.25 was sufficiently reliable that
simpler error recovery could be used as opposed to the full
capabilities of a TP4 or TCP (this latter view was in fact
incorrect)).</div>
<div><br>
</div>
<div>The supporters instead supported an *Application Protocol*
called
RTSE (Jon, do you remember the X. number?). The supporter
claimed that this was a checkpoint recovery-like service for
something
like file transfer. This strategy met the constraints (or at
least they thought so) to let them pursue their economic
desires.</div>
<div><br>
</div>
<div>However, if one looked at the specifics of the protocol (time
constants, etc.), it was clear that this was a Transport
Protocol in
the Application Layer.</div>
<div><br>
</div>
<div>Take care,</div>
<div>John</div>
<div><br>
</div>
<div>At 9:33 AM -0500 4/26/13, Jon Crowcroft wrote:</div>
<blockquote type="cite">x.25 provides a network service which is
modelled as a non multiplexed, in-order loss-less, flow
controlled
packet delivery which is known as a "virtual" circuit - in
fact, from the end host perspective, that looks very much like
the
service that a stream socket gives except that you need a
multiplexing
layer if you want multiple host associations...(i.e. iso
tp0)</blockquote>
<blockquote type="cite"><br>
</blockquote>
<blockquote type="cite">inside the network, you do NOT have to
preserve e2e packet ordering or reliability (i.e. you don't HAVE
to do
hop by hop ordering, loss recovery or flow control, although
layer 2
flow control can help with the latter micro-protocol part of the
X.25
service) - some implemenations of X.25 actually did a datagram
network
inside the network, and did end-to-end protocol work (strictly.
NIC-to-NIC) to fix up missing packets and ordering etc...</blockquote>
<blockquote type="cite"><br>
</blockquote>
<blockquote type="cite">most x.25 switches, tho, did do op-by-hop
work, which made them cumbersome, slow, expensive, and also,
remember
back in the 1970s, people wrote a lot of code in very low level
languages (macro 11, various uglier assembers...later on perhaps
C)
which made software incredibly hard to get right so having a lot
of
complex protocol code in a switch in the net was a v. bad idea
then
(nowadays you might get away with it, hence SDN/Openflow and the
proliferation of middle boxen- not all there for bad
reasons)...</blockquote>
<blockquote type="cite"><br>
</blockquote>
<blockquote type="cite">note the model of "end2end"
being NIC-to-NIC (rather than host to host) means that you don't
get
real e2e reliability out of X.25 since the semantics are (as per
telephone semantics) delivery to the "socket on the wall"
not to the ear of the human (i.e. a phone with a broken
mike&speaker, or a host that has errorered memory )</blockquote>
<blockquote type="cite"><br>
</blockquote>
<blockquote type="cite">note this is not especialyl bad since TCP
(when used by an app) delivers data to the socket queue - if the
app
fails to write it to disk (or render to screen) correctly, TCP
can't
know</blockquote>
<blockquote type="cite"><br>
</blockquote>
<blockquote type="cite">(of course, the person holding the phone
handset might be deaf, dumb or not speak the same language as
the
speaker at the other end:)</blockquote>
<blockquote type="cite"><br>
</blockquote>
<blockquote type="cite">hence the semantics of ends are in the
eye of the beholder imho</blockquote>
<blockquote type="cite"><br>
</blockquote>
<blockquote type="cite"><br>
</blockquote>
<blockquote type="cite"><br>
<br>
</blockquote>
<blockquote type="cite">On Fri, Apr 26, 2013 at 5:01 AM, Detlef
Bosau <<a moz-do-not-send="true"
href="mailto:detlef.bosau@web.de">detlef.bosau@web.de</a>>
wrote:<br>
<blockquote>Am <a moz-do-not-send="true"
href="tel:26.04.2013%2003">26.04.2013 03</a>:00,
schrieb <a moz-do-not-send="true"
href="mailto:l.wood@surrey.ac.uk">l.wood@surrey.ac.uk</a>:</blockquote>
<blockquote><br>
<blockquote>
<blockquote>On the other hand: Do you know a current
technology which
is actually<br>
being used that does not use Ethertypes?</blockquote>
<blockquote><br>
</blockquote>
</blockquote>
<blockquote>CANbus, SpaceWire, CCSDS, RapidIO, (A)X.25...<br>
</blockquote>
</blockquote>
<blockquote><br>
</blockquote>
<blockquote>Oh, yes :-)<br>
<br>
I'm sorry about that...<br>
<br>
Additional question: Can you tell me which car uses TCP over
CANbus,
e.g. to control his lamps? ;-)<br>
<br>
<br>
But you made an important point: My view on this matter is too
simplistic.</blockquote>
<blockquote><br>
<blockquote><br>
But you can always layer (Cisco) HDLC or HDLC/ Frame Relay
across any<br>
of these to get an Ethertype. Or lobby SpaceWire to put a
value in<br>
their single-byte not-an-Ethertype field.<br>
</blockquote>
</blockquote>
<blockquote><br>
</blockquote>
<blockquote>At least we have do agree on talking about "packet
switching networks" in a quite narrow sense here, when it
comes
to Ethertypes.<br>
<br>
E.g. X.25 to my understanding is circuit switched. The packet
switching view is mounted upon the top ;-) The same holds true
for
Frame Relay in a sense, however in FR the whole packets are
switched
IIRC and not subdivided into smaller pieces.<br>
<br>
However, this is in fact a discussion of implementation
issues.</blockquote>
<blockquote><br>
<blockquote><br>
(The CCSDS community finds the thought of layering HDLC over
CCSDS<br>
especially abhorrent, because it cuts down their custom
engineering,<br>
and any layering or modularity is considered to be
inefficiency.)<br>
</blockquote>
</blockquote>
<blockquote><br>
</blockquote>
<blockquote>At least, it is not a "holy cow". Layers should
assist network design. And not the other way round.</blockquote>
</blockquote>
<div><br>
</div>
</blockquote>
<br>
</body>
</html>