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