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.
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), 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.
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.
As a former control engineer, I tend to consider any communication loop without
feedback as being inherently broken. 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.
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. In fact any distinction is a fault in my view.
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.
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.
The bigger limitation of the Internet is that it provides no mechanism for
clients, servers and infrastructure to advertise what is supported. We are
trapped in the same old TCP+UDP box. In fact the box is shrinking to port 80 +
443 and may well shrink to just 443.
If Google and Comcast both deploy such a technology, how do applications
discover that it exists and make use of it? That is the architectural gap that
needs to be filled and the one that we should be discussing. Solve that problem
and the apps area can make use of new transport area innovation.
-----Original Message-----
From: John C Klensin [mailto:john-ietf(_at_)jck(_dot_)com]
Sent: Tue 12/2/2008 10:43 AM
To: Hallam-Baker, Phillip; ietf(_at_)ietf(_dot_)org
Subject: Re: Applications assume bilateral connections?
--On Tuesday, 02 December, 2008 07:04 -0800 "Hallam-Baker,
Phillip" <pbaker(_at_)verisign(_dot_)com> wrote:
One of the topics that came up in the architectural debate is
that a few folk made statements of the form that application
developers assume that applications only engage in bilateral
communications. In fact one person went so far that
applications developers are not aware of the range of
applications protocols.
But more generally, some appear to have voiced the opinion
that the IETF transport area only serves the IETF applications
area, not the Internet application developer community which
is many, many times the size of the IETF.
No examples were given of these non-application application
protocols. So here is why there can only be bilateral
communications at the application layer.
...
Of course, there are a whole class of exceptions to this. There
are applications that perform minimal-effort notification or
database update functions that do not particularly care if the
notification gets through (i.e., can accept some data loss in
the process). I've worked on several such applications over the
years in which the consumer of the data needed only the most
recent values available and perhaps an indication of whether
recent data had been lost (easily accomplished with a simple
sequence number) or how recent the most recent available data
were (for which a time stamp is usually sufficient).
One set of examples for this involves remote sensors (sometimes
very remote, as in "in orbit") that are reporting on data that
are considered only statistically for other reasons.
Constructing, e.g., moving average models that can allow for
some missed data points is fairly straightforward and often
makes a lot more sense than trying to assure reliable
transmission or anything else that would require a bilateral
connection arrangement. While it is outside my personal
experience, I'd assume that sensors that deliver snapshots from
high-data-volume, high-data-rate experiments in physics would
have much the same properties, with the quantity and arrival
rate of the data overwhelming any possibility of bilateral
handshaking and the probability of some data loss being much
more acceptable than a lower sample rate.
In some cases, the transmitter at the sensor just broadcasts the
data on a known channel, with no information (including either
names or addresses) about who is going to receive it or how it
is going to be received. Certainly the receiver(s) need to
know the channel and the way in which the data are encoded, but
that doesn't involve the network in anything bilateral.
Or perhaps you are using "bilateral" in a way that I don't
understand.
john
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf