--On Tuesday, 02 December, 2008 08:52 -0800 "Hallam-Baker,
Phillip" <pbaker(_at_)verisign(_dot_)com> 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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf