[e2e] Port numbers in the network layer?

[Detlef Bosau]

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 <detlef.bosau at web.de 
>> <mailto:detlef.bosau at web.de>> wrote:
>>
>>     Am 26.04.2013 03 <tel:26.04.2013%2003>:00, schrieb
>>     l.wood at surrey.ac.uk <mailto: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/0348690c/attachment.html