[e2e] Port numbers in the network layer?

Detlef Bosau detlef.bosau at web.de
Fri Apr 26 09:22:02 PDT 2013


Am 26.04.2013 16:33, schrieb 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...

Q: Was loss recovery (although being rarely necessary due to very robust 
line- and channel coding) done only hop to hop? Including the 
possibility of a head-of-line blocking for the flow? (If I may ask, but 
to find this in the specification is extremely cumbersome....)

....
>
> 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 )

Interesting point, however the model in TCP is "socket-to-socket". There 
is no means to detect (or even correct) errors between application and 
socket, neither at the sender nor at the receiver. (I well know that the 
residual risk of errors here is /extremely/ small.)
>
> 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

Absolutely. And for this reason, we often find md5 checksums for huge 
files on file servers. So, when I reinstall my ubuntu from CD, I 
ususally dowload the iso and the md5 files and to a md5 check before 
burning the CD ;-)
>
> (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:)

Ok., so the one person speaks English, the other one American? ;-)

But in that very case I would like to ad a remark on speach. (Recovery 
from my COMCAR experience.) In speach / voice over mobile, you don't 
care for a QoS in terms of bit errors or something similar, but 
typically for a MOS, Mean Opinon Score, which is assessed by field tests 
and questionnaires because you are not interested in a bit error free 
stream but the listener should clearly understand the speaker.

>
> hence the semantics of ends are in the eye of the beholder imho
>
>
>

Or in the ear ;-)

Absolutely.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20130426/03cd21e4/attachment.html


More information about the end2end-interest mailing list