[e2e] Port numbers in the network layer?

[John Day]

X.25 does not provide the same reliability that TCP or TP4 does.

As Jon described, it is important to note that X.25 is an *interface* 
protocol in the ITU sense of interface.  It only specifies behavior 
between the DTE (host) and DCE (first router).  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.  However, even with the Telenet 
interpretation, a Reset would cause the loss of packets that were not 
recovered.

At 9:27 PM +0200 4/26/13, Detlef Bosau wrote:
>So, x.25 lacks the required e-2-e reliability. Correct?
>
>
>
>Am 26.04.2013 19:29, schrieb John Day:
>
>>Re: [e2e] Port numbers in the network layer?
>>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.
>>
>>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)).
>>
>>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.
>>
>>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.
>>
>>Take care,
>>John
>>
>>At 9:33 AM -0500 4/26/13, Jon Crowcroft wrote:
>>
>>>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)
>>>
>>>
>>>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...
>>>
>>>
>>>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)...
>>>
>>>
>>>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 )
>>>
>>>
>>>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
>>>
>>>
>>>(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:)
>>>
>>>
>>>hence the semantics of ends are in the eye of the beholder imho
>>>
>>>
>>>
>>>
>>>
>>>On Fri, Apr 26, 2013 at 5:01 AM, Detlef Bosau 
>>><<mailto:detlef.bosau at web.de>detlef.bosau at web.de> wrote:
>>>
>>>Am <tel:26.04.2013%2003>26.04.2013 03:00, schrieb 
>>><mailto:l.wood at surrey.ac.uk>l.wood at surrey.ac.uk:
>>>
>>>
>>>On the other hand: Do you know a current technology which is actually
>>>being used that does not use Ethertypes?
>>>
>>>
>>>CANbus, SpaceWire, CCSDS, RapidIO, (A)X.25...
>>>
>>>
>>>Oh, yes :-)
>>>
>>>I'm sorry about that...
>>>
>>>Additional question: Can you tell me which car uses TCP over 
>>>CANbus, e.g. to control his lamps? ;-)
>>>
>>>
>>>But you made an important point: My view on this matter is too simplistic.
>>>
>>>
>>>
>>>But you can always  layer (Cisco) HDLC or HDLC/ Frame Relay across any
>>>of these to get an Ethertype. Or lobby SpaceWire to put a value in
>>>their single-byte not-an-Ethertype field.
>>>
>>>
>>>At least we have do agree on talking about "packet switching 
>>>networks" in a quite narrow sense here, when it comes to 
>>>Ethertypes.
>>>
>>>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.
>>>
>>>However, this is in fact a discussion of implementation issues.
>>>
>>>
>>>
>>>(The CCSDS community finds the thought of layering HDLC over CCSDS
>>>especially abhorrent, because it cuts down their custom engineering,
>>>and any layering or modularity is considered to be inefficiency.)
>>>
>>>
>>>At least, it is not a "holy cow". Layers should assist network 
>>>design. And not the other way round.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20130426/7b5dc5fb/attachment-0001.html