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@xxxxxxx]
Sent: Tue 12/2/2008 10:43 AM
To: Hallam-Baker, Phillip; ietf@xxxxxxxx
Subject: Re: Applications assume bilateral connections?
--On Tuesday, 02 December, 2008 07:04 -0800 "Hallam-Baker,
Phillip" <pbaker@xxxxxxxxxxxx> 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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf