--On Tuesday, 02 December, 2008 08:52 -0800 "Hallam-Baker,
Phillip" <pbaker@xxxxxxxxxxxx> wrote:
> It was not clear from the context of the argument what was
> being referred to. Seemed more likely that they were imaging
> something involving more parties than bilateral. It was one of
> those 'well people only disagree with me because they are
> ignorant of an area that I will specify so vaguely a to make
> it impossible to refute the claim' type shots.
Then why did you initiate this conversation thread rather than
not wasting your/our time on it?
> As someone with significant experience of high bandwidth, high
> data rate physics experiments (My doctorate is on work I did
> on the ZEUS experiment at DESY in Hamburg),
That is why I mentioned that example.
> I would
> distinguish two classes of communication:
>
> 1) Sensor reading
> 2) Network communication
>
> Sensor reading is physics, not network engineering. Once you
> get past the initial sensor the communications become
> bilateral pretty quickly. Flow control becomes more critical,
> not less when you have a system of that size. And you have to
> take account of the fact that you have more than one event in
> the pipeline at the same time. Flow control may only be a
> single bit but it is bilateral communication.
As I indicated, I've got no experience with physics experiments.
I do have quite a bit (although years ago) with data from
meteorology and satellite observations) and the categories
above don't quite work. In those cases, at least in my
experience, the sensor is paired with a sampling arrangement and
a transmission device, and the transmission device is strictly
one-way, without acknowledgements and often without flow
control. The problem with even one-bit flow control is that it
requires data buffering and, at least in my time, there was
often a better use of resources than pairing buffering (or any
two-way protocol capability) with the sensor. Conversely, the
sensors themselves, and what they were measuring, could never be
considered 100% accurate or consistent, so any use of the data
at the far end of the link required smoothing or filtering and
it didn't make much difference whether what was smoothed or
filtered out were occasional erroneous (or sufficiently deviant)
measurements, errors in transmission, or dropped sets of
readings.
That approach obviously becomes a lot less useful in situations
in which one is trying to observe very rare events or when, to
paraphrase John Tukey, the residuals or rough are much more
important than the smoothed data themselves.
> A unilateral communication is simply a bilateral communication
> where only one party has something interesting to say. I don't
> see how it could be imputed to create a need for applications
> to concern themselves with IP header contents or have any
> other architectural consequences.
If you change that definition into "a bilateral communication
where only one party has anything at all to say", I could agree
with you, but it seems to me that such a communication is
tautologically not bilateral, especially when the sender simply
broadcasts with the expectation that someone might be listening
(a broadcast without that expectation takes down the path toward
trees falling in empty forests and I don't think anything would
be served by going there).
> As a former control engineer, I tend to consider any
> communication loop without feedback as being inherently
> broken.
I would have said that a communication loop without feedback is
not a communication loop. _Transmission_ mechanisms without
feedback can be designed so that the assumption of delivery
depends on design and statistical quality control mechanisms,
not feedback loops. All things being equal, they are less
desirable that loops with feedback, but sometimes things are not
equal.
> If a thing is worth saying then it is worth making
> sure that it is listened to. Sure there are communications
> media such as satellite that are inherently one-way. Such
> media require a completely different architectural approach if
> used alone.
And that was, I thought, the point that others were trying to
make.
> From the apps point of view I don't see why an application
> interface to a multicast stream should look any different from
> an application interface to a unicast stream.
At a network level, I tend to agree. But, if transmission-only
media require a different architectural approach, hiding that
approach from the receive-only application may or may be worth
the trouble and/or feasible. If the application wants any data
bundles/ bursts that arrive, together with any sequencing or
time stamp information that may be part of those bursts, the
question of what to do about the bursts that don't arrive (and
that must be presumed to have not been sent or lost in transit
depending on what information is in the bundle) is an
application problem, not a network one. I think that takes us
quickly into a debate about layering models that, while
interesting, probably would shed no light on the issue.
> In fact any distinction is a fault in my view.
Well, in an IP-like model, it implies that the application has
to receive the raw datagram stream since only it can have the
context and subject matter expertise to process the data and
interpret what is not delivered. That makes it quite different
from an application that runs over, e.g., TCP or even one that
works with UDP with reliability, packet reassembly, or flow
control extensions. The traditional Internet assumption that a
packet either arrives or is lost does not really apply because
information content depends on the stream, not just individual
packets. I don't know if that is a fault; it is certainly
somewhat different.
> One of the limitations of TCP/IP for apps developers is that
> it requires applications to merge control and data into a
> single channel. A better applications interface would allow
> these to be separated (c.f. DIME, BEEP etc) so you have a data
> channel paired with a (possibly lossy, possibly
> unidirectional) data channel.
That is an interesting comment given how recently people were
denouncing the one major application that separates control and
data channels as hopelessly outdated and generally hopeless.
> Then write a network stack that allows such a connection to be
> established and opportunistically make use of whatever network
> resources are available at each end.
>...
You are moving off into what I believe to be an entirely
different issue -- your theories about resource location in
network designs-- and that is one on which I have no desire to
comment.
john
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf