<!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>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.&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)).</div>
<div><br></div>
<div>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.</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" 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)</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...</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)...</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>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" 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:)</blockquote>
<blockquote type="cite" cite><br></blockquote>
<blockquote type="cite" cite>hence the semantics of ends are in the
eye of the beholder imho</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>:</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 &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.</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>
<div><br></div>
</body>
</html>