[e2e] Port numbers in the network layer?

[Jon Crowcroft]

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> wrote:

> Am 26.04.2013 03:00, schrieb 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/4864f11b/attachment.html