[e2e] Port numbers in the network layer?

[John Day]

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/293dac48/attachment-0001.html