<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>Re: [e2e] Port numbers in the network
layer?</title></head><body>
<div>X.25 does not provide the same reliability that TCP or TP4
does.</div>
<div><br></div>
<div>As Jon described, it is important to note that X.25 is an
*interface* protocol in the ITU sense of interface.&nbsp; It only
specifies behavior between the DTE (host) and DCE (first router).&nbsp;
For some implementations (e.g. the French Transpac) this meant only
that an ack meant that first DCE (router) got your packet; in Datapac
(the Canadian offereing) an ack meant that the last DCE (router) got
your packet; and in Telenet (the US offering), an ack meant that the
remote host had acked the packet.&nbsp; However, even with the Telenet
interpretation, a Reset would cause the loss of packets that were not
recovered.</div>
<div><br></div>
<div>At 9:27 PM +0200 4/26/13, Detlef Bosau wrote:</div>
<blockquote type="cite" cite>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>
<blockquote type="cite" cite>Re: [e2e] Port numbers in the network
layer?</blockquote>
<blockquote type="cite" cite>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.</blockquote>
<blockquote type="cite" cite><br></blockquote>
<blockquote type="cite" cite>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.&nbsp; This and the degree to
which some believed the claims of reliability lead to OSI Transport
Classes 0, 1 and 2.&nbsp; (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)).</blockquote>
<blockquote type="cite" cite><br></blockquote>
<blockquote type="cite" cite>The supporters instead supported an
*Application Protocol* called RTSE (Jon, do you remember the X.
number?).&nbsp; The supporter claimed that this was a checkpoint
recovery-like service for something like file transfer.&nbsp; This
strategy met the constraints (or at least they thought so) to let them
pursue their economic desires.</blockquote>
<blockquote type="cite" cite><br></blockquote>
<blockquote type="cite" cite>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.</blockquote>
<blockquote type="cite" cite><br></blockquote>
<blockquote type="cite" cite>Take care,</blockquote>
<blockquote type="cite" cite>John</blockquote>
<blockquote type="cite" cite><br></blockquote>
<blockquote type="cite" cite>At 9:33 AM -0500 4/26/13, Jon Crowcroft
wrote:<br>
<blockquote type="cite" 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 &quot;virtual&quot; 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)<br>
</blockquote>
<blockquote type="cite" cite><br></blockquote>
<blockquote type="cite" 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...<br>
</blockquote>
<blockquote type="cite" cite><br></blockquote>
<blockquote type="cite" 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)...<br>
</blockquote>
<blockquote type="cite" cite><br></blockquote>
<blockquote type="cite" cite>note the model of &quot;end2end&quot;
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 &quot;socket on the wall&quot;
not to the ear of the human (i.e. a phone with a broken
mike&amp;speaker, or a host that has errorered memory )</blockquote>
<blockquote type="cite" cite><br></blockquote>
<blockquote type="cite" cite><br></blockquote>
<blockquote type="cite" 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<br>
</blockquote>
<blockquote type="cite" cite><br></blockquote>
<blockquote type="cite" 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:)<br>
</blockquote>
<blockquote type="cite" cite><br></blockquote>
<blockquote type="cite" cite>hence the semantics of ends are in the
eye of the beholder imho<br>
</blockquote>
<blockquote type="cite" cite><br></blockquote>
<blockquote type="cite" cite><br></blockquote>
<blockquote type="cite" cite><br>
<br>
</blockquote>
<blockquote type="cite" cite>On Fri, Apr 26, 2013 at 5:01 AM, Detlef
Bosau &lt;<a
href="mailto:detlef.bosau@web.de">detlef.bosau@web.de</a>&gt;
wrote:<br>
<blockquote>Am <a href="tel:26.04.2013%2003">26.04.2013 03</a>:00,
schrieb <a
href="mailto:l.wood@surrey.ac.uk">l.wood@surrey.ac.uk</a>:<br>
</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?<br>
</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.<br>
</blockquote>
<blockquote><br>
<blockquote><br>
But you can always &nbsp;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 &quot;packet
switching networks&quot; 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.<br>
</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 &quot;holy cow&quot;. Layers should
assist network design. And not the other way round.</blockquote>
</blockquote>
</blockquote>
</blockquote>
<div><br></div>
</body>
</html>