<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Am 26.04.2013 16:33, schrieb Jon
Crowcroft:<br>
</div>
<blockquote
cite="mid:CAEeTejLsgSsP5nAQ4q-tFOVoDUz8wjtWkOYntySADiN9=8r1pQ@mail.gmail.com"
type="cite">
<meta http-equiv="Context-Type" content="text/html;
charset=ISO-8859-1">
<div dir="ltr">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)
<div>
<br>
</div>
<div>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...</div>
</div>
</blockquote>
<br>
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....)<br>
<br>
....
<blockquote
cite="mid:CAEeTejLsgSsP5nAQ4q-tFOVoDUz8wjtWkOYntySADiN9=8r1pQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><br>
</div>
<div>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 ) <br>
</div>
</div>
</blockquote>
<br>
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 <i>extremely</i>
small.)<br>
<blockquote
cite="mid:CAEeTejLsgSsP5nAQ4q-tFOVoDUz8wjtWkOYntySADiN9=8r1pQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><br>
</div>
<div>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</div>
</div>
</blockquote>
<br>
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 ;-)<br>
<blockquote
cite="mid:CAEeTejLsgSsP5nAQ4q-tFOVoDUz8wjtWkOYntySADiN9=8r1pQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><br>
</div>
<div>(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:)</div>
</div>
</blockquote>
<br>
Ok., so the one person speaks English, the other one American? ;-)<br>
<br>
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.<br>
<br>
<blockquote
cite="mid:CAEeTejLsgSsP5nAQ4q-tFOVoDUz8wjtWkOYntySADiN9=8r1pQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><br>
</div>
<div>hence the semantics of ends are in the eye of the beholder
imho</div>
<div><br>
</div>
<div><br>
</div>
</div>
<div class="gmail_extra"><br>
</div>
</blockquote>
<br>
Or in the ear ;-) <br>
<br>
Absolutely. <br>
</body>
</html>